Why do AI pilots stall?
A pilot is built to prove an idea. It runs on tidy sample data, with a keen person watching it, away from the daily mess. It works. Everyone claps. Then nothing happens.
The gap is rarely the model. It is everything around it. The pilot was never wired into the tools people use, nobody was told it was their job to run it, and nobody agreed what "working" meant. So it sits in a demo folder.
Here is the pattern we see. The pilot proves that AI can do the task. Production needs to prove that your business can rely on it on a bad Tuesday, with the wrong data, while the keen person is on leave.
What does it mean to operationalise AI?
To operationalise AI (you will also see it spelt operationalizing AI) is to make it part of how work gets done, every day, without a hero holding it up. It has an owner. It connects to your systems. It is tested, watched and improved.
That is the fourth step of how we work: Discover, Prototype, Build, Operationalise, Improve. A pilot lives at step two. Most of the value sits at steps four and five.
What gets an AI pilot into daily work?
Five things. Miss one and the pilot tends to drift.
1. Name an owner
One person, in the business, who is responsible for the result. Not the IT team by default, and not a committee. The owner decides what good looks like, approves changes and chases problems. If you can't name this person, stop here.
2. Pick one workflow and fit the AI into it
Draw the workflow as it really runs: who does what, in which tool, in what order. Then mark the single step the AI takes over. Keep it narrow. An AI that drafts the first reply to a supplier query inside the inbox people already use beats a clever standalone app that needs a new login.
3. Sort the data
The AI can only work with what it can reach. Find where the information lives, who can change it, and how out of date it is. Fix the worst gaps before launch. Be honest about what it can't see, and tell the AI so, rather than letting it guess.
4. Set test gates
Decide in advance what must be true before it goes live, and before each step wider. For example:
- It handled a set of real past cases, picked by the owner, and the owner is happy with the answers.
- The people who will use it have tried it on live work.
- There is a clear route for someone to say "that is wrong" and have it fixed.
- The cases it must not handle are written down, with where they go instead.
We build in two-week sprints with a test week after each one for this reason. You use the work on real tasks before the next sprint starts.
5. Measure it
Pick one measure before you start and write down where it stands today. It could be time to answer a customer, number of steps in a process, or how many items a person clears in a day. Check again at 30 and 90 days. If you didn't measure the old way, you can't show the new way is better.
How is a pilot different from production?
| Pilot | Production | |
|---|---|---|
| Who uses it | A few keen people | The whole team, including the sceptics |
| Data | A clean sample | Live, messy, changing data |
| Where it lives | A separate demo | Inside the tools people already use |
| When it fails | Someone shrugs | Someone is told, and it gets fixed |
| Who is responsible | Whoever built it | A named owner in the business |
| Running costs | Ignored | Known and budgeted |
What can you do this week if a pilot is stuck?
You don't need a new project to get moving. Try this short list with the person who ran the pilot.
- Write the owner's name at the top of a page. If it is blank, that is your first job.
- List the last twenty real cases the pilot would have handled. Run them through it and mark each one right, wrong or unsure.
- Write down the one number you will watch, and what it is today.
- Ask two people who would use it what would make them stop using it.
- Pick a date, a small group and a clear way to say "stop".
The answers tell you whether you have a stalled pilot or a pilot that was never aimed at a real job. Both are fixable. They are fixed differently.
What happens when AI is adopted fast with no plan?
You get the opposite problem: too many pilots, not too few. A global recruitment business we worked with took up AI quickly. Teams built their own tools. There was duplication, inconsistent systems and uncontrolled experimentation. Nothing was stuck in a pilot. Everything was half-live.
We turned that rapid experimentation into a resilient AI operating model. Read the full case study. The lesson holds for small teams too: the production habits matter more than the number of experiments.
How long does it take to move a pilot into daily use?
It depends on the build, so we won't give you a number here. What we can say is how to keep it short. Move in small steps, each with a test, rather than one big switch. Start with the people who want it. Fix what they find before the next group joins.
If you already have a pilot, a short, paid discovery is a good way to find out what stands between it and daily use. You come out with requirements for each build, a refined plan, costing and a fixed price, then a go or no-go. See what happens in a two-day AI discovery.
A pilot that was built in a vibe coding tool has extra steps: security, testing and a proper home for the code. That is covered in vibe coding to production.