AI Governance Operating Model: Decision Rights by Risk

Most enterprises now have an AI policy signed and filed. Far fewer have an AI governance operating model that turns that policy into consistent decisions. The policy exists. What most organizations cannot answer is who approved their last AI system and what evidence backed the decision.

The gap becomes visible when AI moves into production. Policy owners may understand the rules but still lack clarity on who owns each AI system, who approves high-risk use cases, how disagreements escalate, and what evidence must support a decision. Without defined authority and workflows, governance remains difficult to enforce and audit.

This guide covers the core components of an AI governance operating model, compares centralized, hub-and-spoke, and federated structures, defines key roles and approval thresholds, and walks through a three-phase implementation.

What is an AI governance operating model?

An AI governance operating model is the organizational structure that turns AI policy into decisions. It defines who holds authority over each AI system, which body approves what, how work routes between them, and what evidence each decision leaves.

In a 2025 survey of 419 directors and senior executives, published in May 2026, the UTS Human Technology Institute found roughly three-quarters described their AI governance as patchy or informal.

AI governance operating model vs. AI governance framework

A framework tells you what to govern. An operating model tells you who decides and how the decision moves.

Here is a test you can run in ten minutes. Name the last AI system your organization put into production. Now name the person accountable for it and the forum that cleared it. If either name is missing, you have a framework and not an operating model.

A policy is a document, and it fails when nobody reads it. A framework is a control set, and it fails when nobody owns a control. An operating model produces a decision with an owner and a record. AI governance is the umbrella. The operating model is the machinery underneath.

OvalEdge expert insight: The fastest way to test whether you have an operating model is to name who approved your last AI system and what evidence they reviewed. If either answer takes more than one email, the model is missing.

Core components of an AI governance operating model

An effective AI governance operating model depends on six connected components that define accountability, decision-making, oversight, and execution.

1. Accountable ownership. A single executive is ultimately answerable for enterprise AI risk and ensures governance decisions have clear accountability.
   
   

2. Decision rights. Clear rules specify who can approve, reject, or escalate AI systems at each risk level, along with expected decision timelines.
   
   

3. Oversight forum. A designated council reviews higher-risk AI systems, resolves governance issues, approves exceptions, and escalates significant risks when necessary.
   
   

4. Working roles. Defined roles such as model owners, validators, data stewards, and governance leads handle the operational work required between council meetings.
   
   

5. System of record. A shared system maintains the AI inventory, ownership, lineage, policies, risk classifications, and evidence needed to support governance decisions.

AI governance operating model examples: centralized, hub-and-spoke, and federated

Three structures cover almost every enterprise AI governance operating model in practice, and they differ primarily in how far approval authority sits from the team building the system. These models concern AI approval authority rather than data ownership. For how centralized, decentralized, and federated approaches apply to data, see data governance models.

IBM's Institute for Business Value found in May 2026 that organizations running orchestration-led governance reported 29% lower losses from AI irregularities and 20% higher ROI.

1. Centralized

One central body, usually chaired by a CAIO or CDO, approves every AI use case, model, and vendor tool.

However, as AI adoption grows, approval queues can slow delivery and encourage teams to activate AI features outside formal intake processes, increasing the risk of shadow AI.

2. Hub-and-spoke

A central hub owns policy, risk-tiering criteria, tooling, and the model inventory, while governance leads embedded within business units handle intake and first-line review.

The model becomes ineffective when embedded leads lack genuine decision-making authority and must send most approvals back to the central team.

3. Federated

Business units approve AI systems within thresholds established by the central governance function, while higher-risk or exceptional cases move to enterprise oversight.

Its effectiveness depends heavily on consistent risk definitions, governance evidence, and a shared AI inventory across the organization.

How to choose an AI governance target operating model

Choose your AI governance target operating model on three variables: how many AI systems you run, how much regulatory exposure they carry, and how much authority your business units hold over technology decisions.

• Under roughly 15 AI systems, or a first year of formal governance, run centralized.

• AI being built in three or more business units at mixed risk levels, run hub-and-spoke.

• Business units with separate regulators, P&Ls, and technology stacks run federated.

Most enterprises run a split model where the risk tier decides which structure applies, keeping high-risk approvals central while everything else moves outward.

Who owns AI governance? Roles, responsibilities, and team structure

One executive owns AI governance accountability, and in most enterprises that is the Chief AI Officer or the Chief Data Officer. Legal, security, and risk hold defined authority over their domains rather than shared ownership, because shared ownership means no ownership.

IBM's Institute for Business Value reported in May 2026 that 76% of organizations now have a Chief AI Officer, up from 26% a year earlier.

The question is what that person actually decides. NIST AI RMF GOVERN 2.3 and ISO/IEC 42001 Clause 5.3 both name a person, not a committee.

