TL;DR
- 70–85% of enterprise AI projects never reach production — mostly for non-technical reasons
- The “last mile” problem — connecting model output to business action — destroys more value than any technical failure
- Start with a business decision and a human who makes it. Not with a dataset.
The graveyard nobody talks about
Somewhere between 70% and 85% of enterprise AI projects never reach production. That number is widely cited and widely ignored — because the AI industry has strong incentives to publicise successes and bury failures quietly. Having worked inside these numbers, I want to be specific about what actually kills projects. Not theoretical failure modes — the actual, recurring, embarrassingly mundane reasons.
Failure 1: The problem was chosen by the data team
The data team sees an interesting dataset and imagines a model. They build it, it performs well in evaluation, and then they go looking for someone to use it. This is backwards. Every AI project I’ve seen successfully ship started with a business owner saying: “I make this specific decision X times per week and I don’t have good information.” When you start with the decision, the model objective is obvious. When you start with data, you’re guessing at the problem.
Failure 2: Optimising the wrong metric
AUC is not a business metric. Before training any model, answer this: what does a false positive cost in currency, and what does a false negative cost? For churn models — a false positive (non-churner flagged) costs the unnecessary retention offer. A false negative (churner missed) costs the full subscriber lifetime value. These are radically different costs and they should directly determine your classification threshold, not the default 0.5.
Failure 3: No business owner from day one
If the person who will act on your model’s output isn’t involved from week one, the project will fail. Not might fail — will fail. By the time you have results you’ll discover: the output format doesn’t fit their workflow, the timing doesn’t fit their operational rhythm, they don’t trust what they don’t understand, or there’s an organisational reason they can’t act on it that nobody mentioned earlier.
Failure 4: The last mile problem
This is the most common technically-competent failure. A model produces good predictions. Those predictions sit in a database table. Nothing happens. Closing the last mile means model output flows — automatically, in the right format, at the right time — into the system where a human sees it and acts on it. The CRM, the inventory tool, the transaction system.
⚠️ The integration work to close the last mile is typically 3× the work of building the model. Budget for it from the start, or it won’t happen.
Failure 5: Data that looked fine in exploration
Exploratory analysis in a notebook is seductive. You find the patterns you expected. Then in production: timestamps are wrong because of a system upgrade 18 months ago, a key label field is calculated differently across three upstream systems, and subscriber IDs aren’t consistent across tables. The fix isn’t more careful exploration — it’s data validation built into the pipeline from day one, with data quality failures treated as first-class incidents.
What actually works
- Start with a specific decision and the human who makes it
- Map their current process — what information do they use, when, in what format
- Define “better” in business terms before writing any code
- Build the simplest possible version (often not ML) and test it with the end user
- Add complexity only when the simple version fails at something measurable
- Instrument everything — you need to know when the model degrades before the business does
💡 Organisations that ship AI reliably don’t have better data scientists. They have better problem selection and tighter loops between model builders and model users.