Why AI pilots never reach production

A Voice of the Enterprise survey of over a thousand IT and line-of-business professionals across North America and Europe found that organizations scrapped an average of 46% of their AI proof-of-concepts before they reached production.¹ Gartner separately predicted that at least 30% of generative AI projects would be abandoned after proof of concept by the end of 2025.² Both figures are global, not Swiss. Industry data shows the same pattern from two angles: a lot of AI work gets started, and a lot of it never ships.

Most of the prototypes behind these numbers probably worked, in the narrow sense of producing a plausible output. They failed on sequence. Teams built before they had priced the idea, checked that the data existed, or defined the evidence that would show whether it succeeded. Each failure below maps onto a stage of work that catches it before it gets expensive.

Failure 1: nobody can say what the project is worth

A project gets approved because AI is a strategic priority this year, without anyone naming the number it has to move. That number could be cost per claim processed, hours reclaimed per case or defect rate on a line. Without a named metric and an accountable owner, a project can run for a year, spend its budget and never produce a verdict. It is neither cancelled nor proven.

The first stage, Stage 01 · Ground the case, prevents this with a written business case before any production code. It names the metric, the owner and the baseline to beat.³ If the value case does not survive being written on one page, it will not survive a budget review either. Better to learn that in week one than in year one.

Failure 2: the data was never there

This failure shows up mid-build and is almost always avoidable. A team assumes the data exists, is accessible and is clean enough to use. It learns otherwise only after the schedule and budget are committed. The data might sit in a system nobody can legally reach, or be too inconsistent after a decade of manual entry for a model to learn from.

A data check on the sources a use case depends on, scored on completeness, accuracy, accessibility and lineage, catches this before the build starts.³ At that point it is still a scoping conversation, not a stalled project. The check usually takes a fraction of the time the failure costs later.

Failure 3: an impressive prototype that never moved the number

A prototype demos well, everyone in the room is impressed, and eighteen months later nobody can point to the metric it was supposed to move. A proof of concept asks whether something can be built, and almost anything can. A proof of value asks whether it moves the number named in stage 01, and answers with evidence. Evaluation before you build shows what that evaluation looks like, adversarial cases included.

Failure 4: it worked on a laptop, not in production

Many AI initiatives that survive a good prototype die at the next step. Something that works once, on curated data, on one machine, is a long way from a system that runs under load on the organization’s own systems. That system needs monitoring, access controls, governance and the documentation an audit will ask for. That is why the engineering stage treats production readiness as the deliverable, not a working demo.³

Failure 5: it shipped, and nobody used it

A system can be live and unused: a success in the status report, ignored on the floor. People keep doing the task the old way, route around the new tool, or were never told when to trust it and when to override it. Model quality has nothing to do with it. What matters is whether anyone redesigned the workflow, trained the people using it and built a feedback loop that shows where the tool is still avoided.

Failure 6: it drifted until an audit found it

A system gets marked complete and handed off, and from then on it drifts. Its accuracy falls as the world it models changes, and its compliance lapses as regulation moves. Nobody notices until an incident or an audit forces the question. An AI system needs a standing owner and a regular review cadence, not a one-time sign-off.

What the six have in common

All six are sequencing failures, and each was visible early to anyone checking. Building AI work in fixed stages, each with a named deliverable and a named failure mode, guards against each one. The KARPINITY method sets out the six stages and which stage catches which failure. If you are earlier than that, the AI opportunity assessment is the fastest, cheapest way to find out whether an idea clears the first hurdle.

Footnotes

1. S&P Global Market Intelligence, “Generative AI experiences rapid adoption, but with mixed outcomes - Highlights from VotE: AI & Machine Learning,” March 2025, based on a Voice of the Enterprise survey of 1,006 IT and line-of-business professionals across North America and Europe: organizations scrapped an average of 46% of AI proof-of-concepts before they reached production. Global data, not Switzerland-specific. https://www.spglobal.com/market-intelligence/en/news-insights/research/ai-experiences-rapid-adoption-but-with-mixed-outcomes-highlights-from-vote-ai-machine-learning ↩

2. Gartner, “Gartner Predicts 30% of Generative AI Projects Will Be Abandoned After Proof of Concept By End of 2025,” press release, 29 July 2024. Global data, not Switzerland-specific. https://www.gartner.com/en/newsroom/press-releases/2024-07-29-gartner-predicts-30-percent-of-generative-ai-projects-will-be-abandoned-after-proof-of-concept-by-end-of-2025 ↩

3. See the KARPINITY method for the full six-stage structure, each stage’s deliverable, and the specific failure mode it exists to prevent. ↩ ↩² ↩³