The operating-model deck was immaculate. Business, data, technology and risk boxes surrounded an AI centre of excellence. Six committees had carefully shaded mandates. When a product team needed to change a production prompt after a customer-impacting defect, nobody could say who could authorise the change, which evidence was sufficient or when the decision would arrive.

The chart described reporting relationships. It did not describe the system of decisions that ran the capability. The product team asked an informal sponsor, risk reviewed operational design, and the actual release happened outside the change record because the next forum was twelve days away. Formal governance remained intact while real authority moved into the shadows.

An AI operating model is the repeatable system by which consequential decisions are made and consumed. It covers outcomes, evidence, data, models, vendors, controls, release, incidents, value, workforce, funding and retirement. Each decision has a question, object, owner, participation rights, constraint, trigger, service expectation, record and condition for review.

The design task is placement. Decisions need proximity to specific knowledge for quality and speed, while enterprise invariants, independent challenge and aggregate exposure remain enforceable. Too much centralisation creates queues without context. Too much distribution fragments evidence and hides common-cause risk.

Original synthesisNine families form the AI decision operating system

The AI decision operating system is this article’s synthesis. It organises recurring decisions across the capability lifecycle without assigning accountability to a committee. A forum may supply input, coordinate or challenge; one named role owns each decision object and its consequence.

The lifecycle is not a waterfall. Portfolio decisions can reopen after an incident; outcome evidence can narrow release; vendor change can alter data authority; retirement can reveal continuing record duties. The system records triggers and downstream consumers so the relevant decision reopens without sending every issue back through every forum.

Organisation design can be understood as information-processing design.[1] Greater uncertainty raises the need to move information or create lateral capacity. The operating system applies that insight to decision objects: evidence goes to a role with the knowledge and authority to act, while repeatable contracts prevent every exchange becoming bespoke negotiation.

A minimum viable system covers consequential release before adding elaborate governance. It identifies the outcome owner, data and model boundary, risk classification, release authority, incident command, recovery state and stop owner. Lower-consequence experimentation can use lighter evidence and faster service, but it still produces an attributable record.

The rival concern is overhead. Explicit decisions can become another bureaucracy if every issue receives a template and meeting. The remedy is deletion and typing. Remove forums that neither decide, produce evidence nor exercise independent challenge. Standardise routine decisions, automate evidence checks and reserve joined authority for genuine boundary conflicts.

Decision placementFormal authority is not the same as the real ability to decide

Specific knowledge is costly to transfer, so decision rights should often move towards the people who hold it.[2] Enterprise risk, shared data and common infrastructure create countervailing needs. Placement separates the accountable decision from input, advice, challenge, veto and constraint rights instead of moving the whole object to a central function.

Formal authority identifies who is entitled to decide. Real authority follows information, expertise, agenda control, incentives and the ability to execute. Research on formal and real authority shows how information acquisition and delegated control interact.[3] A named owner without access to evidence, staff or production permissions cannot exercise the role.

The committee-ownership failure hides this difference. A steering group votes to proceed, yet no person owns the completed outcome, capture receipt or stop decision. Members can later describe themselves as advisers. The operating record instead names the business outcome owner and records which forum supplied portfolio coordination.

Risk-as-product-owner is another failure. Independent risk may classify consequence, set constraints, challenge evidence and veto a breach within its mandate. It should not design the business workflow or become responsible for operating value. Doing so weakens first-line ownership and compromises the independence of later challenge.

Technology authority is similarly bounded. Architecture can enforce enterprise identity, telemetry, data and release invariants. It cannot accept a credit, clinical, employment or customer consequence merely because it owns the platform. The domain owner decides the business object inside those constraints and provides comparable evidence.

IT-governance research focuses attention on decision rights and accountability rather than technology organisation alone.[4] Strategic alignment likewise concerns the relationship between business and technology choices.[5] The operating system extends these ideas across evidence, service time, incidents, value and retirement.

Evidence contractGive each recurring decision a record, trigger and service time

A decision record begins with the recurring question and the object being changed. “Approve AI” is too vague. “Authorise model version M for bounded claims triage under release policy R” identifies the thing, population and consequence. The record can then name one owner and the roles entitled to input, advise, challenge, constrain or approve.

Evidence standards are typed by decision. A portfolio allocation needs outcome thesis, option value, dependency and exposure. A release needs evaluation, control, permission, recovery and change-delta evidence. An incident decision needs observed effects, possible actions, authority and time. Retirement needs records, dependencies, data, contractual and customer duties.

Confidence and missing information remain visible. The standard does not require false certainty; it specifies what uncertainty is acceptable for a reversible test and what cannot remain unknown for an irreversible action. Sponsors cannot move the evidential threshold silently. Exceptions record scope, owner, expiry and compensating control.

