Where AI pilots stall – and what to do first

Most AI pilots don’t fail on the technology. They stall in 5 predictable places – and the first move is rarely another pilot.

In short

  • Pilots stall on ownership, benefits and governance – not models.
  • Replace ‘hours saved’ with a business measure you can baseline.
  • Agree production criteria before the pilot starts, not after.
  • Fix one stalled pilot that matters before launching another.

Most organisations now have more AI pilots than they can name. Many of them work. The model performs, the demo impresses, the steering group nods. And then nothing much happens.

The pilot doesn’t fail. It stalls. It sits in a state of permanent promise – too successful to stop, never quite ready to scale. Ask why and you’ll hear about data, security or budget. Look closer and the cause is almost always organisational rather than technical.

Getting from AI pilot to production is an operating-model problem, not a model-building problem. Here is where pilots get stuck, and what to do first.

Why AI pilots succeed technically and stall anyway

A pilot is designed to answer a narrow question: can this technology do this task? It is usually run by a technology or innovation team, with friendly data, enthusiastic users and protection from business-as-usual pressures.

Production asks entirely different questions. Who will use this every day? What changes in their work? Who pays to run it? Who signs off the risk? What happens when it gets something wrong? A pilot that was never designed to answer those questions will reach the end of its timeline with a successful demo and no route forward.

In our experience, pilots stall in 5 predictable places.

The 5 places AI pilots stall

1. Nobody in the business owns it

The pilot was sponsored by a technology or innovation team. It was built for a business area rather than with it. When the time comes to change how that business area works, nobody there has signed up to do it.

A pilot without a business owner is a solution looking for a home. It will stay in the lab because no one outside the lab is accountable for getting value from it.

2. The benefit is expressed as time saved

“This saves each analyst 4 hours a week” is the most common benefit statement in AI, and one of the least useful. Time saved is a theoretical benefit until someone decides what happens to that time. If the answer is “people will do more valuable work”, the next question is which work, measured how.

Finance teams know this, which is why pilots built on time-saved arguments struggle to secure production funding.

3. Governance has become a permanent blocker

Data protection, information security, legal and model risk all have legitimate questions. The problem isn’t the questions; it’s that they arrive late, one at a time, with no agreed route to a yes. The pilot passes every technical test and then waits indefinitely for a review that nobody owns.

4. The workflow hasn’t changed

The AI has been bolted onto the existing process. People still do every step they did before, plus one more: checking what the AI produced. Unsurprisingly, the gains disappear. Real value comes when the work itself is redesigned around what people and machines can each do well.

5. There’s no route from pilot to production

Nobody agreed, before the pilot started, what it would need to prove in order to be scaled – or what it would cost to run. So when it finishes, the organisation starts a fresh debate rather than taking a decision.

“A pilot that cannot fail cannot really succeed either.”

What to do first

The instinct, when pilots stall, is to launch another one. Resist it. The first move is to take one stalled pilot that matters and answer 5 questions about it honestly.

1. Who in the business will own the outcome? Not the system – the outcome. If you can’t name a person with the authority to change the work, find one before you spend anything else.

2. What business measure will move? Replace hours saved with something that shows up in performance: cycle time, error rates, cost to serve, revenue per customer, cases resolved. Baseline it now, before anything else changes.

3. What must the work look like afterwards? Map the current workflow and redesign it. Decide which tasks the AI does, which people do, and where human review sits. If nothing in the workflow changes, expect nothing in the numbers to change either.

4. What are governance’s actual conditions? Get data, security, legal and risk into one conversation and ask a different question: not “is this allowed?” but “what would we need to see to say yes?” Write the answers down. They become your production criteria.

5. What would make us stop? Agree, in advance, the evidence that would justify scaling and the evidence that would justify stopping.

BEFORE THE PILOT

Name the owner, the measure and the production criteria.

AFTER THE PILOT

Take the decision you agreed to take. Scale, change or stop.

Taking stock of your whole AI portfolio

Once one pilot is moving, apply the same discipline to the rest. Run an honest inventory: every pilot, who owns it, what it costs, what it has changed. Expect the list to be longer than anyone admits.

Then rank each one on 2 axes – the value if it works, and the distance to production. Fund the few that score well on both. Park the rest with a date to revisit, and stop the ones that have no owner and no measurable benefit. Fewer, better-backed use cases will create more value than a long tail of experiments competing for the same scarce attention.

Data readiness deserves a specific mention. Programmes that try to fix “all the data” before scaling AI tend to finish with nothing. Fix data in the order your prioritised use cases need it, starting with the fields the first one depends on.

Fewer pilots, clearer choices

Organisations that get value from AI tend to run fewer pilots than those that don’t. They are quicker to stop the ones going nowhere and more deliberate about the ones they back. They put a business owner on every use case, measure in business terms and bring governance in at the start.

That’s less exciting than a new demo. It’s also how experimentation turns into enterprise performance.

Common questions

Why do most AI pilots fail to reach production?

Usually for organisational reasons rather than technical ones: no business owner, benefits expressed as theoretical time savings, late and sequential governance reviews, unchanged workflows, and no agreed criteria for scaling.

How do you move an AI pilot to production?

Name a business owner for the outcome, define a business measure and baseline it, redesign the workflow, agree governance conditions up front, and set explicit criteria for scaling or stopping before the pilot ends.

How many AI pilots should an organisation run at once?

Fewer than most do. Back a small number of use cases with clear owners and measurable value, and stop or park the rest. Breadth of experimentation is rarely the constraint; follow-through is.

Is time saved a valid AI business case?

Only if you can say what happens to the time. Time saved becomes real value when it reduces cost, increases capacity for specific work, or improves a measurable outcome.

What this looks like in practice

A health-tech scale-up we’re working with asked for a data governance readiness diagnostic, not a full audit – one that told leadership where its regulatory exposure was and what to fix first, ahead of investor due diligence. That’s the pattern: decide what matters, then build only what that needs. Read the case study →

AI Value & Scale

AI scaling

Operating model

Benefits realisation

Let’s deliver outcomes, together.

Get in touch→