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

A working AI operating model is a repeatable system for deciding, funding, delivering, governing, operating and learning. Strategy stalls when authority is left implicit: a pilot waits for funding, an exception has no authorised owner, or production problems bounce between a central team and a business unit. The remedy is a decision-rights register that names who decides, what evidence they need, what they may delegate, when escalation applies and what event reopens the decision.

Which decisions must an AI operating model assign?

An AI operating model must assign the recurring decisions that move work from an idea to responsible retirement. It should show how each decision is owned, supported by evidence, escalated, recorded and reviewed. NIST frames AI risk governance as continual and connected to organisational priorities, with clear roles, communication, monitoring, periodic review and executive responsibility. That makes an operating model more than a strategy document, committee list or reporting line.

Begin with six domains that together expose the main interfaces. Current lifecycle guidance spans strategy, funding, prioritisation, risk review, release, production monitoring, value reporting, incidents, improvement and retirement, although the allocation must fit the organisation. Grouping those responsibilities consistently makes omissions visible before leaders debate whether the organisation is centralised, federated or hybrid.

• 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 business outcomes.
• Risk assessment, assurance and acceptance: classification, review, control verification, residual exposure and incident escalation.
• Production operation and lifecycle: service performance, value, adoption, drift, intervention, improvement and retirement.
• Reuse and capability learning: reusable components, evaluations, standards, training, vendor rules and ownership of shared assets.

Keep organisational authority separate from the decision rights built into an AI-enabled system. MIT CISR distinguishes how humans and autonomous AI can participate in framing decisions, acting and learning according to ambiguity and risk. The operating model must address both questions without confusing them: one allocates authority between enterprise roles; the other defines how people and AI participate in a particular operational decision.

What should a usable decision-rights register contain?

A usable decision-rights register contains one precisely scoped row for every consequential decision and names one accountable role. A row must make clear whether it concerns an enterprise standard, a domain initiative, a production service, an exception or a portfolio allocation. Several people may deliver, advise or provide independent assurance, but collective participation must not obscure who has formal authority to decide.

1. Name the decision and its scope so teams can recognise when the right applies.
2. Record one accountable role and any responsible or permitted delegates.
3. Specify the evidence and minimum controls required before a decision can be made.
4. Name consulted roles and independent-assurance roles without merging their duties with authorisation.
5. Set a service expectation appropriate to the decision rather than promising a universal turnaround time.
6. Define the escalation trigger, the escalation owner and the authority available at that level.
7. State what event reopens the decision, such as new evidence, an incident, material drift or an expiring exception.
8. Identify the durable location for the decision, rationale, evidence, conditions and next review trigger.

This register turns vague accountability into an interface that teams can test. Microsoft's adaptable agent-centre example places platform strategy, architecture, monitoring standards, risk tiers and guardrails centrally, while domains own prioritisation, knowledge, local KPIs, lower-risk operation and improvement within those guardrails. NIST remains non-prescriptive about structure but calls for clear roles, documented processes and review. The World Economic Forum also separates leadership responsibility from assurance duties, although its playbook is guidance rather than a binding standard.

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 necessary authority, context and lifecycle ownership can be sustained. Microsoft describes centralised, hybrid and federated patterns that divide rule-setting, delivery and production monitoring differently, and notes that organisations may blend them. The useful question is therefore not which label wins, but which allocation best fits each decision domain while preserving explicit interfaces and escalation rights.

Microsoft and IBM describe the trade-offs as directional rather than guaranteed: centralisation can strengthen consistency while creating bottlenecks, federation can distribute ownership while allowing drift, and hybrid arrangements need clear interfaces. Hub-and-spoke is one such hybrid. Its hub may own common platforms, standards, enablement, registries and reusable capability, while spokes own domain priorities, delivery, adoption and bounded operation. Ambiguity returns if both sides assume the other owns funding, residual risk or production performance.

How should review forums turn evidence into durable decisions?

Review forums should exercise rights held by named roles and finish with durable decisions, not status commentary. Every output should record the decision, rationale, owner, affected resources, next evidence requirement and review trigger. NIST connects monitoring and feedback with actions including recalibration, mitigation, removal and control changes. The meeting supports that action; it does not become the accountable owner simply because several functions attend.

