When an AI system causes harm, most organisations discover that the data science team built it, a business unit bought it, IT runs it, and nobody was ever named as accountable for the decision to put it in front of customers. This template is a RACI matrix for AI governance at [Organisation]: who is responsible, accountable, consulted and informed for each decision across the AI lifecycle, from intake and risk tiering through build or procurement, deployment, human oversight, monitoring, incidents and retirement. It is built to give evidence for NIST AI RMF GOVERN 2.1, ISO/IEC 42001 clause 5.3 and, where the EU AI Act applies, the human oversight assignment in Article 26(2). It is for AI governance leads, CISOs, data protection officers, risk and compliance teams and the product owners who put AI into service. The reasoning behind committee design is in the AI Ethics Board and AI Review Committee Guide; this page is the matrix you fill in.
How to use this template
- Replace placeholders: text in square brackets, such as [Organisation], [Chief AI Officer] and [12 months], is for your own titles and values. Bracketed numbers are illustrative, not standards.
- Codes: R = Responsible (does the work), A = Accountable (owns the outcome and signs it off, exactly one per row), C = Consulted (before the decision, two-way), I = Informed (after the decision, one-way). A/R means the same role is accountable and does the work.
- Roles, not names: the matrix uses role codes from section 2. Keep the names of current holders and deputies in the register in section 2.3, so the matrix survives reorganisations.
- Tier drives depth: rows marked [T2+] apply only to systems at [Tier 2] or above in your AI Agent Risk Assessment Template or AI Impact Assessment Template. Low-risk tools follow the shorter path in section 4.
- Store it with the register: link each AI system's entry in the AI Register and AI Inventory Template to the named holders of the AO, SO and OVR roles for that system. A RACI that is not tied to the inventory cannot be audited.
1. Purpose and scope
1.1 This RACI sets out who decides, who acts and who must be consulted or told for AI governance activities at [Organisation]. It supports the AI policy and the AI management system, and it is the record that roles, responsibilities and lines of communication for mapping, measuring and managing AI risk are documented (NIST AI RMF GOVERN 2.1).
1.2 It applies to every AI system that [Organisation] develops, procures, configures or uses, including generative AI services, models embedded in purchased software, AI features switched on in existing SaaS tools, and AI agents that act with their own credentials.
1.3 It does not replace the incident response RACI or the programme-wide security RACI. Where they overlap, this RACI covers the AI-specific decision and points to the others for the rest. See the Incident Response RACI Template and the Security RACI Matrix Template.
1.4 Owner: [AI Governance Lead]. Approver: [Executive Committee]. Review cycle: [12 months] and after any change in law, organisation structure or a [Severity 1] AI incident.
2. Roles
2.1 Governance roles
| Code | Role | Default holder | Authority |
|---|---|---|---|
| EXE | Executive sponsor | [Chief AI Officer, CIO or COO] | Accountable for the AI policy, risk appetite and resourcing; takes responsibility for decisions about AI risk (NIST AI RMF GOVERN 2.3) |
| BRD | Board or board committee | [Risk or Audit Committee] | Oversight; approves risk appetite and receives reporting |
| ARC | AI review committee | [Chair named in charter] | Approves or rejects [T2+] systems, sets conditions, grants exceptions within appetite |
| AGL | AI governance lead | [AI Governance Lead] | Runs intake, the register, policy and reporting; owns this RACI |
| LEG | Legal and compliance | [General Counsel] | Regulatory classification, contracts, intellectual property, notification decisions |
| DPO | Data protection officer or privacy lead | [DPO] | Data protection impact assessment, lawful basis, data subject rights |
| SEC | Security | [CISO] with [AI security lead] | Threat modelling, security testing, identity and access, security monitoring |
| RSK | Risk management (second line) | [Chief Risk Officer or model risk] | Independent challenge of risk ratings and validation |
| AUD | Internal audit (third line) | [Head of Internal Audit] | Independent assurance over the whole framework |
2.2 System roles (named per AI system)
| Code | Role | Default holder | Authority |
|---|---|---|---|
| AO | AI system owner | [Business unit head using the system] | Accountable for the system's purpose, outcomes and residual risk; accepts business impact |
| DEV | Build or configuration team | [Data science, ML engineering or the platform team] | Builds, fine-tunes, configures prompts and tools, documents the model |
| SO | Service operator | [IT operations or platform owner] | Runs the system in production, logging, change and availability |
| OVR | Human oversight operator | [Named staff in the business process] | Monitors outputs, can override, stop or escalate; must have the competence, training and authority for this |
| PRC | Procurement and vendor management | [Head of Procurement] | Supplier due diligence, contract terms, renewals |
| HR | Human resources | [HR Director] | Workforce impact, informing workers and representatives, training records |
2.3 Role register
2.3.1 For each role, record the current holder, a deputy, the date appointed and the training completed. Every [T2+] system must have a named AO, SO and at least two OVR holders before go-live.
2.3.2 The AO must sit in the business, not in the team that built or bought the system. The person who validates a [T2+] model (RSK) must not have built it (DEV).
2.3.3 Where [Organisation] is a deployer of a high-risk system under the EU AI Act, OVR holders are the persons assigned human oversight under Article 26(2) and the register is the evidence that they have the necessary competence, training and authority, and support.
3. Decision rights
| Decision | Accountable | Must consult | Escalate to |
|---|---|---|---|
| Set AI risk appetite and prohibited uses | EXE | LEG, RSK, SEC, DPO | BRD approves |
| Classify a system (risk tier, EU AI Act role and category) | AGL | LEG, AO, DPO | ARC if disputed |
| Approve a [T2+] system for production | ARC | SEC, DPO, LEG, RSK | EXE if outside appetite |
| Approve a [T1] system or AI feature in an existing tool | AGL | SEC, DPO | ARC |
| Accept residual risk for a system | AO | RSK, SEC | EXE above [High] |
| Grant an exception to the AI policy | ARC | LEG, SEC | EXE for [more than 6 months] |
| Suspend a system in production | AO, or OVR in an emergency | SO, SEC | AGL informed at once |
| Decide whether an AI incident is reportable | LEG | DPO, SEC, AGL | EXE |
| Retire a system | AO | SO, DPO, SEC, LEG | AGL records closure |
3.1 Any OVR holder may stop or suspend a system's use when they believe it presents a risk to health, safety or fundamental rights, and must not be penalised for doing so in good faith. Article 26(5) requires a deployer that identifies such a risk to suspend use and inform the provider and the market surveillance authority.
4. RACI by lifecycle stage
| Activity | EXE | ARC | AGL | AO | DEV | SO | OVR | SEC | DPO | LEG | RSK | PRC |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Maintain the AI policy and this RACI | A | C | R | C | C | C | C | |||||
| Intake: register a new use case or AI feature | A | R | C | I | I | C | ||||||
| Document intended purpose, users and context | C | A/R | R | C | C | C | ||||||
| Classify risk tier and legal category | I | A/R | C | C | C | C | R | C | ||||
| AI impact assessment [T2+] | I | C | A | R | C | C | R | C | C | |||
| Data protection impact assessment, where required | I | C | R | C | A | C | ||||||
| Supplier due diligence and contract terms | C | A | C | R | R | R | R | |||||
| Training data sourcing and quality | A | R | C | C | C | |||||||
| Threat model and security testing, including red teaming [T2+] | I | C | C | C | A/R | I | ||||||
| Independent validation and performance testing [T2+] | I | C | C | A/R | ||||||||
| Identity, credentials and permissions for the system or agent | C | R | R | A | ||||||||
| Go-live approval | I | A | R | R | C | C | I | C | C | C | C | |
| Train and authorise human oversight operators | C | A | C | R | ||||||||
| Inform affected workers and their representatives | C | A | C | C | ||||||||
| Operate, log and keep logs for the set retention period | A | R | C | C | ||||||||
| Monitor outputs and override or escalate | I | A | C | R | C | |||||||
| Monitor drift, performance and fairness metrics | I | I | A | R | R | C | C | |||||
| Approve material change (new model, tools, data or purpose) | A [T2+] | R | R | R | C | C | C | C | C | |||
| Handle an AI incident or serious error | I | I | R | A | R | R | R | R | C | C | ||
| Periodic review and re-approval | A [T2+] | R | R | C | C | C | C | C | C | |||
| Decommission: revoke access, delete or retain data, close records | I | R | A | R | R | R | C | C | R | |||
| Report AI risk posture to the board | A | C | R | C | C | C | C |
4.1 Short path for [T1] systems and AI features in existing tools: AO registers, AGL classifies and approves, SEC and DPO are consulted, SO operates. No ARC review unless the tier changes.
4.2 BRD, AUD and HR are left out of the table to keep it readable: BRD is informed of every row that EXE is accountable for, AUD reviews the whole matrix under section 7, and HR is consulted on worker-facing rows.
5. Where identity fits
5.1 Every AI system that calls an API, reads a data store or runs as an agent holds a non-human identity. The row "Identity, credentials and permissions" makes SEC accountable for how that identity is issued, scoped and rotated, while the AO remains accountable for what the system is allowed to do. Record the permissions agreed in the AI Agent Permission Matrix Template.
5.2 Each agent identity must have a named human owner (normally the AO) and a deputy. When the AO leaves or changes role, ownership transfers under section 6 before their own account is disabled. See the NHI Ownership RACI and the Agentic AI Identity Guide.
5.3 Decommissioning is complete only when the system's credentials, API keys, OAuth grants and service accounts are revoked and that revocation is evidenced in the register.
6. Handovers and escalation
6.1 A change of AO, SO or OVR holder is recorded in the role register within [10 working days]. Until a new AO is named, the business unit head is the AO by default.
6.2 Disagreements between AO and SEC, DPO or RSK on a [T2+] system go to ARC. ARC decisions outside the risk appetite go to EXE.
6.3 Third parties that operate AI on [Organisation]'s behalf are mapped to the system roles in the contract. The PRC row in section 4 ensures contracts name who performs SO and OVR duties and how incidents are reported back. See the AI Vendor Security Questionnaire Template.
7. Review and approval
7.1 AGL reviews this RACI every [12 months] and confirms every [T2+] system in the register has named, current AO, SO and OVR holders.
7.2 AUD includes the RACI in the internal audit plan and tests a sample of systems: does the go-live record carry the accountable approver's sign-off, and were the consulted roles actually consulted before the decision date?
| Version | Date | Change | Approved by |
|---|---|---|---|
| [1.0] | [Date] | [Initial issue] | [Executive Committee] |
Implementation guidance
Rollout steps
- Start from the register: list every AI system and AI feature in use. A RACI written before the inventory exists assigns accountability to a picture, not to real systems.
- Name the system roles for the top tier first: for each [T2+] system, agree the AO, SO and OVR holders with the business. Expect disputes about AO; resolve them at executive level, not in the governance team.
- Agree decision rights before the full matrix: get section 3 signed by EXE. Most of section 4 follows once those few decisions are settled.
- Pilot on two live systems: walk one built and one bought system through every row and record where the real process differed from the matrix. Adjust the matrix, not the evidence.
- Wire it into workflow: make the intake form, go-live ticket and change request require the accountable role's approval, so the RACI is enforced by the process rather than by memory.
- Train role holders: OVR holders need training specific to each system; AO holders need to understand what accepting residual risk means. Link this to the AI Literacy Training Plan Template.
Common failure patterns
- The builder owns the risk: the data science lead is made AO, so the person who gains from shipping also accepts the risk. Put AO in the business.
- Two accountable roles: rows with "A" in two columns mean nobody owns the outcome. Check every row has exactly one A.
- Oversight on paper: OVR is assigned to a team mailbox, or to people without authority to stop the system. Article 26(2) asks for competence, training and authority, which a mailbox cannot have.
- SaaS AI features missed: AI switched on inside an existing tool never goes through intake, so no AO is named. Treat enabling an AI feature as a change that triggers row 2.
- Retirement left out: systems are switched off but their agent credentials and data stores remain. NIST AI RMF GOVERN 1.7 expects safe decommissioning; give it a row and an owner.
Measuring whether it works
- Percentage of [T2+] systems in the register with a named, current AO, SO and two OVR holders (target [100%]).
- Percentage of go-live and material change records carrying the accountable approver's sign-off before the change date.
- Median days from intake to classification, as a check that the process is usable rather than bypassed.
- Number of AI features found in use that never went through intake, per quarter (should fall).
- Percentage of retired systems with credential revocation evidenced.
Framework mapping
| Framework | Reference | What this template evidences |
|---|---|---|
| NIST AI RMF 1.0 | GOVERN 2.1, 2.2, 2.3 | Documented roles and lines of communication, training, executive responsibility for AI risk decisions |
| NIST AI RMF 1.0 | GOVERN 3.2, GOVERN 1.7, MANAGE 4.1 | Roles for human-AI configurations and oversight; decommissioning; post-deployment monitoring with override |
| ISO/IEC 42001:2023 | Clause 5.3, clause 7.2 | Roles, responsibilities and authorities for the AI management system; competence of role holders |
| EU AI Act | Article 26(2), 26(5), 26(7) | Deployer human oversight assignment; suspension and reporting of risk; informing workers |
| EU AI Act | Article 17(1)(m) | For providers of high-risk systems: the accountability framework in the quality management system |
| EU AI Act | Article 4 | AI literacy measures for staff operating or using AI systems |
Standards and references
- NIST: AI RMF 1.0 Core (GOVERN, MAP, MEASURE, MANAGE)
- NIST: AI Risk Management Framework
- ISO/IEC: 42001:2023 Artificial intelligence management system
- European Commission AI Act Service Desk: Article 26, Obligations of deployers of high-risk AI systems
- European Commission AI Act Service Desk: Article 17, Quality management system
- European Commission AI Act Service Desk: Article 4, AI literacy
Related NHI Mgmt Group resources: the AI Governance Guide, the NIST AI RMF Guide, the ISO/IEC 42001 Guide, the EU AI Act Article 14 Guide and the AI Incident Management and Escalation guide.