The figure everyone quotes comes from one place, and it is more honest than its reputation. RAND's 2024 study opens by noting that “by some estimates, more than 80 percent of AI projects fail”, twice the rate of IT projects without AI. RAND is repeating an estimate it did not measure, and that hedge matters. What it did measure, across 65 interviews with data scientists and engineers, was the reasons, and almost none of them concern the algorithm. They concern the problem definition, the data, and the distance between a model that works and a system that runs.
The structural reasons most AI initiatives stall before they scale
Most AI failures are undramatic. Nothing explodes. The data turns out messier than the scoping assumed, the sponsor's attention moves, the model behaves differently on live traffic, and a year later nobody can say when it stopped being a priority.
Four causes account for most of it, and they compound in this order:
- the problem was never specified in terms anyone could measure
- the organisation did not have data adequate to train the model it wanted
- the technology was chosen before the problem was understood
- nobody owned the distance between a working prototype and a running system
RAND's own phrasing of the second is blunt: many projects fail “because the organization lacks the necessary data to adequately train an effective AI model”. Our MLOps work starts at the fourth, because it is the one that quietly consumes the budget.
Deployment rates support the diagnosis. In the 2023 Rexer Analytics survey, only 22% of data scientists said their genuinely new initiatives usually reach deployment, and only 48% said their organisation measures the impact of the models it does deploy. S&
Marcus Aurelius, writing in the field around 170 AD, has a line that survives the transfer: “What stands in the way becomes the way”, in Gregory Hays's rendering of Meditations 5.20. The friction in the data and the deployment path is where the work actually lives.
Why is “good enough” data never good enough for production?
The data problem is underestimated at scoping and overestimated once the project is already in trouble.
Two things go wrong. The training set carries errors the model then applies at scale: a 2% labelling error rate across a million records is 20,000 corrupted examples, quietly teaching the wrong thing. Then, after deployment, the world moves and the model does not, and without monitoring that decay stays invisible until a business number moves. Gartner has put the cost of poor data quality at an average of $12.9 million a year per organisation, a figure it first published in 2021 and still cites.
The European supervisory record is the strongest evidence here. In workshops the ECB ran with 13 supervised banks across nine countries in 2025, it found that “only a few banks reported to effectively applying data management standards in practice”. Its own supervisory priorities for 2026 to 2028 note persistent deficiencies in banks' risk data aggregation frameworks “with no improvement” on the previous year.
The pattern in proposals is consistent. Data preparation appears as a line item that is already handled, priced as a fraction of the model work, and then absorbs the first quarter of the project. An audit of the actual data before the scope is signed costs a fraction of the same audit six months later, when it arrives as a change request and a delay.
Choosing who builds it matters more than the model
Our free checklist covers what to ask in an RFP, three warning signs that a vendor may not deliver, and a scoring matrix for comparing proposals on something other than price.
What the 20% do differently: from prototype to production value
The teams that ship have the clearest definition of done and the shortest distance between an experiment and something a colleague can run. Model quality is rarely what separates them.
We hold ourselves to that test. On a private on-premise knowledge assistant for a logistics operator, done was four measured numbers rather than a demo: answer faithfulness 1.00, answer correctness 0.99, relevancy 0.98 and context relevance 0.96, with nothing leaving the customer's network.
Andrew Ng put the constraint plainly to IEEE Spectrum in February 2022: “I think for a lot of the practical applications the bottleneck will be whether we can efficiently get the data we need to develop systems that work well.”
Factor | Common pattern | What the 20% do |
|---|---|---|
Problem definition | “Use AI to improve X” | A measurable target agreed before any model is built |
Data readiness | Assumed clean, checked late | Audited before the project is scoped |
Production path | Prototype handed to IT | The deployment pipeline designed from day one |
Success criteria | Set after the fact | Agreed with the business sponsor upfront |
Exit strategy | None | A performance threshold and a review date |
In a regulated European institution there is a further step that catches teams from outside the sector. Under the ECB's guide to internal models, switching a credit model from a traditional approach to a mostly machine-learning one is itself a material change requiring supervisory approval, with four months' notice before the intended application date. From 1 October 2026 that gets easier: the ECB will let banks implement material credit-risk model changes shortly after submitting a complete application package. Either way, a team that discovers this after building the model has lost two quarters.
A failing AI programme rarely announces itself. It consumes engineering time and management attention gradually, and no single month looks bad enough to escalate, which is why the abandonment shows up in a survey a year later rather than in a decision. The defence is the last row of that table: a performance threshold agreed at the start, and a date on which somebody has to say out loud whether it was met.
AI work that reached production
Stuck between a working prototype and production?
WislaCode builds and runs machine learning systems inside regulated environments, where the model is the easy part and the pipeline, the monitoring and the audit trail are the work.
What percentage of AI projects actually fail?
The quoted figure is more than 80%, which comes from RAND's 2024 report and is framed there as “by some estimates” rather than as a RAND measurement. Measured figures are narrower and more useful: S&P Global Market Intelligence reported in 2025 that the average organisation scrapped 46% of its AI proofs of concept before production.
What is the most common reason AI projects fail?
Data, followed closely by an unclear problem definition. RAND found many projects fail because the organisation lacks data adequate to train an effective model. IBM's Global AI Adoption Index 2023 put limited AI skills first at 33% and data complexity second at 25%, so the two usually appear together.
Why do AI projects fail in production even when they work in testing?
Because live data is not test data and it keeps changing. A model tuned on a controlled sample meets a different distribution, missing fields and latency limits, and its performance decays as behaviour shifts. The ECB found that few of the European banks it examined had automated validation tools or explicit fallback procedures for AI failures.
Does the EU AI Act change how AI projects should be run?
For credit scoring, materially. Annex III point 5(b) of Regulation (EU) 2024/1689 makes it high-risk, with fraud detection expressly excepted, and Article 10(3) requires training data to be “relevant, sufficiently representative, and to the best extent possible, free of errors and complete”. Those obligations now apply from 2 December 2027 after Regulation (EU) 2026/1744 deferred them.
What can organisations do to improve their AI project success rate?
Three things, in order. Agree a measurable success criterion and a review date before any model is built. Audit data quality before scoping rather than after, since that is where the schedule goes. And treat deployment, monitoring and retraining as engineering work owned from day one.