• Chief AI Officer. Owns enterprise AI risk accountability, chairs the council, and holds final approval on high-risk systems. Does not own model build decisions.
  
  

• Chief Data Officer. Owns the data that trains and runs AI, its lineage and classification. Does not own model performance.
  
  

• CISO. Owns security review, agent access boundaries, and incident response. Does not own fairness or business-impact judgments.
  
  

• Chief Risk Officer or General Counsel. Owns regulatory interpretation, risk appetite, and legal exposure. Does not own technical validation.

Whoever chairs the council is accountable when a system fails, and that name goes in the charter.

OvalEdge expert insight: Shared ownership sounds collaborative, but in governance it means nobody is accountable when something breaks. One named person per decision is the minimum standard that holds up under audit.

How to structure an AI governance team

An AI governance team is not a new department. It is named responsibilities assigned to people who already hold other jobs, plus one or two dedicated roles past roughly 20 systems. Organizations building a data governance team at the same time will find the staffing overlap is real.

• AI governance lead. Runs intake, prepares council packets, tracks actions. Usually the data governance lead.
  
  

• Model owner. The named accountable person for one AI system across its life.
  
  

• Model validator. Independently tests a model before approval, sitting outside the build team.
  
  

• Data steward. Confirms the data feeding a model is classified, consented, and traceable.
  
  

• AI Center of Excellence. Sets build standards, tooling, and reusable patterns.
  
  

• Business unit governance lead. The spoke. Runs first-line review against the hub's standards.

The validator cannot report to the person who built the model, or the review is not a review.

AI governance RACI matrix

A RACI matrix clarifies who performs, owns, advises on, and stays informed about each AI governance activity. It prevents approval gaps and makes accountability visible across teams.

Organizations should replace these role names with their actual governance structure. If an activity has multiple accountable roles or no accountable role at all, that is a clear sign that its decision rights need to be clarified.

How to design an AI governance council

A practical council design covers four things: mandate, membership, quorum, and cadence.

Start with mandate. Define which decisions belong to the council, typically high-risk AI approvals, policy exceptions, significant incidents, and escalated governance issues. Keep data policy decisions with the data governance committee even when some members serve on both groups.

Membership should bring together the functions needed to evaluate AI from business, legal, risk, security, and data perspectives. Seven to nine voting members keep the council functional without losing representation.

Quorum specifies who must be present before the council can formally approve or reject. For example, the chair, legal, and either security or risk. Document whether decisions require consensus or a simple majority.

Schedule monthly reviews for routine matters, but high-risk or time-sensitive systems need an out-of-cycle approval route. Define how these requests are submitted, reviewed, and recorded so urgent decisions do not bypass governance.

Document all of this in an AI governance council charter.

What should be documented in the council charter?

The charter formalizes the council's authority and prevents uncertainty about what it can and cannot decide.

The authority limits deserve particular attention. Explicitly documenting what the council cannot approve prevents issues from being routed to a forum that lacks the expertise or mandate to decide them.

At OvalEdge, we believe the most overlooked line in any council charter is what the council cannot decide. A council that lists powers without limits gets asked to judge things outside its expertise, and saying yes to those erodes credibility faster than saying no.

Decision rights, approvals, and escalation

Decision rights define how an AI system moves from review to approval based on its level of risk. They establish which decisions business teams can make independently, which require specialist review, and which must go to the AI governance council. NIST AI RMF GOVERN 3.2 similarly emphasizes defining and differentiating roles for human oversight of AI systems.

For guidance on establishing risk categories, see the AI risk management framework.

1. Map decision rights to AI risk tiers

Each risk tier should specify an approver, required evidence, and expected turnaround. This gives teams a predictable governance path before development or deployment begins.

Published turnaround targets make governance more predictable and help prevent teams from bypassing review because approval timelines are unclear.

Agentic AI requires additional controls because its behavior can extend beyond a single predefined output. An agent may execute multiple actions, operate at machine speed, and inherit user permissions. Approval should therefore cover what the agent is permitted to do, the systems and data it can access, and how its access can be revoked. See how to govern and audit AI agents for additional compliance considerations.

2. Define separate escalation paths

Not every governance issue should follow the same escalation process. Establish distinct routes based on what has happened:

• Exception: A team needs temporary permission to operate outside an established policy. Send it to the council with a documented justification, owner, and expiry date.
  
  

• Incident: An AI system behaves outside its approved boundaries. Escalate immediately to the model owner and relevant security or risk function, followed by council review.
  
  

• Dispute: A business unit challenges a governance decision. Escalate it to the accountable executive for a final, documented resolution.

Separating these routes prevents routine exceptions, operational failures, and disagreements from entering the same review queue.