Cadence serves predictable decisions, while triggers serve events. Portfolio choices may have a regular review. Drift, incident, vendor change, legal change or material outcome evidence reopens a relevant object immediately. A meeting calendar must not delay a production safety decision or force routine low-risk changes into an emergency process.

Service time is part of governance design. It states when a complete request receives a decision, when the clock pauses for missing evidence and how consequence changes priority. Without it, queues become invisible controls. Teams then escalate through relationships or release outside the record.

The output is a consumable receipt: decision object and version, owner, evidence, challenge, constraints, conclusion, conditions, effective time, expiry and downstream destinations. Production permissions, monitoring, finance, operations and records systems consume it. A slide-minutes archive is insufficient when no operational system can enforce the result.

Consequence and frequencySplit decision paths before centralisation becomes a queue

Decision placement uses at least five properties: consequence, reversibility, frequency, specific knowledge and enterprise-wide exposure. A rare irreversible decision with common-cause risk may need joined enterprise authority. A frequent reversible decision that depends on local workflow knowledge should sit close to the domain inside tested invariants.

Frequency changes the economics of governance. Sending every prompt correction, evaluation update and access change to one central forum consumes scarce context and lengthens feedback. Allowing every high-consequence model or permission change to proceed locally hides correlated exposure. The solution is not an average placement; it is a typed family with distinct consequence bands.

A low-consequence reversible change can use automated contract tests, domain release authority and sampled review. A medium-consequence change may require domain ownership plus independent challenge under a published service time. A high-consequence or difficult-to-reverse change can join business, technical and control authorities, while still leaving the business outcome with the role that owns it.

Federation preserves local decision objects behind shared evidence and constraint contracts. Polycentric governance offers a useful account of multiple centres operating under common rules.[6] The enterprise can mandate identity, provenance, telemetry, prohibited actions and aggregate exposure while domains decide context-specific thresholds and workflow outcomes.

The central-review negative control sends a low-risk prompt clarification and a high-impact permission expansion to the same monthly forum. The low-risk queue grows, domain learning slows and urgent requests acquire sponsor escalations. Meanwhile, the high-impact decision receives too little attention because the agenda treats every item as equivalent.

Splitting the path changes service and evidence, not accountability. The same decision family can have standard, elevated and exceptional routes. Each route names its owner, threshold, evidence, challenge, service expectation and escalation. Teams can predict the path before investing in a request, and central specialists focus where their knowledge changes the decision.

Placement is reviewed when the observed system differs from the design. Repeated exceptions may indicate an unsuitable invariant. Rising aggregate exposure may justify a stronger enterprise constraint. Improved automated evidence may move a routine change closer to the domain. A decision record can therefore be reassigned without redrawing the entire organisation.

Governance flowService-time failure creates bypass loops and shadow releases

A governance queue is an operating queue. Requests arrive with different completeness, urgency and consequence. Reviewers have finite capacity. Rework returns incomplete evidence. Sponsors can jump the queue. Without entry criteria, triage and service time, the process produces the same delay and gaming as any unmanaged workflow.

The shadow-release failure begins when the formal path cannot meet the product’s change cycle. A team updates a prompt, model parameter or tool outside the recorded object, arguing that the change is minor. Monitoring and recovery still refer to the previous version. Later, an incident team cannot reconstruct what acted or which evaluation supported it.

Speed does not excuse unattributed change. The minimum path records the changed object, version, scope, owner, tests, authority, effective time and rollback state. Standard changes can be pre-authorised when their contracts and evidence checks pass. Novel or consequential deltas move to a different route. Automation should remove clerical delay while preserving the decision receipt.

Queue health is measured by arrival, completeness, service distribution, rework, escalation, abandonment and bypass. A fast average can conceal high-consequence ageing. A low bypass count can reflect invisible changes. Configuration and telemetry reconciliation therefore compares production state with authorised receipts and treats unmatched state as an incident.

Escalation belongs to the decision design. It states who acts when the service window will be missed, evidence is disputed, constraint rights conflict or a decision cannot safely wait. Escalation does not mean asking a senior sponsor to approve by reputation. It joins the relevant authorities, preserves dissent and sets a temporary operating state.

Exceptions have expiry and a closing route. The owner must either integrate the change into the standard contract, return to the approved state or stop the capability. Repeated exceptions of the same type are evidence that the service, evidence standard or placement needs redesign. They are not evidence that governance should be ignored.

NIST’s AI RMF Core connects governance, context, measurement and management across the lifecycle.[7][8] Its generative AI profile adds considerations for generative systems.[9] The decision system turns those activities into attributable objects and timed operating routes.

Audit the operating model through decision traces

