AI Governance Operating Model: Roles, Gates and Controls

An organisation can have an AI policy, a risk committee and a model register, and still be unable to answer who approves a new agent with access to customer data and the ability to send external emails. Legal assumes product owns it. Product assumes security signed it off. Security assumes the model team assessed it. The system goes live because everyone has a plausible reason to think someone else is responsible.

That is an operating-model failure, rather than a policy failure.

AI governance breaks when organisations organise it around documents rather than decisions. A policy can say “use AI responsibly”, but it cannot decide whether a particular agent may act autonomously, which controls it needs or who is accountable when its behaviour changes in production.

I start with a harder question: which decisions must be made, when, by whom, on what evidence — and how are they enforced?

Separate decision rights from delivery work

I separate governance from delivery at decision rights. A governance team should not become a second engineering department, and delivery teams should not define their own acceptable risk.

Decision	Accountable role	Required input	Enforcement point
Is this use case permitted?	Business sponsor and risk owner	Purpose, affected users, data class, expected outcome	Portfolio approval
Is the data use acceptable?	Data owner and privacy/security	Data map, retention, retrieval boundary	Data access policy
Is the architecture proportionate?	Architecture owner	Model, tools, integration, human-gate and failure mode	Architecture review
Can the system act autonomously?	Business owner with risk approval	Action class, reversibility, approval design	Runtime policy gateway
Is the output good enough?	Product owner	Evaluation plan, acceptance threshold, fallback	Release gate
Can it remain in production?	Service owner	Monitoring, incidents, drift, spend and review record	Ongoing operational review

This is a map from decision to evidence and enforcement, rather than a committee chart. Without the last column, governance becomes a recommendation the runtime can ignore.

Govern the lifecycle, not just the launch

Most governance attention arrives before release, when the system is still a diagram. The larger risk often appears afterwards: a new data source changes retrieval, a model version changes output behaviour, a tool gains a permission, or a product team broadens the workflow without revisiting the original risk assessment.

I use lifecycle gates to make the obligation recurring.

Stage	Evidence	Gate outcome
Idea	Purpose, expected outcome, affected users and alternative non-AI path	Proceed, redesign or stop
Design	Data flow, model/tool choices, action classes and control map	Approved architecture with constraints
Build	Evaluation set, security tests, policy implementation and trace design	Ready for controlled release
Release	Acceptance results, rollback plan, support owner and monitoring	Limited release or production approval
Operate	Quality, incidents, spend, interventions and user impact	Continue, restrict, remediate or retire
Change	New model, tool, data, permission or action class	Reassess before broadening authority

The change gate is usually the missing one. Treat a material permission, tool or data change as a new risk decision even if the product name did not change.

A material change returns the service to a risk decision before its authority broadens. The governance model is a loop, not a launch-stage approval.

The RACI that prevents governance theatre

Activity	Business sponsor	Product owner	Engineering owner	Security / privacy	Data owner	FinOps / operations
Define business outcome	A	R	C	C	C	C
Map data and permissions	C	C	R	A	A	C
Define action and approval policy	A	R	R	C	C	C
Implement controls and logs	C	C	A/R	C	C	C
Define evaluation and fallback	C	A/R	R	C	C	C
Monitor quality, cost and incidents	C	C	R	C	C	A/R
Approve material scope change	A	R	C	A	A	C

I would not copy this table blindly. Its job is to expose the role nobody assigned. If an agent has no business sponsor, it lacks an owner for the value it is supposed to create. If it has no operations owner, it lacks an owner for the risk it creates at 03:00.

Use proportional governance

I would not put a knowledge assistant that summarises approved internal documents through the same process as an agent that changes a customer record. Risk turns on data, autonomy, consequence, scale and reversibility.

Risk profile	Example	Governance posture
Low	Internal drafting with approved, non-sensitive content	Standard controls, basic evaluation, periodic review
Moderate	Employee support agent with retrieval from internal records	Data boundary, evaluation, audit trail and named owner
High	Customer-facing agent making recommendations or updates	Human approval for consequential actions, monitoring and change gate
Critical	Financial, legal, safety or privileged actions	Independent controls, strict approval, enhanced evidence and continuous review

Proportional does not mean optional. It means matching the control burden to the consequence.

Exceptions are part of the model

A policy without an exception route creates shadow delivery. Teams with a legitimate urgent need will work around it. I want the exception path visible: what is requested, who accepts the residual risk, how long it lasts, which compensating controls apply and when it expires.

Every exception should expire. A permanent exception is an undeclared policy change.

Test the model against one live workflow

Use the AI governance operating-model worksheet for one live or proposed workflow. Name the business sponsor, data owner, engineering owner, action class and ongoing review cadence. If any role is blank, the workflow is not governed yet.

Then read AI Governance Is Enforcement, Not Intent for the underlying argument.

I do not measure governance by the number of approvals. I measure it by whether the decision to move quickly is explicit, bounded and reversible where possible. That is how an organisation accelerates without letting an incident discover who owned the decision.