Most AI pilots die between the notebook and the org chart. The demo is genuinely good — retrieval works, answers look right, the room is impressed. Then nothing ships. In our experience the gap between that demo and a production system is not one missing feature. It is six distinct kinds of work, and most of them are not model work at all.
1. Permissions are enforced at query time, or you don’t ship
The demo searched a folder someone exported. The production system searches contracts, tickets, wikis and drawings — which means it must enforce the permission model of every source system, at query time, for the person asking. Not as a filter bolted on afterwards: as part of retrieval itself. This is usually the single largest engineering effort in the whole project, and it is the reason a demo built in a week takes months to make real.
2. Evals before features
If you can’t measure whether it works, you can’t ship it — and you definitely can’t change it later. So the evaluation harness comes first: golden datasets adjudicated by the people who own the domain, regression evals wired into CI, pass thresholds that gate every release. It is often the first thing we build in an AI engagement, and it is the reason everything built afterwards survives.
3. Hallucination is measured, not hoped away
In a demo, a wrong answer is a shrug. In production it is a liability with your logo on it. The mechanics are unglamorous: citations mandatory on every answer, citation coverage tracked as a release metric, and abstention preferred over confident invention. If the system cannot show its sources, it does not get to speak.
4. Humans gate consequence
Wherever an action moves money, data or risk, a person approves it. That is not a limitation to engineer away later — it is the design. Agent autonomy is earned per workflow, with evidence from the eval suite, not granted per project. Auditors ask exactly one question about your automation: who approved this action? The system has to have an answer per action, not per quarter.
5. Drift, cost and latency get budgets
Models change under you — providers update them, your data shifts, prompts rot. Production AI treats quality drift the way SRE treats uptime: monitored continuously against the golden set, with alerts when it moves. Cost and latency get the same treatment. A budget in CI beats a surprised invoice, and “the model got slower and worse last Tuesday” should be a page, not a rumour from sales.
6. The org chart is part of the system
The last mile is people. Copilots that live in a new tab die in that tab — assistants have to be wired into the tools where work already happens, and adoption has to be instrumented from day one, because a system nobody uses fails silently. And accountability cannot be automated: in our own delivery loop, AI handles the mechanical work under senior architecture, and an engineer still signs every merge. The same bar for machine-written code as for ours.
Boring infrastructure wins
None of the six is a model problem. They are permissions, queues, retries, tests, monitoring and adoption — the plumbing AI systems actually fail at. Build that layer first and the demo ages well. It is the least glamorous possible answer to “why did your pilot succeed”, and it is the honest one.
This is the discipline behind our Applied AI & Automation practice — evals before features, humans gating consequence, model-agnostic and data-jealous. If you have a pilot stuck between the notebook and the org chart, bring it to us: an hour with a tech lead, on your architecture, not a sales call.