Why AI Projects Fail: It's Rarely the Model
TL;DR: Most AI projects that fail do so between pilot and production, or in the year after the vendor hands over. The cause is rarely the model. It is usually ownership: nobody inside can run the system, leaders want different outcomes, the data was never production-grade, governance shows up at go-live, or the builder leaves. Each has warning signs you can check for early.
A pilot that works in a demo proves that a model can do a task. It does not prove that your organisation can run it next year, on live data, under audit, after the people who built it have moved on. That second question is where most AI programmes stall.
What the research says about the AI project failure rate
The figures you see quoted are real, but each comes with a caveat.
- RAND (2024). In The Root Causes of Failure for Artificial Intelligence Projects and How They Can Succeed, RAND writes that “by some estimates, more than 80 percent of AI projects fail — twice the rate of failure for information technology projects that do not involve AI.” Note the hedge: RAND’s own evidence comes from interviews with 65 experienced data scientists and engineers. They named five root causes: a misunderstood problem, missing data, chasing the latest technology instead of a real user need, inadequate infrastructure to manage data and deploy models, and problems too hard for AI. Only the last is about what the model can do.
- Gartner (July 2024). Gartner predicted that “at least 30% of generative AI (GenAI) projects will be abandoned after proof of concept by the end of 2025, due to poor data quality, inadequate risk controls, escalating costs or unclear business value.” That was a forecast, not a measurement.
- MIT NANDA (2025). Fortune reported that in The GenAI Divide: State of AI in Business 2025, “for 95% of companies in the dataset, generative AI implementation is falling short,” and The Register quotes the report as saying “only 5 percent of custom enterprise AI tools reach production.” The sample was modest (52 interviews, a survey of 153 people and a review of more than 300 public initiatives), so read it as directional.
The numbers disagree, but the explanations line up. None of these sources puts model quality at the centre. They point at problem definition, data, risk controls, cost and fit with how work actually gets done.
Where AI programmes actually stall
The failures cluster at two points: the move from pilot to production, and the handover from whoever built the system to whoever has to run it. Five causes account for most of them.
No internal team that can run it
A model in production needs someone to watch its evaluation scores, adjust it when inputs drift, handle incidents and answer the auditor’s questions. If the only people who understand it work for a vendor or a central innovation lab, the business unit that nominally owns it cannot change anything. Small fixes become change requests, change requests become budget conversations, and the system quietly falls out of use.
Leadership that wants different things
One executive wants a visible AI story, another wants cost out, a third wants one painful process fixed. A pilot can satisfy everyone for a while because it commits to nothing. Production forces a choice about which metric the system must move. RAND’s most common root cause, a misunderstood problem, is often this disagreement surfacing late.
Data foundations that were assumed
Pilots run on an extract someone cleaned by hand. Production needs a pipeline that delivers the same fields at the same quality every day, with lineage and access controls. When the team finds customer records spread across systems with no shared key, the AI project becomes a data programme nobody budgeted for.
Governance added too late
Risk, compliance and security often see the system for the first time when it is ready to launch. Their questions are reasonable: where does the data go, how is output quality measured, who approves a prompt or model change, and what happens when it is wrong. If none of that was designed in, the answers take months.
Vendors who build and leave
Outside help is not the problem in itself. Fortune’s report on the MIT NANDA research says buying from specialised vendors and building partnerships “succeed about 67% of the time,” while internal builds succeed only one-third as often. The failure is narrower: a vendor delivers a working system and a document, its team moves to the next client, and nobody left behind can extend it. The system worked on handover day and degraded after that.
A stage-by-stage diagnostic for AI pilot to production
If you recognise two or more warning signs at one stage, fix them before moving on.
| Stage | Warning signs | What to do |
|---|---|---|
| Before the pilot | The use case came from a vendor demo. Nobody can name the metric it should move. Sponsors describe different goals. | Agree one business outcome and one accountable owner. Write down what “good enough to launch” means. |
| During the pilot | Data is a one-off extract. Risk and security have not seen it. Nobody from the future operating team is involved. | Build on the production data path. Bring risk in at week one. Put operators on the build team. |
| Pilot to production | No budget for integration, monitoring or support. Launch is blocked on a review nobody scheduled. | Fund production as its own phase. Design evaluation, logging and access control into the first release. |
| Handover and year two | Every change goes back to the vendor. Quality is not tracked. Usage is falling. | Make knowledge transfer a contract deliverable. Train the internal team to evaluate, update and release. |
Before the pilot: decide what it is for
Most of the damage is done before any code is written. Pick a process whose current cost is already measured, such as hours per case, error rate or response time. Name one executive owner who will still be accountable in a year. Agree in writing what the system must achieve to go live and what would make you stop. This is the Spark stage of our approach, and an Executive AI Workshop is a quick way to find out where the leadership team disagrees.
During the build: treat the pilot as release one
- Use the real data path. The pilot should read from the sources production will use, so data gaps surface in week two rather than month six.
- Write an evaluation set early. A few hundred labelled examples from real cases, run on every change, tell you whether a prompt or model update helped or hurt.
- Log inputs, outputs and decisions with enough context to reconstruct why the system did what it did.
- Put the people who will run it on the team. Pairing transfers more than documentation does.
This is how we work in the Build stage, building production systems alongside the client’s engineers.
After go-live: make ownership real
A handover is complete when your team can ship a change without the vendor: adjust a prompt, add an evaluation case, retrain a model, roll back a bad release. Test that before the contract ends. Run governance as a routine with a named owner, a change log and a review cadence, not as a one-off launch gate. That is the Own stage, with the AI Academy training the people who take the system over.
What this looks like for banks and telcos in Bangladesh
The same failure modes apply here, but local conditions make some of them sharper.
Bangla data. Customer messages, call-centre transcripts and complaint forms arrive in Bangla, English and romanised Bangla, often in the same sentence. The BenLLM-Eval study (LREC-COLING 2024) found that zero-shot LLMs did well on some Bengali tasks but performed poorly on most compared with fine-tuned models. A pilot evaluated on clean English examples tells you little about production, so build the evaluation set from real local text, messy cases included.
Data-residency expectations. Banks work under Bangladesh Bank’s ICT security guidelines, and the government has approved the Personal Data Protection Ordinance, 2025. In practice, boards and regulators in banking and MFS and telecom generally expect customer data to stay under local control. That often rules out sending raw data to an overseas API and points towards on-premises or in-country deployment with open-weight models. Settle this before the pilot, because changing the hosting model later usually means rebuilding.
Scarce AI engineers. Experienced ML and platform engineers are hard to hire in Dhaka and easy to lose. That makes “build and leave” more expensive, because there may be nobody internal to absorb the system. The practical answer is to grow the owning team while the system is being built, not to try hiring it after go-live.
The short version
If your AI programme is stalling, check ownership before you check the model. Ask who will run the system in a year, whether the data path is real, whether risk has approved the design and whether your team could ship a change without outside help. Fix the weak answers first.
FAQ
What percentage of AI projects fail?
There is no reliable single number. RAND’s 2024 report says that by some estimates more than 80 percent of AI projects fail, twice the rate of IT projects without AI. Gartner predicted in 2024 that at least 30% of generative AI projects would be abandoned after proof of concept by the end of 2025. Treat these as evidence of a pattern, not a base rate for your organisation.
Why do AI pilots not make it to production?
Pilots are usually built on a cleaned data extract by a small team, with no integration, security review or support model. Production needs live data pipelines, an accountable owner, monitoring and an approved risk position. When nobody planned or funded that work, the pilot succeeds and then stalls.
Is AI project failure usually a technical problem?
Rarely the model itself. Of the five root causes RAND identified, only one concerns problems too hard for AI. The others are a misunderstood problem, missing data, chasing new technology instead of a user need, and inadequate infrastructure to manage data and deploy models.
How do you move an AI pilot to production?
Before the pilot starts, decide who will own the system in production, which metric it must move and what the risk team needs in order to approve it. Build on the production data path, not an extract. Design in evaluation, monitoring and access control from the first release, and put the people who will run it on the build team.
Should we build AI in-house or use a vendor?
Fortune’s report on MIT NANDA’s 2025 research says buying from specialised vendors and building partnerships succeed about 67% of the time, while internal builds succeed only one-third as often. A partner can get you to production faster, but make knowledge transfer and a working handover part of the contract, or every change will depend on the vendor.
What makes AI projects harder for banks and telcos in Bangladesh?
Customer text mixes Bangla, English and romanised Bangla, and general-purpose models handle Bangla less reliably than English. Boards and regulators generally expect customer data to stay under local control, which often means on-premises or in-country hosting. Experienced AI engineers are scarce, so a system only an outside vendor understands is an operational risk.