Every stalled AI governance program I’ve looked at had a framework. Most had two. What they didn’t have was an answer to a much smaller question: when a business unit wants to deploy a generative AI use case next month, who decides, on what basis, and who can say no?

Frameworks describe outcomes. Operating models allocate authority. You need the second one to get the first.

This is also the part of AI governance that is least about technology. Over 25 years I’ve built ISMS governance for banks, run risk committees, and briefed CIOs and VPs on control decisions — and the pattern holds: governance programs die from ambiguous decision rights far more often than from weak controls.

Start with decision rights, not committees

The instinct is to create a committee. The better first move is to write down the decisions that need making, then work out who should make each one. There are roughly seven:

  1. Is this use case permitted at all? (policy conformance)
  2. What risk tier is it? (drives everything downstream)
  3. Is the intended data use lawful and appropriate? (privacy, contractual, jurisdictional)
  4. Is this vendor and model acceptable? (third-party and model provenance risk)
  5. Has it met its pre-deployment evidence bar? (the launch gate)
  6. Who accepts the residual risk, and for how long?
  7. When does it get reviewed, and what triggers retirement?

Notice that only two of the seven are meaningfully technical. That’s why AI governance sitting entirely inside a security team under-performs — and why the strongest programs I’ve seen are led by someone who can hold a conversation with Legal about liability, with Procurement about contract clauses, and with an engineer about evaluation methodology, without being the expert in any of those seats.

A RACI that survives contact with reality

Here’s the allocation I’d defend in most large enterprises. Adapt the names; keep the shape.

Activity Accountable Responsible Consulted Informed
AI policy & standards Chief Risk / CISO AI governance lead Legal, Privacy, Technology, HR All staff
Use-case intake & triage AI governance lead Business system owner Risk, Privacy Technology
Risk tiering decision AI governance lead AI governance lead Legal, Risk, business owner Audit
AI impact assessment Business system owner AI governance lead Privacy, Legal, affected-stakeholder proxy Risk
Legal & regulatory review Legal Legal counsel Privacy, Compliance AI governance lead
Vendor AI due diligence Procurement TPRM analyst Security, Legal, Privacy, AI governance Business owner
Contract clauses (AI-specific) Legal Legal + Procurement AI governance lead Business owner
Technical controls & guardrails Technology / CISO Platform & security engineering AI governance lead Risk
Model evaluation & testing Business system owner Data science / vendor AI governance lead, Security Risk
Production monitoring Business system owner Technology operations AI governance lead Risk
Residual risk acceptance Executive risk owner AI governance lead (facilitates) Legal, Risk Audit, Board
Independent assurance Chief Audit Executive Internal audit — Board, Executive
Incident response (AI) CISO SecOps + business owner Legal, Comms, Privacy Executive
Retirement & decommissioning Business system owner Technology AI governance lead, Records Audit

Two design rules make this hold up.

One accountable party per row. Shared accountability is unaccountability. If Legal and Risk are jointly accountable for the regulatory review, it will be late.

The AI governance lead is rarely accountable for controls. This surprises people. The governance function’s job is to define the requirement, facilitate the decision, and hold the evidence — not to own every control. A governance lead who becomes accountable for implementing technical guardrails stops being able to challenge them. This is the single most common structural mistake, and it usually happens because the governance lead is the only person who understands the problem in year one.

What each function actually contributes

Technology owns the platform-level guardrails — identity, data boundaries, logging, environment separation, connector governance. It’s also where the honest answer lives about what’s technically enforceable versus what’s policy-on-paper. Governance requirements that Technology can’t enforce should be labelled as detective or procedural controls, not pretended into preventive ones.

Risk owns the taxonomy and integration into enterprise risk. The best thing Risk can do for an AI program is refuse to let AI risk live in its own register. AI risk that isn’t mapped to existing operational, conduct, model, privacy and third-party risk categories will be treated as a novelty and defunded when the news cycle moves on.

Legal owns regulatory interpretation, liability, IP (both directions — what you put in and what comes out), and contractual position. Legal is also the function most likely to surface the question no one else asks: if this system harms someone, what is our exposure and can we explain the decision?

Procurement is the most underused lever in AI governance. Most enterprise AI risk arrives through purchase, not through internal development — and by the time a tool with embedded AI reaches a security review, the business has already committed. Fix this by inserting an AI screening question into the intake stage of the procurement workflow, not the assessment stage: does this product use, embed, or transmit data to an AI or machine-learning model? One question, at the front, routes everything else. Then build a standard AI clause set: model change notification, training-data restrictions, subprocessor disclosure, evaluation and audit rights, incident notification timelines, and exit/data-deletion obligations.

Audit provides independent assurance and — importantly — must not be part of designing the controls it will later test. I’ve sat on both sides of this line as a CISA and ISO 27001 Lead Auditor, and the temptation to have Audit “help build it” because they understand controls best is real and should be resisted. Audit’s contribution during build is to review the design for auditability and tell you where the evidence will be thin.

The business owns the use case, the residual risk, and the outcome. If the business isn’t accountable for anything in your model, you’ve built a compliance function that the business will route around.

Three lines, applied to AI

Map it to the three-lines model and the structure clarifies:

  • First line — business system owners and the technology teams building and running AI systems. They own the risk and the controls.
  • Second line — the AI governance function, Risk, Legal, Privacy and Compliance. They set the requirements, challenge the first line, and aggregate the picture.
  • Third line — internal audit. Independent assurance that lines one and two are doing what they claim.

The recurring failure mode is a second line that has drifted into doing first-line work because the first line lacked capability. It’s understandable and it’s corrosive: you lose challenge, and when Audit arrives there’s no independent view left. If your governance function is writing the risk assessments rather than reviewing them, that’s the symptom.

Committee design: fewer, sharper, with a decision log

Once decision rights exist, the forum becomes obvious. My preferences:

  • One AI governance forum, meeting fortnightly or monthly, reporting into an existing executive risk committee. Do not create a new board-level committee for AI — it isolates AI risk from enterprise risk and gives it a shelf life.
  • A written charter covering membership, quorum, decision authority, escalation thresholds, and what it explicitly does not decide.
  • A decision log. Every approval, rejection, condition and risk acceptance, with date, rationale and owner. This is the artifact that turns your governance forum into evidence — for auditors, regulators and certification bodies. It costs one person twenty minutes a meeting and it is the highest-return administrative act in the entire program.
  • Delegated authority for low-tier use cases. If every trivial use case needs the committee, the committee becomes the bottleneck and shadow AI becomes the workaround. Delegate low-risk approvals to the governance lead with post-hoc reporting.

Sequencing it

If you’re building this from scratch:

  1. Write the decision list. One page.
  2. Assign accountability for each decision. Get it signed off by the executives named.
  3. Stand up the forum with a charter and a decision log.
  4. Insert the intake question into the procurement workflow — the cheapest, highest-coverage control available to you.
  5. Publish the RACI where the business can find it.

Then, and only then, worry about the lifecycle workflow, the NIST AI RMF mapping and the management system. Frameworks are portable. Decision rights are the part you have to build yourself.

If you’re designing an AI governance operating model and want a second pair of eyes on the allocation, let’s talk.