The board’s role is to oversee AI risk rather than approve individual systems. Quarterly reporting should cover the distribution of AI systems by risk tier, overdue approvals, active exceptions, and significant incidents. Issues involving regulatory exposure, significant customer impact, or unresolved executive disputes should be escalated immediately rather than held for scheduled reporting.

The system of record behind the AI governance operating model

An AI governance council can only govern systems it can see. A shared system of record connects each AI system with its owner, underlying data, applicable policies, and governance decisions. Without it, inventories become outdated, evidence stays fragmented, and systems can operate outside formal oversight.

Visibility starts with the AI inventory. It should cover internally developed models, embedded SaaS AI, and enterprise agents, with a named model owner, data steward, and approving authority for each.

Data context supports governance decisions. Lineage shows how source data reaches an AI system, while classification identifies sensitive or regulated data. Linking policies, risk tiers, and access requirements helps reviewers determine which controls apply.

Decision history provides auditability. Approvals, exceptions, validation evidence, owners, and review dates should remain traceable, especially when governance is distributed across business units.

OvalEdge expert insight: Unified data governance platforms like OvalEdge connect inventory, lineage, classification, and policy mapping in one place so the council reviews each system with its evidence attached, not assembled from five tools the night before.

How to implement an AI governance operating model

You cannot assign decision rights over systems you have not inventoried, and you cannot delegate authority you have not first held. That is why enterprises that start by writing a charter usually rewrite it within two quarters.

The Digital Omnibus on AI entered into force on 27 July 2026, moving Annex III stand-alone high-risk obligations to 2 December 2027 and Annex I obligations to 2 August 2028. Article 50 transparency obligations apply from 2 August 2026 as originally scheduled.

The extra time is for building the structure, not for postponing it, because deployer obligations assume a named owner and a decision record that take longer to establish than to write down.

Phase 1: Establish inventory and ownership

This phase exists because a council with an incomplete inventory approves a subset and calls it governance.

1. Discover every AI system in production, including AI features inside purchased SaaS tools and agents on internal platforms.
   
   

2. Assign one named model owner per system. No system left ownerless; no owner listed as a team.
   
   

3. Assign a data steward to the data feeding each system.
   
   

4. Name the accountable executive in writing before the first council meeting.

Example: A regional bank deployed an AI credit-scoring model without assigning a single owner. When regulators asked who approved it and what training data it used, three departments pointed at each other. No decision record existed, and the model was pulled from production for six months while ownership was resolved.

Move to Phase 2 only once every system has a named human owner and the inventory is refreshed by discovery rather than self-reporting. Self-reported inventories drift inside a quarter.

Phase 2: Define governance and decision rights

This is where authority gets written down, and the council starts deciding.

1. Sign the charter, including what the council cannot decide.
   
   

2. Publish the decision rights table with turnaround targets, so teams can plan around approval rather than around it.
   
   

3. Route every new system through intake, with no exceptions for pilots. Pilots are how most ungoverned AI reaches production.
   
   

4. Record every decision with a timestamp, an approver, and the evidence behind it.

Move to Phase 3 only once the council has run two full quarters without an approval bypassing it and every decision traces to a named approver and evidence. If either is untrue, the structure is not stable enough to delegate.

Phase 3: Move from centralized to federated governance

Move from centralized to federated by delegating authority one risk tier at a time, starting with the lowest, and only once the shared inventory, risk-tier definitions, and evidence standards are stable enough that delegated decisions look the same in every unit.

Unit leads take low-tier approvals first while the council audits a sample each quarter, delegating the next tier only once sampled decisions match what it would have decided itself. Most enterprises stop at hub-and-spoke.

Four triggers signal it is time to move:

• The council spends most of its agenda on low-risk approvals it has never once rejected.

• Approval turnaround exceeds the published target for two consecutive quarters.

• Teams start shipping AI inside SaaS tools that never reach intake.

• More than three business units are building AI independently.

The reverse trigger matters equally: when a sampled audit finds two units classifying the same system at different tiers, pull that tier back to the center until the definitions hold. For the federated data governance mechanics, the data-side principles are worth reading alongside this.

Conclusion

Pick one AI system in production. Trace it from intake to risk tier to approver to the evidence behind the approval to the last review; wherever the trail breaks is the first thing to fix.

An AI governance operating model answers who decides. The record is what makes those decisions hold up.

Most enterprises already have much of this foundation through their existing data governance programs. OvalEdge connects and activates that existing foundation through the Enterprise Context Graph, linking catalog metadata, lineage, classification, ownership, and policy mapping so governance decisions rest on auditable evidence and AI systems can consume trusted context for analytical AI.

Book a demo to see how your AI inventory, ownership, and lineage come together in one governed system of record.