Why AI projects in operations stall after the pilot, and how to prevent it

Is it true that 95 percent of AI pilots fail?

The figure comes from The GenAI Divide: State of AI in Business 2025 by Project NANDA, a research group at the MIT Media Lab. The report is dated July 2025 and made the news in August 2025, including through Fortune on 18 August. The key sentence in the summary is that 95 percent of organisations get no return from generative AI. The same summary states that only 5 percent of integrated AI pilots deliver millions in value, while the vast majority remain stuck with no measurable effect on the profit and loss account.

Anyone who reads the report itself will find a narrower basis than the headlines suggest. According to its own methodology section, it rests on a systematic review of more than 300 publicly disclosed AI initiatives, structured interviews with representatives of 52 organisations and survey responses from 153 senior leaders, collected at four industry conferences. The research period ran from January to June 2025 inclusive. The document presents itself as preliminary findings, and one of the four authors is listed as the reviewer.

What counts as failure is also narrower than it seems. The report is about generative AI. The figure says nothing about predictive models for maintenance or demand, or about image recognition on a packaging line. For task-specific applications, 'successfully implemented' in the text means that users or executives report that the application has a marked and sustained effect on productivity or financial results. The appendix also states that success is defined as deployment beyond the pilot phase with measurable KPIs, with the return measured six months after the pilot. Of the figures on the step from pilot to production, the authors themselves write that they are directional, based on individual interviews and not on official company reporting, and that definitions of success vary by organisation.

Moreover, those figures are shares of organisations, not of pilots. According to the summary, 60 percent of organisations evaluated custom or vendor applications, 20 percent reached a pilot and 5 percent reached production. If you look only at the organisations with a pilot, those numbers give roughly one in four that reached production. The report itself does not make that calculation; it is our reading of its own numbers.

The authors cite further limitations. The sample may not be representative of all segments and regions. Organisations that are willing to talk about their AI problems may differ systematically from organisations that are not. And six months may be too short to assess more complex systems, which means success may be underestimated. No conclusion for a Dutch food company or a refrigerated haulier with eighty employees can be drawn from that.

In the retelling, the figure has shifted further. On 18 August 2025, Fortune ran the headline that 95 percent of generative AI pilots at companies are failing, and described the basis as 150 interviews, a survey of 350 employees and an analysis of 300 deployments. Those are different numbers from the ones the report itself gives. Futuriom analyst R. Scott Raynovich also pointed out that the report does not explain exactly how the 95 percent figure was arrived at. The original download link on the MIT site now redirects to the project page; we read the archived version of 18 August 2025.

What do other studies say about failed AI projects?

The other widely used figures are also less solid than they sound. In August 2024, RAND published a report on the root causes of failed AI projects, based on interviews with 65 data scientists and engineers with at least five years of experience. The often-cited 'more than 80 percent of AI projects fail' appears in that report as an estimate by others, not as its own measurement. In July 2024, Gartner predicted that by the end of 2025 at least 30 percent of generative AI projects would be abandoned after the proof of concept, because of poor data quality, inadequate risk controls, escalating costs or unclear business value. That too is a prediction and not a count.

So there is no reliable failure rate that you can apply to your own company. The causes, by contrast, do recur consistently. They are more useful than any percentage, because you can do something about them in advance.

Why do AI pilots stall in operations?

For medium-sized companies, the question is no longer theoretical. According to provisional figures from CBS (Statistics Netherlands) for 2025, 27 percent of companies with 10 to 50 persons employed use AI, and 45 percent of companies with 50 to 250 persons employed. By sector, that is 16 percent in manufacturing, 12 percent in trade and 7 percent in transport and storage. Anyone who starts will sooner or later face the step from trial to daily work.

From the studies above, we derive five causes that keep recurring at that step. The grouping is our own translation to operations, not a list from a single report. The causes are less about the model than about the organisation around it:

• There is no owner in the line organisation.
• The data is not maintained after the pilot.
• Only the champion has been trained.
• The application falls outside the quality system.
• No one has defined in advance what success is.

Cause 1: there is no owner in the line organisation

A pilot almost always has a champion: an enthusiastic employee, someone from IT or a vendor. After the trial period, the work has to move to the line organisation, to the planner, the team leader or the QA manager who runs the process every day. If no one there becomes the named owner, then after the evaluation there is no one who decides what happens with deviations, who updates the work instruction and who calls the vendor.

The MIT report describes how the organisations that did get through let initiatives originate with line managers rather than a central lab, and spread implementation while keeping accountability clear. That pattern comes from interviews and is not proof of cause and effect. It does, however, fit with what RAND calls the most common cause: misunderstandings about which problem actually needs to be solved, with models that are optimised for the wrong metric or do not fit into the workflow. An owner in the line organisation knows that problem at first hand.

Cause 2: the data is not maintained after the pilot

During a pilot, the data is often put in order by hand. An export is cleaned up, an item file is updated, the awkward exceptions are left out. After that, ordinary work carries on, with new items, suppliers, packaging and customers. If no one has been given the task of keeping that up to date, the system works from a picture of how things used to be. Quality then declines unnoticed, until the shop floor quietly ignores the system.