An operating-model review should sample decisions, not merely inspect governance documents. Start with a consequential production state and trace backwards. Which authorised receipt created it? Which owner acted? What evidence and challenge were available? Did the path meet its service time? Which downstream systems consumed the result? What signal would reopen or stop it?

Trace forwards from a trigger as well. A material drift signal, customer complaint, vendor notice or missing-data event should reach the correct decision object without relying on personal memory. The trace reveals whether monitoring has authority attached, whether escalation preserves context and whether the temporary operating state is safe while evidence is assembled.

A RACI table can describe participation, but it cannot prove the decision worked. Several people may be marked accountable, an approval may lack a constraint mandate, and a consulted role may hold the knowledge that actually determines the outcome. The trace tests the owner’s real information, incentive, service capacity and ability to change the operating state.

Review both completed and abandoned requests. An abandoned change may show that entry requirements were unclear, service time exceeded product need or a sponsor pursued an informal route. Review rejected decisions too. A healthy system preserves the reason and allows later evidence to reopen the object without reframing the entire request around a preferred answer.

Decision quality and decision flow need separate evidence. A prompt decision can be fast and poorly supported; an excellent analysis can arrive after the customer consequence. Quality review examines relevance, uncertainty, challenge and later outcome. Flow review examines completeness, wait, rework, escalation and downstream consumption. Neither measure can substitute for the other.

Informal vetoes deserve particular attention. A function may lack documented constraint authority yet delay access, evidence or implementation until its preference is accepted. Conversely, a formal veto may be unusable because the holder receives evidence too late. The operating-system record either makes the constraint explicit and bounded or removes the shadow power.

Decision load also shapes the model. Count recurring objects by family, route and owner, then compare demand with available attention. An overloaded owner delegates real choices informally or turns evidence review into a signature. Work can be standardised, moved under contract or split by consequence, but outcome accountability cannot be diluted across more names.

The review ends with deletion, repair or reassignment. Delete a forum that produces no decision or challenge. Repair evidence and service when bypass is rational. Reassign a right when the named owner lacks specific knowledge or execution. Strengthen an enterprise constraint when local choices create correlated exposure. Every change has its own owner and review trigger.

Finally, compare the formal path with interviews and production evidence. Ask operators where they seek an answer when time is short, whose disagreement changes the outcome and which approval they regard as ceremonial. Compare those accounts with access logs, configuration state and recorded receipts. The differences expose real authority without assuming that informal work is always wrong. Some lateral coordination should be formalised; some sponsor routes should close; some evidence should move closer to the accountable role. The aim is not to eliminate judgement, but to ensure consequential judgement is visible, supportable and connected to the operating state it changes.

Worked counter-caseA regulated product joins domain outcomes to enterprise constraints

Consider a regulated claims product that uses an AI capability to assemble evidence and propose a triage route. The claims director owns customer and operating outcomes. A portfolio role allocates funding against a thesis and stop condition. Finance validates capture. Neither the steering group nor the delivery programme owns the completed result.

The domain product owner designs workflow states, adjuster authority, exception handling and customer communication. Data owners define claim and policy meaning, permissible use, quality and provenance. A central platform supplies identity, model routing, telemetry and evidence interfaces under enterprise contracts. These decisions exchange records without collapsing into one owner.

Risk classifies consequence and sets required control evidence. Independent validation challenges model performance, limitations and monitoring within its mandate. It does not select the customer workflow or become accountable for service value. Current interagency model-risk guidance emphasises a tailored, risk-based approach for models within its scope.[10]

Release authority is typed. A bounded prompt wording correction can follow a domain standard route after regression, policy, provenance and rollback checks. A model-family change requires elevated technical, domain and independent evidence. A permission change that could alter a claim outcome requires the named business authority inside enterprise constraints.

The release receipt is consumed by production access, telemetry, incident and records systems. It states object, version, cohort, evidence, owner, constraint, recovery and expiry. Configuration reconciliation detects any live state without a matching receipt. The product team can move quickly because routine changes do not wait for an unrelated enterprise agenda.

Incident authority separates command from consequence. An incident commander can contain, suspend permissions and enter a safe state. Claims leadership decides how customer work continues and owns remediation outcomes. Risk and legal exercise challenge and notification rights. The record preserves who made each time-sensitive decision and on which evidence.

Operational-resilience principles emphasise governance, tolerance for disruption, dependencies, incident management and learning.[11] The run family turns those concerns into triggers, service times and recovery decisions. Recovery is not complete when the service restarts; affected state, customer consequence and evidence must reconcile.

Value decisions use finance-owned receipts. Verified flow improvement may be used for service, demand absorption, redeployment or cost. The outcome owner chooses and records the route. If promised capture does not occur, portfolio funding reopens. Favourable model evaluation cannot substitute for an operating decision.

