The AI operating model: ownership, measures and decision rights.

As AI activity expands, organisations often respond by creating governance: an AI council, standards, an intake process and a portfolio dashboard.

Those mechanisms can improve coordination and control. They do not by themselves create an operating model.

An operating model explains how work and decisions happen. For AI, it should answer:

• Who chooses which opportunities deserve attention?
• Who owns whether value appears?
• How are capabilities built and tested?
• How are data, technology and risk decisions made?
• What changes when evidence is weak or strong?
• Who operates and improves the capability after launch?

1. Business ownership of value

Every material AI opportunity needs a named business owner accountable for the outcome. That person does not need to manage every delivery task. They do need to own the value hypothesis, the relevant workflow change and the decision to scale, revise or stop.

Technology can own reliability and architecture. Data can own data products and quality. Risk can set control requirements. Product can own the capability. None should be left carrying a financial outcome the business has not owned.

Make the distinction explicit:

• Outcome owner: accountable for the business result.
• Capability owner: accountable for product performance and improvement.
• Workflow owner: accountable for how the work operates end to end.
• Control owners: accountable for security, privacy, compliance and model risk.

One person may hold more than one role in a smaller business. The decisions still need to be clear.

2. A value-led opportunity system

The operating model should define how opportunities enter, progress and leave the portfolio.

A useful sequence is:

1. Frame the material outcome.
2. Inspect the relevant work.
3. Define the value hypothesis.
4. Assess strategic fit, value, time, workflow leverage and feasibility.
5. Approve bounded Build and Prove work.
6. Review evidence against pre-agreed thresholds.
7. Scale, revise, defer or stop.

This prevents the intake process from rewarding the volume and enthusiasm of proposals rather than the quality of the value case.

3. Cross-functional teams around the workflow

AI opportunities rarely fit within one function. A team may require business expertise, frontline users, product, engineering, data, design, security, legal, risk and change capability.

Organise that team around the outcome-producing workflow, not around a sequence of departmental handoffs. Give it enough autonomy to test assumptions quickly within clear control boundaries.

The core team should be small. Specialists can join at the point their expertise affects the decision.

4. Decision rights that change with the stage

The decisions needed during exploration are different from those required for scaled operation.

Find and focus

Decide whether the opportunity is material and which uncertainty matters.

Build and prove

Decide scope, test conditions, controls and whether evidence justifies another increment.

Embed and scale

Decide target workflow, investment, architecture, ownership, workforce change and benefits realisation.

Avoid applying full production governance to a low-risk exploratory test, but do not use the pilot label to evade controls that are already material. Governance should be proportionate to consequence and reversibility.

5. Measures across four levels

A balanced AI operating model tracks:

1. Capability performance — accuracy, reliability, latency, cost and failure modes.
2. Behaviour and workflow — adoption, action, review burden, exceptions and cycle time.
3. Operational outcome — quality, capacity, conversion, cancellation, service or risk.
4. Financial or strategic value — revenue, margin, cost, working capital or defensible capability.

Activity measures such as users, prompts or pilots can help explain adoption. They should not substitute for the outcome.

6. Staged funding linked to evidence

AI work often begins with imperfect information. Funding should reflect that reality.

Use bounded stages with explicit decisions:

• a small amount to understand and focus;
• enough to build a Minimum Viable Capability;
• further investment only when evidence improves;
• production and transformation funding when the capability and value mechanism are credible.

This is not an argument for underfunding. It is an argument for matching commitment to the quality of evidence while acknowledging that meaningful operating change may require multi-year support once the direction is proven.

7. A shared technical and data foundation—only where shared value is real

Platforms, models, data products, evaluation, observability and security controls can create leverage across opportunities. The operating model should identify genuine common components and assign ownership.

Avoid building a comprehensive foundation in anticipation of a portfolio that has not been validated. Allow leading opportunities to reveal which shared capabilities are actually needed.

The architecture should make approved capabilities easier and safer to build without turning standardisation into delay.

8. Human judgement and workforce design

The model must define how human judgement changes:

• which decisions remain human;
• where review is mandatory or sampled;
• what expertise is required;
• how accountability is maintained;
• how exceptions are escalated;
• how feedback improves performance;
• what old work is removed;
• how roles, capacity and incentives change.

“Human in the loop” is a starting phrase, not an operating design.

9. Control, evaluation and incident response

The required controls depend on consequence. Define:

• approved and prohibited uses;
• data handling and privacy;
• evaluation before and during use;
• model and prompt/version control;
• output monitoring and auditability;
• security and supplier management;
• human override and fallback;
• incident classification, escalation and learning.

Controls should make responsible action possible, not simply make experimentation slower and less visible.

10. Capability transfer and continuous improvement

A scaled capability will change as models, data, user behaviour and business conditions change. Ownership cannot end at deployment.

Build routines for:

• ongoing evaluation;
• user feedback and exception analysis;
• value tracking;
• model and workflow improvement;
• retirement of weak or redundant capabilities;
• review of controls as consequence changes.

The organisation should know how to improve the system and when to replace or stop it.

A practical operating-model canvas

For each material AI capability, document:

The standard to use

A strong AI operating model makes value and decisions easier to own. It connects the technical capability to the workflow and the workflow to the business result. It allows the organisation to move quickly where consequence is low, govern rigorously where it is high and stop activity that does not earn further investment.