The pilot didn't die of bad AI. It starved.

The post-mortem is always held in the wrong room.

By the time a pilot is formally declared unsuccessful, the meeting has usually been booked by whoever sponsored it, attended by whoever built it, and framed around a question that sounds reasonable and is not: what went wrong with the model?

Nothing went wrong with the model. In nearly every failed pilot I have been asked to look at, the model did exactly what a model does — it consumed what it was given and produced an output proportional to it. The failure happened upstream, weeks or months before anyone opened a notebook, and it was a failure of supply.

Pilots do not usually die of incompetence. They starve. And starvation has a trail you can follow, if you are willing to walk it backwards.

The first thing to examine is the moment everyone remembers fondly.

Almost every dead pilot has a demo in its history that went extraordinarily well. Someone assembled a dataset, ran it through, and showed a room full of executives something that looked like the future. Budget followed within the week.

What is rarely examined is how that dataset was assembled. It was almost always hand-built: pulled by a person who knew where the good records were, cleaned by hand, restricted to the cases that were complete. That is not dishonest. It is what you do when you have three days to show something. But it means the demo tested the model against the best data the organisation possesses, curated by its most knowledgeable person, at a moment of maximum attention.

Production is the opposite of all four conditions. Average data, no curation, whatever arrives, nobody watching.

So the first finding in most post-mortems is that the pilot was never actually tested. It was previewed. And the gap between preview and test was invisible to everyone in the room, because the person who built the demo knew how much work had gone into the dataset and did not think to say so — it was Tuesday's task, not a caveat.

Follow the supply back one step and you usually find a human being.

The demo dataset was extracted manually. The plan was always to automate that later. Later did not arrive, because automating it turned out to require access to three systems, one of which is owned by a team with different priorities, and one of which nobody has touched since the vendor relationship ended.

So the pipeline stayed manual. Someone pulls the file weekly. The pull takes half a day, then a full day, then it slips to fortnightly because that person has an actual job. The model, which was specified as a live decision aid, is now running on data that is on average ten days old.

This is the point where a pilot dies without anyone noticing it has died. The output is still produced. It is still shown in the dashboard. It is simply no longer worth acting on, and the operational users — who are not stupid — quietly stop acting on it. Adoption metrics decline. Someone concludes the model isn't accurate enough and asks for a retrain.

The retrain is a waste of money. The model was fine. The supply line was one person's half-day, and it broke the way a single point of failure always breaks.

Go back further and the trail leads to the source, where it usually ends.

Nearly every stalled programme I have examined has a dependency on one or two fields that everyone assumed were populated and are not. Not empty exactly — worse. Populated for some regions and not others. Populated properly for two years, then a system upgrade changed the picture and the entry became optional, and the completion rate quietly fell to a third.

Nobody hid this. The field appears in the schema. It appears in the data dictionary. It is only when you count non-null values by month that the discontinuity appears, and the reason nobody counted is that counting is what you do when you are already suspicious, and nobody was suspicious in month two.

The consequence is specific and ugly: the model learns from the period when the field was populated, which is the past, and is deployed into the period when it isn't, which is now. Its performance in testing is a description of a world that no longer exists.

One more step back, and you leave the systems entirely.

The data records what the process produced. It does not record how the process worked. And in most organisations, a meaningful proportion of the work happens in the gap between the two — the call that resolved the dispute, the manager who waved something through, the local team that has a different sequence because the central sequence does not fit their market.

None of that is in the file. So the model learns the residue of the process rather than the process, and it learns it best where the process was most routine. The exceptions — where the value was — are represented thinly or not at all.

I see the sharpest version of this in institutions running across several countries on one central system. The system encodes headquarters. The markets have adapted around it, sensibly and invisibly. A model trained on the central data performs respectably at headquarters and poorly everywhere else, and the diagnosis offered is usually "local data quality issues" — which is both true and completely the wrong end of the problem.

The last step back is the one that would have prevented all the others, and it takes about an hour.

Before committing, someone should have asked: what data does this need, does it exist, is it complete, can we get it repeatedly, and how will we know if it's working? Five questions. An afternoon of honest answers would have redirected most of the failed programmes I have reviewed — usually not by cancelling them, but by reordering them, so that the first three months went to fixing supply rather than building on top of a supply that wasn't there.

That afternoon is skipped for a reason worth naming. It is the least exciting hour in the whole programme, it produces no demo, and it tends to surface answers that are inconvenient for the person who has already told their board a number. So it gets deferred until it becomes a post-mortem, where the same five questions are asked with far more expensive consequences and considerably less goodwill.

Vivienne Umusu is Co-founder and Director of Kenvitek, a vendor-neutral AI data readiness and transformation practice working across Africa and the United States. Kenvitek's Failed-AI Forensics practice reconstructs stalled programmes to identify what can be recovered and what must be rebuilt.