Every year, Gartner, McKinsey and BCG publish a report with the same number — between 70 and 87 percent of AI projects never reach production. The figure recurs so consistently that it has become statistical wallpaper. Everyone knows it, nobody responds.

There is something unsettling in that. If four out of five projects end at proof-of-concept, we are not talking about isolated execution errors. We are talking about a failure structure — repeatable, predictable, identifiable before it happens.

For two decades I've worked with boards of banks, utilities and manufacturers on projects where technology was a tool but never the goal. Now I look at the AI sector from a different angle — as an integrator connecting ambitious organizations with technology teams. This article is an attempt to systematize what I see in conversations every week.

In this piece
  1. Let's define the failure we are talking about
  2. Seven reasons a pilot doesn't become a product
  3. Three features of projects that reach production
  4. A decision framework before starting a pilot
  5. A conclusion for those deciding AI budgets

Let's define the failure we are talking about

An AI project does not "fail to reach production" in one way. I see four variants of the same story:

  • The technical pilot succeeds, but the project never receives a deployment budget. The team shows the model works on 94% of the test data. The board nods, funding for the next quarter is not approved.
  • The pilot is partially deployed and dies in maintenance. The system runs at two branches; nobody has the budget or capability to develop it further. A year later, employees return to the old process.
  • Technical deployment succeeds, but nobody uses the system. The model recommends optimal decisions. Decision-makers ignore the recommendations because nobody worked on earning their trust.
  • The system works, but does not generate the value that was promised. Technical metrics are excellent. ROI is incalculable, because nobody defined what ROI meant for this project at the start.

In all four variants, the organization spent money on a technology that — from a business standpoint — never existed. That is the failure we are talking about.

Seven reasons a pilot doesn't become a product

1. The project started from the technology, not the problem

"We need GenAI in banking." "We have to introduce AI agents in customer service." "Our competitor has computer vision, we should too." These are sentences I hear regularly — and they almost always lead to projects that end in PoC.

The right question is different: which business process in our organization is painful, expensive or broken today — and is AI the best way to solve that specific problem? If the answer does not come in a few sentences, the project has a structural problem before it even begins.

2. No business owner with real authority

AI projects run from the IT department, without a strong business owner, have below-average odds of success. Not because IT doesn't understand the technology — often it understands better than anyone else in the company. But because production deployment requires process change, and processes are not changed from the IT role.

A project needs an owner who can say "yes, in my division employees will use this system" — and enforce that without asking others for permission.

3. Success metrics defined after the fact

A question asked in the fourth month of a pilot — "how are we actually measuring whether this works?" — is a sign that the project has already lost. Metrics must be defined before the first line of code, and they must be:

  • Objectively measurable, not through a satisfaction survey
  • Tied to a specific number in the P&L or an operational KPI
  • Agreed between the business owner and the vendor
  • Measured before launch (baseline) and during the project (trajectory)

4. Choosing a vendor that builds prototypes

The AI vendor market splits into three groups. Creative agencies that build flashy demos. Research teams specializing in new science. Firms that deploy production systems. These three groups often look identical on a website.

The difference shows up only when the project moves beyond the happy path and you have to handle corner cases, monitoring, model versioning, rolling out updates without service interruption. Agencies and research teams don't have those capabilities — not because they don't want to, but because it's a different profession.

The vendor question that filters "Show me a system you deployed in production two years ago that still runs today — and tell me how many times you updated it." If the answer is vague or leads to a demo, you know enough.

5. No maintenance plan from day one

An AI system in production requires active maintenance. Data changes (data drift), models lose quality, new edge cases appear, regulations evolve. Projects that don't have an operational budget for 3–5 years after deployment are projects destined to die.

This is where many organizations fall apart — the deployment budget is planned, the maintenance budget does not exist. A year later the system "doesn't work," though in reality nobody was maintaining it.

6. Misfit with the existing technology stack

A bank with a core system from the 1990s and an application layer from the 2000s will not deploy a cloud-native AI solution in weeks. Not because the technology doesn't work — because the integration takes six months, and the pilot had three.

A good technology partner asks about the existing stack in the first hour of conversation, not in the fifth month. A bad vendor brings a demo and is later surprised that "your systems are hard."

7. The project has no option to say "no"

The biggest trap — projects where the deployment decision was made before the pilot started. The pilot is then not a validation of a hypothesis, but a ceremony. Nobody can say "this doesn't work," because that isn't an option on the table.

A healthy project starts from the question "will this solve our problem" — and has a structure where the answer could be "no." If that option doesn't exist, the project is not a pilot — it's a budget looking for justification.

Three features of projects that reach production

After that list, you might think production deployment requires a perfect sequence of events. In reality, three things done well are enough.

1. One business owner, one decision, one P&L

The project has an owner at a level that allows decisions about processes in their division. The owner sees the project in their P&L — as a cost or a saving — and is ready to carry the accountability at year-end. That automatically filters out projects with no real inside.

2. Metrics defined before launch, measured from day one

Baseline taken before work begins. Trajectory monitored during the project. The rollout decision based on hard numbers, not on the impression from a demo. This sounds obvious — it is rarely implemented.

3. A technology partner with a history of production deployments in a similar context

Not in a similar industry — in a similar technical, regulatory and operational context. A team that deployed AI systems in a large bank understands DORA and the AI Act in a way a team used to startups cannot learn in three months.

A decision framework before starting a pilot

Instead of starting a pilot, I suggest a simple checklist. If any of these questions doesn't have a clear answer, the project needs work before launch, not after.

  1. What specific business problem are we solving? (Not: "we want to use AI." Yes: "credit complaint handling time is 12 days; the goal is to get to 5.")
  2. Who owns this problem in the organization? Must have a name and operational authority.
  3. How do we measure success? A specific number, not declarative satisfaction.
  4. What is the baseline — the current state against which we measure change?
  5. What is the budget for the pilot, deployment and maintenance across a three-year horizon? If we only fund the pilot, we know we'll end at the pilot.
  6. What does the continuation decision look like? What conditions must be met to roll out — and what conditions mean we stop.
  7. Which systems must we integrate, and do we have the capability for that integration?

An organization that has answers to these seven questions before starting a pilot statistically does not have the "80% of projects don't reach production" problem. It has a different problem — sometimes a pilot doesn't reach production, because we learn it shouldn't. And that's a good outcome.

A conclusion for those deciding AI budgets

The "80% of pilots don't reach production" number is not a natural law of the sector. It is a function of how organizations start AI projects — and it is fixable in a single project, if it is started consciously.

The most costly decision a board makes in an AI project is not the budget decision. It is the decision about what the first hour looks like — whether we start with a vendor presentation or with a conversation about the business problem we want to solve.

The same dollars spent in a different sequence produce a project that reaches production.

Next conversation If you feel your organization is considering an AI project and you want to talk about how to set it up on the 20% side from the start, rather than the 80% side — write to us. The first conversation is an hour and costs nothing.