Data & AI

AI that has to get past the pilot

Who you actually need, and in what order

The pilot worked. The model found the churn signal, the board saw the demo and asked when it would be live. A year and a half later it is still a pilot, and the people who built it have been pulled back onto the warehouse migration. Someone has told you the answer is to hire AI people. It usually is not, or not first.

This is why that happens, who you actually need, and in what order.

Why pilots stall

We see four causes, and the model is rarely one of them.

The data was clean once, for the demo. The pilot ran on an extract someone prepared by hand. Production means the pipeline runs every night, the source systems change underneath it, and someone owns the definition of “customer”. Most organisations discover here that nobody does.

Nobody owns production. The data science team built it, the platform team did not ask for it, and the business sponsor thinks it is live. A model with no owner for monitoring, retraining and incidents is not in production.

Risk and governance arrive late. The pilot did not need the privacy assessment, the model risk review or an answer to “what happens when it is wrong”. Production does. If those functions meet the model for the first time at the go-live gate, the gate stays shut.

The outcome was never measured. “The model is accurate” is not a business result. Without a baseline and a number the CFO recognises, the pilot loses every funding argument.

The hiring order that holds up

The common move, and the common mistake, is to appoint a head of AI first and expect the pilots to become products. A head of AI with no platform under them spends the first year asking the data team for things it was never funded to do, and the second year explaining why.

The order we see hold up:

  1. A data and platform leader who can make the foundations boring: pipelines that run, definitions that are agreed, access that is governed, costs that are known. Unglamorous, and the whole game.
  2. An AI or ML engineering lead who has shipped to production, not presented a pilot. Someone who has owned a model through retraining, drift, an incident and a quarter where the number moved.
  3. The engineers, hired against the products the first two have scoped, not a generic “AI team” headcount.

Head of AI comes later, if at all, once there is something to be head of.

The roles, and what each actually does

Data platform lead. Owns the pipelines, the warehouse or lakehouse, the access model and the cost. Measured on reliability and on how quickly a new data product can be stood up.

ML engineering lead. Takes models from notebook to production and keeps them there: deployment, monitoring, retraining, rollback. The person on the call when the model starts doing something strange.

Data product owner. Sits in or beside the business, owns the outcome a data product delivers, decides what gets built next and says no. The missing role in most stalled pilots.

AI governance and risk. Runs the model risk framework, the privacy and fairness assessments, and the register of what is in production and why. A function in a bank or insurer; in a mid-sized firm, one senior person with authority, in place before go-live rather than after.

Analytics engineering. Turns raw data into the trusted, documented layer that analysts and models consume. Where the “customer” definition finally gets settled.

What “has done it” looks like

Every CV in this market says AI. The ones to take seriously say something narrower: a named model or data product in production for at least a year, a business outcome with a number against it, and a constraint that tells you it was real. Volume, regulation, latency, a hostile source system.

In conversation, three things separate the people who did it from those who were nearby. The thing that broke: what the model did, who noticed, what they changed. The data decision they reversed: a feature removed, a source they stopped trusting, a definition they fought the business over. And the measurement: who signed off the baseline, and what the number did once the pilot stopped being watched. People who have carried production talk about Mondays. People who have presented it talk about potential.

Where the people are

The banks and insurers that industrialised early, where model risk discipline is strongest and people have run production under a regulator: strong on governance, sometimes slower on pace. The consulting AI practices, wide on breadth and sometimes thin on production ownership: ask who kept the model running after the engagement ended. The scale-ups, where people have shipped fast with small teams and rarely inside a risk function or a legacy estate. And the academic path, strong on method and lighter on production, which produces excellent second hires once a platform and an ML lead are in place.

Permanent, contract, or a bench

Contract teams build a first pilot quickly, and that is often the right call. The risk is the bench that moves on: when the engagement ends, the knowledge of why it was built that way leaves with it. The pattern that holds is permanent leadership in the first two seats, contract capacity for the build, and a handover written into the contract. If you cannot name the permanent person who will own the model in eighteen months, you are not ready to build it.

How we assess and run the search

We know this network and we talk to it every week: the platform leads, the ML engineers who have carried production, the data product people in the business. Our data and AI work rests on that network and on close to 20 years in technology and transformation search, and we would rather say that plainly than overstate it.

The assessment is against the brief, not the keyword list. For the first two seats we want the production evidence above, tested in conversation and confirmed with a referee from the business side. On a retained search you hear in week one whether the brief asks for a head of AI when it needs a platform lead, and whether the package reaches the people who have done this.

The pilot proved the idea. Getting past it is a hiring problem before it is a technology one.

Questions clients ask

Do we need a Chief AI Officer?

Usually not yet. A Chief AI Officer makes sense once there are several AI products in production, a governance function to oversee and a board that wants one accountable voice. Before that, the title creates a leader with no platform under them. Most organisations need a strong data and platform leader first, with AI inside their remit, and can revisit the question in eighteen months.

Should we hire data scientists or data engineers first?

Data engineers, almost always. A data scientist without reliable pipelines spends most of their time cleaning data and the rest of it explaining why the model cannot be deployed. Once the platform is stable and governed, scientists and ML engineers become productive quickly. The one exception is a single senior ML lead brought in early to shape what the platform must support.

How do we assess AI experience when every CV says AI?

Ask for one model or data product that has been in production for a year and the number it moved. Then ask what broke, what they changed and which data decision they reversed. People who have carried production answer in specifics and without defensiveness. People who have presented it return to the potential of the technology. Referees from the business side, not the technical team, settle it.

Have a role like this one?

Most searches we run start with a conversation about the brief, not a job description. If you are at that point, we are easy to talk to.