The AI Governance Operating Model: Who Owns AI Risk?

The gap every AI framework leaves open

An AI governance operating model is the piece every framework assumes you already have. ISO 42001, NIST AI RMF, and the EU AI Act all agree on one point: AI risk has to be owned by a named human being, not by a process. But none of them spell out how to build the structure around that person. So most organisations skip it, and their governance collapses the moment something goes wrong.

Here is the pattern we keep running into. A company adopts an AI tool. Something breaks. The response is a scramble. Legal points at the product team, the product team points at procurement, procurement points at the vendor, and nobody can say who was accountable for the outcome. The frameworks are not vague on this point. ISO 42001 Clause 5.3 requires top management to assign and communicate roles, responsibilities, and authorities for the AI management system. NIST's AI Risk Management Framework makes accountability structures its GOVERN 1.2 subcategory. The EU AI Act's Article 4 puts a literacy obligation on every provider and deployer. The requirement to name names is everywhere. The practical operating model is the missing piece.

This post is that operating model. Six steps. Fill in the names and you have an accountability structure that survives a real incident, a regulator's question, and an enterprise buyer's due diligence.

There is also a timing reason to do this now. AI has moved from experiment to core business infrastructure, and the questions regulators and buyers ask are shifting from "do you have a policy" to "who is accountable when it fails." A named owner is the difference between a governance program that survives scrutiny and one that does not.

Step 1. Name one accountable executive

Start with a single name. Not a committee, not a slide that says responsibility is shared across the organisation. One executive who owns AI risk end to end, the same way a CFO owns financial risk and a CISO owns security risk.

ISO 42001 Clause 5.1 puts leadership and commitment first, and Clause 5.3 makes top management responsible for assigning those roles and making them known. That authority has to sit with someone who can actually change a budget, stop a deployment, and answer to the board. A data scientist given an "AI lead" title and no authority does not count.

Give this person three specific powers. The power to block a new AI deployment. The power to mandate a risk assessment before any tool goes live. The power to escalate straight to the board. Without those three, the title is decorative.

Step 2. Build a committee that can say no

The accountable executive needs a governance body with real decision rights. It does not need to be large. Four to six people is enough, but the seats matter more than the headcount.

A useful AI governance committee includes legal, information security, data or privacy, the business unit that uses the AI, and someone technical who understands the models. What kills these committees is not composition. It is a lack of decision rights. A committee that only advises will be ignored. A committee that approves gets a seat at the table.

Keep a separate working group for the operational detail. The committee decides, the working group prepares. When the two roles blur, the committee drowns in spreadsheets and stops making decisions.

Write down which decisions the committee makes. Approving new AI use cases. Signing off risk assessments. Approving high risk deployments. Reviewing incident reports. That list is your terms of reference, and it should be a written document, not a slide deck.

Step 3. Build a RACI for the six decisions that matter

Most teams skip this step and regret it. A RACI matrix assigns, for each decision, who is Responsible, Accountable, Consulted, and Informed. It turns "someone should handle this" into a specific name. The Accountable column is the one that matters most, because it is the single name that owns the outcome.

Six decisions cover most of what goes wrong with AI in practice.

• Approving a new AI system. Accountable: the AI executive. Responsible: the requesting business unit. Consulted: legal and security.
• Signing off the AI risk assessment. Accountable: the AI executive. Responsible: the risk owner. Consulted: the vendor or model owner.
• Approving a high risk or high impact deployment. Accountable: the AI executive, with board escalation for anything that touches people's legal rights or safety.
• Responding to an AI incident. Accountable: the AI executive. Responsible: incident response. Consulted: legal and communications.
• Approving a material model change. Accountable: the AI executive. Responsible: the model owner. This is where silent model updates get caught.
• Retiring or decommissioning an AI system. Accountable: the AI executive. Responsible: the business owner.

Put these six rows on one page and fill in actual names. If any cell is empty, you have found your accountability gap before it finds you.

These six decisions map directly onto the risk process in the standards. ISO 42001 Clause 6.1.4 requires an AI system impact assessment before a system goes live, and the accountable name on that assessment is the name a future audit will ask for. When the RACI and the risk assessment disagree about who owns the outcome, fix the RACI first.

