Almost every organisation we meet has run an AI pilot. Far fewer have one in daily use. The pilot impressed people in a meeting, a few enthusiasts tried it for a month, and then it quietly stopped. The model was rarely the problem. What was missing was everything around it: an owner, a way to measure quality, a connection to real systems and a plan for the people who were meant to use it.
This article sets out how we take AI work from a promising pilot to a system that runs every day. It draws on our delivery work, including an enterprise assistant now used by more than 2,000 staff. It is ordinary delivery discipline, applied to a technology that is easy to demonstrate and harder to trust.
Why most pilots stall
- No owner. The pilot belonged to an innovation team or a supplier. Nobody in the business was accountable for the outcome once the demo was over.
- No evaluation. There was no agreed way to tell whether the answers were right, so every discussion about quality became a matter of opinion.
- No integration. It lived in a separate tab, on a copy of the data, outside the tools and permissions people actually use.
- No change management. People were shown the tool once and expected to change how they work. Most did not.
When we review a pilot that did not make it, the reasons are almost always the same four. None of them is fixed by a better model.
Define success before you build
Before any build starts, we agree three things in writing with the business owner. First, the task: which decision or piece of work the system supports, and for whom. Second, the measure: the one or two numbers that should move, such as time to answer a customer query, the share of requests resolved without escalation, or hours spent on a weekly report. Third, the threshold: how good the system must be before real users see it, and what level of error is acceptable for this task.
A drafting assistant that saves time on first drafts can tolerate an occasional weak answer, because a person always reviews it. A system that answers policy questions for staff cannot invent a rule.
We also name the owner at this stage. One person in the business owns the outcome, signs off releases and decides when the system is ready. Without that person, a pilot has no route into production.
If you cannot say how you will know the system got worse, you are not ready to change it.
Evaluation sets and quality gates
The single most useful thing a team can build is an evaluation set: a collection of real questions or tasks, drawn from the people who will use the system, each with a known good answer or a clear description of what a good answer contains. We usually start with a hundred or so cases and grow the set as new failure modes appear. It should include the awkward cases: ambiguous requests, out-of-scope questions, documents that contradict each other, and requests the system should refuse.
The evaluation set turns quality into something measurable. Every change, whether a new prompt, a new data source or a new model version, is run against it before release. If accuracy drops, the change does not ship. That is a quality gate.
Scoring can combine automated checks with human review. Automated checks are good at format, citations and whether the answer used the right source. People are still better at judging tone, usefulness and subtle errors. A short weekly review of real conversations with subject experts keeps the set honest.
Integration, permissions and data
A pilot built on a clean export of documents will behave differently on the real thing. Production systems have duplicates, outdated versions, scanned files and gaps. We build on the real sources from the start, so problems surface while they are cheap to fix.
Permissions matter as much as data. An assistant must only show people what they are already allowed to see. That means respecting the access rules of each source system, passing the user's identity through every request and filtering results before they reach the model. This is far easier to design in than to retrofit.
Finally, the system should sit where people already work: their chat tool, their email, their case management system or intranet. An assistant that needs a new login and a new habit will be forgotten.
Security and privacy by design
Where data is processed, how long it is kept, who can read logs and which model providers are involved are design decisions. We settle them with security, legal and data protection colleagues in the first weeks, not at sign-off. For sensitive work this may mean running models within the organisation's own cloud tenancy or on its own servers.
We also plan for misuse and error. That includes limiting what actions the system can take on its own, testing it against attempts to override its instructions, and recording enough detail to investigate an incident. The NIST AI Risk Management Framework and, in Europe, the EU AI Act give a useful structure for these conversations.
Adoption: training, champions and feedback
Adoption is a programme of work, not a launch email. Short, role-specific training shows people what the system is good at, where it is weak and how to check its answers.
Champions make the biggest difference. In each team we identify one or two people who use the system early, help colleagues and bring back problems.
Feedback must be easy and visible. A simple thumbs up or down with an optional comment, reviewed every week, gives the team a steady flow of real cases. When people see their feedback fixed, they keep giving it.
Running it in production
Once live, we monitor usage, response times and error rates, and also the quality signals: feedback scores, escalation rates and the share of answers with a valid source. A drop in any of these is treated as an incident.
Cost needs active management. Usage grows once a system is useful, and costs follow. Caching common answers, routing simple requests to smaller models and setting budgets per team keep this predictable.
Models change. Providers release new versions and retire old ones. With an evaluation set in place, a model update becomes a routine change: run the set, compare the results, review the differences and release if the quality gate is met. Without one, every update is a risk.
A production checklist
- Name the owner and the measureOne accountable person in the business, the task the system supports and the number it should move.
- Agree the quality thresholdDecide how good it must be before real users see it, and what kinds of error are unacceptable for this task.
- Build the evaluation setCollect real cases with known good answers, including awkward and out-of-scope ones, and score every release against them.
- Connect to real systemsUse the production data sources, respect existing permissions and place the system inside the tools people already use.
- Settle security and privacyAgree data location, retention, logging and model providers with the right colleagues before the build is far along.
- Plan adoptionRole-specific training, a champion in each team and a feedback loop that is reviewed every week.
- Set up operationsMonitoring for quality as well as uptime, cost controls, an incident route and a routine process for model updates.
Frequently asked questions
How long should a pilot run before we decide?
Long enough to test against the agreed evaluation set with real users and real data, usually a matter of weeks rather than months. If the success measure was defined up front, the decision is usually clear.
Do we need our own model?
Rarely. Most business value comes from good data, good integration and good evaluation around an existing model. Training a model is worth considering only when the task and data are highly specialised.
Who should own an AI system once it is live?
The business function whose work it supports, with technology teams running the platform. Ownership of the outcome should not sit with the supplier or an innovation team.
What if the model provider changes or retires a model?
Treat it as a normal change. Run the new version against your evaluation set, review the differences and release only if it passes the quality gate.
None of this is glamorous. It is the difference between a demo that impresses a room and a system that people rely on every day.