The enterprise AI governance operating model: roles, controls and decision rights

Almost every large organisation now has an AI policy. Very few have AI governance. The distinction is not pedantic: a policy states intent, while governance is the machinery that decides, constrains, records and intervenes. A policy can be written in a fortnight by people who will never operate it. An operating model has to name individuals, allocate their time and survive contact with a project that wants to ship.

What follows is the structure we deploy with clients, stripped of the parts that only exist to look thorough. It assumes you want AI in production, not a moratorium dressed as prudence.

Start with decision rights, not principles

Principles are cheap and interchangeable. Every framework says fairness, transparency, accountability and human oversight, and none of that tells a product owner whether they may deploy on Thursday. Decision rights do. Write down, for each class of AI use, who proposes, who approves, who can veto after the fact, and what threshold escalates to the board.

The grid matters less than its existence. Two hours in a room producing an imperfect version of this table removes more programme risk than a quarter spent drafting principles.

The three-lines split, applied honestly

The three-lines model works for AI, but only if the second line is competent to challenge. A risk function that approves AI deployments on the strength of a vendor deck is not a control, it is a signature. This is the single most common structural weakness we find, and it is expensive to fix late because the credibility of the whole control set depends on it.

• First line owns the use case, the output quality and the day-to-day operation. The named business owner sits here.
• Second line owns the control design, the challenge and the register. It needs at least one person who can read an evaluation report and disagree with it.
• Third line tests whether the controls operated, not whether they were designed. Internal audit needs the audit store to be queryable, which is a design requirement on the engineering team.

Controls for agents that act

The governance question changes when a system stops answering and starts acting. An agent that reads a mailbox, queries a ledger and updates a case record is an actor in your control environment. Treat it as one, with the controls you would apply to a new joiner who had been granted the same access on their first day.

1. 01

   Its own identity

   A dedicated service principal per agent, never a borrowed human credential. Every action must attribute to the agent and to the human who authorised the run.

2. 02

   Least privilege, scoped narrowly

   Enumerate the systems and the operations. Start read-only, and require a separate approval to add each write capability.

3. 03

   A spend and rate boundary

   A hard ceiling on calls, tokens and cost per run. Runaway loops are the most common agent incident, and they are trivially preventable.

4. 04

   A full action log

   Input, every tool call, every result, final output. Logging only the answer makes post-incident review impossible.

5. 05

   A human gate on the irreversible

   Payments, external communications, deletions, anything that touches a customer. The gate can be lightweight, but it must exist and it must be recorded.

Note that none of these controls is specific to AI. That is deliberate. Reusing your existing access, change and logging disciplines is faster than inventing an AI control framework, and it produces something your auditors already know how to test.

The register is the artefact that earns you time

When a regulator, auditor or board committee first asks about AI, the question is almost never technical. It is: what do you have, what does it decide, and who is responsible. An accurate register answers that in one document and buys the programme credibility that a policy cannot. Keep it short enough to stay current.

1. System name and the decision it supports.
2. Data classifications it may read, and the lawful basis.
3. Named accountable owner, and the approver of record.
4. Whether it can act, and on which systems.
5. How output quality is measured, and when it was last evaluated.
6. What it may not do without human approval.

What the board should actually see

Boards are poorly served by AI reporting that describes activity. Counts of pilots and workshops tell a director nothing about exposure. Report instead on the register’s shape and on the small number of things that would matter if they went wrong: how many systems can act without human approval, which decisions affecting individuals are now AI-assisted, what the evaluation trend looks like, and which incidents occurred with what remediation.

In South African practice, anchoring this to King IV Principle 12 on technology and information governance shortens the approval path considerably, because it places AI oversight inside a structure the board already recognises rather than presenting it as a new category of risk requiring a new committee.

A sequence you can start on Monday

1. Build the register from what already exists, including the tools people are using without approval. Amnesty produces better data than enforcement.
2. Draft the decision-rights grid with the executives who will actually approve things. Two hours, imperfect, signed.
3. Pick one live use case and put it through the grid retrospectively. The friction you find is your real control gap.
4. Fund one person in the second line to become genuinely competent at challenge.
5. Only then write the policy, and write it to describe the machinery you have built rather than the machinery you aspire to.