Plenty of large retailers now have a board mandate for AI, strong data people, and nobody who has actually shipped an AI system into production. Hiring for the gap is the obvious move and usually the wrong first one.
The pattern looks like this. A large retailer, healthy revenue, decent margin, respectable technology function. The board has asked what the AI plan is. The CIO comes from a data background and is comfortable with warehouses, pipelines and reporting, but has never run a production model that makes decisions. There is no AI lead. There are perhaps a dozen pilots scattered across marketing, service and merchandising, all at different stages, none of them owned centrally.
The instinct is to hire. Write a job description for a Head of AI, run a search, and let them build the strategy.
That instinct is reasonable and it usually costs a year. A senior search takes three to six months. The successful candidate spends their first quarter learning the systems and the politics. Their first real deliverable lands somewhere around month nine, and it is a strategy document, because that is what someone with no working systems can produce.
Meanwhile the pilots keep multiplying and nobody has yet proven what an AI system in your business is actually worth.
Stripped of the title, an effective AI lead does four things.
Portfolio triage. Deciding which of the many possible use cases get built, in what order, and killing the ones that will never justify their operating cost. This requires a good sense of what these systems cost to run and maintain, which is knowledge you acquire by running them, not by reading about them.
Architecture and guardrails. Deciding how systems connect to production data, what they are allowed to do autonomously, where a human has to approve, and how every decision gets logged. Getting this wrong is how organisations end up with a system that quietly does something expensive at scale.
Operating the estate. Production AI is not a project that finishes. Models drift, data changes shape, upstream systems get updated, and something that worked in March quietly stops working in September. Somebody has to own that, or the estate degrades into a set of things nobody trusts.
Enablement. Making existing teams capable of building and running their own automation, so demand does not funnel through one central bottleneck forever.
Notice that three of those four are operational. The strategic part is the smallest piece, and it is the only part you can do without having built anything.
Prove two or three use cases first, with people who have already done it, and let the evidence write the job description.
Pick candidates that satisfy three conditions. The value is measurable in an existing cost or revenue line. The data required already exists in a system you own. And the failure mode is contained, so the worst case is a recommendation nobody acts on rather than a customer-facing incident.
In retail, the usual shortlist is customer service intelligence, a pricing or markdown recommendation engine, marketplace catalogue quality, and some form of internal service-desk automation. All four are measurable, all four use data you already have, and none of them require a foundational platform programme before they can start.
Run them properly rather than as pilots. A pilot ends with a deck. A production deployment ends with a system that runs on a schedule, an owner, a monitoring story, and a number attached to it. The difference matters, because only the second one teaches you what the operating burden really is.
Three things, none of which is a strategy document.
Working systems in production, with measured results and an honest account of what they cost to run. Two is plenty. They become the reference for everything that follows, and they end the internal debate about whether this works here.
A pattern others can copy. How systems connect to data, how guardrails are specified, how decisions are logged, how something gets promoted from experiment to production. Written down once, from real examples, so the fifth system does not reinvent the first.
A named internal owner for each system, who has been alongside the build and can operate it. This is what turns an external engagement into internal capability, and it is why enablement should be part of the work from day one rather than a handover event at the end.
With those three in hand, the AI lead search becomes straightforward. You know which problems the role owns, what the estate looks like, what skills the first year genuinely requires, and what good performance would be. You are hiring someone to scale a working thing rather than to invent a plan.
You will also attract better candidates. Strong operators are wary of roles where nothing has been proven and the mandate is to convince an organisation from a standing start. A role with production systems, a live portfolio and demonstrated executive support is a materially easier sell.
A CIO with deep data experience is a real advantage. The warehouse exists, the pipelines are maintained, and the organisation already argues about definitions, which is more than most retailers can say.
The gap is a different one, and it is worth naming plainly rather than treating as a shortfall. Analytics answers questions for people. Production AI takes actions inside a business process. The skills that differ are guardrail design, failure handling, decision logging, human review paths, and the operational discipline of running something that acts on its own on a Sunday morning.
Those are learnable, and the fastest way to learn them is alongside people doing it in your own systems, on your own data, with your own edge cases. That is a very different experience from a training course, and it leaves capability behind rather than certificates.
You do not need an AI lead to start. You need two or three production systems, an operating pattern, and a named internal owner for each. Then hire, from a position where you can describe the job precisely because you have watched it being done.
The alternative is a year of strategy while the pilots multiply and nobody can say what any of it is worth.
We bring the operational team, prove two or three use cases in your systems, and leave your people able to run them.