From Pilot to Production: Hiring the Leaders Who Operationalise AI

Walk into almost any large organisation and you will find a portfolio of impressive AI pilots. Walk back in a year and most of them will still be pilots. Building a model that works in a demo is the easier half of enterprise AI. The harder half is getting it into production, keeping it running and persuading people to use it, and that is where most of the value is lost. The leaders who can do that have a different profile from the leaders who build demos, and they are the people most organisations are short of in 2026.

Key takeaways

• Most enterprise AI value is lost in the gap between a working pilot and a deployed, monitored, trusted system.
• Operationalising AI is an organisational skill as much as a technical one: integration, monitoring, change management and adoption.
• The leader who builds the most impressive prototype is often not the leader who can ship and sustain it, so a hiring process that rewards the prototype selects for the wrong skills.
• In regulated domains, production also means defensible: monitored, documented and governed for the long term.
• 88% of organisations in McKinsey’s 2025 survey use AI, but only 7% say it has been fully scaled across the organisation (McKinsey, December 2025).
• Screen for a track record of systems that reached production and stayed there, rather than for the cleverest proof of concept.

Why pilots stall

Most pilots stall for organisational reasons rather than technical ones. The data pipeline that worked on a curated sample breaks on live data. No one owns monitoring, so quiet drift goes unnoticed. The workflow it was meant to support never actually changed, so clinicians or analysts route around it. None of these are research problems. They are operational and human, which is why the leader worth hiring treats deployment, monitoring and adoption as the main body of work rather than something to arrange once the model is built.

Most organisations have more AI pilots than AI systems in daily use. The gap between the two is an operational problem.

What the evidence says about stalled pilots

The gap is measurable. McKinsey’s 2025 global survey found 88% of respondents’ organisations using AI, but only 7% reporting that it had been fully scaled across the organisation (McKinsey, December 2025). Two years earlier, Gartner predicted that at least 30% of generative AI projects would be abandoned after proof of concept by the end of 2025, and gave four reasons: poor data quality, inadequate risk controls, escalating costs and unclear business value (Gartner, 29 July 2024).

None of those four reasons is solved by a better model. Data quality is an engineering and ownership problem. Risk controls are a governance problem. Cost is a problem of architecture and vendor management. Unclear value is a problem of choosing the right use case and measuring it honestly. Each one maps to a leadership capability, and a hiring process that tests only for modelling skill will miss all four.

The profile that ships

The leader who gets systems into production usually has a different background from the researcher. They are as comfortable with change management and stakeholder trust as with architecture. They design for monitoring from day one. In healthcare and life sciences they also know that a system in production has to be defensible: documented, overseen and able to satisfy clinical governance and the EU AI Act. This is the builder-and-steward profile we described in building a healthcare AI leadership team and returned to in our 2026 hiring outlook: technically credible, but valued for judgement and follow-through rather than novelty.

What production means in a regulated setting

In healthcare and life sciences, getting a system live is the start of a set of formal duties. Under the EU AI Act, providers of high-risk AI systems must run a post-market monitoring system that continuously tracks how the system performs (Article 72), and deployers must monitor operation and keep the automatically generated logs for at least six months (Article 26) (Regulation (EU) 2024/1689). Update, September 2026: the application dates for those obligations have moved to December 2027 and August 2028, as we explained in our analysis of the delay, but the systems being deployed now are the ones that will have to meet them.

In the US, the FDA’s final guidance on predetermined change control plans lets a manufacturer of an AI-enabled device make planned modifications, such as retraining, without a new marketing submission for each change, provided the plan was set out in advance (FDA, final guidance, August 2025). The practical consequence is that retraining and model updates have to be designed before launch. A leader who treats monitoring and change control as an afterthought will either freeze the model or trigger a new regulatory submission every time it needs to improve.

Why this profile is scarce and underpaid

The market still tends to pay the largest premiums to the most visible builders. The people who get systems live and keep them running are often paid less than their impact would justify. We made the same point about the talent shortage: there are more people who can build models than people who can deploy them. A buyer who knows how to screen for the second group can hire well without paying the top of the market.

How to hire for production

Change what you test for. Instead of admiring the prototype, ask what the candidate has taken into production, what broke, how they monitored it, and what happened to adoption a year later. Probe for the unglamorous work: integration, drift monitoring, retraining, the politics of changing a workflow. A technical screen on its own will not surface this kind of judgement. It comes out of structured referencing with the people who worked alongside the candidate, which is how executive search assesses it, and our guide to hiring data leadership covers the questions in more detail.

Where production leaders come from

Production leaders are often found outside the pools a search usually starts with. Research labs and the AI teams of large technology companies produce excellent model builders, but their infrastructure is so mature that many of their people have never had to build monitoring, integration or change control themselves. The candidates who have done that work tend to come from four other places.

The first is platform and machine learning operations engineering in regulated software, where deployment, audit trails and rollback are part of the job. The second is clinical informatics, where people have spent years getting software adopted by clinicians who had every reason to resist it. The third is medical device and diagnostics companies, where quality and regulatory teams include engineers who understand both validation and machine learning. The fourth is the digital operations function of large health systems and pharmaceutical companies, where someone has had to keep dozens of vendor tools running inside a live organisation.

None of these backgrounds guarantees the right person, and each has gaps. A clinical informatics leader may need support on model architecture; a platform engineer may need support on clinical governance. The brief should say which gap the organisation can fill around the hire and which it cannot, because that decides which pool to search first.

What to put in the brief

Write the brief around outcomes at twelve months rather than a list of technologies. Name the two or three systems that should be in daily use by then, who should be using them, and how performance will be monitored and reported. State who owns the budget for integration and change management. A candidate who reads that brief will know whether the organisation is serious about production, and the strongest ones will ask sharper questions about it than about the salary.

It helps to be explicit about what the organisation already has. If there is a strong data platform team, the hire can lean towards adoption and governance. If the data platform is weak, the first year will be spent on pipelines and monitoring, and the hire needs to have done that before.

Questions that separate the two profiles

These are the questions we use to tell a production leader from a prototype builder. The answers are usually specific and a little uncomfortable when the candidate has done the work.

• Which system that you led is still in daily use two years after launch, and who uses it?
• What was the first thing that broke on live data, and how did you find out?
• How did you monitor for drift, and what threshold triggered retraining?
• Which workflow had to change for the system to be adopted, and who had to agree to that change?
• Which project did you stop, and how did you make that case to the sponsor?

In Fergal Nolan’s experience of hiring AI leaders over 25 years, the last question is the most revealing. Leaders who have shipped systems have also killed projects, and they can explain why without defensiveness.

An AI budget produces a return only when systems are in use. The leaders who take a model from pilot to production and keep it there are the hire that decides whether that happens, and they are worth the extra time it takes to find them.

Update, August 2026: our analysis of Every Cure looks at the team design behind getting AI outputs into clinical use; see what Every Cure teaches about building healthcare AI teams.

Fergal Nolan is the founder of Banba, a specialist executive search firm for Healthcare AI and Life Sciences AI, with offices in New York, London and Berlin. He has spent more than 25 years in talent acquisition, including as a founding team member at SThree / Real Staffing and as founder of Upstream, where he has built Data Science & AI teams and AI leaders for start-ups, scale-ups and global enterprises.