Most of the AI pilots we get asked to rescue worked. That is the frustrating part. The demo went well, the steering group nodded, somebody said “let’s scale this”, and then nothing happened for nine months.
When we dig in, the model is almost never the problem. A modern foundation model, sensibly prompted, will usually do the task well enough. What stops the pilot is everything around the model, and almost all of it was visible in week one if anyone had been looking for it.
These are the five patterns we see most often, roughly in the order they bite.
The demo ran on data nobody will maintain
Pilots are built on an extract. Someone pulls a few thousand records, a data scientist spends two weeks cleaning them by hand, and the model is evaluated on that. It looks great, because it is looking at the best version of the data that will ever exist.
Production is different. Fields are missing. Two systems disagree about a customer’s address. The PDF that was text in the sample is a scanned image in the real queue. And the cleaning that happened in a notebook has no owner, no schedule and no tests.
The fix is boring and it works: connect the pilot to the real source in the first fortnight, even if that source is ugly. If the model cannot cope with the data you actually have, you want to know in week two, not after the budget for phase two has been approved.
Nobody wrote down what “good” meant
Ask a pilot team how accurate their system is and you will often get a number. Ask them how they measured it and the answer gets vaguer. Somebody looked at fifty outputs and most seemed fine.
That is not a measurement anyone can defend to a risk committee, and it gives you no way to tell whether next month’s prompt change made things better or worse.
Before writing a single prompt, we now build an evaluation set: a couple of hundred real cases, each with the answer a competent person in the business would give, and a note on which mistakes are cheap and which are expensive. A wrong category on a support ticket is annoying. A wrong figure in a credit memo is not. Those two errors should not count the same, and the evaluation set is where you say so.
If you cannot say how you would know it got worse, you are not ready to put it in front of customers.
The approvals started in month four
In a large organisation an AI system that touches customer data will need sign-off from security, from whoever owns data protection, often from legal, and increasingly from a model risk or AI governance group. None of them are being difficult. They have real questions about where data goes, what gets logged, who can see the prompts, and what happens when the model is confidently wrong.
Pilots tend to meet these people for the first time when someone asks to go live. Each review takes weeks, each one asks for changes, and the changes trigger the other reviews again.
We invite those reviewers into the first fortnight. We show them the architecture on one page, tell them which data is involved, and ask what they will need to see at the end. Most of the time their list is shorter than people fear, and building to it from the start costs almost nothing.
It lived next to the work, not inside it
A pilot is usually a separate web page. Paste something in, get something back. That is fine for a demo. It is not how anyone does their job.
If a claims handler has to copy text out of the claims system, paste it into another tab, read the answer and type it back, they will do it for a week and then stop. The useful version of the tool lives inside the system they already have open, and that means an integration that the pilot never budgeted for.
The question we ask early is simple: on the day this goes live, where exactly will the person be sitting, which screen will they have open, and what will they click? If the honest answer is “a new screen”, the integration work belongs in the plan from day one.
The pilot team went home
Pilot teams are often a mix of an innovation group, a consultancy and a couple of keen people from the business. When the pilot ends, they move on to the next idea. The system they built has no product owner, no support rota and no budget line.
AI systems need more looking after than ordinary software, not less. Models get updated by their providers. The documents they read change. Users find new ways to ask questions. Someone has to watch the quality numbers, review the odd answers and decide when to change something.
If no one in the business is willing to own that, it is a strong sign the use case was not important enough to begin with. That is a fine outcome for a pilot, by the way. It is much better to learn it before the production build.
What we do differently
None of this needs a new framework. It needs a few decisions made earlier than people usually make them.
- Pick a process with an owner. A named person in the business who will still be accountable for it a year from now.
- Build the evaluation set first. Real cases, real expected answers, and a note on which mistakes matter.
- Use production data from week two. Mess and all.
- Design for being wrong. Confidence thresholds, a human in the loop where errors are expensive, and an easy way for users to flag a bad answer.
- Bring the reviewers in early. Security, data protection and risk, in the first fortnight rather than the last.
- Cost the running, not just the building. Tokens or compute at real volume, monitoring, and a few hours a week of somebody’s attention.
A pilot run this way is slower in its first month and much faster in its sixth. More importantly, when it does not work out, you find out cheaply and early, which is the whole point of a pilot.
Written by the people at Ucanly who do this work for clients. If you think we have got something wrong, or you have seen it go differently, we would genuinely like to hear it: support@ucanly.in.