The graveyard between POC and production

Every mid-size company we talk to has at least one AI proof of concept that impressed everyone and then went nowhere. The story is so common that the AI proof of concept to production gap has become its own budget line: money spent proving something "works", followed by silence. The uncomfortable explanation is that most POCs are designed, from day one, in a way that makes graduation impossible. They prove the demo, not the workflow.

A demo answers the question "can the model do this on inputs we chose". Production answers a different question: "does this hold up on every input, integrated into how people actually work, at a cost we can carry, with someone accountable when it is wrong". You can pass the first while having gathered no evidence at all about the second. That is the graveyard.

What production requires that the POC skipped

Five things, almost always the same five.

Error handling. In the demo, the happy path is the only path. In production, the scanned document is rotated, the API times out, the question is in Portuguese, the input is a forwarded email chain with the actual request buried at the bottom. A production system needs defined behavior for every one of these: retry, degrade, refuse, or escalate to a human. Deciding what the system does when it cannot do its job is half the engineering.

Evals. The POC was validated by people looking at outputs and nodding. That stops working at the second prompt change, when nobody can say whether the system got better or worse. Production needs an evaluation set, real inputs with known good answers, run on every change. This is the single sharpest predictor we know of whether a team will make it to production; we wrote up the practice in evals, the unglamorous work that separates systems from demos.

Monitoring. The demo ran while everyone watched. Production fails at scale, quietly, on Saturday. You need tracing, cost per request, and quality signals with alerting, or your users become the monitoring, which they do exactly once before abandoning the tool. The full production picture is in you cannot run an AI system you cannot see.

Permissions. The POC ran on an exported folder of documents with nobody asking who may see what. Production must respect access rights, which regularly reshapes the architecture, and occasionally kills the design outright. Finding that out after the POC is the expensive order.

Cost control. The POC cost 40 euros of API calls, so nobody looked. At production volume the naive design can be a six-figure annual bill. Unit cost has to be engineered, with model routing and caching, and it is much cheaper to design in than to retrofit.

The POC was still not useless

The failed POC did prove something: the model can do the core task. That is real information, and in 2026 it is also cheap information, because model capability is rarely the open question anymore. Which is exactly why the POC should stop being scoped as a capability test and start being scoped as the first slice of a production system. The question worth 30,000 euros is not "can AI read our contracts", it is "does this system, on our real contract flow, produce answers our team accepts, at a cost that works". If your team treats the POC as a throwaway, expect to pay twice: once for the demo, once for the real build.

How to scope a POC that can graduate

Four rules, all cheap to apply and all of them decided before any code is written.

Run it on live data, not an export. The mess is the point. Wire it into the real workflow for at least a small group, even crudely, because workflow friction kills more AI systems than model quality does. Define the graduation metric and the kill condition up front, in numbers, so week four is a decision, not a debate. And build the skeleton production-shaped from day one: logging, a basic eval set, error paths sketched rather than skipped. This costs perhaps 20 percent more than the throwaway version and converts the POC from a demo into evidence. The discipline is the same one we apply when scoping any AI project, and skipping it is a leading cause of the failure statistics we dissected in why most AI projects die.

The teams that cross the graveyard do not walk through it. They route around it, by never building the version that cannot ship. That is how we structure our custom AI work: the 2 to 4 week prototype on your real data is the first slice of the production system, so graduating is a decision about value, not a second project.