Ask ten institutions who approves a high-risk model for production and you get ten different answers, half of them wrong and most of them uncertain. That uncertainty is the operating model failing. A control set with no clear owner is a control set that stalls at the first hard decision, and AI produces hard decisions on a schedule.
The operating model is the human architecture: who decides, who does the work, who must be consulted, who gets told. Get it right and the crosswalk from the last article becomes a living process. Get it wrong and every model launch becomes a negotiation. This article gives you a structure grounded in CGEIT and COBIT, a decision-rights map you can adapt, and the three failure patterns to design against.
§ 3.1Three lines, one accountability
Borrow the three-lines model from risk management, because your regulators already think in it and because it works.
- First line owns the AI. Product teams, data scientists and the architects who build and run models. They own the risk they create and the controls embedded in their work.
- Second line oversees. Model risk, AI risk, compliance and the governance function. They set standards, challenge, validate independently and can say no.
- Third line assures. Internal audit, testing whether the first two lines actually do what they claim, and reporting to the board and audit committee.
The common mistake is putting the AI governance function in the first line, inside the team that builds models, because that is where the expertise sits. Do that and you have lost independence before you start. The people who build cannot be the people who independently challenge. Keep the expertise close and the reporting line separate.
Design rule
Independence is structural, not personal. It does not matter how rigorous your lead data scientist is if they both build the model and approve it. Effective challenge requires that the challenger's incentives, reporting line and mandate are separate from the builder's. Draw that line on the org chart before you draw it in a policy.
§ 3.2The committee structure
Committees are where governance either happens or performs. Keep the structure lean. Most institutions need three tiers and no more.
| Body | Mandate | Cadence | Decides |
|---|---|---|---|
| Board / Risk Committee | Sets AI risk appetite; owns ultimate accountability; approves the policy | Quarterly | Appetite, policy, material exceptions, incident escalations |
| AI Governance Committee (exec) | Cross-functional: risk, tech, legal, business, data. Runs the program | Monthly | High-risk model approvals, standards, exception rulings |
| Model Review / Working group | Technical review, validation triage, tiering decisions | Weekly / on demand | Tiering, validation scope, medium-risk approvals |
Push decisions to the lowest tier that can safely make them. If the executive committee approves every low-risk forecasting model, it will meet for four hours and rubber-stamp, which is theatre. Reserve the committee's attention for high-risk models, novel use cases and exceptions. Everything else clears at the working group under delegated authority with the committee informed.
§ 3.3Decision rights: the AI RACI
Committees describe where people meet. Decision rights describe who actually decides, which is the question that stalls programs. Map it explicitly. Below is a decision-rights table for the model lifecycle. Adapt the roles to your titles; keep the discipline of a single accountable owner per decision.
| Decision | Product / 1st line | Model Risk / 2nd line | AI Gov Committee | Business owner |
|---|---|---|---|---|
| Assign risk tier | R | A | I | C |
| Approve data sources | R | A | I | C |
| Validate (independent) | C | A / R | I | I |
| Approve high-risk to prod | R | C | A | C |
| Approve medium-risk to prod | R | A | I | C |
| Grant a control exception | R | C | A | C |
| Retire / roll back a model | R | C | I | A |
Two rules make this work. Every row has exactly one A. And the A for approving a high-risk model to production is never the same person as the R who built it. Violate either rule and you have reintroduced the independence problem the whole structure exists to solve.
§ 3.4Two rulebooks, one structure
US enterprise
SR 11-7 already gives you the vocabulary: model owners, independent validation, effective challenge, board oversight. Extend the existing model risk committee to cover AI rather than building a parallel body. Where AI differs from traditional models is monitoring frequency and the pace of change; the committee cadence for AI models often needs to be tighter than for a quarterly-recalibrated regression.
GCC / MENA
SAMA and the CBUAE expect named senior accountability and, frequently, a designated executive answerable for AI. Sharia governance adds a body in Islamic institutions whose sign-off may be required for products that use AI in structuring or pricing. Map the Sharia board into the decision rights explicitly rather than treating it as an afterthought at launch.
§ 3.5The three failure patterns
Design against these directly, because every stalled program I have seen exhibits at least one.
The committee that cannot say no
If a committee has never rejected a model, it is not governing, it is approving. Build in the expectation of rejection: a clear standard, an escalation path, and cover for the person who blocks a launch. A governance function without the authority and the incentive to say no is decoration.
The bottleneck
If every model waits weeks for a monthly committee, teams route around governance. Delegated authority and risk tiering are the release valve. Let low and medium risk clear fast so the committee's scarce attention goes to what is genuinely consequential.
The orphan model
A model with no named owner is a model no one monitors, updates or answers for. Make ownership a gate: no owner, no deployment. This is the same control from AG-01, now enforced through the operating model rather than the pipeline. Both should carry it.
Worked example
An insurer stood up an AI governance committee that met monthly and approved everything, because rejecting a launch meant a business head escalated to the CEO and the committee had no cover. Nothing was ever governed. The fix was two changes: the board set an explicit risk appetite that gave the committee a standard to enforce, and exceptions above appetite required board-level sign-off, which moved the escalation pain to the business rather than the governance function. Rejections started the following quarter.
The operating model decides who governs. The next article decides where governance meets the build: how to wire AI controls into the architecture function itself, through the TOGAF ADM, so that governance is a step in delivery rather than a gate bolted onto the end.
Use three lines of defense. Never place the AI governance function inside the team that builds models; independence is structural, not personal.
Three committee tiers are enough: board for appetite, executive committee for high-risk and standards, working group for tiering and routine approvals.
Map decision rights explicitly. One accountable owner per decision, and the approver of a high-risk model is never its builder.
Extend existing structures. In the US, grow the SR 11-7 model risk committee; in the GCC, map named senior accountability and Sharia governance into the decision rights.
Design against three failures: the committee that cannot say no, the bottleneck, and the orphan model.