Why AI proofs of concept never reach production

The proportion of AI proofs of concept that never reach production is high in every organisation. The causes are remarkably consistent, and none of them is an algorithm problem.

Cause 1: the metric was never settled

The project starts with an objective phrased in natural language: "forecast demand better", "detect anomalies". Nobody wrote what "better" means in numbers, or compared to what.

Consequence: at the end of the POC the team presents 87% accuracy. Management asks whether that is good. Nobody can answer, because the question only has meaning relative to current practice, which was never measured.

The fix fits in one sentence: before the first line of code, write down the metric, its current value, and the threshold above which the project counts as successful. Have the business sign it.

Cause 2: the POC runs on data production will not have

The extract used for the POC was often prepared by hand, cleaned by someone who knows the subject, and covers a period chosen for its quality.

In production the data arrives as a stream, with its missing values, its duplicates and its unannounced format changes. The model that reached 87% drops to 60%, and nobody understands why because the POC was never confronted with that reality.

The fix: build the POC on the real stream, with its defects, from day one. It is slower to start and it removes the main nasty surprise.

Cause 3: the industrialisation cost was never budgeted

The POC costs a few tens of thousands. Industrialisation — packaging, deployment, retraining pipeline, monitoring, error handling, operations documentation, handover to the internal team — often costs more.

When that amount has not been anticipated, it arrives at the worst moment: the POC is a success, everyone is enthusiastic, and you have to ask for a second budget larger than the first for a project that "already works". Many projects die exactly there.

The fix: present a two-tranche budget from the start, with the second one priced. A provider who does not mention the industrialisation cost in their initial proposal is not doing you a favour.

Cause 4: nobody knows who will operate the model

A model in production needs an owner: someone who receives drift alerts, decides on retraining, and answers when a user disputes a prediction.

That role is almost never assigned during the POC. The model is handed to a team that did not ask for it and lacks the skills to diagnose it. Six months later it degrades silently.

The sequence that works

1. Two weeks of framing: feasibility on real data, arbitrated metric, established baseline.
2. An explicit go or no-go decision, with the full two-tranche budget.
3. Model development under the rule that it must beat the baseline to be deployed.
4. Industrialisation, including drift monitoring and an incident runbook.
5. A named handover, with an identified and trained owner.

Each of those steps costs less than running one more POC.