Why this is still an open question in most companies
Ask five people at a mid-sized company "who owns AI governance here?" and you'll usually get five different answers: IT, legal, the DPO, whoever built the first internal AI tool, or "nobody, technically." That's not a training problem — it's a structural one. Every major framework requires accountability without prescribing who holds it, so organizations default to either everyone owning it a little (which means no one owns it) or one overloaded person owning all of it (which means it doesn't scale past the first audit).
This page exists to close that gap: a practical breakdown of the roles a functioning AI governance program needs, and a RACI matrix mapping those roles against the activities regulators and auditors actually check.
What the three main frameworks actually require about roles
None of the frameworks below names job titles. All three require the same underlying thing: a documented, named owner for every AI governance decision.
| Framework | What it requires about roles | Reference |
|---|---|---|
| EU AI Act | Deployers must assign human oversight to people with "the necessary competence, training and authority" (Art. 26§2); providers need a risk management system with assigned ownership (Art. 9) and a quality management system (Art. 17); deployers must inform worker representatives before workplace deployment (Art. 26§7) and keep logs for at least six months (Art. 26§6). | Regulation (EU) 2024/1689 |
| ISO/IEC 42001 | Top management must ensure that "responsibility and decision-making authority are assigned and communicated for all roles involved in the AI lifecycle," covering compliance, strategic, implementation and operational functions. | Clause 5.3 |
| NIST AI RMF | Organizations should document roles, responsibilities and communication lines (Govern 2.1) — typically as a RACI matrix — train people for their specific AI risk duties (Govern 2.2), and have a named executive formally own AI risk decisions (Govern 2.3). | Govern function |
The common thread: every framework treats "we have a policy" as insufficient. What they check for is a named person who can be asked, in an audit, "why did this system get deployed, and who signed off on it."
The 9 roles in a practical AI governance RACI
Most of these roles already exist in some form at a mid-sized company — this isn't a hiring plan, it's a mapping exercise. Small teams collapse several of these into one or two people; larger, regulated organizations split them further.
- Executive Sponsor. A board member or C-level executive who formally owns residual AI risk decisions — the person NIST AI RMF's Govern 2.3 expects to exist. Without this, every other role operates without real authority.
- AI Governance Committee. The recurring decision-making forum — approves policy, reviews incidents, signs off on high-risk deployments. See how to build one from scratch.
- AI Governance Officer. Runs the program day to day: maintains the AI system inventory, coordinates technical documentation, and is the point of contact for regulators. See the full breakdown of this role.
- Data Governance Lead. Owns the data feeding AI systems — training data quality, lineage, and access. Article 10 of the AI Act runs through this role. See the minimum Data Governance team structure.
- DPO (Data Protection Officer). Owns personal-data aspects that overlap with AI: DPIAs, lawful basis for training data, and Article 22 automated-decision rights. Distinct from the AI Governance Officer, though the two roles coordinate constantly.
- Model / Product Owner. The business or technical lead accountable for a specific AI system — its intended use, its risk classification, and whether it still matches its original documentation after updates.
- Legal & Compliance. Interprets regulatory obligations, reviews vendor contracts for AI-specific liability terms, and signs off on public-facing transparency disclosures (Art. 50).
- IT / Security. Owns technical access controls, logging infrastructure (Art. 12), and the security half of "human oversight" — making sure the people who are supposed to intervene actually can.
- Internal Audit. Independently verifies that the other eight roles are functioning as documented — not just that a policy exists, but that it's followed.
RACI matrix: who owns what, activity by activity
R = Responsible (does the work) · A = Accountable (owns the outcome, signs off) · C = Consulted · I = Informed. This is a starting template — adjust it to your actual org chart before treating it as final.
| Activity | Exec Sponsor | AI Gov. Committee | AI Gov. Officer | Data Gov. Lead | Legal / Compliance | IT / Security |
|---|---|---|---|---|---|---|
| Risk classification (Annex III) | I | A | R | C | C | I |
| Technical documentation (Art. 11 / Annex IV) | I | C | A | C | C | R |
| Training data governance (Art. 10) | I | I | C | A/R | C | C |
| Human oversight design & assignment (Art. 14 / 26) | A | C | R | I | C | C |
| Incident & serious-incident reporting (Art. 73) | I | A | R | I | C | C |
| Vendor / third-party AI risk assessment | I | C | A | I | R | C |
| Monitoring & drift detection (post-market) | I | I | C | C | I | A/R |
| AI literacy training (Art. 4) | I | A | R | I | C | I |
| Regulatory registration (EU database) | I | C | A/R | I | C | I |
Two roles are deliberately absent from the table above to keep it readable: the DPO should be added as Consulted on every row that touches personal data (training data governance, human oversight, incident reporting), and Internal Audit should be Informed on every row and Accountable for periodically re-verifying the whole matrix still matches reality.
How this differs from a Data Governance RACI
AI governance and Data Governance responsibilities overlap heavily but aren't identical. A Data Governance RACI covers who owns data quality, access, and lineage regardless of whether that data ever touches an AI system. This page's RACI covers the additional layer that appears specifically because a system makes automated decisions: risk classification, human oversight design, and AI-specific incident reporting. If you're building both from scratch, start with Data Governance — Article 10 of the AI Act assumes it already exists — then layer the AI-specific roles on top. See AI Governance vs Data Governance: which comes first for the full sequencing logic.
Common mistakes when assigning AI governance responsibilities
- One person covers all nine roles. It works for the first internal AI pilot and breaks the moment a second high-risk system launches, because no one has bandwidth to be Accountable for everything at once.
- The RACI lives in a slide no one reopens. A matrix an auditor can't find during an inspection functions the same as no matrix at all.
- Confusing "Consulted" with "Accountable." Legal being consulted on a vendor contract doesn't make Legal accountable for the vendor's AI risk — that ambiguity is exactly what regulators probe for.
- No Executive Sponsor named. Without a named executive who owns residual risk, every other role operates without real backing when a hard call needs to be made.
- Treating this as a one-time exercise. New systems, new vendors and org changes all require the RACI to be re-checked — Internal Audit's row above exists for exactly this reason.
Checklist: is your AI governance RACI actually operational?
- Executive Sponsor named, with a documented mandate to own residual AI risk decisions.
- AI Governance Committee meeting on a fixed cadence, with minutes kept.
- AI Governance Officer (or an extended existing role) assigned, with the AI system inventory as their responsibility.
- Data Governance Lead's mandate explicitly extended to cover AI training data (Art. 10).
- DPO looped in as Consulted on every activity touching personal data.
- Every high-risk AI system has a named Model/Product Owner.
- Legal & Compliance sign-off required before any new vendor AI tool goes live.
- IT/Security owns logging and confirms human overseers can actually intervene in practice, not just on paper.
- Internal Audit has a standing item to re-verify the RACI at a fixed interval.
- The RACI itself lives in an accessible, version-controlled document — not a slide deck from a kickoff meeting.
Frequently asked questions
Who is ultimately accountable for AI governance in a company?
Legally, accountability sits with the provider or deployer as an organization. Internally, it has to be assigned to a named executive: Article 26(2) of the AI Act requires deployers to assign human oversight to people with "the necessary competence, training and authority," and NIST AI RMF's Govern 2.3 requires executive leadership to take responsibility for AI risk decisions.
What's the difference between an AI Governance Committee and an AI Governance Officer?
The Committee is a collective decision-making body that meets periodically, approves policy and reviews incidents. The Officer is an individual role that runs the day-to-day program and typically reports to, or chairs, that committee. In small companies the same person often does both, but the two functions are distinct.
Does ISO 42001 require a specific role like "AI Governance Officer"?
No. ISO/IEC 42001 Clause 5.3 requires that responsibility and decision-making authority be assigned and communicated for all roles involved in the AI lifecycle, but it deliberately leaves the actual titles and org structure up to each organization.
What's the fastest way to put a RACI matrix in place without hiring anyone new?
Start by mapping the people who already own data governance, security and legal against the activities in the table above, then formalize it in a single document reviewed and signed off by leadership. Most companies can staff every role on this page with people already on the payroll — the gap is usually documentation, not headcount.