GenAI pilots rarely fail because of the model. They fail because nobody owns the outcome and because there is no measurable criterion for promoting them to production. The way out is to treat production as a gated decision: an accountable owner, a success criterion agreed before building, and an evaluation that is allowed to block the deployment.
As long as approval depends on a demo that impresses the room, the pilot stays trapped between enthusiasm and risk.
What is a GenAI pilot?
A GenAI pilot is a system built on a language model to prove, within a narrow scope and with limited users or data, that a specific use case delivers value before anyone invests in taking it to production. A pilot is not a product. It does not have to scale, it does not have to be cheap to run and it does not have to survive hostile input. That is exactly why moving from pilot to production is not just the next step on the same road: it is a change in kind. What was acceptable in the pilot (a slow answer, a broad permission, an edge case left uncovered) becomes an incident in production.
The trouble starts when nobody makes that change explicit. The pilot works in the meeting, the team celebrates, and the conversation jumps straight to “when do we launch?” without anybody having defined what would have to be true in order to launch. That is where pilot purgatory begins: the system exists, but no decision pushes it forward and no decision stops it.
Why does a pilot that works in the demo never get deployed?
The causes I have actually run into are four, and none of them has anything to do with picking the wrong model. They reinforce each other: a pilot rarely stalls for a single reason, and the first problem usually hides the rest.
What happens when there is no success criterion and no evals?
The first cause is that the pilot gets approved on the strength of demos. Somebody prepares a session with questions the system handles well, the audience walks away convinced, and that impression becomes the only argument for moving forward. The problem is that a demo measures the best case, not how the system behaves across the real range of inputs it is going to receive. Without a success criterion written down before building, nobody can say whether the pilot is ready, nearly ready or nowhere close.
Evals are the technical answer to that gap: a set of representative cases, including the hard and the adversarial ones, with a reproducible way of scoring each answer. When they exist, the question stops being “did we like it?” and becomes “does it clear the threshold we agreed on?”.
Why is the data almost never ready?
The second cause is data. The pilot runs on a clean extract, sometimes prepared by hand, with broad permissions so that nothing slows the work down. In production, the system has to read from the real systems, with their real quality, their gaps and their inconsistencies. Questions the pilot could sidestep suddenly matter: who is allowed to see what, which personal data reaches the model, how privacy is respected, which systems actually expose the information the use case needs, and how quickly they answer.
None of these questions is exotic, but all of them take time and involve people who were not in the demo. Discovered after approval, they leave the pilot waiting for another team to prioritize work that nobody asked them for in time.
Why do security and compliance arrive too late?
The third cause is that security and compliance come in at the end, when the system is already built, and their review stalls the deployment. This is especially common in regulated industries, where a mistake is not an inconvenience but exposed personal data, an out-of-scope recommendation, or a decision somebody must be able to audit. The reviewers are not being obstructive. They are asking legitimate questions the pilot never had to answer. What happens if somebody tries to extract the system instructions? Is every decision logged with its source? Can the agent see data the user is not allowed to see?
If those questions arrive after the design is closed, the honest answer is usually “part of this has to be rebuilt”. And that rebuild, without an owner pushing for it, is precisely where pilots stall.
What is a demo architecture, and why does it not scale?
The fourth cause is a demo architecture: a system designed to show that something is possible, not to be operated. During the pilot nobody looked at cost per interaction, latency under load, observability or day-to-day operation. At real volume, cost climbs, answers take longer than users will tolerate, and when something breaks nobody can tell why, because there are no traces to reconstruct what the system retrieved, what it decided and what it said.
A production architecture is not more complex by principle: it treats cost, latency and observability as requirements measured from the start, with explicit budgets.
What is the clearest sign that a pilot will not reach production?
The clearest sign is that nobody owns the outcome. I do not mean whoever built the pilot or whoever sponsored it in the approval meeting. I mean a business owner who will operate and measure the system after the pilot. That person has a real reason to demand a success criterion, to get the data ready, to bring security into the conversation early and to ask what each interaction will cost at scale.
Without that owner, the four causes above have nobody to resolve them. The technical team can build evals, but it cannot decide which threshold is acceptable for the business. It can propose a production architecture, but it cannot approve the operating budget. It can document the risks, but it cannot accept them on anybody’s behalf. So when a pilot is not moving, the most useful first question is not a technical question: it is who will answer for this system once the pilot is over. If the answer is silence, the pilot already has its diagnosis.
How do you take a GenAI pilot to production?
My method has four parts, and each of them tackles a cause at the beginning instead of discovering it at the end. It is how a POC-to-Production Sprint with a measurable success criterion works: tightly scoped, with an explicit promotion decision at the end.
The first part is to narrow the scope and set a measurable success criterion before building. Which cases the system covers, which ones are out, what the evaluation has to measure and which threshold turns a pilot into something that can be promoted. That agreement is made with the owner of the outcome, in writing, and it is what later makes it possible to say yes or no without a battle of opinions.
The second part is an evaluation harness that acts as a promotion gate, with a verdict that can block the deployment. If the verdict is not green, the change is not promoted. That forces the evaluation to be reproducible, to cover adversarial cases and not just the comfortable ones, and to be read per category, because a high average can hide a serious failure in a single dimension.
The third part is guardrails, governance, access control and traceability from the first day, in proportion to the risk of the use case. The agent should only see what the user is allowed to see; it should refuse what falls outside its scope and escalate what needs escalating; every decision should leave a record with its source. Designed in from the start, the security review stops being a wall at the end and becomes a conversation that runs alongside the build.
The fourth part is cost and latency budgets, backed by observability, as an exit criterion. Answering well is not enough: the system has to answer well within an agreed time and cost per interaction, and it has to be possible to see what it is doing in production. If a change improves quality but breaks the budget, the gate stops it just as it would stop a change that broke quality.
What happens when the gate says no?
The case I can show with numbers, because it is documented in public, is the AI agent for regulated industries and its adversarial harness. It is a conversational agent grounded in verified sources, built independently, that goes through an evaluation harness before every promotion to production.
The harness, the automated test battery that decides whether a change can ship, combines 8 scorers: 5 deterministic ones, fixed rules that run without a model, and 3 that use a model as a judge for what a rule cannot decide. In the pinned run of 2026-07-28, 231 of 319 scored entries pass; the other 88 are flagged with gate reasons, mostly missing citations. On top of that, the cost and latency gate failed: mean corpus latency was 8088 ms against a per-turn budget of 8000 ms. It is a single run and the budget is set on the mean, with no p95; repeating the run and measuring p95 is the next step. The overall verdict is FAIL on both counts, and the change measured in that run is not promoted: the live system stays on its last approved version.
It is not a minor detail: it is the method working. A system whose answers are convincing, but which leaves claims uncited and overruns its latency budget, is not ready for production by the criterion that was set, and the gate says so without hedging. A well-designed gate does not let a good demo make up for the number. Exceptions are not negotiated in a meeting: they are accepted in writing. In this agent, the harness caught over-escalation on negated phrases, and the decision to accept it was recorded in public decision records.
That is the difference between a gated pilot and a pilot approved by demo. With approval by demo, that change could have reached production because its answers are convincing, and the missing citations and the latency would surface in front of real users. With a gate, they surface while they are still cheap to fix.
A gate that never says no is not a gate. A red verdict, published and with concrete causes, is the best proof that the production decision is being made by the criterion and not by enthusiasm.
What should you answer before the next pilot, or if yours is already stuck?
The same questions work before writing a line of code and for diagnosing a pilot that has stopped moving:
- Who owns the outcome, and will they operate the system afterwards?
- What measurable criterion makes it promotable, and which cases will it be evaluated against?
- What data does it need, who is allowed to see it, and what state is it in?
- Which security and compliance review does it have to pass, and who runs it?
- What is the cost and latency budget per interaction, and how is it observed in production?
If the pilot is already stuck, the order of work follows a POC-to-Production Sprint that finds the real blocker: first, diagnose which of the causes is holding it back; then agree in writing with the outcome owner what “production-ready” means and how it is measured; and finally, put a gate in front of the promotion.
Production is not the prize for a demo that impresses. It is a gated decision, made by somebody who owns the outcome, against a criterion agreed before anything was built. When that exists, the model is almost never the problem.