An AI pilot stops short of production for six reasons, most settled before a model is chosen: the data never held the signal, the process underneath was already broken, no pass condition was written, the demo ran on a curated sample, nobody costed inference at production volume, and nobody declared which capabilities may be probabilistic. Diagnosis takes a week, not a quarter.
Ross Jones — Founder, The Hopium Lab. Last modified 22 July 2026. Twenty-four shipped products across fifteen sectors.
Two are specification failures wearing a technology costume, and a stronger modelling team fixes neither. One is organisational, one is methodological, one is economic, and one is genuinely in the data.
Did the data ever contain the signal?
Sometimes not — but "the data was bad" collapses three separate absences, each with its own diagnostic, and collapsing them is the error that makes an AI post-mortem useless.
The first is genuine: the outcome is not a function of anything the organisation records, and no architecture recovers a signal the instrumentation never captured. Two domain experts labelling a hundred records blind will agree at some rate, and that rate bounds what you can measure — you cannot score a model above the noise in its own labels.
The second is leakage: the pilot measured a signal that will not exist at inference time. Kapoor and Narayanan found documented cases across 17 scientific fields affecting 329 papers, and catalogued 8 leakage types (arXiv:2207.07048, 14 July 2022). Enterprise pilots are not held to the standard of a peer-reviewed paper. Assume worse.
The third is underspecification: many predictors score equivalently on held-out data and behave very differently in deployment, shown by D'Amour and colleagues across five domains including medical imaging and EHR-based clinical risk prediction (arXiv:2011.03395, November 2020; JMLR 23(226), 2022). The signal exists, the score is honest, and the wrong predictor shipped.
Underneath every version sits the data cascade: an upstream data problem compounding downstream, late and out of sight. Sambasivan and colleagues interviewed 53 practitioners; 92% had hit at least one, 45.3% two or more in a single project (CHI 2021, DOI 10.1145/3411764.3445518).
Was the process the model served already broken?
Frequently, and the test costs an afternoon. Automating a defective process buys a faster defective process plus a maintenance bill. Michael Hammer set out the argument in Reengineering Work: Don't Automate, Obliterate (Harvard Business Review, July–August 1990): technology laid over an existing process delivers marginal gains and entrenches the defects. Ford's North American accounts payable employed more than 500 people; Mazda ran the equivalent function with five. The automation plan already on the table projected a 20% cut. Redesigning the process — pay on receipt of goods, not on receipt of invoice — delivered 75%.
Draw the process the model serves and count the steps that exist only to correct an earlier step. A majority means the model is not the intervention: step nine cannot reach back and fix step three.
Was a pass condition ever written down?
Rarely, and a pilot without one cannot end, because no result contradicts it. A pass condition is a threshold, on a named metric, measured on data the system has never seen, agreed in writing before the build starts. Each clause fails independently: a named metric with no threshold, a threshold with a hand-picked evaluation set, or both agreed after the numbers came in.
A pass condition agreed after the results are in is not a test. It is a description of what happened, written by the people it judges.
Did the demo run on a curated sample?
In the pilots I have been handed, almost always — and almost never on purpose. Curation arrives disguised as housekeeping: drop the malformed rows, deduplicate, use the quarter where the export worked, park the awkward cases. Each step is defensible alone; the aggregate is a distribution production will never see.
The remedy is a post-freeze rerun — re-score on records created after the pilot set was frozen, no cleaning, no re-prompting. A few points of drop is normal. A collapse means the demo measured the curation.
Did anyone cost inference at production volume?
Almost never in the pilots that reach me: the invoice was small enough to approve without reading. Publish the cost model, not a price — any token figure printed here is stale within a quarter. The shape that matters is cost per decision, and Gate 5 of the checklist sets out the arithmetic.
Gartner predicted on 29 July 2024 that at least 30% of generative AI projects would be abandoned after proof of concept by the end of 2025, naming escalating costs among the causes. Note what it measures: abandonment after proof of concept, at 30%, which is not the same quantity as the 95% in circulation and cannot be swapped for it. Still a prediction, and its window closed with no published retrospective either way. The per-decision economics are worked through in When should you not use an LLM at all?
Did anyone declare which capabilities were allowed to be probabilistic?
Almost certainly not, in any pilot I have been asked to review, and the omission resurfaces in month seven as a quality complaint nobody can adjudicate. A capability is probabilistic when a different answer to the same input is a tolerated outcome rather than a defect. Undeclared, every stakeholder assumes their own answer.
RAND names the failure directly: leaders who expect repeatability from a model that "incorporates some degree of randomness and uncertainty" lose faith in the product and the team. Inside the EU AI Act's high-risk classes the declaration stops being an engineering preference. Regulation (EU) 2024/1689 (OJ L, 12 July 2024) at Article 14(4) requires oversight measures enabling assigned persons to stay aware of automation bias, 14(4)(b), and to interpret the output correctly, 14(4)(c). Neither is achievable while nobody has written down which outputs may legitimately vary. The Digital Omnibus deferred stand-alone Annex III obligations to 2 December 2027 and Annex I embedded systems to 2 August 2028, so what applies now is design pressure, not enforcement pressure. Architecture supports a conformity case; architecture never confers one.
Do the six causes overlap?
Yes, in two pairs. An unwritten pass condition and an undeclared probabilistic capability are both specification failures; a broken process generates the inconsistently labelled data that later reads as an absent signal. The first cause splits into three under diagnosis, so six causes produce eight rows, each with a test that separates it from its neighbours.
| Autopsy | How it presents | Test that distinguishes it | Verdict |
|---|---|---|---|
| Absent signal | Strong score on history | Two experts label 100 records blind; chance-corrected agreement bounds what you can measure | Kill if the bound is below the pass condition |
| Leakage | Score collapses after the freeze date | Remove the suspect field or context element; pilot score falls to the post-freeze score | Rebuild the feature set, re-pilot |
| Underspecification | Equal holdout scores, erratic live behaviour | Three seeds or three prompt variants, one holdout | Constrain, stress-test on real slices, re-pilot |
| Curated sample | Demo unreproducible on fresh records | Post-freeze rerun, no cleaning, no re-prompting | Rerun clean, then re-decide |
| Broken process | Model correct, outcome unchanged | Count steps that only correct an earlier step | Kill; keep the budget, redesign first |
| No pass condition | Nobody can say whether the pilot ended | Ask three stakeholders separately for the threshold | Stop; write one, backdate nothing |
| Uncosted inference | Unit economics never modelled | Cost per decision at ten times pilot volume | Cut scope, or kill |
| Undeclared probabilistic capability | Recurring arguments about "consistency" | Every capability signed by a named owner | Reclassify: model proposes, code decides, human signs |
Which AI failure statistics should you not trust?
All the headline ones, including the ones that flatter this article. Not one page ranking for this question links the primary documents, and several reproduce a Gartner figure that says something else.
The famous 95% does not say what it is used to say. The GenAI Divide: State of AI in Business 2025 (MIT NANDA, July 2025, mirrored PDF) reports that 95% of organisations are getting zero return, and separately that only 5% of custom enterprise tools reach production. The 5% is the tail of one funnel — embedded and task-specific tools at 60% investigated, 20% piloted, 5% implemented — while the same exhibit puts general-purpose LLMs at 80/50/40. Title page: "Preliminary Findings". Survey component: 153 senior leaders recruited at four industry conferences. One listed author is also the report's reviewer. An appendix discloses that Project NANDA builds the agentic infrastructure the conclusion recommends.
The report behind "95% of AI pilots fail" also records an approximately 83% pilot-to-implementation rate for general-purpose LLMs.
RAND's much-quoted line is borrowed too. "By some estimates, more than 80 percent of AI projects fail" carries endnote 13, resolving to a Fortune interview with a vendor chief executive published on 26 July 2022. RAND's own work is the best in the field — 65 practitioners with five or more years building models, 84% naming leadership-driven causes as primary (RR-A2680-1, Ryseff, De Bruhl and Newberry, 2024) — and endnote 1 excludes pretrained LLMs used without customisation, which is most 2025–26 pilots. Three causes travel intact: problem misdefinition, inadequate infrastructure, and problems too hard for the technology. A fourth, chasing the newest model instead of a user's problem, travels harder than it did. Only the fifth weakens: RAND's data cause is about having enough data to train, and you are not training.
"More than 80 percent of AI projects fail" is not a RAND finding. One endnote away it is a magazine interview with a vendor CEO.
"Gartner says 85% of AI projects fail" is wrong three times over. A 13 February 2018 forecast said 85% would deliver erroneous outcomes through 2022, through bias in data, algorithms or the teams managing them: output quality, not project failure; a forecast, not a measurement; a window that closed four years ago.
When is "kill it" the right verdict?
When a gate returns a defect no amount of downstream work removes. Recommending a kill is not a brave position; what matters is that every gate below routes on evidence one engineer can generate inside a working week, not on an industry failure rate nobody has checked. I sell the sequence as a fixed-price go/no-go when a board wants a signature on it. The gates are yours either way.
PILOT AUTOPSY — KILL OR CONTINUE — v1.0 (22 July 2026)
The Hopium Lab. Every gate routes on evidence one engineer can
generate in six working days. Take it, fork it, argue with it.
GATE 0 — THE PASS CONDITION (half a day)
[ ] A threshold, on a named metric, measured on data the system has
never seen, agreed in writing before the build starts?
NO -> STOP. Write one now. Backdate nothing. Re-enter at GATE 1.
GATE 1 — THE POST-FREEZE RERUN (1 day)
[ ] Re-score on records created AFTER the pilot set was frozen.
No cleaning. No re-prompting. No prompt edits mid-run.
Falls below the GATE 0 threshold -> the demo measured curation.
Record the delta, go to GATE 2 tests A and B.
Holds, but live behaviour is erratic -> GATE 2 test C.
Holds and behaviour is stable -> GATE 3.
GATE 2 — WHICH KIND OF NOTHING? (2 days)
A [ ] Remove the suspect field — for a prompted system, the
retrieved context element or metadata line most likely to
encode the answer — and re-score the PILOT set. Score falls
towards the post-freeze score -> leakage. It will not exist
at inference time. Rebuild the feature set.
B [ ] Two domain experts label 100 records blind, stratified to
include the rare class. Their chance-corrected agreement
bounds measurable accuracy. Bound BELOW the GATE 0 threshold
-> you cannot demonstrate the signal. KILL.
C [ ] Three temperature or seed settings where you control them,
three prompt variants where you do not, one holdout.
Equivalent scores, divergent behaviour -> underspecification.
Stress-test on real application slices, constrain, re-pilot.
GATE 3 — THE PROCESS UNDERNEATH (1 day)
[ ] Draw the process the model serves. Count the steps that exist
only to correct an earlier step. A majority -> the process is
the defect. KILL the pilot, keep the budget, redesign first.
GATE 4 — THE PROBABILISTIC DECLARATION (half a day)
[ ] Mark every capability ALLOWED-PROBABILISTIC or
MUST-BE-DETERMINISTIC. Unsigned by a named owner -> not done.
[ ] Money, credentials, access rights, or a decision about a named
person marked ALLOWED-PROBABILISTIC -> reclassify. Model
proposes, code decides, a human signs.
GATE 5 — THE COST MODEL (half a day)
[ ] INPUT tokens/request x (1 + observed retry rate)
+ retrieval-call input tokens
- cached-input tokens, priced separately
[ ] OUTPUT tokens/request x reasoning / agent-loop multiplier
[ ] + evaluation tokens per release, amortised per request
[ ] Price each stream at its OWN dated list rate from the vendor's
pricing page. Input, output and cached input are different
numbers.
[ ] Compare COST PER DECISION with VALUE PER DECISION at ten times
pilot volume. Cost above value -> cut scope until the
arithmetic survives, or KILL.
GATE 6 — THE REPLAY (half a day)
[ ] Can you rebuild the answer without calling the model, from the
stored record alone — inputs, retrieved context, prompt and
model version, parameters? If not, you don't have a system.
You have a demo with a try/except around it.
VERDICT
KILL -> any gate returns KILL. Write the autopsy. Name
decisions, never people.
CONTINUE -> every gate passes and GATE 0 carries a signature.
UNDECIDED -> not a state. A slow kill with a budget attached.
Gate 6 is expanded in The Replay Test. Gates 0 to 5 sit inside four of the seventeen categories my auditor scores before the synthesis pass (the full taxonomy).
A pilot that stalled was not beaten by the model. Run the gates while the people who made the decisions still remember the dates.
Ross Jones, Founder, The Hopium Lab. Last modified 22 July 2026. Engineering commentary, not legal advice.