The Enterprise AI Playbook: From Pilot Purgatory to Production
Most enterprise AI initiatives die in the demo. The bottleneck is rarely the model. It is the absence of an operating model for evaluation, ownership and governance. Here is the one we use.
Almost every organisation we meet has run an AI pilot. Far fewer have one running in production with real users depending on it. The gap between those two states is where most AI budgets quietly go to die, and it is worth being precise about why.
The failure is almost never the model. Foundation models are extraordinarily capable and getting cheaper by the quarter. What is missing is everything around the model: a definition of what good means, a way to measure it that survives contact with real inputs, someone accountable for the outcome, and a path to production that does not require a leap of faith.
Why pilots stall
A demo is optimised for a room. Production is optimised for the long tail. A pilot that answers twenty curated questions impressively tells you very little about the thousandth question a real user will ask at 4pm on a Friday.
Three patterns account for most of the stalls we see.
- No definition of done. The pilot's success criterion was "the demo went well". Nobody wrote down the accuracy, latency or cost the system must hit to be worth operating, so nobody can say whether it is ready.
- No owner. The pilot lived with an innovation team. Production requires a team that carries a pager, and that team was never consulted about whether they want this system.
- No path through risk. Legal, security and compliance were shown the result rather than involved in the design, so their first substantive review arrives when momentum is highest and changes are most expensive.
Build the evaluation harness first
The single highest-leverage thing you can do is to build the evaluation harness before you build the feature. Not after. Before. It changes what you build, because you cannot optimise for a target you have not defined.
A workable harness needs a dataset of real inputs with expected outcomes, a scoring method appropriate to the task, and enough automation that any engineer can run it against a change in minutes. The dataset matters more than the sophistication of the scoring.
Start with what you can grade cleanly
Some tasks grade themselves. Extraction, classification and routing have correct answers you can compare against. Start there, even if the more exciting use case is open-ended generation. A team that has shipped a graded extraction pipeline has built the muscles (data collection, regression testing, rollout) that the harder use case will need.
For open-ended output, a model-graded rubric works better than most people expect, provided you validate the grader against human judgement on a sample and keep that sample fresh. Treat the grader as a component that can itself regress.
If you cannot measure the system getting worse, you have no way to let it get better.
Design for the wrong answer
Every AI system produces wrong answers. The question that separates production systems from pilots is what happens next. A system that fails visibly and recoverably is far more valuable than one with higher raw accuracy that fails silently.
- Make confidence legible. Show the user what the system was working from: the retrieved passage, the source record, the reasoning. A user who can check the work can catch the error.
- Route the hard cases out. Define what the system declines to answer and where those go. A confident 92% with a clean escalation path beats an ambiguous 96%.
- Log everything, from day one. Inputs, outputs, retrieved context, model version, latency, user action. Your future evaluation set is being generated right now, and if you are not capturing it you are throwing it away.
Governance as a design input
Governance arrives eventually whether you invite it or not. Inviting it early is cheaper, and it is usually less obstructive than teams fear. Most legal and risk functions are asking reasonable questions about data residency, retention, auditability and human oversight. Those questions have architectural answers, and architectural answers are far cheaper to give before the architecture exists.
Write down which data classes may reach which models, how long prompts and completions are retained, who can see them, and what the human-in-the-loop step is for consequential decisions. That document is not bureaucracy. It is a design specification, and it will resolve a dozen arguments before they happen.
A staged path to production
The rollout that works is boring and incremental. Internal users before external. Suggestion before automation. Read-only before write. Each stage answers a question the previous stage could not, and each is reversible.
Shadow mode deserves particular mention: run the system against real traffic, capture what it would have done, and compare against what actually happened. It is the cheapest production-grade evaluation available, and it costs nothing but logging.
None of this is exotic. It is the same discipline good teams apply to any system that touches customers: clear success criteria, real measurement, accountable ownership, staged rollout. AI has not repealed that discipline. It has raised the cost of skipping it, because a system that is confidently wrong is more dangerous than one that is simply broken.