Short answer
AI projects rarely fail on the technology. RAND research puts the failure rate above 80 per cent — roughly twice that of IT projects without AI — and traces it mainly to misunderstood problems, data that does not survive production, and change management nobody owned. All nine failures below are organisational.
Key takeaways
- Over 80 per cent of AI projects fail, about double the rate of non-AI IT projects.
- Starting from the technology instead of the work is the most expensive mistake on the list.
- Pilots that run on curated data collapse on production data — test the worst files first.
- Corrections made by your people are the most valuable data you will produce. Most firms discard them.
- Settle data residency in week one; it is the most common late-stage killer in regulated supply chains.
We have watched enough AI projects in manufacturing and professional services to notice that the failures rhyme. Almost none of them are technical. Here are the nine we see most, roughly in the order they show up in a project.
1. Starting with the technology instead of the work
Somebody sees a demo, gets excited, and goes looking for a place to apply it. This produces solutions in search of problems, and it is the single most expensive mistake on this list because it consumes the organisation's goodwill on something nobody asked for. Start from a task your people resent doing, and work backwards to the tool.
2. Running five pilots instead of shipping one thing
A portfolio of pilots feels like progress and is usually the opposite. Pilots are cheap to start and hard to finish, so a company that starts five will typically finish none — each one gets to the awkward eighty per cent where the remaining work is unglamorous integration, and attention moves to the next shiny thing. One use case in production teaches you more than five pilots at eighty per cent.
3. Testing on clean data
Every vendor demo uses a tidy document. Your reality is a scan with a coffee ring on it, a revision nobody can explain, and a product description somebody typed at 4 p.m. on a Friday. If you do not test on your worst inputs before you sign, you are buying a system that works everywhere except at your company.
4. Letting AI act without a human approving it
The temptation to remove the review step is strong once accuracy looks good, because the review step is where the remaining cost sits. Resist it anywhere the output leaves your company or enters a controlled document. Under AS9100 or IATF 16949, "the system decided" is not a record, and an auditor will not accept it.
5. Throwing away the corrections
When a person overrides the system, that correction is the most valuable data your company will generate this year. Most companies discard it — the person fixes the output, the job moves on, and nothing is recorded. Log what was wrong, what the right answer was, and who decided. Within a few months that log is what lets you tune the system to your work rather than to the world's average.
6. Buying per-seat licences for work that is per-document
A lot of AI tooling is priced per user because that is how software has always been priced. If the work is document-shaped — drawings checked, quotes produced, invoices read — then seat pricing either overcharges you for occasional users or quietly caps the thing you actually wanted to scale. Model your real annual volume against both pricing shapes before you sign anything.
7. Skipping the data-residency question until it is too late
Many subcontract agreements in aerospace and automotive prohibit disclosing a customer's drawings or specifications to a third party without written consent — and uploading a file to a SaaS vendor is disclosure. This is the most common reason a promising pilot is stopped by legal, and it almost always happens late, after the effort has been spent. Settle it in week one, in writing, before you evaluate a single feature.
8. Measuring the wrong thing
Documents processed, users onboarded, pilots running — these are activity metrics, and they go up whether or not anything improved. The only numbers that matter are hours returned to a named team and errors caught before they cost money. If you cannot state the benefit in one of those two currencies, you do not yet know whether it worked.
9. Announcing it as an efficiency programme
If the first thing people hear about AI is framed around cost, they will reasonably conclude it is about headcount, and you will lose the cooperation of exactly the experienced people whose knowledge the system needs. Frame it as removing the work they already resent, be specific about which tasks, and be honest about what you do not yet know.
Every one of these is an organisational failure wearing a technical costume. The model is rarely the problem.
In short
Not one of these nine is a reason to avoid AI. They are reasons to run it like any other operational change: pick a problem people recognise, prove it on the data you actually have, keep a person accountable for the output, and measure it in hours or errors rather than in activity. The failure rate is high because most companies skip those four things, not because the technology does not work.
Frequently asked questions
What percentage of AI projects fail?
RAND reports more than 80 per cent, about twice the failure rate of IT projects that do not involve AI. Estimates elsewhere range from 46 to 95 per cent depending on how failure is defined — whether a pilot that never scaled counts as one. The spread matters less than the pattern: most stall between pilot and production.
Is it the technology that fails?
Almost never. The recurring causes are a misunderstood problem, data that does not reflect reality, a proof of concept that hid the integration work, and no owner for the change. Each is an organisational failure wearing a technical costume.
Why do AI pilots not scale to production?
Because the pilot moved fast precisely by excluding what production contains: curated data, controlled scope, manual handling of edge cases and minimal governance. Scaling reintroduces all of it at once. A pilot proves a capability can work; production requires the organisation around it.
How do we avoid the clean-data trap?
Make your worst inputs part of vendor selection. Send the five ugliest files you received last month — the fax, the scan with a coffee ring, the one with handwriting — and ask for the raw output rather than a demo. Vendors who engage with that test are the ones worth shortlisting.
Who should own an AI project?
Somebody in the business that the output belongs to, not IT alone. The failures cluster around unclear objectives and low adoption, and neither is fixable by the team that installed the software.