Pilot Graveyard

A pilot tests, under controlled conditions, whether an AI application can handle a task in the business. It ends up in the pilot graveyard when no decision follows: the prototype exists, but nobody adopts and supports it, and nobody officially shuts it down. The same pattern is often called pilot purgatory. The term has appeared in consulting literature since at least 2018, back then for digital projects in manufacturing.

Many pilots stall at the handoff to operations, not at the technology. The trial showed that something can work. Routine operation takes more: a proven benefit, data that is accessible and cleared for use, quality that holds up in daily work, and someone who supports the application and reviews its output. If any of these is missing, the pilot stays where it is.

For leadership, this is a management question. Every stalled pilot ties up budget and attention without leaving a usable result. When such cases pile up, teams lose faith in the next initiative. Whether a pilot goes into operation, gets reworked or ends is a leadership decision, made on a date that is fixed before the pilot starts.

What the studies show, and what they don't.

The best-known figure comes from "The GenAI Divide: State of AI in Business 2025" by MIT NANDA, a research initiative at MIT, published in July 2025. It draws on more than 300 publicly disclosed AI initiatives, interviews with representatives of 52 organizations and a survey of 153 senior leaders, collected between January and June 2025. According to the report, 95 percent of organizations get no measurable return from their generative AI investments. Success there means deployment beyond the pilot with measurable KPIs. The authors themselves call the findings preliminary and point to possible sample bias.

In July 2024, Gartner predicted that at least 30 percent of generative AI projects would be abandoned after proof of concept by the end of 2025, due to poor data quality, inadequate risk controls, escalating costs or unclear business value. That is a forecast, not a measurement. In November 2025, McKinsey reported from a survey of 1,993 participants that nearly two-thirds of respondents say their organizations have not yet begun scaling AI across the enterprise.

The numbers differ because each study defines success differently. Their shared finding: the gap sits between trial and operation. Anyone quoting one of these figures should give the source and the definition too.

Four reasons pilots get stuck.

The reasons fit into four questions every pilot has to pass, one after another.

First, benefit: is it clear which work gets measurably shorter, cheaper or better? A pilot that starts with "let's see what AI can do" ends without a result anyone can base a decision on. Second, data: is the data needed accessible, current and cleared for this purpose? A trial often gets by with a few hand-picked examples. In operation, the application needs ongoing access to systems that other people run.

Third, quality: is it good enough for every case in daily work, exceptions included, and can it be checked with reasonable effort? The MIT authors name tools that fit poorly into existing workflows and don't learn from feedback as the main reason pilots stall. Fourth, ownership: who supports the application, who reviews its output, who pays the running costs? This question is especially easy to put off, because nobody misses it in the prototype. In daily work, it's missing on day one, when nobody takes on support.

If any answer is no, the pilot needs a decision: rework it, pause it or end it.

Why the handoff to operations gets underestimated.

A pilot runs under favorable conditions. The cases are hand-picked, the testers motivated, the developer often checks the results personally, and the costs sit in the project budget. In routine operation, almost all of that changes. Every case comes in, including the messy ones. Every employee works with it, including the skeptics. Then come permissions and access, data protection, ongoing model costs, bug fixing, training and keeping up with new model versions.

Pilots are often planned around a tool instead of a workflow. They then prove that the tool can do something, but not what the work looks like afterward. Who checks the result, at which step, and what goes away in exchange? McKinsey found in 2025 that respondents at the organizations getting the most value from AI are nearly three times as likely as others to say they have fundamentally redesigned individual workflows.

The planning lesson: operational questions belong at the start. A pilot should run under conditions as close to daily work as possible, with real data, real users and the review step that will exist later.

Set the criteria before the start.

A pilot stays out of the graveyard when it's settled before launch when, and on what basis, it will be decided. A short checklist is enough.

The benefit is stated in measurable terms, with a baseline from today's workflow. Data access is settled, including whether personal data is processed. The quality standard is fixed, and so is the person who reviews the output. If it succeeds, it's clear who supports the application day to day and which budget covers running costs. The trial period and the decision date are agreed. And there is a stop criterion: a value or condition at which the initiative ends.

On the decision date there are three possible outcomes. The pilot moves into supported routine operation. It gets reworked, with a specific change and a new date. Or it ends. Each outcome is written down with its reasons, so the next use case benefits. A pilot for which these points can't be settled in advance shouldn't start.

How to recognize a well-founded stop.

An ended pilot is not a failure if it answered a question. A well-founded stop has four marks: it happens on the agreed date, it refers to a criterion set in advance, the lessons are written down, and the technology is cleaned up.

That last point is often overlooked. An abandoned prototype holds access to data sources, API keys for model providers and often copies of company data. If it stays in place, it becomes a security risk nobody owns anymore, and sometimes costs keep running. Ending a pilot therefore means revoking access, disabling keys, deleting data copies and canceling running subscriptions.

The pilot graveyard shows the opposite marks. There was never a decision date. The prototype keeps running "just in case." Nobody knows exactly who still uses it. Costs come in without being assigned to any initiative. Regularly checking all running pilots against these questions quickly turns up a company's own graveyard.

Common misconceptions.

The first misconception is that a convincing demo proves the application is fit for daily work. A demo shows the best case. Only the many ordinary and difficult cases show whether an application holds up.

The second: more pilots mean more progress. Many parallel trials spread attention and budget thin, and none reaches operation. A few pilots with clear criteria achieve more than a long list of open tests.

The third: a better model will fix it. The MIT authors write that the divide between successful and unsuccessful organizations does not seem to be driven by model quality but by approach. Switching models helps little if data, review or ownership are missing.

The fourth concerns vendor proposals. If a proposal ends with the prototype demo, with no handover, no operating concept and no estimate of running costs, the path to the graveyard is already laid out. A good proposal describes who runs the application after the pilot, how it is monitored and what it costs in operation.

Where the term stops working

Not every ended pilot belongs in the pilot graveyard: if a pilot misses criteria set in advance and the lessons are written down, stopping it was a good decision. A proof of concept is designed to end anyway, and a pilot within its agreed trial period is still open. Shadow AI is a different thing: there, employees use tools without approval, while the graveyard holds an approved trial without a decision.