AI skills: hire, train or outsource?

The question comes up in almost every executive discussion about AI: should we hire experts, train the teams we have, or bring in outside help? It is usually treated as a budget trade-off. That is a framing error. The right criterion is not cost, it is the nature of the capability the organisation needs — and that nature changes with the phase it is in.

A confusion needs clearing first. "AI skills" covers at least four distinct professions whose labour markets have nothing in common. The data scientist designs models. The data engineer builds and maintains the pipelines that feed them — today the scarcest and most decisive resource. The production engineer, often called MLOps, keeps those systems running over time. And the business translator, a hybrid profile with no stable job title, converts an operational problem into a question a model can address. An organisation that hires three data scientists without a data engineer ends up with three highly qualified people spending half their time on plumbing work they dislike and were not trained for.

Hiring is justified when the capability must be permanent, exercised daily, and fed by internal knowledge of the organisation. That is typically the case for data engineering and production work: these roles rest on a fine-grained knowledge of in-house systems that cannot be bought and is lost with every departure. Hiring does, however, assume an ability to retain. Recruiting a scarce profile into an organisation that can offer neither stimulating projects, nor progression, nor a decent technical environment is funding a competitor's training programme.

Internal training is justified when the capability to develop is adjacent to a profession already mastered. Teaching a financial analyst to question a model, a lawyer to assess an automated decision, a controller to read the limits of a prediction: these work because the professional base is already there and only the technical layer is missing. Conversely, the idea of turning non-technical teams into data science practitioners through a few weeks' programme mostly produces frustration.

External help is justified in two situations, and only two. The first is a one-off need for rare expertise it would be absurd to internalise: strategic framing, architecture, a compliance audit. The second is skills transfer — bringing someone in precisely so the organisation can do it alone afterwards. Any other arrangement creates a dependency that is paid for over a long time.

The case below is rebuilt from several comparable situations, not copied from one specific company. A company hires a data science team of six, with solid profiles and market-rate salaries. Eighteen months later, four have left. The exit interviews mention neither pay nor atmosphere. They mention three things: no access to production data, several months' wait for a working environment, and the sense that delivered models were never deployed. The organisation did not have a recruitment problem. It had a working-conditions problem, and recruitment simply made it visible and expensive.

This is a point we press consistently: before asking how to attract AI skills, an organisation must ask whether it is in a state to employ them. At KAIROS Impulse that check precedes any recommendation on team sizing. It covers four concrete elements: access to data, availability of technical environments, the existence of a path to production, and a business sponsor for each use case. Without those four, the best hire will fail, and the failure will be attributed to the people rather than the setup.

A fair objection concerns pace. Waiting until those conditions are met would delay entry into the subject while the market moves. The answer lies in sequencing: the first capability to secure is not the data scientist but the data engineer, because they build the conditions in which the others can work. Many organisations do the reverse and are surprised by the outcome.

One final factor weighs more than all the others and appears in no budget: the ability to let people grow. AI professions evolve fast, and a professional who feels their skills depreciating will leave, whatever the salary. Time spent on watching the field, experimenting and continuous learning is not overhead: it is the condition of retention. Organisations that grant it keep their teams; those that refuse it in the name of project load recruit permanently.

Three questions to close. What capability do we actually need — designing models, building data pipelines, running systems, or translating business needs? Are we in a position to offer that person an environment where they can work from the first month? And if we bring in outside help, have we defined what we must be able to do alone once the engagement ends?