Why AI pilots fail (and what production actually requires)

Published 18 August 2026 · Relayworks AI

AI pilots fail because a demo and a production system are different products. A demo has to work once, for a friendly user, on a chosen example. A production system has to work continuously, for hostile inputs, at a known cost, with someone accountable when it doesn't. Five specific gaps account for most failures — and all five are solvable before you start.

The pattern is consistent enough to be predictable. Someone builds a prototype in a week. It is genuinely impressive. A budget appears. Then six months later the project has quietly stopped being mentioned in leadership updates, and nobody can point to the moment it died.

It did not die from one dramatic failure. It died from five ordinary ones.

Gap 1: nobody can prove it works

The prototype was judged by watching it. Someone typed a few inputs, the outputs looked good, everyone agreed it was impressive. That is not a quality measurement — it is an anecdote, and it does not survive contact with a stakeholder who asks "how accurate is it?"

Without a labelled test set you cannot answer that question, which means you cannot get sign-off, which means the system never leaves the pilot. Worse, you cannot tell whether a change made things better or worse, so iteration becomes guesswork.

The fix is unglamorous and cheap: before building, collect 100–300 real cases with known correct outcomes. Score against them. Agree the pass threshold with the business owner in advance, so launch is a measurement rather than a negotiation.

Gap 2: it has no defined failure behaviour

Demos are shown on inputs that work. Production is mostly inputs that don't: the ambiguous request, the customer who asks two things at once, the record that is stale, the API that times out, the question the system has no business answering.

A prototype's answer to all of these is to generate something anyway. A production system needs an explicit answer for each, and the most valuable behaviour you can build is the ability to stop.

Gap 3: it was never integrated, only demonstrated

Prototypes read from a spreadsheet or a copied sample. Production reads from the system of record — which has authentication, rate limits, pagination, stale caches, inconsistent identifiers and a change-management process.

This is where timelines quietly double, and it is almost always underestimated because integration work is invisible in a demo. In our experience the model layer is rarely the hard part of an AI project. Getting reliable, permissioned, auditable access to the data is.

Gap 4: the cost was never modelled

A prototype processes fifty examples. Nobody looks at the bill. Then somebody multiplies by monthly volume and the project stops.

The failure here is not that AI is expensive — it usually isn't, relative to the labour it replaces. The failure is that the cost was never designed. Most systems we inherit send every step to a large model, including steps that are entirely deterministic: looking up a record, formatting a date, checking whether a field is empty.

Routing the deterministic 60% of steps away from the model routinely cuts inference cost by half or more, and makes the system faster at the same time. That is a design decision, and it has to be made early.

Gap 5: nobody owns it

The prototype belonged to whoever built it — often an enthusiastic individual or an agency that has since moved on. Production systems need a named owner, a runbook, an on-call path, and a budget line.

This matters more for AI than for conventional software, because AI systems degrade in ways ordinary services do not. The model gets deprecated. A provider changes a default. Your data drifts. Users find inputs nobody anticipated. Without continuous evaluation, quality erodes silently and the first person to notice is a customer.

What production actually requires

None of this is exotic. It is ordinary engineering discipline applied to a technology that is unusually good at appearing to work. That appearance is precisely the risk: conventional software fails loudly, while an AI system that has quietly become 20% less accurate looks exactly like one that has not.

The honest version of the advice

If you are choosing between an impressive prototype delivered in three weeks and a narrower system delivered in ten with evaluation, guardrails and observability, choose the second. The first is a demonstration you will pay for twice.

And sometimes the right answer is not to build at all. Roughly one process in four that we assess turns out to be better solved by a rules engine, a database index or a change to the process itself. Finding that out in a two-week diagnostic is a good outcome, not a failed one.

This is the gap our four-phase method exists to close, and it is why every build we ship includes an evaluation suite and an operating plan rather than treating them as extras.

Last updated 18 August 2026. If something here is out of date or wrong, tell us — we will fix it and credit you.