You have finally been given budget for one AI hire. The job description sits open on your screen, the cursor blinking, and the first decision is the one you are least sure about. Are you recruiting an engineer or an operator? The instinct, after months of running AI on top of your real job, is to hire someone more technical than you. Someone who can build the thing properly. That instinct is usually wrong, and acting on it is an expensive way to learn that the work was never mainly technical.
What does a first AI hire actually do?
A first AI hire in an owner-managed business is far more likely to be an operator than a builder. The role takes tools already in use and makes them reliable, used, and accountable. That means running adoption across teams, monitoring whether outputs still hold up, keeping a register of what is live, managing the vendors, and writing things down so the knowledge does not walk out the door.
Model building rarely features in any of that. The title sounds technical, which is what catches people out, but the work underneath it is operational discipline applied to a new class of tool. The research on mid-market failure is blunt about where the value leaks. Around 88% of AI projects never reach production, and only about 20% deliver significant return. Crucially, roughly 95% of those failures trace back to data and readiness problems rather than the technology itself.
Read that the right way and the hiring decision gets clearer. If the thing that sinks AI initiatives is rarely the absence of a model builder, then buying a model builder first is solving a problem you probably do not have. The work that decides whether your AI keeps earning its place is the unglamorous middle, and that is what the spec needs to describe.
Why is the operational gap the one you have?
The operational gap is the one many firms your size carry, because the technical work is increasingly bought rather than built. The capable models, the vendor platforms, the off-the-shelf assistants already exist. What does not exist, until someone owns it, is the connective tissue. Who checks the outputs each month. Who logs the new tool the marketing team started using last week. Who reads the contract before it renews.
That connective tissue is where deployed AI goes quiet and stops paying its way, and the evidence for drift is hard. A study from MIT, Harvard, and the University of Monterrey found that 91% of machine learning models degrade in performance over time as live data pulls away from what they were trained on. A system that worked at launch is not a system that still works in a year. The errors do not just grow, they grow erratically, so the gap between a good day and a bad day widens.
Catching that early needs continuous monitoring across the input data, the performance against real outcomes, and the running system itself. That is a standing operational job with a named owner, not a one-off build. A specialist engineer can tell you why a model is drifting. An operator is the person who notices it is drifting at all, because they are the one watching the dashboards every week and chasing the answer when the numbers move.
What does the operational hire own?
The operational hire owns five things, and the spec should name all of them. First, adoption, getting teams to actually use the tools rather than working around them. Second, monitoring, watching whether outputs still hold up and flagging when they slip. Third, the register and risk log, a current record of what is live and who is accountable for it. Fourth, vendor management. Fifth, knowledge transfer, so the firm is never hostage to one person.
Each of these has teeth, and vendor management is the one people underrate. It is not admin. Lock-in to a single provider raises prices over time, limits your access to better technology elsewhere, and leaves you exposed if the vendor changes its business model, so the contract needs exit terms and data portability written in before it renews rather than discovered after. Treating tools as something you can swap is what keeps an AI estate from turning into expensive dead weight.
The register matters for the same reason, and regulation is moving the same way. The EU AI Act already requires lifecycle risk management, automatic event logging, and human oversight for higher-risk systems. Even where your tools sit below that threshold, the discipline travels well, and the recordkeeping has to live somewhere with a name attached. None of this is glamorous. All of it is the difference between AI that compounds value and AI that becomes a liability the next person has to clean up.
When should you ask, and when should you wait?
Time the hire to evidence, not to a feeling of falling behind. The signal is concrete and arrives as a cluster. The person running AI on top of their day job has become a bottleneck on work you can see slipping. Monitoring that used to happen monthly now happens when someone remembers. And no single person can hand you a current list of which tools are live and who owns each one.
When those show up together, the side-of-desk model has run out of desk, and waiting longer has a price you can put a number to. Specialist replacement costs can exceed 200% of annual salary once you count recruitment, lost institutional knowledge, and the months of ramp time. The person carrying an unfunded AI mandate on top of a full role is exactly the kind of capable operator who leaves, and they take the only map of your AI estate with them when they go.
There is a wider pattern here worth naming. Around 56% of mid-market firms stall in what practitioners call pilot purgatory, cycling through experiments without anyone owning the move to production. The cause is rarely the technology. It is that nobody has the time, mandate, or accountability to push a working pilot into daily use and keep it there. A dedicated operational hire is how you break that loop, which makes the timing question one of readiness rather than appetite.
What about the genuinely technical hire?
A genuinely technical hire is the right call when an operational owner has confirmed a real model-building need, and not before. There are owner-managed businesses with a proprietary dataset or a bespoke product where a data scientist earns their keep from day one. If that is you, you usually already know it, because the value depends on something you cannot buy off a shelf. For everyone else, the engineer arrives too early.
The sequencing matters and the reporting line matters more. Research on mid-sized firms favours distributing AI ownership without creating bureaucracy or an isolated technical silo. So put the role in operations, with a direct line to whoever holds the AI mandate, and give it the authority to change how teams actually work. A specialist buried in IT with no operational reach builds clever things nobody adopts, which is the same failure the operational hire exists to prevent.
So get the operator in first. Let them run adoption, stand up the monitoring, and build the register. Then let them tell you, from inside the work, whether you ever need the engineer at all. That way you spend the one budget you have on the gap you genuinely have, and the technical hire, if it comes, lands into a business that knows what to do with it.
If you want a second pair of eyes on the spec before you post it, that is exactly the kind of decision worth talking through. Book a conversation.
