Ask a governance lead how their program is going and you will often hear about the framework. It has principles, a risk taxonomy, a lifecycle diagram, and a policy set. It was reviewed by legal and approved by a steering group. It is also, six months later, not visibly changing what engineering ships.
This is the normal failure, and it is not a failure of the framework. It is the absence of an operating model: the machinery that turns a document into decisions. A framework says risk assessments are required. An operating model says who performs one, who reviews it, who can refuse to proceed on the strength of it, what happens when they do, and where the record lives afterwards. Without that second layer, the policy is advice.
If you have not written the framework yet, start with our guide to building an enterprise AI governance framework. This article assumes the framework exists and asks the harder question: what has to be true for anyone to follow it.
Why frameworks stall
Across the programs we see, three causes account for most of the stalling, and none of them are about the quality of the policy.
No decision owner. The policy says high-risk systems require additional review. It does not say who conducts it, so the question circulates. Engineering assumes risk owns it, risk assumes legal owns it, legal assumes the product owner owns it. The system ships because shipping is the default and nobody was accountable for the alternative.
A forum with no teeth. An AI governance committee meets monthly, reviews a paper, and records a view. It has no authority to withhold a release and no budget of its own. Attendance drops. Within two quarters it has become a reporting channel, which is a useful thing but not a control.
Gates that produce opinions. A review happens, someone is broadly comfortable, work proceeds. Twelve months later an auditor asks what was assessed and by whom. There is a calendar invite and a recollection. The control existed and left no trace, which for evidentiary purposes is close to the control not existing.
Each of these is an operating-model defect. The fix is structural rather than editorial.
The three lines, applied honestly
The three lines model is familiar from financial services and is often invoked for AI without being applied. The pattern is simple: the first line owns and runs the activity, the second line sets policy and challenges the first, the third line independently assures that the first two work. The academic treatment in Three lines of defense against risks from AI is a useful adaptation to this domain.
| Line | Who, typically | Owns | Common corruption |
|---|---|---|---|
| First | Product owner, ML engineering, the deploying business unit | Building it, documenting it, running it, monitoring it, raising incidents | Treats governance as a form to clear rather than a property of the system |
| Second | Risk, compliance, privacy, security, the AI governance function | Policy, standards, risk assessment methodology, challenge, sign-off on higher-risk cases | Drifts into doing the first line's work, then cannot credibly challenge it |
| Third | Internal audit, or an external assessor | Independent assurance that the first two lines operate as described | Audits the policy rather than sampling the evidence the gates produced |
The corruption in the second row is the one worth guarding. A small governance team under delivery pressure starts writing the risk assessments rather than reviewing them, because writing is faster than teaching. It feels like progress. It quietly removes the challenge function, because nobody credibly challenges their own work. If your governance function is authoring first-line artefacts, you have two lines, not three, and the third line will eventually say so.
The forum: mandate before membership
Most committee designs start with who attends. Start instead with what it can decide, because that determines who needs to be there.
A governance forum worth convening can do at least three things: approve or refuse a use case at defined risk thresholds, require specific conditions before deployment and verify they were met, and suspend a system already in production. If it cannot do the third, it is an advisory body. That is a legitimate thing to have, but call it that, and place the real authority somewhere explicit.
Practical settings that tend to work:
- Chair with delegated authority. Someone senior enough that a refusal holds, usually via written delegation from an executive committee.
- Standing members with domain veto. Privacy, security, and legal each hold a veto in their own domain rather than a vote on the whole. This prevents a technical majority from outvoting a legal blocker.
- Quorum that includes challenge. A quorum with only first-line attendees is not a review.
- Escalation path with a clock. Refusals get appealed. Say to whom, and by when, or the appeal becomes the informal decision route.
- Explicit thresholds for what never reaches it. A forum that reviews everything reviews nothing carefully.
Decision rights, written down
This is the artefact most programs are missing. It is one table, and it settles arguments before they happen.
| Decision | Proposes | Reviews | Decides | Can veto |
|---|---|---|---|---|
| New AI use case may proceed to build | Business sponsor | AI governance function | Sponsor, within risk tier | Privacy, security, legal in domain |
| Risk tier assigned to a use case | AI governance function | Second line peers | Head of AI governance | None, appealable to the forum |
| High-risk system may deploy | Product owner | Second line, with evidence pack | Governance forum | Any standing member in domain |
| Material model change may ship | ML engineering | AI governance function | Product owner, within change policy | Second line above a defined impact |
| Third-party AI system may be procured | Procurement | Second line plus security | Governance forum above a threshold | Security, privacy, legal |
| Production system must be suspended | Anyone | None, act first | Named on-call decision owner | Not applicable |
Two things about that last row. Suspension has to be executable by one person without a meeting, because incidents do not wait for quorum. And the right to raise has to sit with anyone, including the engineer who noticed. Restricting who may pull the handle is how organisations discover a problem late.
Gates across the lifecycle
Governance becomes real at the points where work cannot continue until something is satisfied. Keep the number small, and define each by the artefact it produces rather than the meeting it requires.
Escalation and the incident path
An operating model needs a route for the case where something has already gone wrong, and that route has legal timings attached to it. Under the EU AI Act, a deployer that identifies a serious incident must inform the provider first, then the importer or distributor and the relevant market surveillance authority, while the reporting duty to authorities sits with the provider. The clock is short and graduated. Design the internal escalation so it can meet the tightest of those deadlines rather than the most comfortable one. We cover the mechanics, including the two, ten, and fifteen day paths, in AI incident response and reporting.
The operating-model requirement is narrow: a single reporting channel that anyone can use, a named on-call owner who can suspend a system, and a triage step that establishes within hours whether a regulatory clock has started. Organisations that route AI incidents through a general IT service desk usually discover the clock late.
AI literacy as an input, not a checkbox
Since 2 February 2025, Article 4 of the EU AI Act has required providers and deployers to take measures ensuring a sufficient level of AI literacy among staff and others operating their systems on their behalf. Two features of that obligation are routinely missed. It reaches beyond employees to contractors and service providers who use the system for you. And it is outcome-based: no format or certificate is prescribed, which means a completed course does not by itself discharge it.
No direct fine attaches to Article 4 itself, which has led some teams to deprioritise it. That reads the risk too narrowly. From August 2025 the penalty provisions bite elsewhere, and inadequately prepared staff operating a system is a plausible route to harm and to liability.
Treated as an operating-model input rather than a training campaign, literacy becomes specific: the people at each gate need the competence that gate assumes. A reviewer assessing fairness measurement needs to read a disparity table. A product owner accepting a risk needs to understand what they are accepting. Map competence to gate, then close the gaps you find.
Evidence, by design
The test of an operating model is what it can show a year later. For each gate, decide in advance what artefact it produces, where that artefact lives, who can attest to it, and how long it is kept. Then check that producing it is the natural consequence of doing the work rather than a separate write-up, because anything requiring a separate write-up decays.
The regulatory instruments converge here. ISO/IEC 42001 is built around documented information and management review. The NIST AI RMF GOVERN function is about accountability structures and their records. The EU AI Act's high-risk regime turns on technical documentation and logging. A gate that leaves a record satisfies all three at once. A gate that leaves a recollection satisfies none.
Anti-patterns worth naming
- The advisory committee with a governance name. If it cannot stop anything, it is not the control. Find where the authority actually sits and document that instead.
- The inventory nobody owns. A spreadsheet updated during an audit is a snapshot, not a register. Ownership and a refresh mechanism are what make it a control.
- Governance as a release blocker of last resort. If the first contact with governance is the week before launch, every interaction is adversarial. Move the contact to intake.
- One tier for everything. Applying high-risk process to a document summariser trains the organisation to route around you.
- Second line drafting first-line artefacts. Fast in the short run, and it removes the challenge function.
- A policy that no gate enforces. Every clause should be traceable to a gate, or be honestly labelled as guidance.
A 30, 60, 90 sequence
If you are starting with a framework and no machinery, this order tends to work because each step makes the next one possible.
| Window | Do | Done looks like |
|---|---|---|
| First 30 days | Write the decision rights table. Name one accountable owner per decision. Stand up intake and start the inventory. Identify who can suspend a system today. | A one-page table your executive sponsor has signed, and a register with real entries |
| Days 30 to 60 | Charter the forum with explicit authority including suspension. Define risk tiers and the thresholds that route cases. Build the pre-deployment evidence pack template. | A charter, a tiering rule anyone can apply, and one use case taken through the gate end to end |
| Days 60 to 90 | Wire change control to material model change. Set the review cadence per tier. Map competence to gate and close the worst gaps. Ask internal audit to sample your evidence. | An audit sample that finds records rather than recollections |
The last item is the real test, and it is worth inviting early. A third-line sample at day 90, when the stakes are low and the finding is cheap, tells you whether you built a control or a ritual.
Frequently Asked Questions
Where should AI governance report?
There is no universally right answer, and the trade-offs are real. Under risk or compliance, independence is easy and engineering credibility is hard. Under engineering, the reverse. Under legal, the function tends to become advisory. What matters more than the box is whether the function has a written mandate, a route to an executive who will back a refusal, and enough technical literacy to review rather than accept. Pick the reporting line that gives you those three, then compensate deliberately for its weakness.
How is this different from the governance framework itself?
The framework states what good looks like: principles, risk categories, required controls. The operating model states who does it: decision rights, the forum and its authority, the gates, the artefacts, the escalation path. Frameworks are portable between organisations. Operating models are not, because they depend on your structure, your delivery process, and who will actually back a refusal.
Do we need a dedicated AI governance committee, or can an existing forum absorb it?
An existing risk or technology forum can absorb it, and often should, because a new committee competes for the same attention. Two conditions apply. The agenda needs protected time rather than a standing last item, and the membership needs the specific competence AI decisions require, particularly on data provenance and on measuring model behaviour. If neither is achievable, a dedicated forum with a narrow remit is the better option.
What is the minimum viable operating model for a small organisation?
A decision rights table naming real people, an inventory with an owner, one pre-deployment gate that produces an evidence pack, and a named person who can switch a system off. That is genuinely enough to start, and it is more than many large programs can demonstrate. Add tiers and a forum when the volume of cases makes case-by-case handling impractical.
How do we govern AI we bought rather than built?
The same gates apply, with the evidence coming from the vendor instead of your engineers, which means procurement becomes a governance control rather than a purchasing step. Deployer duties do not transfer with the purchase: under the EU AI Act a deployer carries its own obligations regardless of who built the system. See third-party and AI vendor risk assessment for the questions and the contract terms that make vendor evidence obtainable.
How often should the operating model itself be reviewed?
Annually as a floor, and on three triggers: a change in the regulatory perimeter that affects your systems, a material incident, and a shift in how your organisation builds AI, of which the move to agentic systems is the current example. Agents break assumptions that single-decision models did not, because the unit of governance stops being a prediction and becomes a sequence of actions.
