During my book project and afterwards, I went looking for AI projects that had failed. I searched for cancelled implementations, projects that cost more than planned and cases where the technology never delivered what it promised. I found almost nothing.
Case studies, on the other hand, are everywhere. They run across every industry and application, collected in vendor libraries, consultancy reports and how-to guides. A retailer cuts its processing time, a bank clears claims faster and a manufacturer lifts output. Every one of them describes a success. The improvement figures come in at 25, 35, 40, 60 percent, and the work takes three to six months.
Those figures share a shape. They sit in a corridor between roughly 20 and 70 percent. Outside that corridor the number stops working: a very small gain is not worth printing, a very large one is not believable. Vendors would never publish a case study promising a 4 percent gain, and no reader would believe one promising 300 percent. So the published numbers settle where they stay impressive and still plausible.
Set this against what the same sources say elsewhere. The consultancy reports I read for the book put the failure rate for AI implementations at over 50 percent. Behind closed doors the line is blunter: most AI projects never leave the pilot phase. Both cannot be true at once. Either nearly everything works, or most of it stalls. Only the success account reaches print.
I do not think the authors are lying. They are reproducing a habit that runs deep in the trade. An implementation that works becomes a case study. Nobody writes up a failure, because it is not a story anyone can sell. The selection removes the failures on its own.
What remains is a published record that contains only successes. A manager reading these guides plans with numbers that were never representative to begin with. He underestimates the risk, because the case studies had edited it out before he ever saw the material. And the projects that failed leave nothing behind for the next team to learn from. Their lessons would matter most, and they go unrecorded.
Anonymity makes this worse. The case studies rarely name the company, the team or the person who ran the project. Without a name, nothing can be checked. No one can ask the manager whether the 40 percent held up two years later, the cost was worth it or the pilot ever became routine work. The case studies present the anonymity as discretion. It protects the source and puts the claim beyond reach of any reader who wants to check it.
This gives a simple test. A case study that names something that went wrong, a data set that was too thin, a team that pushed back, a bill that ran over, came from a real project. One where everything went right is sales copy.
I know consultants who tell me privately that most AI projects fall significantly short of expectations. Over beers they are specific: data quality was not sufficient, managers underestimated the resistance in the teams and costs exploded after the pilot. None of this reaches the guides. It stays in the conversation after the meeting, off the record, where it changes no one’s decision.
To me, consulting means putting the whole truth on the table. The failures matter more than the successes, because they show where the technology breaks and what it costs to find out. Vendors and consultancies that publish only half their record are selling their clients an illusion. A manager who trusts that record decides without ever seeing the risk the case studies left out.