Who Runs This Thing? The Question That Kills More AI Programmes Than Bad Technology

The technology worked. The experiment delivered the numbers. The steering group approved scaling. Six months later, the capability was still technically running, but nobody was reviewing the outputs, the integration had broken twice without anyone noticing, and the team had quietly gone back to doing it the old way.

Ownership failed, not the capability itself.

I've seen this pattern before, in CRM rollouts and BI dashboard deployments long before AI arrived. The difference is that an unowned BI dashboard produces stale reports. An unowned AI system produces confidently wrong outputs that people act on, and the failure stays invisible until something goes visibly, expensively wrong.

The ownership gap

The project team that built the capability moves on to the next experiment. IT assumes the business owns it because they're the users. The business assumes IT owns it because it's a piece of technology. The vendor assumes someone is monitoring quality because that's what the contract said would happen.

Nobody owns it, and the gap is a governance problem with a clear fix, provided you ask the question before you need the answer.

Five questions define operating model clarity:

• Who owns the capability day to day?
• Who maintains the technology?
• Who monitors quality?
• Who handles exceptions?
• Who is accountable for outcomes?

In most organisations that have run experiments and reached the scale decision, the honest answer to most of these is "unclear" or "assumed, not confirmed." That assumption is where AI capability goes to die quietly.

What an unowned capability looks like

A multi-category retailer had technically stable AI demand forecasting running in two of its buying functions. Twelve months after launch, the tool was still running, the outputs were still going into the planning system, and nobody had reviewed them against actual performance in eight months.

The underlying model had drifted as the product mix changed. The data pipeline was pulling from a legacy source that had been partially superseded in an ERP update. The buying team had stopped trusting the outputs around month four, after a few high-profile calls went wrong, but nobody escalated it or raised a review. They were generating AI-assisted forecasts and then adjusting them manually before use, paying for an AI layer and ignoring it.

The technical function knew the system was running. The business function knew the outputs were unreliable. Neither owned the problem clearly enough to fix it. That's the ownership gap made concrete.

Four operating model options

There's no single correct structure for AI ownership, but there are four established models, and the right one depends on where you are in AI maturity.

The Embedded in IT model places responsibility with the technology function: IT builds, maintains, and monitors everything. It works for early-stage organisations with a limited AI portfolio, but it creates distance between the capability and the business problem it's meant to serve.

The Centre of Excellence model puts a small central team in charge of standards, tool evaluation, and vendor relationships, while business functions own their capabilities day to day and are accountable for outcomes. Most consumer businesses land here, because it balances consistency with proximity: two to four people at the centre, named owners in each function.

The Federated model embeds AI ownership entirely within business functions, each owning its capabilities end to end. It works for large organisations with mature digital functions, but the risk is fragmentation: inconsistent standards, duplicated effort, no mechanism for sharing what's been learned.

The Hybrid model combines central coordination and functional ownership in whatever mix fits the organisation's structure, often the practical evolution of a Centre of Excellence as the AI portfolio grows.

How to choose

The choice comes down to three variables: how mature the AI capability is, how many capabilities are running or planned, and where the relevant expertise currently sits.

Organisations at an early stage, running one to three capabilities out of the programme team or IT, do best embedding ownership in IT with named business owners attached. Developing organisations, running three to seven capabilities across a mix of IT and business, tend to need a Centre of Excellence. Established organisations with seven or more capabilities distributed across functions do better federating ownership with central coordination. Organisations scaling a large, multi-function portfolio with a strong internal AI function tend to run a hybrid, evolving toward federation.

Most consumer businesses at the experiment-to-scale transition belong in the Centre of Excellence group: a technical AI lead transitioning from the experiment programme, a capability owner responsible for the portfolio, and a governance lead, often a part-time role combined with another function.

The model you start with isn't permanent. Define it clearly enough to work now, and plan the evolution as maturity grows. The AI Transformation Playbook at transformationplaybook.ai has an assessment that helps pin down which of these four models fits where you are.

The role nobody creates

The single most common omission in AI operating models is the AI Capability Owner.

The AI Capability Owner is a product management role applied to the AI capability portfolio: prioritising the development backlog, coordinating between the technical team and business functions on requirements, reviewing performance against business case commitments, and reporting to leadership on the state of the portfolio.

The role doesn't get created because it doesn't map neatly onto existing org structures. It sits between IT and the business, between the programme team and the operational functions that inherit what the programme built, so organisations default to assuming someone in IT owns it, or someone in the business does, and neither is quite right.

The role needs enough commercial understanding to manage the capability backlog against business priorities, enough technical literacy to hold credible conversations with the AI and data teams, the authority to escalate performance issues without being blocked by functional boundaries, and protected time, at least two days a week at the outset, to do it properly.

It doesn't need to be a permanent senior hire from day one. In many organisations it starts as an explicit responsibility added to a capable mid-senior person in a commercial or operational function, with the expectation that it grows into a standalone role as the portfolio grows. What it can't be is an afterthought. This role is where an AI programme's continuity lives. Without it, every capability the programme builds will gradually lose coherence and value.

Answer it before you need to

The ownership question isn't interesting while the experiment is running. The experiment team owns it, the governance structure is clear, and everyone knows what they're doing. It becomes critical the moment the project team moves on, which is exactly when most organisations discover they've never answered it.

Build the operating model before you scale. Name the owners. Protect their time. Define the quality thresholds and the escalation paths. Review the business case commitments on a cadence that reflects the risk profile of the capability.

The AI programmes that keep their returns are the ones where someone is still actively responsible for the capability twelve months after the experiment team shipped the first version. Put that ownership structure in place while the experiment is still running, and it survives the handover.