Why most AI pilots stall before production

A pilot that works in a notebook and a system that works on a Tuesday afternoon are different engineering problems. The gap between them is where most internal AI projects stop. The pilot is not wrong, and the people who built it are not careless. The two things are simply built against different assumptions, and almost none of the assumptions that hold in a demo survive contact with production traffic.

What follows are the five places projects most reliably stall, and what to do instead.

The demo runs on curated inputs

Pilots are usually built against a handful of examples someone picked by hand. Those examples are clean, representative, and quietly filtered: the ambiguous cases never made it into the set. Nobody did this deliberately. When you are assembling test data, the record that takes twenty minutes to interpret is the one you skip, and the skipped records are exactly the ones that define production behaviour.

Production traffic is the opposite. It contains malformed records, edge cases nobody documented, and inputs that are technically valid but semantically strange. A field that is nominally a date arrives as a free-text string in four formats. A document that should be three pages is a hundred and forty, because someone attached the entire contract. An identifier that is unique in the specification turns out not to be.

The failure is not that the model gets worse. It is that the input distribution was never the one you tested against. This distinction matters because the two problems have different fixes. A weaker model is solved by a better model. A distribution mismatch is solved by looking at real traffic, and no amount of model upgrading substitutes for that.

Before automating a task, pull a sample of real inputs. Not a curated sample. Take a window of actual traffic and read it. The point is to find the shapes you did not know existed while the cost of finding them is still low.

Nobody owns the failure path

In a pilot, when the output is wrong, a person notices and tries again. That person is load-bearing infrastructure, and they do not scale. They are also invisible in every demo, because their intervention happens between the run and the screenshot.

Production needs an answer to what happens when the model returns something unusable. There are four options and you have to pick one for each failure mode: retry with modified input, fall back to a deterministic path, escalate to a human queue, or fail loudly and stop. Deciding this late is expensive, because the surrounding system was built assuming success.

The harder question is detection. Retrying is easy once you know the output is bad. Knowing requires a check that runs on every response: schema validation if the output is structured, a constraint on length or format, a rule that catches the specific ways this task fails. An unusable output that passes silently into a downstream system is substantially worse than a crash, because the crash gets attention and the bad record does not.

Escalation deserves particular scrutiny. A human review queue is a reasonable answer only if someone actually owns the queue and it has a defined maximum depth. An unowned queue is a way of deferring failure, not handling it.

Evaluation is an afterthought

Teams that ship tend to build the evaluation harness before the feature. Not a benchmark score, but a set of cases drawn from real traffic with known-correct outputs, run on every change.

Without it, you cannot tell whether a prompt edit helped. You change the wording, spot-check three outputs, and they look better. Whether they are better across the distribution is unknown, and whether the change broke a case that used to work is also unknown. Teams in this position stop editing prompts, because every change is a gamble against invisible regressions.

A workable evaluation set does not need to be large. Thirty to fifty cases covering the common paths and the known failure modes will catch most regressions. What matters is that the cases come from real traffic and that the expected outputs were verified by someone who understands the task. Synthetic cases test whether the system handles inputs you imagined, which is a weaker guarantee than it sounds.

Add every production failure to the set as it is found. This is the mechanism by which the harness becomes valuable over time: it accumulates precisely the cases that broke, so they cannot break the same way twice.

This is unglamorous work and it is the difference between a system you can modify and one you are afraid to touch.

The integration surface is larger than expected

The model call is a small part of the work. Authentication, rate limits, retries with backoff, cost controls, logging, and access to the systems the output has to touch account for most of the engineering.

Pilots skip all of it because a single developer running locally already has the permissions. Their credentials are in the environment, they are the only caller so rate limits never trigger, cost is invisible at demo volume, and if something fails they see the traceback. Every one of those becomes a work item when the system runs unattended.

Rate limits deserve early attention because they fail in a misleading way. Under demo load you never see them. Under production load you see them intermittently, which reads as flakiness rather than a limit, and the instinct is to add a retry. A retry without backoff makes it worse.

Cost is the other item that only appears at scale. A per-call cost that is negligible in testing becomes the line item somebody asks about. Track spend per run from the first day, because retrofitting cost attribution after the fact means correlating logs that were never designed to be correlated.

The task was never defined precisely

This one is upstream of the rest. A pilot can succeed against a vague brief because a human is interpreting the output and filling gaps. Production cannot, because there is no interpreter.

If two people on the team would grade the same output differently, the task is underspecified. That disagreement will surface eventually, usually as a dispute about whether the system is working. Resolve it early by writing down what a correct output looks like, including the cases where the honest answer is that the input does not permit one.

Tasks where the correct answer is genuinely contested are not good first candidates for automation, however appealing the demo looks.

What to do differently

Start from a narrow task that a specific person does repeatedly, and instrument it before you automate it. Watching how the task is actually performed usually reveals that the real work is not the step you planned to automate.

Build the evaluation set from real cases, including the ones that went wrong. Decide the failure path first, for each way the task can fail. Then write the prompt.

The order matters. A pilot built this way is slower to demo and considerably faster to ship, because the work that usually happens between demo and production has already been done.