Step 4. Set escalation triggers, not just a reporting cadence

Boards do not need a monthly AI update. They need to know when something crosses a line. Define the triggers that force an escalation, then set the cadence for routine reporting separately.

Escalation triggers worth writing down: a high severity incident, a regulator inquiry, a material model change, a bias or discrimination finding, a data breach involving AI training data. Each of these should have a defined path to the board within a set number of days, not "when the next meeting happens."

For routine reporting, quarterly is enough for most organisations. The report should cover three things: what AI is in production, what risks changed, and what decisions are coming up. If the report runs longer than a page, it is being written for the wrong audience.

Step 5. Stand up AI literacy, not a training video

The EU AI Act's Article 4 requires providers and deployers to ensure, to their best extent, a sufficient level of AI literacy among staff and anyone operating or using the systems. That has been a live legal obligation in the EU since February 2025, and it is becoming the benchmark buyers and regulators apply everywhere else.

AI literacy is not a one hour module everyone clicks through in December. It is role specific. Your risk team needs to understand impact assessments. Your support team needs to know when to escalate a model behaving oddly. Your leadership needs enough literacy to ask useful questions. Map the requirement to the role, the way you already map security awareness training.

ISO 42001 Clause 7.2 makes competence a requirement and asks organisations to determine, provide, and evaluate the competence of the people doing AI work. Document who needs what, how they get it, and how you verify it.

Step 6. Write it down and connect it to the system registry

An operating model nobody can find does not exist. ISO 42001 Clause 7.5 requires documented information, and a real AI management system ties the accountability structure to the inventory of systems it governs.

If you do not have an AI system registry yet, that is the place to start. Each system in the registry should carry the name of its accountable owner and its risk rating. When a buyer or a regulator asks who owns this system, the answer should be one lookup away, not a week of email.

ISO 42001 Clause 7.4 requires the organisation to determine what it communicates, internally and externally, about the AI management system. For an operating model that means three audiences. Staff need to know who owns what. The board needs the escalation triggers. Buyers and regulators need to see that a named owner exists and can be pointed to.

The three ways this becomes governance theater

There are three ways this framework gets built for show instead of for use, and they are all worth naming out loud.

First, the accountable executive has the title but not the authority. If they cannot stop a deployment, you have a figurehead, not an owner.

Second, the committee exists but never says no. A governance body that approves everything has decided nothing. If you cannot remember the last time it blocked something, it is not doing its job.

Third, the RACI lives in a drawer. The test is simple: during your next incident, does anyone consult it? If not, it is decoration.

What enterprise buyers actually check

If you sell AI, this operating model is also a sales asset. Enterprise buyers have learned that a responsible AI page with no named owner is marketing. The first week of due diligence now includes a specific question: who is accountable for AI risk in your organisation, and can you show us the structure?

Vendors who can name an accountable executive and produce a documented governance structure answer that question in minutes. Vendors who cannot spend weeks trying to find someone. That delay is real friction, and it is exactly the kind of friction that turns a promising deal into silence. This is the difference between a static certificate on a wall and a governance program someone can actually verify.

Where independent verification fits

A documented operating model is necessary, but it is still self attested. The next question a sceptical buyer asks is: how do I know this structure is real and not a slide? That is where independent assessment changes the conversation. A live verification signal, showing that a third party checked the governance structure rather than just reading the policy, is the difference between "trust us" and "check for yourself."

Build the operating model first. It is the foundation. Verification is what makes the foundation visible to people who cannot walk your halls.

If you are adopting AI and want a head start on this structure, see what a real assessment looks like, or talk to us about standing one up. And if you are a vendor, ask yourself whether your trust signal says "we own this" or just "we wrote a policy."

Written by David Swan, reviewed and fact-checked against primary regulatory sources. AI-assisted but human-directed.

Related reading

AI Hiring Tools: The Discrimination Gap Bias Audits Miss

SOC 2 Is Not Enough for AI: What Buyers Check in 2026

Australia AI Regulation 2026: From Guardrails to Standards