• A standards-and-exceptions forum receives the affected standard, exception request, risk and interoperability evidence, time boundary, compensating controls and proposed owner. It records approval, rejection, constraint or a time-limited exception, together with any standard change and review trigger.
• An initiative-evidence forum compares the original hypothesis and baseline with outcomes, workflow and adoption evidence, technical performance, operating cost, incidents, risk findings and limitations. It records scale, change, pause, stop or retirement, including funding consequences, ownership and the next evidence requirement.
• A portfolio-and-strategy forum aggregates comparable initiative decisions, recurring blockers, exceptions, value and cost ranges, capability gaps, incidents, drift and reuse evidence. It records any justified change to priorities, funding, shared capability, standards, sourcing rules or decision rights.

Set cadence and escalation conditions according to risk, decision latency and available operating evidence rather than imposing a universal calendar. Microsoft's lifecycle guidance supplies a practical inventory spanning intake, prioritisation, risk classification, release, monitoring, value reporting, incidents, improvement and retirement. IBM describes how a centre or hub can maintain portfolio evidence, governance methods, common platforms, reusable assets and value measures, although a formal centre of excellence is not the only unit able to do so.

How does pilot evidence become portfolio and strategy learning?

Pilot evidence becomes portfolio and strategy learning only when it reaches a named decision and changes what the organisation does. Activity counts alone do not establish an outcome. The evidence path must start with a testable initiative proposition and continue through an initiative decision, a reusable lesson, comparison across the portfolio and an explicit strategy update. NIST connects traceable evidence, monitoring, feedback, review and management action across the lifecycle.

1. State the hypothesis, baseline, accountable owner, intended outcome and risk boundary.
2. Define the evidence that could support scaling, changing, pausing or stopping.
3. Capture business outcomes, workflow effects, adoption, technical performance, cost, incidents, risk findings and limitations.
4. Record the initiative decision with its funding and ownership consequences.
5. Extract any reusable component, evaluation, standard, vendor rule, training need or workflow pattern, including evidence that reuse is unwarranted.
6. Compare lessons across initiatives before treating one result as an enterprise signal.
7. Exercise the named right to retain or revise a priority, assumption, allocation, shared capability, standard, sourcing rule or structure, then publish the update and its review trigger.

IBM describes a centre of excellence as capable of maintaining an opportunity portfolio, common platforms, reusable assets, governance methods and measures connecting technical work with business outcomes. The complete loop above is a reasoned editorial synthesis of that portfolio guidance and NIST's evidence-and-feedback model. It is not a validated formula for financial performance, and one pilot should not automatically prove or disprove an enterprise strategy. The breadth and consistency of the evidence determine how far the lesson can travel.

When should decision rights move inward or outward?

Decision rights should move when operating evidence shows that their present location no longer provides timely, controlled lifecycle ownership. Change the specific right that is failing rather than relabelling the entire enterprise model. Microsoft's guidance allows blended structures and warns about central bottlenecks and federated standards drift. NIST likewise calls for governance roles, processes and controls to be reviewed and adjusted using organisational monitoring and feedback.

• Consider moving a right outward when a local team can own the full lifecycle, common controls remain enforceable, evidence quality is reliable and a central queue is materially delaying action. Standards can remain central even when contextual delivery moves closer to the business.
• Consider moving a right inward when standards or vendor choices drift, platforms are repeatedly duplicated, evidence fragments, incidents recur, cross-domain exposure grows or local lifecycle ownership remains weak. Production intervention may move centrally while bounded improvement stays local.
• Treat maturity as context, not destiny. The World Economic Forum describes a possible move from central cross-functional coordination towards federated or hybrid oversight while retaining leadership responsibility and segregation of duties, but it does not establish a universal path.

To draft or repair the model, inventory the six domains and select a small set of consequential recurring decisions. Complete the register, then test it against one live initiative and one genuine exception. Route both through the three bounded forums and examine whether decisions were timely, evidence was sufficient, escalation worked and outputs changed ownership, funding, standards, reuse or strategy as intended. Revise the interfaces before expanding coverage. Where decisions involve regulated obligations or consequential exposure, the register should identify the appropriately authorised legal, regulatory, security, privacy, risk or other professional roles rather than attempting to replace their judgement.