Who should own AI in a company?

One named person, with a budget line, a reporting slot on the board agenda, and no ability to hand the problem sideways. Not a committee, not a steering group, and not a new Chief AI Officer. In a business of 50 to 10,000 people the right answer is almost always the COO or the Managing Director, because AI outcomes land in process and in people, and those are the two things a COO already controls. The CIO or CTO owns the platform underneath. That is a different job.

The reason the answer feels unsatisfying is that nobody owns it today, in most companies, and that is structural rather than careless. AI outcomes sit across data quality, process design, staff capability, tooling, commercial strategy and risk. Six owners. Every one of them can say, accurately, that the thing is not solely theirs. McKinsey found that only 28% of organisations place direct AI governance ownership with the CEO, and 17% with the board. Which leaves a majority of companies where governance ownership sits somewhere further down, or in several places at once, which is the same thing as nowhere.

Why ‘nobody’ is the default, not the exception

Think about how an AI project actually fails in a 600-person business.

Someone in operations wants invoice processing automated. The tool works in a demo. Then it turns out the supplier master data has three versions of the same company name, so IT says the data needs fixing. The data owner, if one exists, says the duplicates came from a 2019 acquisition that finance never cleaned up. Finance says they flagged it at the time. Meanwhile the ops team that wanted the tool has no authority over any of this, and the project sits in a queue for seven months.

Nobody lied. Nobody dodged. Each function described its boundary correctly. The failure happened in the space between the boundaries, and there was no owner of that space.

This is why committees do not fix it. A steering group is a mechanism for distributing a decision across people who each have a partial view and a legitimate reason to defer. It generates minutes. It does not generate an owner. If your AI steering group has met four times and the pilot is still a pilot, the group is working exactly as designed.

The evidence that this is widespread rather than a local embarrassment is reasonably blunt. Infosys surveyed over 1,000 senior executives at large US companies and found 72% said fewer than a quarter of their AI pilots had scaled to full production while delivering the intended ROI. Pilots do not fail because the model is weak. They stall at the boundary between functions, which is precisely the territory an owner would have to cross. I have written separately on the four ways pilots die between proof of concept and production.

Why appointing a Chief AI Officer usually changes nothing

The tempting move is to create a role. Do we need a chief AI officer? Almost certainly not, and here is the mechanism by which the appointment fails.

A new C-level officer arrives with a mandate and no operating authority. They do not own the data platform. They do not own the process owners. They do not sign off hiring in the business units where the work happens. They own a remit. So they do what anyone would do in that position: build influence, run a programme office, produce a roadmap, and escalate when a function will not move. Which means every real decision still routes back to the COO or the CIO, except now with an extra layer and a defensible reason for delay.

There is a second failure mode, quieter and worse. Creating the role lets everyone else off. The CFO no longer has to think about whether finance data is fit for a model, because that is now the Chief AI Officer’s problem. The ownership vacuum has not closed. It has been relabelled and given an office.

A title is only worth something if it comes attached to the three things that make accountability real: control of a budget, authority over the people who do the work, and a standing obligation to report outcomes to the board. If you can give a new CAIO all three, you have not created an AI role, you have created a second COO. If you cannot, you have created a scapegoat with a nice business card.

There are companies where a dedicated AI leader makes sense. Businesses where the product itself is a model, where there is a research function to run, or where regulatory exposure is severe enough to warrant a named individual at board level. Mid-market services firms automating back-office work are not in that category, whatever the conference circuit says.

The pressure that keeps the vacuum open

Two numbers explain why this does not get fixed by itself.

PwC’s 2026 Annual Corporate Directors Survey found that 82% of directors rate the information linking AI outcomes, risks and business performance as fair, poor, or not provided. So the board cannot see what is happening, which means it cannot ask a precise question, which means it asks a vague one. Vague questions get vague answers.

And a survey of over 500 technology leaders found 79% feel pressure to overstate AI progress, with nearly half saying that pressure comes from the C-suite or the board. Put those two together and you get a reporting loop that rewards performance over progress. An under-informed board asks whether AI is being taken seriously. A technology leader with no authority over outcomes reports that it is. Everyone leaves the room satisfied, and the invoice processing project is still in a queue.

An owner breaks that loop, because an owner can be asked a question that has only one true answer. Not ‘are we doing AI’, but ‘what shipped, what did it cost, what changed in the P&L’. You can refuse to answer that once. Twice is a career event.

The one-page test for naming an owner this quarter

Run this on paper. It takes longer to argue about than to complete, which is the point.

1. Write one name. No slashes. No ‘IT and Ops’. No committee. If you cannot write a name without qualifying it, you have found your problem and it is not a technology problem.

2. Check they control process. Can this person change how work is done in at least three departments without asking permission? If no, they cannot deliver an AI outcome, because every AI outcome is a process change wearing a software costume.

3. Check they have a budget line. Not access to a project fund. A line they own, that shows up in their numbers, that they will be asked about at year end. Ownership without money is advocacy.

4. Check they can say no. The owner must be senior enough to kill a pilot that a department head is emotionally invested in. If they cannot stop things, they cannot sequence anything, and you will end up running eleven pilots badly.

5. Check they are on the board agenda. A named, recurring slot. Fifteen minutes, quarterly, minimum. Not a line in the CIO update. If the owner only appears when something goes wrong, they will manage to avoid appearing.

6. Name the five people they can compel. Data, process, people, technology, risk, and whoever owns the commercial case. Write their names next to the owner’s. These are not committee members. They are people the owner can require to deliver by a date. Being clear about this in advance stops the first real escalation turning into a negotiation about authority.

7. Write the first question the board will ask them in 90 days. One sentence. Specific enough that a yes or no is possible. If you cannot write that question, the accountability is still theoretical.

Seven lines. If all seven survive contact with your actual org chart, you have an owner. If three of them fail, you have discovered what you need to fix before you buy anything, which is more useful than a roadmap.

What the owner does in their first quarter

Not strategy. Diagnosis, then one thing finished.

The first job is to find out where the business actually stands, which is harder than it sounds because the honest answer lives in several heads and none of them has been asked. Run the question from our data pillar on your own team: if you needed a clean, accurate list of your best 500 customers this afternoon, how confident are you in what would arrive, and how long would it take? Time it. The gap between the answer people give in a meeting and the answer the system gives by Thursday is the real starting position. We go into this in more detail in the data readiness checks worth running before you adopt anything.

The second job is to pick one use case and take it all the way to production, including the unglamorous parts: the data cleanup, the process documentation, the training, the sign-off on who is liable when the model is wrong. One finished thing teaches the organisation more than six pilots, and it gives the owner something to put in front of the board that is not a slide. Getting one use case done properly is the whole of the first quarter.

The third job is to report honestly, including the bad bits. This is the hardest of the three, because the incentive structure described above pushes the other way.

If you are reading this because you are the owner

You probably already know, in the way people know these things, that the job has quietly landed on you without anyone saying so. That is the common case in a mid-market business. The CEO assumes you have it. You assume there is a plan somewhere. There is not.

Start with the diagnosis rather than the plan. Our free AI readiness audit is 30 questions across six pillars, Data, Process, People, Technology, Strategy and Governance, and takes 7 minutes. It gives you a score out of 120, a band for each pillar and a short synopsis. It does not give you an action plan, and it does not look at your systems, because every answer is self-reported by you. What it does do is tell you which of the six pillars is holding you back, in writing, which is a more useful thing to take to a board meeting than a conviction.

Then write the name. Yours, if it is yours.