AI risk rarely sits inside one function. Security sees access and attack paths. Legal sees obligations. Data teams see provenance. Product teams see speed. The board sees an enterprise decision, but too often nobody can name the person who owns the whole outcome.
Key takeaways
- Distributed work does not require distributed accountability.
- Every material AI use case needs one accountable executive and named control owners.
- A governance forum should make decisions, not merely receive updates.
- Evidence should show that controls work in practice, not only that a policy exists.
The ownership gap appears before the technology fails.
Most organisations do not have an AI awareness problem. They have an accountability design problem. A new use case moves from experimentation to a business workflow while responsibility remains split between teams that each own only one part of the risk.
The result is predictable: security reviews the connection, privacy reviews the data, procurement reviews the supplier, and the business sponsor assumes those reviews amount to approval. They do not. They are inputs to a decision that still needs an owner.
Shared activity is not shared accountability.
Collaboration is essential, but collective responsibility can become a polite way of saying no one has authority to stop, change or accept the use case. The board should be able to ask one simple question: who is accountable for the outcome if this system behaves differently from what we expect?
Accountability is the named authority to make a decision, accept its consequences and require evidence that the decision remains sound.
A workable AI accountability model has four distinct roles.
Keep the model small enough to use. It should make authority visible without turning every experiment into a committee process.
Accountable executive
Owns the business outcome, material risk decision and conditions under which the use case may operate.
Use-case owner
Maintains the workflow, user behaviour, expected benefits and operating documentation.
Control owners
Operate the security, privacy, legal, data and supplier controls that support the decision.
Independent challenge
Tests whether assumptions and evidence are strong enough for the level of exposure.
What the board needs to see
| Decision | Named owner | Minimum evidence |
|---|---|---|
| Approve the use case | Accountable executive | Purpose, impact and residual risk |
| Release into production | Use-case owner | Testing, controls and rollback path |
| Accept an exception | Accountable executive | Expiry date and compensating controls |
| Continue operation | Accountable executive | Performance, incidents and control health |
One owner does not mean one team does all the work.
The executive owner makes the decision. Specialists produce evidence and operate controls. The distinction prevents technical teams from silently carrying business risk they do not have authority to accept.
Build governance into the pace of the work.
A quarterly forum cannot govern weekly releases. The cadence should match the rate at which the use case, model, data and supplier dependencies change.
- 01
Intake
Record the intended outcome, affected people, data, model dependency and accountable executive before build begins.
- 02
Decision
Set approval conditions in language teams can implement and reviewers can later test.
- 03
Operation
Monitor behaviour, incidents, overrides and changes to the assumptions behind approval.
- 04
Reassessment
Trigger a fresh decision when the purpose, model, data, audience or exposure materially changes.
Evidence should make the decision independently checkable.
Policies are useful declarations of intent. Boards also need operating evidence: artefacts that demonstrate how a decision was made, how conditions were implemented and whether controls continue to perform.
Use a small evidence set consistently.
- Decision recordThe owner, date, scope, conditions and residual risk accepted.
- System recordModel, data, integration, supplier and material change history.
- Control recordTest results, exceptions, monitoring outcomes and unresolved actions.
- Human recordWho may approve, override, investigate, suspend and restore the system.
This is enough to start. The aim is not a larger document library; it is a reliable chain from intent to decision to operating proof.
What to do in the first 30 days.
Begin with the most consequential live use cases, not a theoretical enterprise inventory that takes months to complete.
Name the decisions
Select five material use cases and identify the decisions that allow each to operate.
Name the owners
Assign one accountable executive and the control owners who produce evidence.
Test the evidence
Ask an independent reviewer to reconstruct why the use case is allowed to continue.
Close the gaps
Prioritise missing authority, expiry dates, monitoring and escalation paths.
Make ownership visible before the next decision.
AI governance becomes practical when the organisation can name who decides, what evidence supports that decision and what would cause it to change. The technology may be distributed across teams. Accountability cannot be.