How pilots stall
Six reasons a working pilot never reaches daily use.
The model is rarely the problem. Pilots stall because the requirement can't be tested, the data isn't ready, nobody can build it, risk can't approve it, nobody owns it, or nobody uses it.
Gartner predicted that at least 30% of generative AI projects would be abandoned after proof of concept by the end of 2025, citing poor data quality, inadequate risk controls, escalating costs or unclear business value.1
Shape
“We don't know what good enough looks like.”
What's actually wrong
The requirement was written like normal software. There's no accuracy threshold, no test set and no fallback for when the model is wrong. So nobody can say whether the pilot is ready, and nobody can say it isn't.
What fixing it looks like
We rewrite the requirement as a testable spec: acceptance criteria, an accuracy threshold for each task, a test set drawn from real cases, and what happens when the model is unsure. “Is it ready?” then has an answer.
You might be here if…
- Success was defined as “users like it”.
- Nobody can say what error rate is acceptable.
- There's no agreed fallback when the model gets it wrong.
- Every review ends in “it needs more work”.
Data
“It worked on the sample. Real data is a mess.”
What's actually wrong
The data the pilot needs in production is siloed, ungoverned, poor quality or legally off-limits. The pilot ran on a clean extract that production will never see.
What fixing it looks like
We find the minimum viable data path for the production slice, then fix access, quality and lineage for that slice only, with the data owner's sign-off. Not a data programme: the narrowest route that holds up.
You might be here if…
- The pilot ran on an extract someone cleaned by hand.
- The data sits in several systems with different definitions.
- Legal or data protection hasn't confirmed you can use it this way.
- Nobody can tell you where a field came from.
Delivery
“IT says Q3 next year.”
What's actually wrong
Nobody can do the integration, orchestration and evaluation work a production AI system needs, and there's no reusable platform to build on. The pilot joins the back of the IT queue.
What fixing it looks like
Senior engineers embed with your team and build the production slice: integration with your systems, orchestration, evaluation and monitoring. Your people build it with us, so they can run it after we leave.
You might be here if…
- The pilot was built by a vendor, an innovation team or one enthusiast.
- Production is on a roadmap a year out.
- Nobody in-house has put a language model into production before.
- Every pilot starts from scratch.
Approval
“Risk won't sign it off.”
What's actually wrong
Your governance was built for traditional software, which behaves the same way every time. There's no evidence pack for an AI system, so risk has nothing to approve.
What fixing it looks like
We produce the evidence risk can approve: controls, test results, monitoring, human oversight and an audit trail, mapped to your existing risk framework. We work with your risk team, not around them.
You might be here if…
- Risk has asked questions nobody can answer with evidence.
- Your approval process assumes software behaves the same way every time.
- There's no record of how the model was tested.
- Sign-off keeps moving to the next committee.
Ownership
“Everyone liked the demo. Nobody owns it.”
What's actually wrong
The pilot was built centrally. No business owner is accountable for the outcome, so when it competes for time and budget, nobody fights for it.
What fixing it looks like
We name the business owner, set the measure of success they'll report against, and redesign the process around the tool so the work actually changes, rather than the tool sitting beside it.
You might be here if…
- Technology sponsored the pilot, not the business that would use it.
- Everyone wants it; nobody's targets depend on it.
- There's no agreed measure of success.
- The process around it hasn't changed.
Adoption
“We launched it. Nobody uses it.”
What's actually wrong
No training, no trust and no change management. The tool was bolted onto the old way of working, so the old way of working won.
What fixing it looks like
We roll it out with the team that uses it, make its accuracy visible, give users an easy way to flag errors, measure weekly use, and fix whatever is stopping people from using it.
You might be here if…
- Use fell away after the first fortnight.
- Users check every output by hand.
- Training was a launch email and a recorded demo.
- Nobody measures how often it's used.
Find out where your pilot is stuck.
Twelve questions, five minutes, an answer on screen. Or talk it through with the people who'd do the work.