Why AI Projects Stall Between Pilot and Production.
The pilot worked because it never touched your systems of record. Why AI projects fail between pilot and production.
Why AI Projects Stall Between Pilot and Production.
Key Takeaways
- The pilot worked because it never had to touch your systems of record. Almost everything else follows from that.
- RAND puts around 80 percent of AI projects as failing to deliver their intended business value, which is not the same as the models not working.
- Deloitte research reported by Forbes found 60 percent of leaders naming integration with legacy systems as the primary obstacle.
- A model cannot fix a field nobody has filled in for four years, so the data is usually the constraint.
- Pilots have a sponsor, a deadline and visible attention. Production has none of those unless somebody arranges them.
A pilot runs on an extract. Someone pulled a sample into a spreadsheet or a sandbox, the model performed well against it, and everyone in the room saw something impressive. Production has to read live data, write results back somewhere people act on them, respect permissions, and keep working when the source schema changes.
None of that was tested. The pilot proved the model was capable, which was rarely the thing in doubt.
If you have partnered with an AI vendor and the integration has stalled, the cause is usually sitting between the model and your existing systems rather than inside the model. Our post on AI solutions for businesses covers what the technology does well, and this one covers what stops it reaching production.
The pilot worked. That was never the hard part.
The Failure Rate, and What the Number Actually Measures
RAND found that around 80 percent of artificial intelligence projects fail to deliver their intended business value, roughly double the failure rate of other technology projects.
That figure gets quoted everywhere and explained almost nowhere, which matters because it is routinely misread. It does not say 80 percent of models did not work. It says they did not deliver the business value they were commissioned for.
Those are different failures with different fixes. A model that performs well on its metric and never reaches the people whose work it was meant to change has failed by this measure while working perfectly by its own.
What the 80 percent figure measures, and what it does not.
Read that way, the number stops being an argument against AI and becomes an argument about delivery. It is a statement about organisations rather than about models, which is also why the remedies are organisational.
Adoption in the UK is still early. Government research puts 16 percent of UK businesses currently using artificial intelligence, so most organisations reading this are making the decision for the first time and have no internal precedent to learn from.
Integration With Legacy Systems is the Wall
The single most cited obstacle is not model quality or skills. Forbes, reporting a 2025 Deloitte study, found 60 percent of leaders identified integration with legacy systems as the primary barrier to scaling artificial intelligence.
That matches what stalled projects look like from the inside. The model is ready, and the system it needs to read from has no API, or has one nobody has used in years, or exposes the data in a shape that loses the context the model needs.
Where it stalls | What it looks like | What it actually needs |
|---|---|---|
No interface to the source system | "We are waiting on the other team" | An integration built and owned |
Data available but not in context | Model accuracy drops in production | Joining data the pilot got pre-joined |
No route to write results back | Output lands in a report nobody opens | A destination inside the existing workflow |
Permissions unresolved | Pilot ran as an administrator | Role-aware access, designed in |
Source schema changes | Worked in March, wrong by June | Version pinning and monitoring |
That fourth row causes more delay than people expect. Pilots routinely run with unrestricted data access because it was quicker, and production cannot, so the permissions model has to be designed after the fact against a system that already assumed it did not need one.
This is ordinary engineering rather than anything exotic. The integration layer underneath is the same work any system-to-system connection requires, which is why it is frequently nobody's job on an AI programme staffed for data science.
Your Data is the Constraint, Not Your Model
A model cannot fix a field nobody has filled in for four years.
Pilots are run on curated extracts, often assembled by the person who knows the data best. Production reads whatever is actually there, including the records where the free-text notes field carries information that should have been structured, and the years where a process changed and nobody backfilled.
Four data problems that surface only in production.
Four questions are worth answering before any scaling decision. Whether the data is complete enough for the task, who owns it and can authorise its use, whether you have the rights to process it for this purpose, and where it is allowed to sit.
The last two are not technical and they stop projects just as firmly. A model that needs data the organisation cannot lawfully use for that purpose is not a technical problem with a technical fix.
Getting the data in order first is unglamorous and it is usually the shortest route to a working system. Teams resist it because it delays the interesting part, and then spend longer debugging model behaviour that was a data problem all along.
Nobody Owns It After the Pilot
Pilots have a sponsor, a deadline and visible attention. Production has none of those unless somebody arranges them.
The evidence on this is fairly stark. Research by Emergn, reported by IT Brief UK, found only 7 percent of UK leaders said every such programme is formally tracked and reported to the board.
If ninety-three percent of programmes are not consistently visible at board level, most are being judged on enthusiasm rather than on evidence. That is a reasonable description of how a project stalls without anyone deciding to stop it.
Stage | Who typically owns it | Who needs to |
|---|---|---|
Pilot | An innovation or data team | Same, this works |
Integration build | Frequently nobody | Engineering, with a named lead |
Production launch | Assumed, rarely assigned | A business owner, not a technical one |
Ongoing accuracy | Nobody | Someone accountable for the outcome |
Model and data drift | Nobody | Monitoring, with an alert to a person |
The two rows that say nobody are where projects go quiet. They are also the cheapest rows to fix, because assigning ownership costs a conversation.
What It Costs to Stall
The UK figures are large and worth attributing carefully, because both come via trade press reporting research rather than from official statistics.
Emergn research, reported by IT Brief UK, put UK losses at about 67 billion pounds a year on failed transformation and artificial intelligence work. Separately, the Centre for Economics and Business Research with Trustpilot estimated that negative artificial intelligence experiences cost UK retail firms around 8.6 billion pounds, as reported by UKTN.
Treat both as indicative rather than precise. They are commissioned research reported second hand, and the methodology behind headline economic figures of this kind is rarely published in full.
The second number is the more interesting one anyway. It measures harm from AI that did reach customers and performed badly, which is the failure mode that a stalled project at least avoids. Shipping something half-integrated is worse than not shipping.
A Realistic Path From Pilot to Production
The pattern that works puts the integration work before the scaling decision rather than after it.
Start with integration discovery. Before committing to production, establish what interfaces exist, what the data actually looks like at full volume, who owns it, and where results need to land. This is a short piece of work and it is the step most programmes skip.
Then build a thin production slice. One workflow, real data, real permissions, a small group of real users, running properly rather than as a demonstration. The goal is to prove the seams rather than the model.
Only then scale, with monitoring and a named owner attached before go-live rather than after. Proving it small before scaling is the same discipline that applies to any product, and AI does not earn an exemption from it.
Three stages, and what has to be true before each one starts.
The thin slice is the part teams most want to skip, because a pilot already worked and repeating it at small scale feels like going backwards. It is not the same exercise. The pilot tested the model and the slice tests everything around it.
What to Stop Doing While It is Stalled
A stalled programme tends to attract activity that feels like progress and is not.
Running another pilot is the commonest. If the first one proved the model works, a second proves it again and answers none of the questions that are actually blocking you.
Changing model is the second. Teams switch provider hoping the new one integrates more easily, and discover the integration work was never about the model. The interfaces, the permissions and the data quality are all still exactly where they were.
The third is waiting for the vendor. If integration into your systems of record sits outside their contract, waiting is not a plan, and the months spent waiting are the months the business case was supposed to be paying back in.
Three responses to a stalled programme that feel productive and are not.
What does move things is smaller and less satisfying. Establish what the source systems can actually expose, get a named owner for the integration, and agree what a thin production slice would have to do to count as working.
That is usually a few weeks of unglamorous work. It is also the difference between a programme that resumes and one that is quietly defunded at the next budget round.
How to Evaluate an AI Integration Partner
Most of the difficulty is integration engineering, so evaluate for that rather than for model expertise you may not need.
Ask | A good answer | A concerning one |
|---|---|---|
Have you taken an AI pilot to production | A named example, with what went wrong | Pilots and demonstrations only |
Who builds the integrations | Named engineers on the team | A partner, undefined |
How do you handle our data | Specific on residency, access and retention | General reassurance |
What happens when the model underperforms | Monitoring, thresholds, a named owner | It will be fine |
Who owns the model and the code | You, in writing | Ambiguous, or theirs |
What does handover look like | Documentation, access, a period of support | Not been asked before |
Arch builds AI products and prototypes as a development team rather than as a model vendor, which puts us on the integration half of the problem. You can see our AI development work and what AI software development looks like when it is treated as software delivery.
Frequently Asked Questions
We Partnered With an AI Vendor but Integration is Stalling. Why?
Most often because the vendor supplies the model and assumes your systems will meet it halfway. The integration work is real engineering and it is frequently outside the vendor's scope and outside your own team's plan.
Ask who is contractually responsible for reading from and writing to your systems of record. If the answer is unclear, that is the stall.
Which Solutions Are Best for Businesses Adopting AI at Scale?
AI solutions for business challenges scale on integration and governance more than on model choice. What matters is whether the systems holding your data expose it cleanly, whether ownership and permissions are resolved, and whether somebody monitors accuracy after launch.
Choosing a model before answering those is choosing the easy part first.
What Are the Main AI Integration Challenges?
Legacy systems without usable interfaces, data that is incomplete or lacks the context the pilot's extract had, unresolved permissions, no route to put results into an existing workflow, and no owner after launch.
Understanding why AI projects fail is mostly a matter of recognising that every item on that list is ordinary software delivery rather than anything specific to AI.
How Long Should Pilot to Production Take?
The integration discovery is usually weeks. The thin production slice depends almost entirely on how many systems it touches and how well documented they are.
Any estimate offered before someone has looked at the source systems is a guess. That is true of building an AI application generally, and it is where optimistic timelines come from.
Is the 80 Percent Failure Rate a Reason Not to Start?
It is a reason to start differently. The figure measures business value delivered, not models that worked, and the gap between those is mostly delivery and ownership.
A smaller first commitment with the integration work funded properly is a better response than either avoiding the technology or scaling a pilot that never touched production. Our post on artificial intelligence development covers what that looks like as a programme.
About the Author
Hamish Kerry is the Marketing Manager at Arch, where he's spent the past six years shaping how digital products are positioned, launched, and understood. With over eight years in the tech industry, Hamish brings a deep understanding of accessible design and user-centred development, always with a focus on delivering real impact to end users. His interests span AI, app and web development, and the transformative potential of emerging technologies. When he's not strategising the next big campaign, he's keeping a close eye on how tech can drive meaningful change.
You can catch up with Hamish on LinkedIn
Sources
- RAND Corporation, The Root Causes of Failure for Artificial Intelligence Projects, 13 August 2024. https://www.rand.org/pubs/research_reports/RRA2680-1.html
- Forbes Business Council, The Real Reason AI Projects Stall Inside Enterprises, reporting a 2025 Deloitte study, 2 June 2026. https://www.forbes.com/councils/forbesbusinesscouncil/2026/06/02/the-real-reason-ai-projects-stall-inside-enterprises
- IT Brief UK, UK businesses lose £67 billion on failed AI work, reporting Emergn research, 1 July 2026. https://itbrief.co.uk/story/uk-businesses-lose-gbp-67-billion-on-failed-ai-work
- Department for Science, Innovation and Technology, AI adoption research, 28 January 2026. https://www.gov.uk/government/publications/ai-adoption-research/ai-adoption-research
- UKTN, Negative AI experiences are costing UK businesses billions, reporting Centre for Economics and Business Research and Trustpilot, 31 October 2025. https://www.uktech.news/ai/negative-ai-experiences-are-costing-uk-businesses-billions-20251031
- Arch, AI software development solutions, 2026. https://wearearch.com/services/ai-software-development-solutions