Design an AI Operating Model With Real Accountability

Where a pilot stops and a service begins

Most organizations can run an AI pilot. They struggle at the point where the pilot has to become something people depend on. Someone has to decide who signs off a change that fixes an error, who answers a complaint from a team that lost a shortcut, and who decides whether the tool may keep reading customer records while the data steward is on leave. If the answer to each of those questions is "the project team", the capability is still an experiment. An operating model is the set of decision rights, routines and records that lets the business run the capability without the people who built it.

This page is written for the person who inherits that problem: a head of service, a transformation lead, or a chief information officer who has seen one promising use case work and now has to decide how the next several are governed. It is less about choosing technology and more about deciding which decisions move to which people, and what evidence each person needs before acting. Readers who have not yet settled which service they need can start with the AI services overview and come back here once a specific pilot is on the table.

Which decisions need a named owner before the second use case

A workable operating model starts from decisions rather than from an organization chart. Each recurring decision needs one accountable person, a short list of people who must be consulted, and a record of what was decided. For most AI services those decisions fall into five groups: whether a use case may start, what the tool is permitted to read and write, when its output may be relied on without human review, when it must be paused, and whether a change to its model, prompt or data source needs fresh approval.

The table is missing one role that many frameworks place at the top: a single "AI owner" who decides everything. A central function can keep the standards, maintain the inventory of services and run the review calendar. It should not be the place where a credit limit, a triage rule or a customer refund is accepted on behalf of the business. Those decisions belong to the people who answer for the outcome, and the operating model should say so in plain terms.

How central coordination and local accountability fit together

Organizations usually settle on one of three shapes. In a central model, one team owns the platform, the standards and most approvals. It starts quickly and stays consistent, but it becomes a queue once several business units want changes in the same month, and it gradually loses touch with what the tool is actually doing day to day. In an embedded model, each business unit runs its own AI services with its own tools and rules. Local knowledge is strong, but controls drift apart, the same data is evaluated three different ways, and nobody can say which services touch a given customer record. A federated model keeps a small central group responsible for the things that must be identical everywhere, and leaves context-dependent choices with the business owner.

The federated arrangement is a common outcome, and it only works when the boundary is written down. A practical test is to list the last five AI-related decisions the organization made and ask, for each, whether the person who made it would have been allowed to make it under the proposed model. Where the answer is unclear, the boundary is not yet specific enough.

• Central: the inventory of services, the minimum evaluation standard, logging requirements and the register of approved tools.
• Local: the decision to deploy into a process, the acceptance criteria for that process, the staffing of reviewers and the handling of complaints.
• Shared: changes that affect more than one service, such as a new shared data source or a switch of model provider.

What a handover from pilot to service should require

The handover is where most operating models are first tested. A pilot is often run by enthusiastic people with close access to the builders, which makes it look better than it will be once a support desk takes it on. The operating model should define entry criteria for that handover. The evaluation was run on cases drawn from live work rather than hand-picked examples. The support route has been tested by people who did not build the tool. The rollback has been rehearsed. A named person has agreed to own the service after the project team leaves. The AI consulting and implementation page covers the delivery side, and the delivery plan and the ownership plan have to agree with each other.

Post-release review matters as much as approval. A service that was reasonable at launch can become unreasonable when request volume doubles, when a source system changes the meaning of a field, or when users begin pasting information into the tool that the original design never anticipated. Set a review point at release and tie it to observed signals, not only to the calendar.

Support, change and disablement as routine operations

Many AI services are judged by how they behave on a bad day. The operating model should describe the routine that applies when a user reports a wrong output: who investigates, how long the investigation may run before the service is restricted, and who holds the authority to restrict it. It should also describe what happens when the person who understands the prompt design or the data mapping is unavailable for a two weeks. If the only documentation lives in one engineer's notes, the service is being kept alive rather than operated. The human oversight and observability page covers AI observability and human oversight in operations.

Change needs its own route. Providers update models, staff edit prompts with good intentions, and source teams reorganize data without knowing that an AI service depends on it. A change log that records what changed, who approved it and what was tested is the minimum. The service is only as stable as its least visible dependency, and that dependency is often a field in another team's table.

Disablement should be designed before anyone needs it. The question is direct: if this service must stop tomorrow, can the business continue the process by hand, and does anyone know how to switch the tool off without waiting for a release? Writing those answers down is uncomfortable, which is why teams tend to skip it until an incident forces the question.

What a review of the operating model should examine

Once the service is running, its own records are the best source of improvement. Incidents, exceptions, reviewer disagreements, unusual usage patterns and decisions made by the service owner all show where the boundaries are too loose or too tight. A regular review of these records, held with the people who actually make the decisions, changes the operating model more than any framework document does. Where the same exception has been granted repeatedly, the exception has become the process, and the written process should be rewritten to match.

Some of those signals will point to controls rather than to the operating model itself. When an approval record turns out to be incomplete, the fix is usually in the controls, which the AI governance and risk controls page frames around approved use, audit evidence and exceptions. The operating model decides who acts on the finding; the control defines what the finding looks like.

Questions buyers ask about AI operating models

Does a central AI team remove the need for business ownership?

No. A central team can keep standards and the inventory consistent, but it cannot know whether a service level or a triage rule is acceptable to the people who live with its results. Those are domain decisions, and the model should name the domain owner for each one.

How many roles does a smaller organization need?

Fewer than large frameworks suggest, but the roles still have to exist. In a small team one person can hold more than one role, provided the conflicts are visible. The person who builds a service should not be the only person who accepts its evaluation results.

When should the operating model be designed?

Before the second pilot is approved, not after the first has succeeded. The first use case is often forgiving because its builders are close by. The second is where the gaps between teams start to show.

What if nobody wants to own a service?

Then the service should not go live. An unowned tool carries risk that no one has agreed to accept, and that risk will usually be discovered through an incident rather than through a deliberate decision.

What to bring to a first conversation

A useful first discussion about an operating model starts with a short list of the services already in use or proposed, the people who currently make decisions about them, and the last decision that was contested. You do not need a finished governance design. You need to show where decisions are made today, even informally, so the boundary can be drawn from real work. From there the conversation can move to who should own each decision, what evidence each owner needs and how often the model should be reviewed. The governed enterprise strategy page covers building an enterprise AI strategy around use-case selection, data boundaries and delivery ownership, which suits teams whose pilot list is still open. Teams that already have a live pilot needing an owner should discuss their AI operating model with us before the next release date is fixed, and the AI adoption and change enablement page covers changed work, decision rights and review responsibilities for the people affected.