Designing an AI Operating Model with Clear Decision Rights and Learning Loops

An AI operating model works when recurring decisions have named owners, evidence requirements, escalation routes and review triggers. Without that machinery, an approved strategy can still stall: a business unit cannot tell who may fund a pilot, a risk forum reviews exposure it cannot accept, and a central team becomes the queue for choices that belong closer to the work. The practical answer is a decision-rights register covering standards, funding, delivery, risk, production and reuse, connected to forums that turn operating evidence into durable decisions.

Which decisions must the operating model assign?

The model must assign every consequential, recurring decision across the AI lifecycle. That includes choices made before work starts, at release and while a system is operating, not merely approval at an intake gate. NIST frames governance as continual and connected to organisational priorities, with clear roles, communication, monitoring, periodic review and executive responsibility. Current lifecycle guidance likewise spans strategy, funding, prioritisation, risk review, release, monitoring, value reporting, incident response, improvement and retirement.

• Enterprise standards and guardrails: platforms, architecture, risk tiers, evaluation minimums, monitoring expectations and exceptions.
• Portfolio funding and prioritisation: exploration, shared capability, domain delivery, scaling, changed funding and retirement.
• Initiative delivery and adoption: workflow redesign, product delivery, domain knowledge, adoption and realised outcomes.
• Risk assessment, assurance and acceptance: classification, review, control verification, residual exposure and incident escalation.
• Production operation and lifecycle: performance, value, adoption, incidents, drift, intervention, improvement and retirement.
• Reuse and capability learning: reusable components, evaluations, standards, training assets, vendor rules and ongoing maintenance.

Map the actual decisions inside each domain rather than assigning a broad activity such as ‘govern AI’. Keep organisational authority separate from authority delegated to an AI system. MIT CISR distinguishes how humans and autonomous AI may participate in framing, acting and learning according to ambiguity and risk; the operating model must separately say which enterprise role may approve that allocation, monitor it and intervene. Blurring the two questions can leave a technically bounded system with no accountable business owner.

What belongs in a usable decision-rights register?

A usable register needs one precise row for each decision, not a broad statement of shared accountability. Scope the row so a team can tell whether it covers an enterprise standard, a domain initiative, a production service, an exception or a portfolio allocation. A single accountable role should sit at its centre. Delivery, consultation and assurance can involve several people, but the row must show who has formal authority to decide and who takes over when escalation is triggered.

• Decision name and scope, including the service, initiative, domain or enterprise boundary.
• One accountable role and any responsible or permitted delegates.
• Required evidence and the minimum controls that must be demonstrated.
• Roles consulted for business, technical, security, privacy, legal or regulatory context.
• Independent-assurance roles, kept distinct from authorisation where appropriate.
• Decision deadline or service expectation, set for the relevant context.
• Escalation trigger, escalation owner and authority available at that level.
• Event that reopens the decision and the durable location of its rationale and evidence.

Test the register at organisational seams. Microsoft's adaptable example places platform strategy, architecture, monitoring standards, risk tiers and guardrails centrally, while domains own prioritisation, knowledge, local measures and lower-risk improvement within those boundaries. The useful lesson is the interface, not the vendor's role names. If the hub and domain each think the other owns funding, production performance, residual risk or maintenance of a reusable asset, the register has exposed a gap that an organisation chart would hide.

An AI operating model becomes real when every important decision has an owner, an evidence path, an escalation route and a reason to be reopened.

Where should each AI decision sit?

Each decision should sit where authority, context and lifecycle capability best meet its consequences. Centralised, federated and hub-and-spoke arrangements divide rule-setting, delivery and production monitoring differently, and they can be blended. Centralisation can strengthen consistency and enterprise visibility but create queues. Federation can increase parallel delivery and domain ownership but permit standards or evidence to drift. Hub-and-spoke combines shared guardrails and capability with distributed delivery, so its interfaces must be unusually explicit.

Use the table row by row rather than declaring the whole enterprise centralised or federated. Standards might remain central, delivery might sit with business units, and production intervention rights might be shared under explicit triggers. The resulting pattern matters less than whether each interface names its owner, evidence, limits and escalation path. These trade-offs are directional, so test the allocation against live work instead of treating any structure as a guaranteed cure for delay, duplication or drift.

How should review forums produce durable decisions?

