When something goes wrong with an AI system, the first question is who owns it. The second is who was supposed to have reviewed it. In most organizations the answers are fuzzy. The engineering team built it. Compliance might have seen a policy. Security might have been looped in for the deployment. The business sponsor wanted it shipped. But nobody is explicitly accountable for the risk decisions, and when a regulator or auditor asks who signed off, the trail goes cold.
AI risk ownership needs a RACI: who is responsible for doing the work, who is accountable for the outcome, who is consulted, and who is informed. Not by role in the abstract. By named individual or clearly designated role, with escalation paths and documented authority.
Why RACI for AI Is Different
Traditional project RACI often maps to phases: design, build, test, deploy. AI governance runs in parallel and keeps running. You're not just shipping once. You're maintaining an inventory, classifying use cases, running impact assessments, responding to incidents, and updating policy. The RACI has to cover ongoing governance activities, not just the initial launch. It also has to account for functions that don't naturally sit in one place: the person who owns the system technically (often engineering), the person who owns the business outcome (product or business), the person who owns compliance (compliance or legal), the person who owns security (security), and where applicable the data protection officer (DPO) or privacy lead. Without a single chart that says "for this activity, this person is R and this person is A," you get overlap, gaps, and "I thought they were doing it."
The Core Roles
Before you fill in the matrix, define the roles that will show up in it. These are the parties that need to be named or designated.
AI system owner: The person accountable for a specific AI system or use case. They own the system's design, operation, and risk posture at the system level. They're the default owner for that system's entry in the inventory, for keeping the impact assessment current, and for ensuring controls are in place. Usually the engineering or product lead for that system. There can be many system owners (one per system or use case); the RACI says who is A for each system.
Business sponsor: The person who represents the business value and use case. They're accountable for justifying the use case, defining requirements, and accepting risk within the bounds set by policy. They're often the "requestor" for a new use case or the owner of the business process the AI supports. Product, operations, or a domain lead.
Compliance reviewer: The person who ensures the system and its use comply with policy and regulation. They review classifications, impact assessments, and policy exceptions. They're consulted on high-risk decisions and may be accountable for signing off that a system meets compliance requirements before go-live or at audit. Compliance or legal, depending on structure.
Security reviewer: The person who assesses and owns security risk for the system: threat model, access controls, prompt injection, data exposure, supply chain. They may be responsible for security testing or for reviewing third-party assessment. They're consulted on security-relevant decisions and may be accountable for a security sign-off. Often the CISO's org or a designated application security lead.
Data protection officer or privacy lead: Where regulation requires it (e.g., GDPR, state privacy laws), the DPO or privacy lead has a defined role in decisions that affect personal data. For AI systems that process personal data, they're typically consulted on data use, retention, and rights; in some cases they must be informed or must approve. Named in the RACI so there's no ambiguity.
Governance lead or AI risk owner: The person who owns the overall AI governance process: policy, inventory, committee, and cross-system risk view. They're often accountable for ensuring RACI is followed, for escalating when ownership is unclear, and for reporting to leadership. They might sit in risk, compliance, or a dedicated AI governance function.
Not every organization has all of these as separate people. Small orgs might combine compliance and legal, or have the system owner also be the business sponsor. The point is to name the function and then assign a person (or a role with a named backup). "Compliance" isn't enough. "Jane Smith, Compliance" or "Compliance Lead (see org chart)" is.
Mapping Governance Activities to RACI
Once you have the roles, map them to the main governance activities. For each activity, assign R (responsible: does the work), A (accountable: owns the outcome, one per activity), C (consulted: input before decision), I (informed: told after). Accountability should sit with one person per activity per system or per process, so that "who's on the hook" is never ambiguous.
AI inventory maintenance: R: System owner (for their system) or governance lead (for keeping the inventory current). A: Governance lead for the inventory as a whole; system owner for the accuracy of their entry. C: Compliance, security (they may flag missing systems). I: Business sponsor, DPO if data is involved.
Use case classification (red / yellow / green): R: System owner or business sponsor (they provide the facts). A: Governance lead or compliance (they own the classification decision). C: Security (for security-relevant use cases), DPO (for personal data). I: Business sponsor, system owner.
Impact assessment (AIA) for high-risk systems: R: System owner (they draft or coordinate the assessment). A: System owner (they own the accuracy and currency of the AIA). C: Compliance, security, DPO; possibly legal. I: Business sponsor, governance lead.
Policy exception or waiver: R: Requestor (business sponsor or system owner). A: Governance committee or designated approver (e.g., governance lead with compliance sign-off). C: Compliance, legal, security. I: System owner, business sponsor.
Security review or security sign-off: R: Security reviewer (they perform or commission the review). A: Security reviewer (they own the sign-off). C: System owner. I: Compliance, governance lead, business sponsor.
Incident response (AI-specific): R: Incident lead (often system owner or security, per your IR plan). A: Incident lead until contained; then system owner for remediation. C: Legal, compliance, security, DPO as needed. I: Governance lead, business sponsor, leadership per severity.
Policy updates: R: Governance lead or compliance (they draft). A: Governance committee or whoever has policy authority. C: Legal, security, business representatives. I: All system owners, compliance, security.
You can turn this into a one-page matrix: rows = activities, columns = roles, cells = R / A / C / I. The matrix is the reference. The critical step is to add a second layer: for each role, the name of the person (or the role title and where to find the current holder). Without that, the RACI is a template. With it, it's an accountability map.
Escalation Paths and Documented Authority
RACI tells you who does what. Escalation tells you what happens when there's disagreement, when accountability is missing, or when the decision is above the room.
Disagreement between R and A or between C and A: If the person responsible and the person accountable can't agree (e.g., system owner says green, compliance says yellow), define who breaks the tie. Often the governance committee or the governance lead. Document it: "Classification disputes are resolved by [Governance Committee / Governance Lead] after input from Compliance and Security."
Missing accountability: If a new system or use case has no clear system owner or business sponsor, the governance lead should flag it and escalate until one is assigned. No system in the inventory without an A for that system. Document: "Systems without a designated system owner may not be approved for production use."
Decisions above the committee: When the governance committee can't approve (e.g., material risk, strategic bet, or regulatory exposure), define who does. Board, C-suite, or a designated risk committee. Document: "Waivers with material regulatory or reputational impact require [CEO / CRO / Board] approval."
Authority to say no: The RACI should make clear who has the authority to block. Compliance might have authority to block go-live if the impact assessment is incomplete. Security might have authority to block if critical controls are missing. Document who can say no and for what reason, so that the business knows whom to satisfy and escalation is clear when someone does say no.
Publish the RACI and the escalation rules. Put them in the same place as your AI policy and governance charter. When an auditor asks who owns AI risk, the answer should be "here's the RACI; here are the names."
Keeping It Current
RACI goes stale when people leave or when roles shift. Assign an owner for the RACI itself (usually the governance lead). That person is responsible for updating the matrix and the name roster when there's a change. Review the RACI at least annually: are the names right? Are the activities still the right set? Have we added new governance activities that need to be in the matrix? Without that, the chart nobody had built becomes the chart nobody maintains. Build it once. Keep it living.
We help clarify AI risk ownership and governance accountability. Contact us for independent AI risk assessments and governance program design.