RAND places two of its five root causes in this area: the organisation does not have the data that is needed, or does not have the infrastructure to manage data and deploy models. In a survey of 1,203 data management leaders in July 2024, Gartner found that 63 percent of organisations either do not have, or are unsure whether they have, what Gartner calls the right data management practices for AI. Gartner predicts that, up to the end of 2026, organisations will abandon 60 percent of AI projects that are not supported by AI-ready data. For practical purposes, what Gartner adds matters more: AI-ready data is not a one-off job but an ongoing task.

Cause 3: only the champion has been trained

In a pilot, one person often works intensively with the system. That person knows what it is good at, where it goes wrong and when a suggestion should be ignored. The colleagues on the other shift, the stand-in during the holidays and the new planner do not know that. As soon as the champion moves on to something else, that knowledge goes with them.

CBS sees the same hurdle at national level, one step earlier. Of the companies that have considered AI but do not use it, 73 percent cite lack of experience as the main reason, according to the figures for 2025. That concerns the decision to start, not pilots that stall, but the hurdle is the same: knowledge that is missing in the organisation. In the MIT report, unwillingness to adopt new tools is the most frequently cited barrier to scaling up, followed by concerns about the quality of the output.

Training is therefore part of the roll-out itself, for everyone who runs the process, not a separate course afterwards. What the AI Act asks for on employees' AI literacy is set out in our article on that subject.

Cause 4: the application falls outside the quality system

In food manufacturing, the fresh produce trade (AGF: potatoes, vegetables and fruit) and greenhouse horticulture, work is often assessed against a standard: HACCP, FSSC 22000, BRC, IFS, GMP+ or GlobalG.A.P. A pilot often runs alongside that system. It is not in a work instruction, not in the verification and not in the records. As long as it is a trial, that is barely noticed. At the first audit or customer query it is, and switching it off is then the easiest way out.

Besides systems that do not learn from context, the MIT report also cites brittle workflows and poor alignment with day-to-day operations as main reasons why custom and vendor applications fail to progress. In a certified company, that alignment is part of the quality system. Two of the seven basic HACCP principles listed by the NVWA (Netherlands Food and Consumer Product Safety Authority) are: check regularly whether your HACCP approach is effective, and record how you comply with the HACCP rules. An AI step that touches a quality task belongs in the same system: described, verified and recorded, with a human who decides and signs. What that looks like around a critical control point is covered in our article on HACCP and AI.

Cause 5: no one has defined in advance what success is

A pilot that feels good is hard to defend after three months to a management team that has to decide on licences and hours. Without a baseline measurement there is nothing to set the result against, and the evaluation becomes a matter of gut feeling.

The MIT report shows how that plays out. Asked to allocate a hypothetical budget, the executives surveyed gave the largest share to sales and marketing, according to the authors partly because outcomes are easy to measure there. Among manufacturers, by contrast, the emphasis was on operations, and the authors saw some of the largest savings in the back office. A procurement director at a large pharmaceutical company is quoted in the report asking how the effect of a team that works faster can be quantified. Gartner cites unclear business value as one of the four reasons why generative AI projects are abandoned after the proof of concept.

A useful measure is small and specific: the time per order, per document or per check, the number of corrections afterwards, and how much time it takes to check the output. With the calculator (in Dutch) you convert your own assumptions into an order of magnitude per year. That is an indication based on your own input and not a promise, but it is the starting point against which you will later measure.

How do you get an AI pilot into day-to-day operations?

The causes above can be dealt with in advance. Use the list below before the pilot starts, not at the evaluation. Every point you cannot fill in is a reason to postpone the start or to make the process smaller.

• Choose one work process with a specific problem, not a tool. Describe in two sentences what is going wrong now and for whom. If you are still deciding which process, our article on where to start in wholesale and logistics will help.
• Record the baseline measurement before the start: time per task, number of errors or corrections, and the time that checking takes. Agree what improvement counts as success.
• Appoint a named owner in the line organisation. After the pilot, that person is responsible for use, deviations and adjustments. IT and the vendor provide support but are not the owner.
• Assign responsibility for data management. Who maintains master data, item files and document templates, and how often do you measure performance again against the baseline measurement?
• Train everyone who runs the process, including the second shift and the stand-ins. Record who has been trained in what, and when.
• Write the AI step into your quality system: work instruction, verification, record-keeping, and who decides and signs. Include re-verification in your change management, so that a new supplier, new packaging or a new standard is a trigger to measure again.
• Plan in advance when you will evaluate against the baseline measurement, with three possible outcomes: continue, adjust or stop. Stopping is a valid outcome, provided it is based on figures.
• Agree what happens if the champion leaves or the vendor changes the product. An application that depends on one person or one contract is not yet part of the operation.

AI that keeps running: how we approach this

Our way of working follows the same sequence. On a Practice Day, we build one work process from your own operation with the people who run that process every day, at your own location, and the team learns it while it is being built. If the process touches a standard, your quality or QA manager takes part and we record the working agreements in the language of that standard, with an accountability document showing who has been trained in what. If a process proves unsuitable, we choose another, because a workflow that has been forced through is soon switched off again.

What we cannot promise is that every process is suitable or that an application will keep running of its own accord. That depends on the five points above, and above all on the owner and the data after the first weeks. The Practice Scan is intended to clarify part of that in advance: which process to start with, what data it needs and where the points to watch are. That is the starting point for your baseline measurement.