The Pilot That Never Becomes Anything

What a Pilot Must Settle

The conviction behind this note, stated plainly: most AI pilots fail not because the technology disappoints, but because they were launched to prove that it works instead of helping to decide. As long as the two remain conflated, the outcome will keep being successful demonstrations that change nothing — and the gap with the rare companies that know how to industrialize will keep widening.

The subject is not a minor one. Behind every pilot that never becomes anything, there is a committed budget, weeks of team effort, and, above all, an eroding conviction: that "deep down, AI is not for us yet." But it is almost never AI that failed. It is the way the problem was framed at the outset. A leader who understands this distinction avoids the costliest disappointment of all — the one that leads to abandoning a field where competitors will keep moving forward.

There is a paradox worth naming right away: a pilot can be a technical success and a strategic failure. The tool answers, summarizes, classifies, predicts; the demonstration's indicators are all green; and yet nothing happens. This note sets out to unpack that paradox, because it is the silent cause behind most disillusionment — and because the fix is not more technology, but a different way of starting.

The Real Wall Comes After

The scene has become familiar. A team presents an impressive AI demonstration to a steering committee: the tool answers, summarizes, drafts, sorts. Everyone nods. Six months later, the tool is used nowhere, no one can say whether it saved anything, and the question "do we scale this or not?" remains unanswered.

Consider the scene in slow motion, because the detail matters. On demonstration day, everyone is convinced — and that is the problem. The conviction rests on an impression: "this looks like it works." No one in the room can say how long the task used to take, how long it will take afterward, or at what threshold anyone would decide to deploy it. The meeting ends with an agreement in principle — "let's keep going with this" — that commits no one and settles nothing. The weeks pass, priorities shift, and the tool becomes an open browser tab that no one visits anymore. In the end, no decision was made not to scale it: the absence of a decision settled things on everyone's behalf.

The pilot did not fail in the sense that "it did not work." It failed in the sense that it settled nothing. And this is not an isolated accident: it is the dominant pattern, measured everywhere.

What makes this pattern hard to see is that it does not look like a failure. No one picked the wrong technology, no team did poor work, the demonstration even impressed. The money is not lost in a crash; it dissolves quietly, into a project that stays "interesting" without ever becoming decisive. It is precisely because there is no obvious culprit that the mistake gets repeated — often several times, with several tools, before wrongly concluding that "AI does not take hold here."

These three figures do not measure the same thing — one speaks to bottom-line impact, another to scaling, the third to meeting timelines — and yet they all point to the same place. From one survey to the next, the step that blocks progress is always the one separating a successful experiment from an established use. The problem, then, is not making AI work once, in a demonstration; it is making it enter the company's operations for good. And that, very precisely, is where most projects stop.

The Cause Is Not Technical

The cause is almost never technical. It comes down to a confusion of purpose. Many pilots are run to show that "it works," to check the box that says "we do AI." But a pilot is not a demonstration: it is an experiment meant to answer a leader's question — "is it worth scaling this, and under what conditions?"

The nuance seems slight; it changes everything. A demonstration seeks to convince: it stages what works, picks its examples, polishes the effect. An experiment seeks to know: it accepts measuring, comparing against a starting point, and possibly landing on a "no." The first is reassuring and sterile; the second is uncomfortable and fruitful. The slide from one to the other is almost always unintentional — the intent was to "test AI," and it ended up as a fine show — but that alone is enough to doom the project, because a show, however successful, never says whether to scale.

Behind this slide there is often legitimate pressure: to show that the company "does AI," to check a box expected by a board, a client, or the market. That pressure is not illegitimate, but it is a trap: it rewards the appearance of movement rather than movement itself. Activity — a pilot launched, a demo presented — then gets confused with progress — a decision made, a use put in place. From a distance, the two look alike; only the results, six months later, tell them apart.

There is a deeper reason, and it is counterintuitive: the value of an AI project comes almost nowhere from the AI itself. Organizations that succeed follow a rule that is now well documented — the 10/20/70 rule (BCG). It describes where the effort that produces value actually goes: roughly 10% into algorithms, 20% into technology and data, and 70% into transformation — that is, everything that is not technical.

