"Who owns AI risk here?" is a question that reliably produces a long meeting and no decision. That is not because it is hard. It is because three different responsibilities travel under one name, and people arguing about the answer are usually answering different questions.
Separate them and it gets much easier.
The three things
| Responsibility | The question it answers | Who holds it |
|---|---|---|
| System ownership | Is this system behaving acceptably? | Whoever already owns the business process it takes part in |
| Coordination | Do we know what we have, and does it meet a standard? | One named person, with authority to stop things |
| Executive accountability | Is our overall exposure acceptable to the board? | An executive who already owns risk |
1. System ownership belongs to the process, not to IT
The default instinct is to give every AI system to IT, because AI is technology. This is almost always wrong, and it fails in a specific way.
If a screening tool is producing bad hiring outcomes, IT cannot tell. They can tell you it is up, that it is fast, that the vendor is responsive. They cannot tell you whether the candidates it rejected should have been rejected, because that is not a question about the system — it is a question about hiring.
So: IT owns the platform. The function owns the decision. The hiring team owns the screening tool's outcomes. The benefits team owns the eligibility model. The permitting team owns the scoring rule. Whoever was accountable for the decision before it was automated is still accountable for it afterwards, and automation should never be the moment that ownership quietly moves.
This is worth saying out loud during deployment, because the drift is subtle: a function adopts a tool, the tool comes from IT, and within a quarter everyone believes IT owns the outcomes.
2. Coordination needs exactly one name
Somebody has to hold the things no single system owner can: the inventory, the standard that systems are assessed against, the escalation path, and the answer when a board or a regulator asks what AI the organisation uses.
This is the role most organisations are missing, and the one worth naming first. Two things matter about who fills it, and job title is not one of them.
They must be able to say no
A coordinator who can advise but not stop a deployment is a documentation function. When the pressure is on — the tool is bought, the launch date is set, the executive sponsor is keen — the ability to refuse is the entire value of the role.
If you cannot give them that authority, be honest that you are creating a reporting function rather than a governance one, and do not later blame them for what shipped.
Watch where they report
If the coordinator reports to the executive whose budget depends on the deployment going ahead, the conflict is structural. It will not be solved by hiring a person with integrity; it will be solved by them losing arguments and eventually leaving.
Reporting to legal, compliance, risk, or directly to the chief executive all work. Reporting to the function that most wants to deploy does not.
3. Executive accountability sits with someone who already owns risk
Somebody at executive level answers for whether the organisation's overall AI exposure is acceptable. In practice this is rarely a new person — it is whoever already owns enterprise risk, and AI becomes another category in an existing conversation.
The failure here is diffusion. "The executive team is collectively accountable" means nobody is, and it becomes visible only during an incident, when the question is asked and everybody looks at somebody else.
Do you need a Chief AI Officer?
Probably not, and the evidence usually cited for it does not say what people think it says.
US federal agencies are required to designate a Chief AI Officer — OMB M-25-21 sets that deadline at 60 days from the memorandum's issuance, alongside an AI Governance Board within 90 days. That is a requirement placed on federal agencies by their own executive branch. It is evidence that agencies must have the role. It is not evidence that a 200-person business must.
The federal model is still instructive, though, and the instructive part is the pairing: a named officer and a governance body and an inventory and tiered controls for high-impact uses. The role is a coordination point within a structure, not a person appointed to be responsible in the abstract.
The way this goes wrong in the private sector is appointing a Chief AI Officer without any of the surrounding structure or authority. That produces someone accountable for outcomes they cannot influence — a worse position than having nobody, because it creates the appearance of governance and absorbs the pressure that would otherwise have produced the real thing.
What this looks like at different sizes
Under about 50 people
One named coordinator, almost certainly part-time, probably whoever already handles compliance, security or operations. Executive accountability sits with the chief executive because it sits with them for everything. System ownership goes to whoever runs the relevant function. Do not create a role.
50 to 500
A named coordinator with explicit authority to stop a deployment, reporting outside the function that deploys most. A small cross-functional group they can convene rather than a standing committee. Executive accountability with whoever owns enterprise risk. See how to stand up an AI governance committee, which is written for exactly this size.
Larger, or heavily regulated
A dedicated coordination role becomes defensible, and the surrounding structure becomes necessary rather than optional: a governance body with decision rights, documented standards by risk tier, and reporting into an existing risk committee.
The test that matters
Ownership is not settled by the org chart. Two questions settle it:
- Has anything ever been refused or materially changed because of this structure? If not, the structure is decorative.
- When something goes wrong, can you name who was accountable and what they were meant to have checked? If the answer is a committee name, ownership does not exist yet.
A third, less comfortable: is the person who refused something still in the role? Governance functions that lose every argument do not stay staffed, and the departure is usually recorded as a personnel matter rather than as the governance failure it is.
For the wider structure this sits inside, see AI governance. For the control that most often depends on clear ownership, see human oversight that is more than a rubber stamp.