Most AI automation projects do not fail because the model is weak. They fail because the demonstration was built in conditions that do not exist in the operation: a small set of tidy inputs, one route through the process, and an engineer watching every output.
The inputs change shape
A document workflow that handles ten sample invoices meets scanned pages, mixed languages, two-page attachments in the wrong order and a supplier who changed their layout last quarter. The correct response is not a better prompt. It is a preprocessing path, an explicit list of accepted formats, and a defined behaviour for everything else.
There is no defined behaviour for uncertainty
A demonstration answers every question. A production system must be able to decline. Before a workflow goes live, someone has to decide what happens when confidence is low, and that decision has to be visible in the interface, not buried in a log file.
- What confidence threshold routes a case to a person
- Who that person is, and how quickly they are expected to respond
- What the system does while it waits
- How a reviewer's correction feeds back into the process
Nobody owns the output
When an automated step produces a wrong result, the question is not whether the model was at fault. It is who noticed, who corrected it, and whether the correction changed anything. Automation that nobody owns quietly accumulates errors until a person stops trusting it and rebuilds the manual process alongside it.
Integration was left until the end
The demonstration read from a spreadsheet export. The production version needs credentials, rate limits, permissions, a retry strategy and a plan for the record that already exists in the CRM. Teams that treat integration as the last phase discover the real constraints after the budget has been committed.
What to do differently
Run the first version against real inputs from the first week, even if it only handles a slice of them. Write down the uncertainty behaviour before writing the automation. Name an owner. Connect one real system early, so the awkward parts arrive while there is still room to respond to them. A narrower workflow that runs unattended is worth more than a broad one that needs supervision.
What to build before the demo, not after
Most of the gap between a demonstration and a working system is not model quality. It is the surrounding machinery that a demo does not need and production cannot run without.
- A held-out set of real inputs, including the ugly ones, scored before launch and again after every change
- An explicit confidence threshold, below which the item routes to a person instead of proceeding
- A queue where those routed items land, owned by a named team with a response time
- Logging that records the input, the output and the version of the prompt or rules that produced it
- A documented way to turn the workflow off without a deployment
None of this is exotic, and all of it is invisible in a demonstration — which is precisely why the estimate made after a successful demo is usually wrong by a factor rather than a margin.
The failure nobody plans for
The most common way these systems die is not a dramatic error. It is quiet drift: the output stays plausible while slowly becoming wrong, nobody is watching closely because the early weeks went well, and by the time someone notices there are three months of decisions to unpick.
Guard against it the same way you would guard against any silent failure. Sample a fixed number of outputs each week and have a person score them against the original criteria. Watch the rate of items falling below the confidence threshold, because a rise in that rate is usually the first sign the inputs have changed shape. Keep the scores somewhere the operations team can see, not only the engineering team — they are the ones who will notice the pattern first.