This rule explains almost everything else. A pilot designed to impress concentrates effort on the easy 30% — the algorithm, the data, the demonstration that lands well in a meeting — and leaves aside the 70% that actually decides the project's fate: reworking a process, training teams, changing habits. That 70% does not show up in a demo; it is not paid for in a license; and it is what is invariably missing when a project "that worked" never becomes anything. Technology is not the issue. The organization is.

It is worth unpacking that 70%, because it stays abstract until it is named. Concretely, it covers four workstreams. Process first: where, exactly, does the tool fit into the actual work? Who triggers the AI, who reviews its output, what happens when it gets something wrong? A model with no process around it is just a demo. Skills next: do teams know how to use it — but more importantly, do they know when not to trust it? Trust last — the slowest to build: as long as the person using the tool is not sure it will not be used against them, or to replace them without saying so, they will quietly route around it. And accountability: who answers for a result produced with AI's help? None of these four workstreams is technical; all of them decide the project's fate.

This is why a pilot built "to impress" is almost always lost from the start: it invests where things are easy and visible, and skips what is difficult, slow, and invisible — yet decisive. Reversing that logic does not require more technology. It requires starting with the question a demonstration is precisely designed to avoid: "if this had to be used every single day, what would be missing?"

The Cost of a Pilot That Settles Nothing

The cost of a failed pilot tends to be measured only by the spending involved: a few tens of thousands of euros, the time of two or three people. That is the visible part, and the least serious one. The real cost is made up of three layers that add up, and the two heaviest do not appear on any invoice.

The first is the direct cost: the budget spent, the time committed. Real, but bounded, and often modest. The second is the opportunity cost: while the organization was polishing a demonstration, the real problem — the one costing money every month — remained untouched. That is not just money lost; it is money not gained, and it is often measured in multiples of the initial spend. The third, and the most insidious, is the cost of belief: after two or three pilots that go nowhere, a conviction takes hold inside the company — "AI is not for us." Once that sentence is spoken in a steering committee, it freezes future initiatives for years. It is false, but it carries the authority of lived experience.

To these three layers is added an organizational fatigue that is hard to quantify but very real. Teams that have watched a promising project die without explanation become cautious; next time, they will invest less, out of self-protection. It looks like one project was lost; in reality, the company's capacity to succeed at the next one has been eroded. That is why the question is not "how much does a pilot cost?" but "how much does a pilot that leads to no decision cost?" — and the answer, properly counted, is almost always far higher than the price of framing it seriously from the start.

Two Pilots, Two Outcomes

This thesis would remain an opinion if practice did not confirm it. It does, with troubling regularity: every time a pilot dies, the same absence of an initial question shows up; every time a pilot decides something, the same measurement of the "before" shows up. Two public cases, opposite in outcome, say exactly that.

Two companies, two different technologies, one single variable explains the gap: one knew, before starting, which decision its pilot was meant to inform; the other did not. It was not model quality that made the difference, nor budget, nor sector — it was the presence, or absence, of a clear question asked at the outset. The lesson can be flipped into a rule of conduct: if you cannot say which decision your pilot is meant to settle, you are not ready to launch it.

The case that failed deserves a closer look, because it is the most instructive — and, on the surface, the most unfair. The team had done good work; the predictive maintenance functioned. But it had answered a question that no one internally was really asking: no one was willing to pay for that gain, because it did not relieve any felt need. The project died not of a technical flaw, but of an absence of demand. At V-ZUG, by contrast, the pilot started from a concrete, measured irritant — unusable service reports — and aimed at a precise threshold. It was not trying to impress; it was trying to find out whether a piece of data used every day could be made reliable. The answer was yes, and it was decidable because the question was.

Spotting a Pilot That Will Die

The good news is that a doomed pilot can be spotted long before it dies. The signs are subtle but reliable, and a leader who knows them can correct course in time — or walk away before spending anything. Here are four, drawn from projects that never went anywhere.

