Where deployments stop

Sixty-one AI deployments were followed from an accepted demonstration through to production or abandonment, tracked from January 2024 to June 2026 in regulated operations — healthcare, banking, professional services and education — where a wrong output carries a named consequence for somebody. Thirty-four came from direct engagement with the organisations involved; twenty-seven were reconstructed after the fact from project records and interviews with the people who ran them. Seventeen reached production.

The study set out to find where deployments actually stop, rather than assuming the answer was technical. It wasn't. Seven of the sixty-one failed at capability — the system genuinely couldn't do the task well enough — and five failed at evidence, unable to answer a regulator's or auditor's question about a specific past decision. Together those account for twelve failures. Acceptance, the point where a named person has to act on a system's output and answer for it, accounted for twenty-six — more than every other stage combined. Nothing was being built at that point and nobody had scheduled it; it simply had no owner in the project plan, which the report treats as the actual finding rather than an oversight to note in passing.

The sixty-one split cleanly on one variable: whether the accountability question — who accepts the output, and what happens when they decline it — was settled before the build began or left for later. Twenty-three organisations settled it first; nineteen of those reached production, an 83% rate. Thirty-eight deferred it; seven reached production, 18%. The report is careful about what this association can and cannot support: it correlates strongly and holds within every subgroup coded, including budget, model choice, team size and vendor, but it does not establish that early accountability causes production, since organisations that settle it first may simply be better run in ways the study didn't measure.

Looking inside the twenty-six acceptance failures, four absences recur: no allocated time for the review, no default action when nothing happened, no defined consequence for declining, and no measurement of whether outputs were actually being acted on rather than just produced. The report argues these failures aren't a training problem, even though eleven of the twenty-six ran additional training after stalling and none of it resolved anything — because declining to accept an output is genuinely the only one of three available responses that carries no personal risk for the person being asked. Where a role rather than a named individual held acceptance, or where a committee held it, deployments were far less likely to ship; where a named individual held it and could also decline without a defined penalty, most still shipped.

The report's own limits are stated in advance of the analysis: sixty-one is not a representative sample, coding wasn't independently blinded, the outcome measure — reached production or not, at eighteen months — says nothing about whether the deployments that shipped were worth shipping, and the finding is scoped specifically to settings where a wrong output has a named consequence. What a reader takes away is narrower and more actionable than a general theory of AI adoption: name who accepts an output, state what they can do without asking again, and settle both before the build starts, because doing it after costs far more than doing it first.