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

An AI strategy becomes executable only when the organisation assigns its recurring decisions: who may fund an experiment, approve a release, accept residual risk, intervene in production and convert a local lesson into shared capability. A useful operating model therefore works as a decision system, not merely an organogram, committee list or centre-of-excellence charter. It names the accountable role, the evidence that role needs, the permitted delegation, the escalation route and the event that reopens each decision. Without that interface, central teams become queues, business units work around guardrails and pilot findings rarely alter the portfolio.

Which decisions must an AI operating model assign?

An AI operating model must assign consequential decisions across six domains before leaders compare organisational structures. NIST frames AI risk governance as continual work aligned with organisational priorities, with clear roles, communication, monitoring, periodic review and executive responsibility. Microsoft’s lifecycle guidance likewise spans strategy, funding, prioritisation, risk review, release, production monitoring, value reporting, incidents, improvement and retirement. Together, these sources support an inventory that follows work from initial choice to eventual withdrawal.

• Enterprise standards and guardrails: approved platforms, architecture patterns, risk tiers, evaluation minimums, monitoring expectations and exceptions.
• Portfolio funding and prioritisation: exploration, shared capability, domain delivery, scaling, funding changes and retirement.
• Initiative delivery and adoption: workflow redesign, domain knowledge, product delivery, 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, improvement, intervention and retirement.
• Reuse and capability learning: reusable components, evaluations, standards, training assets, vendor rules and accountable maintenance.

Keep these organisational rights separate from the rights granted to an AI system. MIT CISR’s decision matrix examines how ambiguity and risk shape human and AI participation in framing, acting and learning. The operating-model question is different: it allocates authority among enterprise roles that decide whether, where and under what conditions such participation is allowed. Both layers must be explicit, but a system’s permission to act can never identify which executive, product, service or risk role owns the organisational decision.

What should a usable AI decision-rights register contain?

A usable decision-rights register contains one precisely scoped decision per row and one accountable role for that decision. Scope matters: approving an enterprise standard is not the same decision as releasing a domain initiative, accepting an exception or funding a shared platform. Microsoft’s adaptable agent-CoE example illustrates the distinction by placing platforms, architecture, monitoring standards, risk tiers and guardrails centrally while domains own priorities, knowledge, local measures and bounded operation within those guardrails.

• Decision and scope, including the initiative, service, standard, exception or portfolio allocation covered.
• One accountable role and any responsible or permitted delegates.
• Required evidence, minimum controls and the decision’s service expectation.
• Consulted roles and independent-assurance roles, kept distinct from authorisation.
• Escalation trigger, escalation owner and the authority available on escalation.
• Review trigger and the durable location of the rationale, evidence and resulting action.

The register should expose incomplete interfaces rather than conceal them behind collective language. NIST calls for clear roles, documented processes, communication and executive responsibility, while the World Economic Forum playbook supports explicit leadership responsibility and separation between authorisation and assurance. A forum may advise, coordinate or verify controls, but it should not replace the named leader authorised to accept consequential exposure. Testing each row against live work quickly reveals when the hub and a business unit both assume the other owns funding, production performance, residual risk or maintenance.

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 AI decision should sit where the required context, authority and lifecycle capability can meet without weakening enterprise controls. Centralised, federated and hub-and-spoke structures are allocations, not maturity grades. Microsoft and IBM describe directional trade-offs: centralisation can improve consistency while creating bottlenecks; federation can strengthen domain ownership while allowing standards and evidence to drift; hybrid arrangements combine shared capability with distributed delivery but need explicit interfaces.

Hub-and-spoke is a particular hybrid. The hub commonly owns shared platforms, standards, enablement, registries and reusable capability, while spokes own domain priorities, delivery, adoption and bounded operation. An enterprise need not choose one label for every row. Standards can remain central while delivery sits in business units; shared-capability funding can be enterprise-wide while domain leaders fund adoption and own the outcome case.

How should review forums turn evidence into durable decisions?

