Why your AI pilots never reach production

The pilot worked. And that is precisely the moment it stopped moving.

Carlos Andrés Ramírez ·

The pilot worked. You showed it, there was polite applause, someone said it should go company-wide. That was in March. It is sitting exactly where you left it.

I have watched flawlessly executed pilots die quietly. No cancellation meeting, no minutes. Nobody kills them and nobody funds them, so they keep running in a sandbox until the team that built them gets reassigned. A year later the same use case shows up in the backlog under a new name and a new sponsor, and the whole show starts again.

The standard diagnosis never changes. Dirty data, weak governance, change management. All true and all useless, because it describes the patient without saying what anybody signs on Monday.

What blocks the move to production is a money decision nobody made, and it rarely reaches the minutes: who pays to keep this thing running once it stops being news.

The symptom

Why don't my AI pilots reach production?

Because a pilot gets approved as an experiment and production gets approved as spend. Two conversations, two committees, two appetites for risk. And the team that won the first one usually finds out late that the second was never on anyone's calendar.

When that second decision is missing, the project settles into a state you can recognise from across the room. It does not look like failure. It looks like nothing at all.

The problem underneath

Nobody approved the cost of it working.

A pilot is cheap because it is incomplete. It runs on an extract somebody prepared, it is watched by the person who built it, and if it falls over on a Tuesday nothing happens. Production reverses all three, and every reversal carries a price: a pipeline that holds itself up, observability that tells you the model drifted before a customer does, and someone on call. That package is not a project extra. It is half the TCO, and it lands after the committee already believed it had approved the spend.

And there is a second thing, considerably less comfortable to say out loud. A pilot carries a perverse incentive inside it: while it stays a pilot, nobody answers for its return. You can walk it through the board, put it in the annual report, dress up the transformation update with it. The moment it goes live it becomes a cost line with somebody's name on it, and that somebody defends it next year in front of a CFO. More people than you would think are quietly served by the pilot staying a pilot.

A pilot that has gone six months without being killed or funded is not under evaluation. It is in a drawer with the light left on.

BECOME

The sequence

What has to be decided, and in what order?

The order matters more than the content. Most organisations already have pieces of this written down somewhere, in the wrong sequence: they open with architecture and get to ownership last, when ownership is the one thing that unlocks the other four.

Kill line
The criterion that decides whether the pilot gets killed or funded, written before anyone looks at a result. A number and a date. Written afterwards, it gets written to justify the call somebody already preferred.
Owner
The business executive who takes the outcome onto their own scorecard. Not the data function and not the build team: whoever already answers for that process and will defend the cost line when the budget closes.
The line
Which P&L line carries the recurring cost: inference, platform, maintenance and on-call cover. If it comes out of innovation, that is not production, that is an extension.
Buying order
What gets bought first when the budget will not stretch. Pipeline before observability, and the polished interface last. It gets done in reverse almost every time.
Rollback
What happens the day you have to switch it off: who runs the process meanwhile, and how long the manual path takes to come back. Without that answer risk will not sign, and they are right not to.

Five answers, one page, and not one of them is an engineering question. Which is exactly why they get postponed: nothing in the project plan owns them, and what has no owner gets debated in corridors until everyone forgets. Meanwhile the team keeps tuning model accuracy, which is the only part of the problem it knows how to solve.

Take the pilot that has been parked longest and find the line in the approval minutes that says what happens if it works. If it is not there, you have your answer. Write it now, with the five decisions resolved, and take it back to the committee that approved the pilot with a proposed kill date attached. If they will not set that date, you have just learned what the project is worth to them.

Frequently asked questions

Why don't my AI pilots reach production?

Rarely because of the model. They stall because the pilot was approved as an experiment while production demands a recurring spend decision nobody prepared: data platform, observability, maintenance and on-call cover. Without a business owner carrying that cost in their own budget and a written kill date, the project keeps running in a sandbox until the team disbands.

When should you kill an AI pilot?

When the kill date set at approval arrives and the criterion written at that point is not met. Both have to be written before anyone sees results, because afterwards the criterion quietly bends to fit the decision people already preferred. A pilot without a kill date never gets killed, it gets abandoned, which costs more and teaches nobody anything.

What does it actually cost to run an AI system in production?

The part almost nobody budgets is the running: the pipeline that no longer gets fed by hand, observability to catch the model drifting, maintenance and someone on call when it breaks. It often weighs as much as the build, and it arrives once the committee already considered the spend approved. Inference cost also grows with usage, so success makes the invoice bigger.

Which budget pays for an AI system in production?

The operating budget of the function that owns the process. Funding live operations from an innovation fund guarantees the system falls over at the first budget cut, because that fund is temporary by design. Moving the spend into an operating line is the most reliable signal that a pilot genuinely reached production, far more reliable than any demo.

Let's unstick your pilot