Between a working proof of concept and a production system, the model barely changes. What changes is everything around it: exception handling, a human review step, a test set with an acceptance bar, monitoring, access control and logging, a fallback path, a named owner with time, and a support arrangement with a known cost. That ring is the work, and it is where the budget goes.
Teams are consistently surprised by this, because a PoC answers a different question than production does. A PoC asks whether the model can produce the right answer. Production asks whether the surrounding system can handle the wrong one safely, at volume, on a Tuesday, when the person who built it is on holiday.
The gap is now the defining problem in enterprise AI. Deloitte surveyed more than three thousand leaders across twenty-four countries for its 2026 State of AI in the Enterprise report and found that twenty-three percent use agentic AI at least moderately today while seventy-four percent expect to within two years, yet only twenty-one percent have a mature governance model for those agents. The ambition is running well ahead of the operating capability, and the space between the two is exactly what this article covers.
Why does a proof of concept not become production by itself?
Because the two are optimised for opposite things. A PoC is built to answer a question quickly, so it runs on sample data, gets invoked by hand, lives in a demo environment and depends on the person who made it. Every one of those shortcuts is correct at the time and every one of them has to be removed before anything real depends on the output.
That gap is where most projects end. RAND interviewed sixty-five experienced data scientists and engineers for its study on the root causes of failure for AI projects and found that more than eighty percent fail, roughly twice the rate of comparable IT projects, with deployment infrastructure treated as an afterthought among the main causes. Gartner expects more than forty percent of agentic AI projects to be cancelled by the end of 2027, naming escalating costs first. Both point at the same place: the ring around the model.
The second reason is that the exceptions were not in the sample. A PoC is usually tested on the cases somebody could easily assemble, which skews towards the ordinary ones. Production traffic contains the document with two invoices in one PDF, the order that arrived without a reference number, the record where a field that is always filled is empty. In our own document processing work the pattern is consistent: the straightforward path is quick to build, and the last stretch of accuracy comes entirely from handling the awkward cases.
A recent example from our own practice makes the shape of it concrete. On a purchase invoice automation project we benchmarked a full year of invoices, roughly seven thousand of them, and reached eighty-eight percent straight-through processing, with the invoices that carried no annotation booked to the right ledger account against booking history in ninety-three and a half percent of cases. Those are good numbers, and the system was still not in production, because at that point nothing had been written back into the financial system. Accuracy was never the constraint. The write-back, the review step and the permissions were.
What actually gets added in production?
Eight things, and none of them is the model.
- Exception handling comes first because it is the largest. Decide what happens when confidence is low, when a required field is missing, when an upstream system is unavailable. In most business processes this logic is bigger than the AI component, and it is what separates a system people trust from one they check behind.
- A human review step needs a place and a person, not a principle. Where in the flow does the human see the output, what can they change, and what happens to their correction? A correction that disappears is a missed opportunity, because the same corrections repeated are the cheapest training data you will ever get.
- A test set with an acceptance bar turns “it seems to work” into a number you can defend. Assemble real cases with known correct answers, including the hard ones, and state the threshold before you measure rather than after.
- Monitoring and alerting answers a question nobody asks until it matters: how would you know if this stopped working? Silent failure is the characteristic failure mode of AI systems, because they keep producing confident output after the input has changed underneath them.
- Access control and logging covers which accounts the system uses, what it may read and write, and what record exists of what it did. This is also where regulatory obligations land, so it is worth aligning with the risk class established during preparation rather than retrofitting.
- A fallback path is the manual route people take when the system is down. If nobody has defined it, the fallback is improvisation, and improvisation during an incident is how data gets lost.
- An owner with time allocated is the condition most often assumed rather than arranged. Somebody has to decide about changes, exceptions and priorities after go-live, and if that is nobody’s job it becomes the developer’s, which is how teams end up unable to start anything new.
- A support arrangement with a known cost makes the running commitment explicit. What is covered, what response time applies, and what it costs per month. Without it, maintenance gets done informally until it quietly stops being done at all.
How do you know when you are actually finished?
When the process being replaced can be switched off. That bar is deliberately harder than “the system works”, and it is the only one that prevents the outcome where a new system runs alongside the old way indefinitely, costing more than either option on its own.
It also makes prioritisation straightforward, because it converts a feature wishlist into four ordered buckets. On the invoice project above we sorted the client’s requested features exactly that way: what already worked, what was needed in this phase, what could wait a quarter, and what we recommended against building at all. Of the features in the current phase, we marked which ones specifically blocked switching off the legacy tool, and those became the definition of finished. The three we advised against, including splitting multiple invoices out of a single PDF, were genuine requests that would have cost more than the manual handling they replaced.
That last category matters more than it sounds. Saying no to a feature the client asked for is uncomfortable, and it is often the difference between reaching production this quarter and reaching it next year.
What does it cost to keep running?
Three components, and organisations tend to misjudge two of them in opposite directions.
- Cloud and model consumption is routinely overestimated. On one recent project the client had budgeted roughly two hundred euros a month for the infrastructure and our engineer estimated about sixty, because the workload was event-driven rather than continuously running. That difference is architectural rather than negotiable: a workflow triggered by incoming documents costs a fraction of a service that polls all day. It is worth checking this assumption early, because inflated running-cost estimates have killed business cases that were actually sound.
- Maintenance hours are routinely underestimated. Changes arrive because the world changes: a supplier alters a document layout, a system gets upgraded, a rule changes. A reasonable planning figure is a modest number of hours a month at a normal engineering rate, and the honest version of that conversation happens before go-live rather than at the first invoice.
- Coordination is the part nobody budgets. As a rule of thumb we allow around ten percent of development effort for project management, and something similar applies after launch for the smaller matter of who decides what when an exception pattern shows up.
What rhythm gets a build across the line?
Short cycles with the people who will use the system, rather than milestone reviews with the people who approved it.
The pattern that works for us is a weekly demo throughout the build. On a customer-facing assistant we delivered last year, the shape was a forty-hour proof of concept followed by ten weekly sprint demos, after which the assistant went live in production on WhatsApp Business. Ten demos sounds like a lot of meetings and it is considerably cheaper than the alternative, which is discovering in week nine that the tone of voice is wrong or that a whole category of question was out of scope.
Weekly also changes who attends. A monthly steering review attracts managers, while a weekly demo attracts the people who do the work, and they are the ones who spot that the output is technically correct but arrives in the wrong place in their day.
What should the handover cover?
More than most contracts specify, which is why it is worth agreeing explicitly rather than assuming.
Source code, prompts and documentation are the obvious components, and a short review before transfer is sensible so that what arrives is usable rather than merely complete. Beyond that, three things need a decision. Whether repository history and logs transfer, which is often outside standard scope and comes as a surprise if nobody asked. Where the system will run afterwards, since a solution handed over as source code moves onto the client’s own infrastructure and any hosting arrangement becomes a separate question. And who holds the credentials, because an application nobody can authenticate into is not really handed over.
The test for a complete handover is simple: could a competent engineer who has never seen this system deploy it, run it and fix a common failure using only what you provided? If the honest answer needs a phone call to the original developer, the handover is not finished.
The shortest useful summary
A proof of concept answers whether something is possible, and that question is usually settled within a few weeks. Everything after that is about making the answer dependable enough that a business process can lean on it, which is ordinary engineering work rather than AI work, and which is where the majority of the effort and nearly all of the surprises live.
Budget accordingly. Treating the PoC as most of the project is the single most reliable way to end up in the group that never ships.
Frequently asked questions (FAQ) about moving AI into production
Why do AI proofs of concept fail to reach production?
Because a PoC proves the model can produce the right answer, while production requires the surrounding system to handle wrong answers safely. Exception handling, monitoring, access control and ownership are usually deferred during the PoC and then discovered as a second project nobody budgeted for.
How long does it take to move an AI PoC into production?
For a scoped single-process use case, plan on eight to twelve weeks of iteration after the PoC. A useful rhythm is a weekly demo with the people who will actually use it, so scope and acceptance criteria get corrected while changes are still cheap.
What does it cost to run an AI system after go-live?
Budget three parts: cloud and model consumption, which is often tens of euros a month for an event-driven workflow rather than hundreds; maintenance hours for changes and incidents; and roughly ten percent of the original development effort for coordination. The first is usually overestimated and the second underestimated.
When is an AI system genuinely in production?
When the process it replaces can be switched off. That is a harder bar than “it works”, and it is the only one that prevents a system running in parallel with the old way indefinitely, which costs more than either option on its own.
What should be handed over when a build finishes?
Source code, prompts and documentation, plus a description of how to run and monitor the system. Agree explicitly whether repository history, logs and hosting transfer as well, because those are often outside the standard scope and the assumption gap surfaces at the worst moment.
