A proof of concept works in a notebook. Then it has to run on live data, be checked against output people trust, and fit into somebody’s working day.
When a pilot stalls at that point, the usual response is to look for another AI engineer, but that’s often the wrong hire.
Why do AI projects stall after the pilot?
A UK government survey of 3,500 businesses, run for the Department for Science, Innovation and Technology (DSIT) with fieldwork between February and May 2025, asked current AI users what held them back.
Limited AI skills was the most common answer, at 54%. Next came lack of tools and platforms (37%), no identified use (30%), projects too complex to integrate and scale (26%) and data complexity (23%).
The survey doesn’t say which skills respondents meant, so it can’t settle who to hire. It does show that skills sit alongside tooling, integration and data on the list of barriers. Results were modest too, and all self-reported: 75% of users reported better workforce productivity, 77% reported no change in revenue so far and 12% an increase.
What’s usually missing?
Four things sit between a working model and a working system.
- Data quality and access: a data engineer who can make the source data complete, current and permitted for use.
- Pipelines and deployment: a platform or machine learning operations (MLOps) engineer who can run the system in production, monitor it and roll it back.
- Evaluation: someone who can define what a good answer looks like and test for it, usually a data scientist or analyst working with the business owner.
- The workflow around the output: a product person who can change the process so that people use what the model produces.
When is an AI engineer the right hire?
When the constraint is the model itself: a task the current system can’t do, a model that needs fine-tuning, or a latency or cost problem that sits inside the model.
Test it: what would change if that person started tomorrow?
If their first month would be spent waiting for data access, a deployment route or a process owner, the hire inherits the same blockers.
How do you tell which hire you need?
Take your last stalled project and trace where it waited.
- If it waited on data that someone had to find, clean or get permission for, hire for data.
- If it waited on a route to production, hire for platform.
- If it shipped and nobody changed how they work, hire for product or process.
- If it waited on none of those, you may well need an AI engineer.
Scarce AI engineers are also expensive and contested. We wrote about one candidate whose accepted offer was doubled two days later.
What should you settle before opening the role?
Four answers make the brief sharper, whichever profile you end up hiring:
- Who owns the data this system reads, and can they give a new hire access in the first week?
- Where does the output go, and whose routine has to change because of it?
- How will you know the output is good enough to rely on?
- Who is on call when it fails?
If nobody can answer the first or last of those, the first hire is probably an owner, not a specialist.
Does this change how you write the job spec?
Yes. Describe the blocker, not the title.
“Own the pipeline that feeds our support model and its evaluation” will reach different people from “AI engineer”. Candidates who’ve kept a production system running often don’t have “AI” in their job title, so a title filter will miss them.
Where SR2 fits
We recruit for data, engineering and AI roles at SaaS, data-led and technology services businesses. If a pilot has stalled and you’re deciding what to hire next, talk to us before you write the spec.
Talk to the SR2 Technology team.
Data or platform engineer looking at AI-related roles? See our open roles.
