AI pilots don't need more models.
They need an owner.

A pilot goes well. The model performs cleanly on test data, then on real data. In a demonstration, it produces a recommendation that is more accurate, more consistent, and faster than the manual process it is meant to support. The room is impressed. Someone asks how soon this can move into production.

That question is usually where the real work begins — not before it.

Who owns an incorrect recommendation once the system is live? Who confirms, six months from now, that the data feeding the model is still current and trustworthy? What systems is the AI permitted to touch, and what actions can it take without a person in the loop? When the model returns a low-confidence result, who is supposed to step in? And once it is running quietly in the background, who is actually measuring whether it created value — and who has the authority to switch it off if it did not?

These are not questions model accuracy can answer. They span technology, operating model, risk and accountability. Yet they are often deferred until a pilot begins moving towards production.

The model worked. The enterprise decision structure did not.

A successful pilot can still expose a failed operating model

A pilot is, by design, a narrow and forgiving environment. The scope is bounded. The data has usually been cleaned by someone who understands it well. A person reviews the output before it reaches anyone else. Nothing the model says actually happens until a human decides it should.

Production removes that safety margin. The moment an AI system's output starts to influence — or directly trigger — a real business action, the organisation is no longer testing a model. It is operating a decision system. And a decision system needs the things pilots never require: named owners, defined authority, an exception path, and a way to measure whether the decision was any good.

This is why a pilot can be a genuine technical success and still be nowhere near ready for production. The accuracy score answers whether the model works. It says nothing about whether the organisation is structured to be accountable for what the model does.

Start with the decision, not the model

Most AI conversations I sit in start with the model and work outward: Model → Data → Application → User. It is a reasonable way to describe a technical build. It is an incomplete way to describe what actually happens once the system is live.

The complete picture looks more like this: Business decision → Data → AI → Human or automated action → Consequence → Measurement. The model is one link in that chain, not the whole chain. An AI system does not merely produce an output. Its output can change what the organisation does next — and that is the point at which architecture, not just engineering, needs to be involved.

Enterprise Architecture that only reviews the model or the platform is reviewing one link and calling it the chain. The useful question is never just "does the model perform well?" It is "what happens to the business the moment this output is acted on?"

The five decision rights

Before any AI system moves from pilot to production, five decision rights need a named accountable owner — not a vague shared responsibility.

Outcome ownership is the question most pilots skip because it feels obvious. It is not. A model that supports a lending decision, a staffing decision, or a maintenance decision needs a clearly accountable owner for that decision's quality — the same way it would if a human made the call unaided.

Data ownership is a commitment that outlives the launch date. Pilots run on data someone recently checked. Production runs on data that ages, drifts, and occasionally breaks in ways nobody notices until the output looks strange. Someone has to own keeping that context current, not just supplying it once.

Action authority is the boundary between a system that informs and a system that acts. A recommendation engine and an execution engine carry very different risk, yet they are often approved under the same review, by the same forum, in the same afternoon.

Exception ownership is where most AI incidents actually originate — not in the confident, correct answers, but in the low-confidence or disputed ones nobody was assigned to catch. A system without a named exception owner will eventually let a bad result travel further than it should.

Value accountability closes the loop. Somebody needs to be checking, on a schedule, whether the AI is still earning its cost and its risk — and needs the standing to retire it if it is not. Without this, an AI initiative simply keeps running because stopping it was never anyone's job.

A model that performs well is not the same as a decision that is owned.

The ownership gap

None of these five rights are usually missing entirely. That is what makes the gap hard to see. A business sponsor owns the budget. A data team owns the pipelines. A development team owns the model. A security team owns the access controls. An operations team owns uptime. Each piece has an owner.

What nobody owns is the whole decision — from the moment the AI is consulted to the moment the consequence lands and someone checks whether it was worth it. Five component owners is not the same as one accountable decision. The gap sits precisely in the handoffs between them, and handoffs are where accountability quietly disappears.

This is a recurring pattern well beyond AI. Complex environments fail less often from a missing capability than from a missing owner of the whole chain. AI simply makes the pattern more visible, because its output moves fast enough that the gap becomes a live incident rather than a slow drift.

What Enterprise Architecture should do

Enterprise Architecture should not be selecting every model, sitting in every AI sprint, or approving every prompt. That is not architecture; it is a bottleneck wearing an architecture badge. Its responsibility sits a level higher, and it is narrower than it sounds.

Before an AI initiative scales, architecture should be able to confirm that:

• The business outcome the system is meant to change is written down in plain language.
• Decision ownership — all five rights — is named, not assumed.
• The data, identity, and access boundaries the AI operates within are understood and enforced.
• The points where a human must intervene are designed in, not left to hope.
• The operational consequences of the AI being wrong, slow, or unavailable have been accepted by someone with the authority to accept them.
• Value remains measurable after deployment, on a cadence someone actually follows.

This is a governance conversation, not merely a technical review. It must begin early and be revisited as the data, autonomy, risk and operating conditions change. The initial discussion can be short. The accountability cannot be temporary.

The AI Decision Accountability Test

Ten questions, asked before scale-up, tend to surface the gap faster than any architecture document.

1. Which business decision will change?
2. Who makes that decision today?
3. What information does the AI require?
4. Who owns the quality and currency of that information?
5. Which systems can the AI access?
6. What actions may it recommend or execute?
7. When must a human intervene?
8. Who owns an incorrect or disputed outcome?
9. How will measurable business value be established?
10. Who can suspend the AI after the project team leaves?

If any of these ten questions returns silence rather than a name, the initiative is not ready to scale — regardless of how well the model performed in the demonstration.

Closing

Most enterprises do not need another committee that reviews AI presentations and nods them through. They need named owners for decisions, for exceptions, for consequences, and for value — the same discipline that has always separated a working operating model from a collection of capable components.

The model can be excellent and still be sitting inside an organisation that has not decided who is responsible for what it does. That is not a reason to slow down AI adoption. It is a reason to finish the architecture before the rollout, rather than after the first disputed outcome.

AI becomes an enterprise architecture concern when its output begins changing what the organisation does.