Review forums should turn defined evidence into durable decisions exercised by named roles. NIST links monitoring and feedback to management actions such as recalibration, mitigation, removal and changes to controls. Microsoft’s lifecycle guidance identifies decisions from intake and risk classification through release, monitoring, incidents, improvement and retirement. The practical implication is that each forum needs bounded authority, standard inputs and a recorded output; a meeting that produces only commentary has not completed the decision.

• Standards and exceptions: receive the request, affected standard, risk and interoperability evidence, time boundary, compensating controls and proposed owner. Record approval, rejection, constraint or a time-limited exception, together with the review trigger.
• Initiative evidence: compare the hypothesis and baseline with outcomes, adoption, workflow effects, technical performance, operating cost, incidents, risk findings and limitations. Record scale, change, pause, stop or retirement, plus funding and ownership consequences.
• 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 or decision rights.

Every output should name the decision, rationale, accountable owner, affected resources, next evidence requirement and review trigger. The forum’s cadence should follow risk, evidence availability and decision latency rather than a universal calendar. A centre or hub can maintain the portfolio, governance methods, platforms, reusable assets and value measures, as IBM describes, but a formal centre of excellence is not the only structure capable of that work. What matters is an authorised path from evidence to action.

How does pilot evidence become portfolio and strategy learning?

Pilot evidence becomes strategy learning only when it travels through a complete, recorded decision loop. Begin with a hypothesis, baseline, accountable owner, intended outcome, risk boundary and the evidence that could support scaling, changing, pausing or stopping. Capture business outcomes, workflow effects, adoption, technical performance, operating cost, incidents, risk findings and known limitations. Activity counts may explain participation, but they should not substitute for evidence about the intended outcome.

1. State the hypothesis, baseline, owner, outcome, risk boundary and decision-relevant evidence.
2. Capture business, workflow, adoption, technical, cost and risk evidence.
3. Record the initiative decision and its funding and ownership consequences.
4. Extract any reusable component, evaluation, standard, vendor rule, training need or workflow pattern.
5. Compare lessons across initiatives before declaring an enterprise-wide signal.
6. Retain or revise the relevant priority, funding allocation, shared capability, standard, sourcing rule or decision right.
7. Publish the update to affected owners and set the next evidence or review trigger.

This loop is a reasoned editorial synthesis, 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 portfolio stewardship, reusable assets, common platforms and measures connecting technical work with business outcomes. Those foundations justify a disciplined evidence path, but not the assumption that one successful pilot warrants enterprise scale or that one failed pilot disproves the strategy. Broader change requires evidence of a broader signal.

When should AI decision rights move inward or outward?

AI decision rights should move when operating evidence shows that the present allocation is failing, not because a new organisational label is fashionable. Microsoft’s guidance allows blended and evolving structures while identifying central bottlenecks and federated standards drift. NIST similarly expects policies, processes, roles and controls to be reviewed and adjusted using monitoring and feedback. Change the specific right at fault: standards may remain central even when delivery moves outward, while production intervention may move inward without removing local improvement authority.

• Consider moving a right outward when local teams can own the full lifecycle, common controls remain enforceable, evidence is reliable and the central queue materially delays action.
• Consider moving it inward when standards or vendor choices drift, platforms are duplicated, evidence fragments, incidents recur, cross-domain exposure grows or local lifecycle ownership remains weak.
• Retain independent assurance and executive responsibility where the exposure requires them, regardless of where delivery sits.
• Update the register, delegates, escalation route, evidence requirements and durable records when authority moves.
• Test the revised interface against live work before extending the change across the portfolio.

Start small: inventory the six domains, select a manageable set of consequential recurring decisions and complete the register. Test it against one live initiative and one exception, then route their evidence through the three bounded forums. Review whether decisions were timely, evidence was sufficient, escalation worked and the outputs changed ownership, funding, standards, reuse or strategy as intended. Revise the interfaces before expanding coverage. Where regulated obligations or consequential exposure are involved, route interpretation to the authorised legal, regulatory, security, privacy or organisational risk specialists rather than expecting the operating model to replace their expertise.