Review forums should convert defined evidence into a recorded choice exercised by a named role. The meeting is not the accountable owner: it may coordinate, challenge, advise or provide assurance, but formal authority remains with the role identified in the register. Each output should state the decision, rationale, owner, affected funding or resources, next evidence requirement and review trigger. Set cadence and escalation thresholds according to risk, decision latency and operating context rather than copying a universal calendar.

• Standards and exceptions: receive the request, affected standard, risk and interoperability evidence, time boundary, compensating controls and proposed owner. Record approval, rejection, a constraint or a time-limited exception, plus whether the standard changes and what reopens the decision.
• Initiative evidence: compare the original hypothesis and baseline with business outcomes, workflow and adoption evidence, technical performance, operating cost, incidents, risk findings and limitations. Record scale, change, pause, stop or retirement, along with funding, ownership and the next evidence need.
• Portfolio and strategy learning: aggregate comparable initiative decisions, recurring blockers, exceptions, value and cost ranges, capability gaps, incidents, drift and reuse evidence. Record any change to priorities, funding, shared capability, standards, sourcing rules or decision rights, with a named owner and rationale.

The forums form one evidence path rather than three layers of status reporting. Lifecycle guidance provides a practical inventory from intake and risk classification through release, monitoring, value reporting, incidents, improvement and retirement. NIST also connects monitoring and feedback with management actions such as recalibration, mitigation, removal and control changes. A centre or hub can maintain the portfolio, methods, platforms, reusable assets and measures, but those functions do not require it to approve every initiative.

How does pilot evidence become strategy learning?

Pilot evidence becomes organisational learning only when it can change a named portfolio or strategy decision. Begin with a hypothesis, baseline, accountable owner, intended outcome and risk boundary, then state what evidence could support scaling, changing, pausing or stopping. Activity counts may describe participation, but they should not replace evidence about business outcomes, workflow effects, adoption, technical performance, operating cost, incidents, risk findings and known limitations.

1. State the initiative hypothesis, baseline, owner, intended outcome, risk boundary and possible decisions.
2. Capture business, workflow, adoption, technical, cost and risk evidence with its limitations.
3. Record the initiative decision and its immediate funding and ownership consequences.
4. Extract any reusable component, evaluation, standard, vendor rule, training need or workflow pattern.
5. Compare lessons across initiatives before treating one pilot as an enterprise signal.
6. Exercise the named right to retain or revise priorities, funding, capabilities, standards, sourcing rules or structure.
7. Publish the update to affected owners and set the next evidence or review trigger.

This complete loop is a reasoned operating method, not a validated formula for financial performance. NIST's Govern and Measure functions support traceable evidence, monitoring, feedback, review and management action across the lifecycle. IBM describes a centre of excellence as capable of maintaining an opportunity portfolio, common platforms, reusable assets, governance methods and measures linking technical work with business outcomes. Together they support the component practices, while the end-to-end portfolio loop remains an editorial synthesis.

When should decision rights move inward or outward?

Move a specific decision right when operating evidence shows that its current location is failing, rather than relabelling the entire model. Blended structures can evolve, and guidance identifies both central bottlenecks and federated standards drift as warning signs. The World Economic Forum describes movement towards federated or hybrid oversight as one possible progression as practices mature, while retaining leadership responsibility and separation of duties; it is not a universal maturity path.

• Consider moving a right outward when local teams can own the full lifecycle, common controls remain enforceable, evidence quality is reliable and a central queue is materially delaying action.
• Consider moving a right inward when standards or vendors drift, platforms are repeatedly duplicated, evidence fragments, incidents recur, cross-domain exposure grows or local lifecycle ownership remains weak.
• Preserve a mixed allocation where it works: standards can remain central while delivery moves outward, or intervention rights can move inward while bounded, lower-risk improvement remains local.

Start with the six domains, then select a small set of consequential recurring decisions and complete the register. Test it against one live initiative and one exception, routing both through the relevant forums. Review whether decisions were timely, evidence was sufficient, escalation worked and outputs changed funding, ownership, standards, reuse or strategy as intended. Revise the interfaces before expanding coverage. Where consequential exposure or regulated obligations are involved, the model should route interpretation to qualified legal, regulatory, security, privacy, risk or other professional functions with formal authority.