In plain terms
A pilot is meant to be a short test with an ending: it works and is rolled out, or it fails and is stopped. Purgatory is the third outcome, in which neither happens. The demo impressed everyone, the team is still “finalising” it a year later, and three new pilots have started in the meantime. The organisation looks busy with AI, and its costs, revenue and customers have not noticed.
Why it matters
Each pilot costs little, which is why they multiply; together they consume the budget, the scarce specialists and the board's patience. The causes are rarely technical. A pilot gets stuck when nobody in the business owns the outcome, when success was never defined, when it ran on a hand-cleaned data extract that does not exist in live systems, and when integration, security review and change management were left for later. The executive check is simple: for every running pilot, ask who will operate it in production, by when, and which result would stop it.
Example
A manufacturer counts 24 AI pilots started in two years and 2 in production. A review of the other 22 finds that 15 have no business owner and 19 have no agreed measure of success. The executive committee stops 14 and funds the remaining 8 to completion, each with a named owner, a production date and a target figure. A new rule follows: no pilot starts without those three and a budget line for integration.
Most often confused with
Pilot Purgatory vs. Proof of concept (PoC)
A proof of concept answers one question, usually “can this work at all?”, and a pilot answers the next: “does it work here, with our people and systems?” Both are healthy when they end in a decision. Purgatory is what follows when the decision never comes. The warning signs are pilots with no end date, pilots extended more than once, and pilots reported by activity where a result was promised.
Origin: The phrase spread through McKinsey's 2018 research on digital manufacturing, which described Industry 4.0 programmes that never got past the pilot stage, and was later applied to AI.
Under the hood
Typical causes: no accountable business owner; no baseline and no success threshold, so that no result can end the pilot; data prepared by hand for the test; integration with core systems, identity and permissions postponed; no budget for running costs, support and monitoring; security and legal review started after the build; and users left out, so that nobody changes how they work. Exits: define the production path before the pilot starts (owner, target system, run budget, criteria for go or stop, and a date); test at small scale on live data with real users; build shared components such as model access, evaluation, logging and guardrails once; hold a decision gate at which projects are stopped as readily as approved; and limit the number of pilots running at one time. Useful portfolio measures: the share of pilots that reach production, the median time from start to production, the share stopped by decision, and the value delivered against the business case. A stopped pilot with a documented finding is a good result.