A COO takes on the AI mandate alongside their existing role. In the first month it looks manageable. By month four the work has expanded to vendor evaluations, board questions on AI risk, keeping pilots alive, and governance conversations that land with no clear owner. At some point the question arises whether this should have its own structure, and getting the answer wrong costs something in both directions.
What choice are you actually facing?
The real decision is narrower than it appears. You are weighing whether the AI work your business now generates has grown heavy enough to need a single, accountable owner, or whether bolting it onto an existing role is still a reasonable ask. The work typically includes tool governance, vendor management, adoption coordination, and board reporting. Both options carry a cost.
For many owner-managed businesses, AI currently sits between experiment and full operation. Tools are running, some are delivering value, and the business has moved past the question of whether to use AI at all. The question now is whether it has moved past the point where informal ownership works.
The answer depends less on the scale of your AI ambition and more on the volume and complexity of the decisions AI is now generating. A business running a small number of stable tools with a settled adoption curve can manage that work inside a wider operational brief. A business with multiple active tools, live pilots, board expectations on AI progress, and growing questions about data governance has a different situation entirely.
When should AI stay as a side-of-desk responsibility?
Side-of-desk AI management works when the volume is low and the stakes are settled. If your business is running a small number of stable tools, adoption is broadly accepted, and governance questions arise occasionally rather than continuously, there is no strong case for a permanent role. Adding headcount to a function that does not yet generate enough work to fill it creates overhead without creating capability.
Three signals suggest the current arrangement is still adequate. First, your AI activity is largely vendor-managed. Vendor-led implementations tend to have stronger completion rates than internal builds, and early-stage projects often do not need an internal specialist to own them. Second, the person currently carrying the AI brief is doing so without visibly compromising their primary role. If the work is genuinely sustainable alongside their day job, the case for a dedicated hire is not yet strong. Third, the business does not have sufficient AI decisions in the pipeline to keep a permanent role meaningfully occupied. A role that runs out of substantive work within a few months generates reports rather than results.
When does the AI work justify its own permanent role?
A permanent AI role starts to earn its cost when AI work becomes continuous rather than episodic. When there is a live programme to run, a set of vendors to manage, a governance layer to maintain, and a board that expects quarterly progress on AI, the informal arrangement breaks under the weight of those demands. One person cannot carry all of that alongside another job.
The role, properly scoped, has five functions. Someone needs to run the AI programme itself, maintaining an intake process so departments do not go off and commission tools independently. Someone needs to identify and prioritise the three to five AI opportunities with the strongest commercial case, updating that list as the business learns. Someone needs to own governance and risk, knowing what tools are in use, on what data, and under what policy. Someone needs to manage vendor relationships before those vendors manage the business. And someone needs to lead adoption, the human work of building enough trust that the team actually uses what the business has invested in.
When those five functions belong to no single person, they belong to everyone, and the result is fragmented tooling, inconsistent governance, and a board that gets different answers to the same question each quarter.
On reporting line, the role sits most effectively inside an operational brief, reporting to a COO or equivalent. A technology-line reporting arrangement tends to produce tooling decisions without adoption plans. A standalone role that sits outside any established leadership structure risks becoming a function that processes vendor contracts and produces quarterly dashboards without meaningfully moving the business forward.
What does getting this wrong actually cost?
The cost runs in two directions. Create the role before the work justifies it and you pay for a function that generates reports more than results, and risk building an AI silo the rest of the business routes around. Wait too long and you pay in pilot drift, fragmented tooling, and the gradual erosion of momentum when no one is keeping the AI agenda live.
The research on AI adoption is consistent on the failure pattern. A significant share of pilots show strong results in their test context, then stall at the boundary between experiment and operation. Ownership gaps are a primary factor. The pilot runs well under the attention of whoever championed it. Then that person moves on to the next priority, and the tool gets used inconsistently until it stops being used at all.
Creating the role too early carries its own risks. The most common is that an AI role placed inside IT generates a technology roadmap without an adoption plan. The team sees the output but not the value, and the role becomes a function that signs off on vendor contracts and produces quarterly updates rather than one that drives the business forward.
What should you settle before writing the job spec?
Before writing a job spec, you need clarity on what you are actually asking someone to own. An AI mandate that sits inside an IT function looks very different from one that reports to operations. A role built for delivery looks different from one built for exploration. Getting those parameters wrong produces a hire that is right for the wrong version of the job.
Four questions are worth settling first.
Is this role about running what you have or finding what is next? A delivery focus needs someone with operational credibility and change management experience. An exploratory focus needs someone comfortable with ambiguity and iteration. Few people are genuinely strong at both, and a job spec that asks for both often produces a long list of candidates who can talk to both and deliver on neither.
Does the mandate include genuine authority over technology decisions, or is this advisory? An AI lead who cannot say no to a weak vendor pitch or an underfunded pilot is held accountable for outcomes they cannot control.
Can the role be fractional or project-based to start? For many owner-managed businesses, a defined-scope arrangement tests whether there is enough AI work to justify a permanent hire before committing to one.
And is the founder genuinely ready to step back from AI decisions? A formal AI owner who operates alongside an informal AI decision-maker in the same business is set up to fail before they start.
The architecture of the role matters as much as the decision to create it. If you are working through this question and want a second perspective on how to scope the mandate, Book a conversation.
