Why AI pilots do not reach production
The model is almost never the reason. Four things underneath it are, and they arrive in a predictable order.
The pilot worked, which is the problem
A pilot is a demonstration that a model can do a task. Production is a demonstration that a system can do it repeatedly, under load, against data nobody cleaned that morning, with a boundary around what it is allowed to touch.
Those are different claims, and the gap between them is not a matter of polish. It is four specific pieces of engineering that the pilot was allowed to skip and production is not.
Failure one — the data was never provisioned
The pilot ran on an extract someone built by hand. Somebody pulled a CSV, cleaned it, and the demo worked.
Production reads live data from six systems, three of them legacy, none of them contracted. There is no pipeline, no retrieval path, and — the expensive part — no owner for what a field means. The moment two systems disagree about a number, there is no one whose job it is to decide.
The tell: the pilot's data cannot be regenerated by anyone other than the person who made it.
Failure two — the infrastructure cannot hold it
Ten questions a day and ten thousand a day are different systems. Throughput, p99 latency, capacity, cost per request and failure behavior are properties you either budget before the build or discover after launch, on the customer.
The inference bill is the version of this that gets noticed first, because it arrives monthly and nobody owns it. The latency is the one that costs more.
The tell: nobody can tell you what the system is supposed to do when it exceeds its capacity, because no capacity was ever stated.
Failure three — security has no model for software that acts
Application security assumes a user behind every action. An agent breaks that assumption: it is a principal with credentials, a tool list, and an input channel an attacker can write to directly.
Most estates respond by handing it a service account and hoping. There is no authority model saying what it may reach and who approved that, no least privilege on tool access, and no answer for a prompt that is itself the attack.
The tell: the review stalls, and nobody can produce a document showing what the agent can actually reach.
Failure four — the legacy estate does not move
This is the one nobody sells against, and it decides whether the other three ever matter.
The system of record is a decade old, the business runs on it, and it cannot be paused. So the AI has to arrive beside it — reading it, writing back through a defined boundary, and failing safely against it. Every fix for failures one to three has to be true while that system keeps serving customers.
The tell: the plan has a cutover date and no rollback.
What the four have in common
None of them is a model problem, and none of them is fixed by a better model. They are seams between layers, and a team that works at one layer hands you the seam. The six-step path exists because each step closes one of them.
Send us the problem
Describe what is stuck. We will come back with an architecture, a timeline and the first commit.