From pilot to production, why AI projects stall

The pattern repeats in organizations of every size. The test works, the team is pleased, the presentation lands well. Six months later nobody uses it and nobody quite knows why it stopped.

It isn't a technology problem. Pilots and production are two different things, and they have to be designed differently.

Reason 1: the pilot was designed to impress

Many tests are built to prove the technology works, using curated data and favourable cases. That answers a question which is rarely the constraint: is this possible?

The question that matters is different: does this fit how we work? A well-designed pilot uses real cases, including the difficult ones, and measures failures as carefully as successes.

Reason 2: nobody defined what moving forward meant

If the success criterion wasn't written down before starting, the debate at the end is endless. Some see a promising result, others see an unacceptable error rate, and without an agreed threshold the decision gets postponed.

The criterion has to be a number and a condition: for example, "if 70% of outputs are usable without correction and time per case drops at least 40%, we scale."

Reason 3: integration was never assessed

The pilot runs in a separate tool with files loaded by hand. It works. But production means connecting to the ERP, respecting permissions, syncing data and handling failures.

That work is often larger than the test itself, and it surfaces only once budget and enthusiasm are spent. The fix is simple: during the pilot, someone from IT has to state in writing whether the integration is viable and what it involves.

Reason 4: there is no owner in the operation

A project driven by innovation or technology teams, without an owner in the area where the process actually lives, loses its sponsor the moment the pilot team moves on.

The owner has to be the person whose metric improves. If the project doesn't improve anyone's metric, there is no possible owner — and that's valuable information to discover early rather than late.

Reason 5: exceptions sink the business case

It works in 85% of cases. The remaining 15% are unusual situations the team resolves with judgement. If nobody defines what happens with those, the team ends up checking 100% just in case, and the saving evaporates.

Designing the exception path is part of the work, not an afterthought: how they're detected, who they go to, and how fast they're resolved.

What to define before starting

Four answers in writing, half a page:

1. Which number it has to move, and its current value.
2. Who will use it every day, by name.
3. Which systems it must integrate with in production, and whether that's feasible.
4. Who decides the move to production, and on what criteria.

A pilot without those four answers isn't a pilot — it's a demo.

What a good pilot looks like

• It runs four to eight weeks.
• It uses a representative sample of real cases, including the awkward ones.
• It's operated by the team that will use it later, not only by technical staff.
• It measures against a known baseline.
• It ends with a written decision: scale, adjust or drop.

Dropping is also a good outcome. A pilot that costs five weeks and prevents a six-month implementation that would never have worked did exactly its job.

The jump to production

When the decision is to proceed, the work that follows is less glamorous: permissions, monitoring, error handling, training, support. It's usually twice the effort of the pilot, and it's what separates a successful test from a process that works every day at nine in the morning.

Frequently asked questions

Why doesn't a successful proof of concept become production?

Because the pilot is designed to prove the technology works, not to fit the operation. When scaling time comes, integration, permissions, exceptions and change management appear — none of which were considered.

How long should a pilot run?

Four to eight weeks. Longer usually signals the scope was never clear, and the project drifts into testing indefinitely without deciding anything.

What should be defined before the pilot starts?

The success criterion as a number, who will use it daily, which systems it must integrate with in production, and who approves the next step. Without those four answers the pilot has no exit.