AI Governance Operating Model: Roles, Gates and Controls

A company had an AI policy, a risk committee and a model register. It still could not answer who approved a new agent that could access customer data and send external emails. Legal thought product owned it. Product thought security had signed it off. Security thought the model team had assessed it. The system went live because everyone had a plausible reason to think someone else was responsible.

That is not a policy failure. It is an operating-model failure.

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

The useful question is not “do we have an AI governance framework?” It is which decisions must be made, at what point, by whom, with what evidence, and how are they enforced?

Separate decision rights from delivery work

A governance team should not become a second engineering department. Equally, delivery teams should not be left to define their own acceptable risk. The boundary is decision rights.

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 deliberately not a committee chart. It is a map from decision to evidence and enforcement. Without the last column, governance turns into a recommendation that 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 after release: 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.

Use lifecycle gates that create a recurring obligation.

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.

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

The table is not meant to be copied blindly. It is meant to expose the one 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

A knowledge assistant that summarises approved internal documents should not wait for the same process as an agent that changes a customer record. Risk depends 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 the control burden is matched 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. A good operating model has a visible exception path: what is requested, who accepts the residual risk, how long it lasts, what compensating controls apply and when it expires.

Make every exception expire. Permanent exceptions are undeclared policy changes.

What to do on Monday morning

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 in Practice: Who Owns the Guardrails? for the underlying argument, and use the MCP security and governance control map where the system reaches external tools.

Good AI governance does not slow useful work down. It makes the decision to move quickly explicit, bounded and reversible where possible. That is what lets an organisation accelerate without waiting for an incident to teach it who was responsible.