Your AI pilot stalled. Which role actually unblocks it?
8 minute read. Updated 2026-08-08.
A stalled AI pilot almost always has a specific cause, and the cause points to a specific discipline: production failures need AI engineering and MLOps, wrong or hallucinated answers need LLM applications and retrieval work, sign-off delays need AI governance and risk and compliance, and low adoption needs AI product or AI training and enablement. Hiring another generalist rarely fixes any of these. Diagnose the symptom first, then hire the discipline that matches it.
Diagnose the symptom before you hire
A pilot stalls for a specific reason, and the reason usually points to a specific discipline. Hiring another generalist to sit on top of the problem rarely moves it. The faster route is to name the symptom precisely and match it to the discipline built to fix it.
This matters because the disciplines involved in AI work, AI strategy, AI engineering, LLM applications, agents and retrieval, MLOps and platform, data engineering, AI governance, AI risk and compliance, AI safety and evaluation, AI red teaming, AI product, fine-tuning, AI training and enablement, and AI research, are not interchangeable. A data scientist who built the prototype is rarely the right person to make it reliable in production. Neither of them is the right person to decide whether it should be shipped at all.
This post works as a lookup. Find the symptom that matches what is actually happening in your pilot, not the symptom you assumed at the start, and go to the discipline listed against it. Where two disciplines could plausibly be the cause, hire for the cheaper, faster diagnosis first, because ruling out data engineering is quicker than ruling out a model capability limit.
The demo worked, production doesn't
If a model behaved well on a laptop and then failed under real traffic, real users or real data drift, the gap is almost never a model problem. It is an engineering problem: no monitoring and no fallback behaviour for when the input looks nothing like the training set.
This is AI engineering and MLOps and platform territory, not further research into the model itself. The fix looks like logging, evaluation pipelines, versioning and a rollback plan, work that a research-minded data scientist is rarely trained to do and rarely enjoys doing.
A useful sign you are in this territory: the failures are inconsistent and hard to reproduce, rather than the model being confidently wrong every time in the same way. Inconsistent failure under real conditions is an infrastructure signature, not a model competence signature.
The answers are wrong, slow, or made up
A system that hallucinates, retrieves the wrong document, or takes too long to respond usually has a retrieval or architecture problem rather than a model problem. That is LLM applications and agents and retrieval work: the way the system finds information, structures a prompt and chains steps together.
If the underlying model genuinely is not capable enough at the specific task, once retrieval and prompting are already solid, that is when fine-tuning becomes worth the cost. Reaching for fine-tuning before fixing retrieval is a common way to spend a great deal of money solving the wrong problem.
Retrieval problems and model capability problems look similar from the outside: both produce a wrong answer. The distinguishing test is whether the correct information was ever available to the system when it answered. If it was in the document set and the system still missed it, that is retrieval. If the information was never available anywhere, that is a different problem entirely, and possibly not one fine-tuning solves either.
Nobody can sign off because nobody owns the risk
If the pilot works technically but stalls at the sign-off stage because nobody can say whether it is compliant, safe to use with customer data, or defensible if a regulator asks, that is a governance gap, not a technical one. It calls for AI governance and AI risk and compliance.
Nothing at all is published for AI governance or AI risk and compliance as job titles in the UK advertised market, which means most companies hiring for this work advertise it under something else entirely and are then surprised when the person they hired cannot actually do it. Name the discipline correctly even if the market will not.
The practical fix is to give someone an explicit mandate to own this question, with a title that says what they do, AI governance or AI risk and compliance, rather than folding the responsibility into an engineering role where it competes for attention with shipping the next feature.
The model behaves until someone tries to break it
A pilot that passes every planned test but has never faced an adversarial one is not tested, it is demonstrated. AI safety and evaluation builds the test suite that checks for failure under normal variation. AI red teaming is the separate discipline of actively trying to break the system before a user or an attacker does.
These are worth bringing in before launch, not after an incident. A pilot that stalls because leadership will not approve a launch without evidence of adversarial testing is stalling for a reasonable reason, and the fix is to commission that testing rather than to push for sign-off without it.
AI safety and evaluation and AI red teaming are frequently treated as one job. They are related but distinct: evaluation is ongoing and structural, built into how the system is tested every time it changes, while red teaming is a targeted exercise run before a specific launch or after a specific concern is raised.
The data underneath it is not fit for purpose
If the pilot's outputs are inconsistent because the data feeding it is incomplete, duplicated, or wrong at source, no amount of model or prompt work will fix it. That is data engineering, and it is frequently the actual blocker hiding behind what looks like a model problem.
It is also the discipline most likely to be underestimated at the scoping stage, because the pilot demo used a clean, hand-picked dataset that never resembled production data in the first place.
A quick diagnostic: ask what happens to the pilot's accuracy when it runs against last week's real data rather than the dataset used in the original demo. A sharp drop points squarely at data engineering, and the fix is unglamorous, dull pipeline work rather than anything to do with the model.
It works, but nobody will use it or fund it
A technically sound pilot that stalls because nobody will fund the next phase or use the output usually has an AI product gap: nobody has built the business case, defined who the user is, or decided what success looks like beyond the demo. AI strategy sits above this, setting which problems are worth solving at all.
If the tool is right but adoption is low because staff do not trust it or do not know how to use it well, that is AI training and enablement, a genuinely different problem to a product one. AI research, by contrast, is almost never the answer to a stalled pilot: it solves problems nobody has solved before, and a stalled pilot is usually a problem plenty of people have already solved.
Of the disciplines listed here, AI research is the one worth naming explicitly as usually the wrong answer to a stalled pilot. It is the right hire when you are attempting something nobody has built before. Almost no stalled pilot is in that position; most are stalled on engineering, data, governance, or product grounds that have well-understood fixes.
What to do about it
- Match the symptom to the discipline before hiring; do not default to another generalist.
- Treat a production failure as an engineering and MLOps problem, not a reason to retrain the model.
- Fix retrieval and prompting before reaching for fine-tuning.
- If nobody can sign off, hire explicitly for governance and risk and compliance, even though the market rarely advertises those titles.
- Commission adversarial testing before launch, not after an incident.
- Do not confuse a data engineering problem with a model problem; check the data first.
Questions people also ask
We already have a data scientist. Why isn't the pilot moving?
Because building a model and making it reliable in production are different disciplines. A data scientist is trained to develop and validate a model. Getting it to survive real traffic, real data drift and real failure modes is AI engineering and MLOps and platform work. If your pilot works on a laptop and breaks in production, the fix is usually a second discipline joining the team, not a better data scientist.
How do we know if the blocker is data or the model?
Test the pilot against a sample of genuinely messy, current production data rather than the clean dataset used in the demo. If the outputs are inconsistent because the input data is incomplete or wrong, that is a data engineering problem. If the data is fine and the outputs are still wrong or invented, the problem sits in the model, the retrieval, or the prompting.
Do we need a red teaming exercise before every launch?
For anything touching customer data, financial decisions or regulated processes, yes, some form of adversarial testing before launch is worth the cost. AI red teaming is a distinct discipline to AI safety and evaluation: evaluation checks behaviour under expected variation, red teaming actively tries to break the system. A stalled sign-off because leadership wants evidence of both is a reasonable stall, not an obstruction.
Is AI governance really a separate hire from AI engineering?
Yes, and the market's own numbers show why this is confusing. Nothing at all is published for AI governance or AI risk and compliance as job titles in the UK advertised market, so the work gets folded into engineering or data science roles where it does not fit well. Someone strong at building systems is rarely also the right person to judge whether the system is compliant or defensible.
Where the figures come from
Every rate and salary quoted in this article is a median or percentile of figures advertised in UK job postings over the six months to 8 August 2026. They are not rates paid, and the gap widens at the top of a range.
- IT Jobs Watch, UK contract rates, 6 months to 8 August 2026, read 2026-08-08.
- IT Jobs Watch, UK permanent salaries, 6 months to 8 August 2026, read 2026-08-08.