No one can quantify the "before." When someone asks "how long does this task take today, at what cost, with what error rate?" and the answer is a shrug, the pilot has no point of comparison. Whatever it produces, no one will be able to say whether it improved anything. This is the earliest and most decisive sign.

The scope widens instead of narrowing. A healthy pilot shrinks as it gets defined; a sick one grows — "may as well add this too…" Widening is almost always an escape route: it pushes back the moment of measurement by promising something bigger.

Success is narrated, not measured. If status updates talk about "team enthusiasm" and "promising potential" rather than a number hit or missed, the project has already slipped to the demonstration side. Enthusiasm is pleasant; it has never gotten anything deployed.

No date forces the decision. Without a deadline, a pilot does not die: it falls asleep. It stays "in progress" indefinitely, neither abandoned nor scaled, tying up budget and attention that would serve better elsewhere. The absence of a date is the comfort that kills.

None of these signs is technical, and that is the whole point: a leader can detect them without knowing anything about models, simply by asking the right questions in committee. Three of them together are enough to predict that a project will get stuck — and to justify reworking the framing before going any further.

Three Underlying Shifts

Three underlying shifts will widen the gap between those who know how to industrialize and everyone else.

None of these three shifts is a distant prediction: they are already under way. Together, they move the competitive advantage — from "having access to AI," which everyone will soon have, to "knowing how to turn it into results," which few will master. For a leader at an SMB or a mid-market company, this is actually good news: that advantage cannot be bought, and it does not depend on budget size. It is built, one well-framed decision at a time — and the window is still open.

Four Lines Before Launch

1. The task: a single one, repeated, named precisely. Not "improve customer service," but "draft the first response to level-1 complaints." The narrower the task, the more decidable the pilot.
2. Current cost: hours/month, volume, error rate — measured, not estimated. This is the quantified starting point without which no "after" means anything. A few days of observation are often enough to establish it.
3. The success criterion: the number to hit in order to say "we scale this," set before starting. If it is decided after the fact, it will always be met — and will prove nothing.
4. The deadline: a short limit, six to eight weeks, at the end of which the matter is settled. The time constraint is not needless pressure: it forces the scope down to what is genuinely decidable.

These four lines fit on half a page. They cost almost nothing and change everything, because they turn an intention — "let's do AI" — into an experiment that will end in a decision, whatever that decision is. A clear "no" after eight weeks beats an indefinite "that was interesting": it frees up budget and attention for the next task.

If any one of these lines stays blank, the pilot is not ready: it will produce a demonstration, not a decision. And in a market where technology no longer differentiates — where the same model is within everyone's reach —, knowing how to frame, decide, and deploy becomes the only thing that truly sets one company apart from another. This is a leadership skill, not an engineering one; and over the next three years, it is what will separate those who "tried AI" from those who actually did something with it.

What This Requires of a Leader

Everything above comes down to a shift in stance, and it falls to the leader — not the technical team — to make it happen. Because an organization's natural inclination, faced with AI, is to produce demonstrations: they reassure, they put on a show, they check the box. Resisting that inclination is an act of leadership. Concretely, it means asking, in the room, the question everyone would rather avoid: "before we continue, what will this pilot let us decide, and at what number?"

It also requires accepting the discomfort of a "no." A leader who requires a pilot to end in a decision must be prepared for that decision to be negative — and to treat it as a success, not a failure. A clear "no," reached in eight weeks at modest cost, is excellent news: it avoided a costly rollout and freed up attention for the next task. An organization that knows how to say "no" quickly is one that can say "yes" often, because it never gets stuck.

Finally, it requires protecting the discipline over time. The 70% — process, skills, trust, accountability — is not built all at once; it is cultivated project after project, and is lost the moment the standard slips. The leader's role is not to understand the models; it is to hold the line on how projects get started, again and again, until it becomes a company habit. On that day, AI will have stopped being a subject for demonstration and become, simply, a way to decide better and produce better. And the pilot that never became anything will have become the first in a long line that, this time, kept its promises.