Why your AI pilot died before it shipped.

An AI pilot is a strange thing. It is funded like a project, staffed like a research effort, scoped like a hackathon, and judged like a product launch. The four expectations are mutually incompatible, and the pilot is asked to satisfy all of them at the same time. This is, before anyone writes a single line of code, the structural reason that most pilots fail.

I have written enough of these post-mortems now to be specific about it. There is a meeting, usually in the third or fourth week, where four things happen at once. The original sponsor is asked to clarify the scope, and they clarify it upward. A new stakeholder is added to the steering committee, and they bring a constraint that was not visible at kickoff. The data team is asked for a feed that turns out to require legal review. And the engineering lead is asked to commit to a date that nobody has the authority to commit to. The pilot does not die that day. But that is the day it stops being viable.

§ 01The unowned scope.

Scope creep is not the right phrase for what kills most pilots, because creep implies slow movement. What I see is sudden, discontinuous expansion — usually triggered by a senior person hearing about the pilot for the first time and asking, perfectly reasonably, whether it could also do this other thing. The team, eager to demonstrate value, says yes. The team's answer is, in the moment, the polite one. It is also, almost always, the wrong one.

Every pilot needs a single owner empowered to say no on the sponsor's behalf, in writing, before the meeting ends.

That sentence sounds bureaucratic. It is not. It is the difference between a pilot that ships and a pilot that becomes an open-ended exploration with a shrinking constituency. The owner does not need to be the most senior person in the building. They need to be empowered, and visibly empowered, by someone who is.

§ 02The data that was promised, and the data that exists.

In every pilot I have ever participated in, there is a gap — sometimes small, sometimes catastrophic — between the data the team was told it would have and the data the team actually has. The gap is not a sign of bad faith. It is a sign that the people who described the data have not pulled it themselves in eighteen months, and the schema they remember is not the schema in production.

The right response to this is not to escalate. The right response is to spend the first two weeks of the pilot doing nothing but a brutal data audit. What rows exist. What rows are missing. What fields are populated in practice versus in theory. What the actual cardinality of every join key is. This audit is unglamorous and almost universally skipped. It is also the single highest-leverage thing the team can do, and the absence of it is the most reliable predictor of failure I know.

§ 03The model selection that wasn't really a selection.

By week four, the team has chosen a model. Often, the choice is presented as the result of a careful evaluation. Often, it is not — it is the result of which API the engineering lead happens to be most comfortable with, dressed up as a structured trade-off matrix. There is nothing wrong with comfort, in moderation. The problem is that the comfort is not stress-tested against the actual production constraints — latency budget, cost per inference, regulatory posture, fallback behaviour — until the pilot is far enough along that switching is expensive.

The forty-two percent figure is the one that should be on every steering committee's first slide, because it tells you something the room would otherwise hide from itself: that the most likely outcome of the pilot, statistically, is that it is killed before it ships. Not because the technology failed. Because the case for shipping it was never made strongly enough to survive the next budget cycle.

§ 04The meeting that ended the pilot.

It is, in my experience, almost always a Wednesday. There is a regular review. The sponsor is two weeks into a different priority and arrives ten minutes late. The team presents progress. The numbers are not bad, but they are not yet conclusive. The sponsor asks, with the tone of someone who has already moved on internally, whether the team thinks they can land this in the quarter. The team, honestly, says they need another six weeks. The sponsor says they will think about it. Nobody schedules the follow-up.

Three weeks later, the pilot is quietly de-prioritised. Six months later, it appears in a deck about lessons learned. The lesson recorded is some version of need clearer success criteria. The lesson is correct. It is also useless, because it does not name where the success criteria should have been clarified, by whom, on what date, and at what cost.

§ 05What I would do differently.

If I were starting a pilot tomorrow — and I have started a few — I would write four things on a single page, in this order, and refuse to begin until the page was signed:

1. The single number that defines success. Not a basket. One number, with its current baseline and its target, and the date by which the target will be measured.
2. The single person empowered to kill the pilot if the number is not on track at the midpoint. Their name and their authority, in writing.
3. The list of decisions that will not be revisited once the pilot starts. Model family. Data scope. Deployment surface. Anything not on this list is in scope to change. Anything on this list requires a formal restart.
4. The integration commitment. What system in production, on what date, will receive what output, and who has signed up to make that integration real.

A pilot without an integration commitment is not a pilot. It is a demo with a higher budget.

None of this is hard. None of it is novel. The reason it does not happen is that doing it forces an honest conversation, in week one, about whether the organisation is actually willing to ship the thing it is funding. That conversation is uncomfortable. It is also, by an enormous margin, the cheapest version of every conversation that follows.

The pilots that died, in my experience, did not die because the technology was not ready. They died because the conversation in week one was deferred to month six, and by month six, the cost of having it honestly was higher than the cost of letting the pilot fade.

If your pilot is in week one right now, you have a window. Use it.