Frameworks / The Pilot Trap
The Pilot Trap
The most dangerous moment in an AI programme is not when the pilot fails. It is when it succeeds.
A failed pilot is easy to deal with. It gets cancelled, the team moves on, and little is lost beyond time. A successful pilot is more dangerous, because success generates the political capital to keep piloting — and organisations mistake that motion for progress. Another quarter, another proof of concept, another impressive demo. The programme feels alive. It is going nowhere.
Why the success is the trap
The conditions that make a pilot succeed are precisely the conditions production will not provide. A pilot runs on a hand-picked team, a clean and curated dataset, a narrow scope, and a temporary absence of the integration, security, and compliance constraints that govern real systems. Remove those advantages — which production does, by definition — and the result that looked so promising rarely survives contact.
So the pilot does not predict production performance. It predicts performance under a set of conditions that will never be repeated. The better the pilot is engineered to succeed, the less it tells you about what happens when it has to run for real.
How to see it in the field
The tell is an organisation with an impressive portfolio of pilots and almost nothing in production. Ask a simple question — “How many of these are actually running, under real load, owned by a team that has to keep them alive?” — and watch the number collapse. If the honest answer is close to zero after eighteen months of visible activity, the organisation is not building; it is piloting as a way of appearing to build.
A second tell: the metrics that get celebrated are all input and effort — number of experiments, models evaluated, use cases explored — rather than output and endurance. Motion is being measured because progress cannot be.
Getting out of it
The way out is to invert what the pilot is for. Instead of designing a pilot to prove a capability works under favourable conditions, design it to surface the conditions under which it breaks. Introduce the integration constraint early. Use the messy production dataset, not the clean one. Hand it to an ordinary team, not the best one. Make the pilot fail in the ways production would, while failure is still cheap.
And change the question at every review from “Did it work?” to “What would it take to run this for a year?” The first question rewards the demo. The second rewards the only thing that matters — whether it can survive being real.
Part of the Frameworks series. Related: the Technology-First Trap and the Solo Trap — the other two ways AI programmes stall before production.