Retirement is a decision family, not a procurement non-renewal. The owner identifies downstream dependencies, customer obligations, records, data disposition, model artefacts, provider access, workforce effects and residual monitoring. The capability closes only when consumers acknowledge the changed state and continuing duties have accountable owners.

The EU AI Act assigns relevant provider and deployer obligations, including human oversight, robustness and deployer responsibilities for systems within scope.[12] Firm-adoption research also points to skills and organisational complements.[13] ISO/IEC 42001 frames policies, roles, objectives and improvement as a management system.[14] These sources inform decision families without transferring business consequence to compliance.

Interactive instrumentAI Decision-System Designer

The designer returns a placement action, owner and missing design element. It does not calculate operating-model maturity. The route follows the most material defect: ambiguous authority, absent evidence and service, collapsed ownership and challenge, an unsplit consequence field, or a forum that produces no decision.

ConclusionOperate the decision system, not the committee calendar

An AI operating model becomes real when recurring decisions have objects, owners, evidence, participation rights, constraints, service times and consumable outputs. Organisation charts can show where roles report. They cannot show whether a production change, incident action, value claim or retirement duty will be decided well and on time.

The nine families provide lifecycle coverage from strategy and capture through workflow, data, models, risk, release, run and disposition. They interact through typed records rather than broad shared accountability. A committee may coordinate a portfolio or hear challenge, but a named role owns the decision and its outcome.

Placement respects both knowledge and enterprise exposure. Frequent reversible decisions can sit close to domains inside automated invariants. High-consequence decisions receive stronger evidence and joined authority without transferring business consequence to technology or risk. Federation preserves local meaning and comparable aggregate evidence.

Governance has an operating performance of its own. Entry quality, service distribution, escalation, bypass and state reconciliation reveal whether the formal path works. A slow route creates shadow authority; an over-broad forum spends scarce expertise on routine changes. Deletion, standardisation and consequence splitting reduce overhead while strengthening attribution.

The durable artefact is the decision receipt. It tells downstream systems what changed, who authorised it, which evidence and constraints apply, when it takes effect and what reopens it. When every consequential operating state can be matched to such a receipt, the operating model has moved from a diagram into the work.

Evidence spineReferences

1. Galbraith, J. R. (1974), ‘Organization Design: An Information Processing View’, Interfaces, 4(3), 28–36. doi:10.1287/inte.4.3.28.
2. Jensen, M. C. and Meckling, W. H. (1995), ‘Specific and General Knowledge, and Organizational Structure’, Journal of Applied Corporate Finance, 8(2), 4–18. doi:10.1111/j.1745-6622.1995.tb00283.x.
3. Aghion, P. and Tirole, J. (1997), ‘Formal and Real Authority in Organizations’, Journal of Political Economy, 105(1), 1–29. doi:10.1086/262063.
4. Weill, P. and Ross, J. W. (2004), IT Governance: How Top Performers Manage IT Decision Rights for Superior Results, Harvard Business School Press. Harvard Business School record.
5. Henderson, J. C. and Venkatraman, N. (1993), ‘Strategic Alignment: Leveraging Information Technology for Transforming Organizations’, IBM Systems Journal. doi:10.1147/sj.382.0472.
6. Ostrom, E. (2010), ‘Beyond Markets and States: Polycentric Governance of Complex Economic Systems’, American Economic Review, 100(3), 641–672. doi:10.1257/aer.100.3.641.
7. National Institute of Standards and Technology (2023), ‘AI Risk Management Framework: Core’. NIST AIRC Core.
8. National Institute of Standards and Technology (2023), Artificial Intelligence Risk Management Framework 1.0, NIST AI 100-1. doi:10.6028/NIST.AI.100-1.
9. National Institute of Standards and Technology (2024), Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1. doi:10.6028/NIST.AI.600-1.
10. Board of Governors of the Federal Reserve System, Office of the Comptroller of the Currency and Federal Deposit Insurance Corporation (2026), ‘Revised Guidance on Model Risk Management’, SR 26-2. Federal Reserve letter.
11. Basel Committee on Banking Supervision (2021), Principles for Operational Resilience. Bank for International Settlements.
12. European Union (2024), ‘Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence’, Articles 14, 15 and 26. EUR-Lex.
13. OECD, Boston Consulting Group and INSEAD (2025), The Adoption of Artificial Intelligence in Firms: New Evidence for Policymaking. OECD Publishing.
14. International Organization for Standardization and International Electrotechnical Commission (2023), ‘ISO/IEC 42001:2023, Information technology, Artificial intelligence, Management system’. ISO standard record.