The AI Pilot That Never Ships: Why Proofs of Concept Stall Before Production

Most AI pilots don’t fail. They stall. The demo runs, the room nods, and the project settles into a holding pattern where nobody kills it and nobody ships it. Months later the model version in the notebook is deprecated, the engineer who built it has rotated to another team, and the deck still says “promising early results.”

That stall is almost never a model problem. Once you have a working prototype, the question stops being whether the model can do the task. The question becomes whether anyone wrote down the second set of criteria — the ones production grades against — and the answer is usually no.

A demo is graded by the person who built it

In a proof of concept, you choose the inputs. You also, without noticing, re-run the bad ones. You tweak the prompt, swap the example document, drop the record with the mangled encoding. Every one of those retries is invisible in the demo, which means the pass rate you’re reporting is the pass rate of you plus the model, not the model. Production ships without you sitting next to it.

The fix is boring and it is the whole game: freeze an evaluation set before you tune anything. Pull 30 to 50 real inputs from the actual system — real support tickets, real contracts, real search queries — and keep the ugly ones. The truncated PDF. The ticket written in a language your prompt doesn’t mention. The customer who pasted an entire 40-message email thread into the subject line. The empty field that your prototype never encountered because the export you tested on had already been cleaned.

Then score against that set without editing prompts between runs. You want one number you can defend, not a highlight reel.

The second missing number is the baseline. “The model gets it right most of the time” means nothing until you know what the current process gets right, how long it takes, and what a mistake costs today. Plenty of pilots stall precisely here — not because the results were bad, but because nobody could compare them to anything, so the decision had no shape and defaulted to “keep exploring.”

Production asks four questions a pilot never has to answer

A prototype’s worst failure mode is a disappointed stakeholder. A production system’s worst failure mode is a confidently wrong answer delivered to a customer, at volume, at 2am. Those are different risk profiles, and they generate four questions your pilot has probably never been asked.

Who owns it when it’s wrong? Not “who built it” — who is paged, who decides to roll back, whose quarterly goals suffer if accuracy drifts after a model update. Pilots often live with a data scientist or an interested engineer with no operational mandate. Nothing that lacks an on-call owner ships.

Where does the data actually come from, and who is allowed to see it? The prototype ran on a CSV export somebody pulled once. Production needs a live connection, plus the permission model attached to it, so a sales rep asking a question doesn’t get an answer synthesized from the HR folder. This step regularly consumes more calendar time than building the feature did, and it is almost never in the pilot’s budget.

What does it cost at real traffic? Take the per-run cost from your prototype and multiply by real volume, then by retries, then by the fact that real documents are longer than demo documents. Pilots run on a rounding error of spend. The production number is what finance will actually see, and discovering it late is a reliable way to get a project frozen rather than rejected.

What happens when you turn it off? If the feature degrades, is there a path back to the old workflow that doesn’t require a deploy and a meeting? Systems without a rollback path get shipped nervously, and nervous ships get postponed.

None of these are AI questions. They’re the questions any internal service answers before launch. The pilot was scoped as a research project, and then quietly asked to graduate into an operational one without the operational work ever being funded.

Change the shape of the pilot, not the model

If your last two pilots stalled, running a third with a better model will produce a better stall. Change the structure instead.

Narrow the slice until it fits in weeks. One document type. One queue. One team. One language. “Summarize any internal document” cannot be evaluated or shipped. “Draft the first response for refund requests under $50, for one support team” can be.

Put it in front of real users early, behind a flag, with a human in the loop. Real usage surfaces failure modes your eval set could not have imagined — the way people phrase things when they’re annoyed, the workflow step everyone skips, the field that’s technically required and always filled with “n/a”. A pilot that only ever runs on curated inputs learns nothing about production.

Log everything from day one. Input, output, model version, latency, cost, and whether the human accepted or edited the result. Acceptance-and-edit rates are the cheapest quality signal you will ever get, and they only exist if you instrument before launch. Retrofitting this after the fact means throwing away the only period of usage you had.

Give it one owner with production authority, and fund the unglamorous majority of the work — auth, permissions, retries, monitoring, the audit trail — as part of the pilot rather than as a phase two that never gets approved.

Keep the decision record in one place. The kill criteria, the eval set description, the baseline, the cost model, and the weekly numbers should live in a single document that the sponsor reads, not scattered across three Slack threads and a notebook.

The pattern behind every stalled pilot is the same: it was designed to answer “can the model do this?” when the decision actually hinged on “can we operate this, at this cost, with this owner, and how will we know if it’s working?” Answer the second set first, and the pilot either ships or dies on schedule. Both outcomes beat the extension loop.