Guide · AI
From pilot to production.
The technology was never the hard part. Adoption is. Most enterprise AI pilots impress in the room, then quietly die. Here is why, and the operator's path to getting them live.
This guide, in 5 parts
The gap is adoption, not intelligence.
The model gets the attention. The workflow gets none. That is the whole story behind the numbers above: the few AI initiatives that scale and the many that quietly die are separated not by the cleverness of the model, but by operational design, the courage to rewire how work flows, and governance that lets a pilot graduate. Close that gap and the same tools that fail for everyone else start to compound.
« The technology was never the hard part. The workflow was. »
Why pilots die.
The model got the attention, the workflow got none
A pilot bolted onto an unchanged process has nowhere to create value. The interesting part is the model; the part that matters is the work it has to do.
No operational owner
A demo belongs to whoever built it. Production belongs to whoever runs it. If nobody owns the running, nobody moves it past the demo.
It was never wired to the real systems and data
Sandbox data and a clean prompt are not production. The pilot has to touch the systems that actually hold the work, with their mess and their edge cases.
No governance, so it cannot pass review
Without controls, traceability and an audit trail, a system cannot pass internal review, the auditor, or the regulator. It stalls at the gate.
It was treated as a project, not an operating change
Ship-it-and-move-on thinking ends at the demo. Production is a way of working, monitored and maintained, not a box ticked once.
The path to production.
Five moves, in order. None of them is the model.
Start from a measurable problem, not a model
Pick a use case with a number on it: a cost, a delay, a defect rate, a backlog. Fix the success criterion before any code, the threshold at which this is worth keeping, and write it down. If you cannot measure it, you cannot graduate it, and you will end up arguing about impressions instead of results.
Wire it to your real systems and data
Connect the model and the agents to the systems and data that actually hold the work, not a clean sandbox. Production is where the mess lives: the edge cases, the legacy fields, the records that contradict each other. A pilot that only works on tidy demo data has not been tested, it has been rehearsed.
Build governance in from the first workflow
Controls, traceability, a named owner and an audit trail, designed in from the start rather than bolted on after a review fails. In a regulated or simply cautious organisation, this is what lets a system pass internal review, the auditor and the regulator. Governance added late is governance that delays the launch.
Ship in stages, with monitoring and a fallback
Roll out in stages, with supervision, guardrails on the model's output, and a clear plan for when it is wrong. Confidence does not come from a model that never fails; it comes from being able to catch the failure before it reaches a customer. Keep the human in the loop until the numbers earn the autonomy.
Transfer it to the team, so it runs without you
A capability that leaves with the consultant was never installed. Hand over the runbook, the alerts, the ownership and the judgement calls, so the team can run it, fix it and extend it. The goal is not a system that depends on us, it is one that no longer needs us.
The production-ready checklist.
A pilot is ready to graduate when it can tick all six. Until then, it is a demo.
- A measurable problem, with a success criterion fixed before any code.
- Wired to the systems and data that hold the real work, not a sandbox.
- A named operational owner who runs it day to day.
- Governance, traceability and an audit trail, built in from the first workflow.
- A staged rollout, with monitoring and a fallback for when it is wrong.
- A runbook handed to the team, so it runs without you.
Frequently asked.
Our pilot impressed everyone, then died. Can it be saved?
Usually, yes. A pilot that wowed the room and then stalled almost always has a fixable problem: it was never wired to the systems that hold the work, it had no operational owner, or it could not pass governance. We pick it up where it stalled, set the real conditions for production, and take it the rest of the way, rather than starting over.
Should we start with AI?
Almost never. AI gives its best results on a process that is already clean and data that is already structured. Starting with AI usually means paying for a demo that never reaches production. Fix the workflow and the data first, then add AI on one or two cases where the return is measurable.
How do we keep it governed as it scales?
Governance is built in from the first workflow, not bolted on afterward. Controls, accountability and an audit trail let a system pass review and run in production, designed to whatever regulation applies. In conservative, regulated markets that is often what turns a stalled pilot into a deployment leadership will sign off.
You can run much of this yourself. Bring us in when a pilot refuses to reach production, when the basics are in place but the result does not follow, or when you want to move fast without hiring. We build and we stay until it holds. See AI in production.
Have a pilot that stalled?
No deck, no gate. A working session on the real system, with the operators who would get it live.