Enter once, for the organisation as a whole. Go as deep as your organisation letter, and implement in your mode.
Why it exists
Decide who decides, before the first deployment. The most common failure in AI adoption is not technical; it is the quiet diffusion of responsibility, in which everyone assumed someone else was accountable — the vendor, the IT department, or the model itself — and no one was. Responsibility that is not pinned to a named person migrates, and it migrates toward whoever cannot be held to account. Pin it before it moves.
What to actually do
Map the stakeholders of each AI system before you assign responsibilities. List who has a stake in the system: inside the organisation, the business owner, the people who operate it, security, privacy, legal, human resources, and procurement; outside it, the provider, the customers and individuals the system affects, the regulators who oversee your sector, and — where the system’s reach is broad — the communities its outputs touch, including concerns of inclusion, misinformation, and environmental cost. You map them for one reason: so that no affected party is discovered for the first time during an incident.
Name one accountable owner per AI system, and make it a business owner, not a technologist. Every AI system in your inventory carries a named person — the AI Owner — who answers for what the system is for, whether its outcomes are fair to the people they affect, and when a human must intervene in its decisions. This person owns the purpose, not the plumbing. A system without a named owner is not merely an administrative gap; treat it as one of your leading risk indicators, because it is the precondition of every other failure in this domain.
Separate the person who wants the system live from the person who certifies it is safe to go live. Keep the AI Owner (the business accountability just described) distinct from the Technology Owner — the person responsible for the system’s technical soundness, its resilience, and its maintenance over time. In smaller organisations the temptation is to fuse both into one head. Resist it: the fusion hides a conflict of interest at exactly the moment it matters most, the go-live decision, where the desire to launch and the duty to withhold approval sit in the same chair.
Scale the roles to your size — combine hats, never delete them. In a mid-size organisation one person may legitimately hold several of these roles; in a large one they separate into dedicated functions — a governance lead, owners per system, a technology lead, an independent security reviewer. What this framework fixes is the set of accountabilities, not the headcount. Every accountability must exist and be assigned, even when several are worn by the same person; what may never happen is that one of them exists in no one.
Put it in writing that accountability cannot be delegated to the provider. Buying a model or a service from a third party transfers work; it does not transfer accountability for the impact of that system on your customers, your staff, and your obligations. Write this into the policy and into the responsibility matrix, because in its absence, “the vendor’s model did it” becomes the default defence — and it is a defence that fails in front of every regulator and every court.
Give the security function an independent challenge role. Assign, to a function separate from the team that builds or buys the system, the standing duty to challenge it: to model how it could be attacked, to test it adversarially, and to assess its impact on people’s rights before it goes live. The builders cannot be their own challengers; independence here is not distrust of colleagues, it is the structural guarantee that someone is paid to find the problems before an attacker or a regulator does.
Controls
Baseline2 controls
Control 9
Name an AI Owner for every system in the inventory.
BaselinePreventiveall rolesthe whole organisation
What it is
One accountable person per system, with the no-owner condition tracked as a key risk indicator.
How to implement it · Minimum content
Owner per system: name and role of a business owner, not a technologist or the provider
What they answer for: the system's purpose, fairness of its outcomes, and when a human must intervene
Named deputy for absences
Date assigned and the owner's written acknowledgement
Key risk indicator: number of systems with no owner, reported to management monthly
Reassignment when the owner leaves or changes role
How to start
Add an AI Owner column to the inventory, fill it for every system, and ask each person named to confirm in writing.
Evidence
The inventory with owners filled in and the history of the no-owner indicator.
Mode: light / standard / full
light
The owner-manager names the owner of each tool in the inventory spreadsheet and holds any system left unassigned.
standard
Business managers own their systems and the AI lead reports the no-owner count to management.
full
Ownership is a mandatory field in the configuration register and the no-owner count feeds the risk dashboard automatically.
Control 10
Define the escalation path for AI decisions and incidents.
BaselineCorrectiveall rolesthe whole organisation
What it is
Everyone who operates or oversees AI knows where a concern goes and who can stop a system.
How to implement it · Minimum structure
What to escalate: harmful or wrong outputs, data exposure, suspected misuse, complaints, breaches of red lines
First contact: the system's AI Owner; next level: named manager or committee
Who can suspend or stop a system, and how quickly (e.g. the same day)
Contact channel and expected response time for each level
How each escalation and its outcome is recorded
One-page summary sent to everyone who operates or oversees AI
How to start
Write one page that answers “who do I tell, and who can switch it off?” and send it to everyone who uses or oversees AI.
Evidence
The published escalation path and the log of escalations handled.
Mode: light / standard / full
light
Every concern goes straight to the owner-manager, who can switch off any tool; a shared email inbox records them.
standard
AI Owners handle first-level concerns and escalate to the AI lead, who holds the authority to suspend.
full
Escalations run through the incident-management process, with defined levels, response times and a documented suspension authority.
Enhanced3 controls
Control 11
Maintain a stakeholder map per AI system, covering internal and external parties.
EnhancedPreventiveall rolesthe whole organisation
What it is
Reviewed when the system’s scope or reach changes.
How to implement it · Minimum content
Internal parties: business owner, operators, security, privacy, legal, HR, procurement
External parties: provider, customers and individuals affected, sector regulators
Wider reach where relevant: communities touched, inclusion, misinformation and environmental-cost concerns
For each party: how the system affects them and their main concern
How each party is consulted or informed, and the contact
Review date, and review whenever the system's scope or reach changes
How to start
For the system that affects the most people, hold a 30-minute session with its AI Owner and list everyone inside and outside the organisation who has a stake in it.
Evidence
The dated stakeholder maps and their review history.
Mode: light / standard / full
light
The AI Owner keeps a short table per system in the inventory spreadsheet.
standard
A common template is used and the map is checked at each approval and scope change.
full
Maps are held with the system record, reviewed by the governance function and used to plan consultation for high-risk systems.
Control 12
Maintain a responsibility matrix across the AI lifecycle.
EnhancedPreventiveall rolesthe whole organisation
What it is
For each stage — from request to retirement — record who is responsible for doing the work, who is accountable for the outcome, who must be consulted, and who must be informed; this is what makes diffusion of responsibility visible before it does harm.
Columns: AI Owner, Technology Owner, security, privacy, legal, HR, procurement, provider, committee or management
Each cell: responsible (does the work), accountable, consulted or informed
Exactly one accountable person per stage; no stage without one
Explicit line: accountability for impact stays with the organisation, never with the provider
Version, approval and review whenever roles or the lifecycle change
How to start
Draft the matrix on one page for the six lifecycle stages and test it against the last system you put live.
Evidence
The approved matrix and its version history.
Mode: light / standard / full
light
A one-page table in which the same person may appear in several columns, but every cell that needs a name has one.
standard
The AI lead maintains the matrix and management approves it.
full
The governance function maintains the matrix per system class, linked to role descriptions and checked in internal audits.
Control 13
Document how the roles scale in your organisation.
EnhancedPreventiveall rolesthe whole organisation
What it is
Which accountabilities are combined in which people today, and what triggers their separation as you grow.
How to implement it · Minimum content
Every accountability: AI Owner, Technology Owner, governance lead, independent security reviewer, privacy, escalation authority
Today's holder of each, showing which are combined in one person
Combinations not allowed even when small (e.g. AI Owner and Technology Owner of the same system)
Triggers for separating roles (e.g. headcount, number of AI systems, first high-risk system)
Confirmation that no accountability is left without a holder
Review date, at least annually
How to start
List each accountability and write today's holder next to it; mark any without a holder and assign it.
Evidence
The dated role-scaling document approved by management.
Mode: light / standard / full
light
A half-page table kept by the owner-manager, updated when someone joins or leaves.
standard
The AI lead maintains it and management reviews it annually.
full
The governance function maintains it with HR, linked to the organisation chart and role descriptions.
Advanced1 controls
Control 14
Separate building from security sign-off.
AdvancedPreventiveall rolesthe whole organisation
What it is
The person or team that certifies a system safe for launch is organisationally independent of the one that built or procured it.
How to implement it · Minimum rules
The security sign-off is given by a person or team outside the reporting line of those who built or procured the system
Builders and buyers cannot approve their own system's security
Before go-live the reviewer models attacks, tests adversarially and assesses impact on people's rights
The reviewer can withhold sign-off; overriding it requires a recorded decision at committee or board level
Conflicts of interest declared and recorded at each sign-off
How to start
Name the function that will give security sign-off and confirm in writing that it does not report to the people who build or buy AI.
Evidence
Sign-off records showing the reviewer's independence and findings.
Mode: light / standard / full
light
Commission an external reviewer for each launch, since internal separation is not possible at this size.
standard
The security team, separate from delivery and procurement, signs off each launch.
full
A dedicated independent AI security function, reporting outside the technology line, signs off and can be overridden only by the board.
Evidence
The stakeholder maps; the responsibility matrix; owner assignments in the inventory; role descriptions; the written non-delegation statement; evidence of independent security review.