Why do companies need AI governance, and who owns it?

Companies need AI governance for one reason that survives contact with reality: so that when an AI tool produces a wrong answer, leaks something it should not have, or quietly makes a decision nobody authorised, there is a named person whose job it is to deal with it. Not a committee. Not a policy document. A person, with a name, who knew in advance that this was theirs.

As for who owns it: in most organisations today, the answer is whoever bought the tool. Schellman’s 2026 State of AI Governance Report found 42% of organisations place AI purchasing and adoption authority with the CIO or head of IT, 16% with a Chief Data Officer or AI Officer, and only 10% with the CEO (Schellman). The more useful finding in that report is not the split. It is that in most of these organisations, the same executive who decides to bring in an AI tool is also the person held accountable if that tool creates a compliance failure. Schellman calls this a single point of failure rather than a governance structure, and that is the correct description.

Governance is not compliance, and confusing the two is why nobody owns it

When most boards hear “AI governance” they hear compliance. Frameworks, registers, a policy PDF, someone from legal presenting slides. That framing is why the job keeps getting pushed to whoever seems most adjacent to regulation, and why it then sits untouched.

Compliance answers the question: does this meet the rules that already exist? Governance answers a harder and earlier question: who decided this, on what evidence, and who carries it if the evidence was wrong?

The difference matters because the failure modes are different. A compliance failure is discovered by an auditor. A governance failure is discovered by a customer, a journalist, or a regulator, and the first thing anyone asks is who signed this off. If the honest answer is “the IT director bought it, marketing started using it, and nobody told the board,” you do not have a compliance problem yet. You have a governance problem that will become a compliance problem on a timetable you do not control.

Grant Thornton’s 2026 AI Impact Survey found 78% of business executives lack strong confidence they could pass an independent AI governance audit within 90 days (Grant Thornton). Read that number carefully. It is not 78% of executives admitting they are non-compliant. It is 78% admitting they do not know whether they are, which is a statement about ownership, not about rules.

The buyer and the blamed party are usually the same person

This is the structural flaw in how most mid-sized companies have ended up running AI, and it happened by accident rather than design.

Someone needed a tool. The CIO or IT director had the budget line, the vendor relationships and the technical literacy to evaluate it. So they bought it. Nobody objected, because nobody else wanted the job. Eighteen months later, the same person is the one being asked why a customer received an automated decision that cannot be explained.

That arrangement fails for a reason that has nothing to do with the competence of the individual. A person cannot meaningfully govern their own purchasing decisions. Every incentive in the role points towards the tool working. When the first ambiguous signal arrives, a version of the question “is this bad enough to escalate?” gets answered by the one person who has the most to lose from escalating it. That is not a character flaw. It is what happens when you put buying authority and accountability in the same pair of hands.

The number that makes this urgent rather than theoretical is the one from PwC’s Global CEO Survey: 56% of CEOs report seeing neither revenue gains nor cost reductions from their AI initiatives, from 4,454 CEOs across 95 countries, with only 12% achieving both (PwC). Spend is happening. Proof is not. In that gap, the pressure to keep quiet about a tool that is underperforming is enormous, and it lands hardest on the person who chose it.

Separating the two roles does not require a reorganisation. It requires one decision: the person who approves the purchase is not the person who reports on whether it is working. I have written more on how that separation actually gets drawn in who owns AI outcomes in a company.

Do you need a Chief AI Officer?

Almost certainly not, if you are between 50 and 10,000 people.

The argument for the role is that AI cuts across functions, so it needs a cross-functional owner. That is true. The argument against is that creating a new C-level role to own something the existing C-suite has been avoiding does not change the avoidance, it just gives it an office. The new officer inherits responsibility without inheriting authority over the budgets, the data or the teams where the actual decisions get made.

A Chief AI Officer earns its keep when you have multiple business units each running their own AI programmes with genuinely competing priorities, and someone needs standing authority to arbitrate. Below that scale, the role usually becomes a heat shield. Something goes wrong, the CAIO absorbs it, and the operating model that produced the problem stays exactly as it was.

What you need instead is narrower and less glamorous: a named accountable executive per AI use case, sitting on the existing exec team, with the CEO or MD as the backstop for anything that crosses functions. Named, not implied. Written down, not understood.

The ownership test you can run in one meeting this week

This takes about twenty minutes and does not need preparation. Put it on the next exec agenda.

Step one. List every AI tool anyone in the business is using. Not the ones you approved. All of them. Include the free ChatGPT accounts, the AI features switched on inside tools you already pay for, the transcription tool someone in sales expensed. You will not get a complete list on the first pass. You will get an uncomfortable one, which is the point. If you suspect the list is longer than anyone will admit, shadow AI at a 500-person company is worth reading before the meeting.

Step two. For each one, ask the room to name the person accountable if it causes a failure. One name. Not a department, not a committee, not “IT would handle it.” A person who could be called at seven on a Sunday evening. Write the names on the board.

Step three. Now ask who bought each one. Write those names next to the first set.

Where the two names match, you have Schellman’s single point of failure. Where the second column has a name and the first is blank, you have a tool in production that nobody owns. Both need fixing. The second is more urgent.

Step four. For anything with no name in the first column, assign one before the meeting ends. Not after. The whole reason this is unresolved in most companies is that assigning it always feels like it can wait until the policy is written. It cannot, and the policy is easier to write once someone has a reason to care about it.

Step five. Ask the named owner one question each: what would have to be true for you to recommend we switch this off? If they cannot answer, they do not yet own it in any way that will hold under pressure. Give them two weeks.

That is the whole test. No framework, no maturity model, no external facilitator. What it produces is a short list of names and gaps, which is more governance than most companies of this size currently have written down anywhere.

Why governance has to come before the next purchase, not after

The standard sequence is: buy the tool, run the pilot, and sort out governance when it scales. That sequence is why so little scales.

A March 2026 survey of 650 enterprise technology leaders found 78% of enterprises have AI agent pilots but under 15% reach production (Digital Applied). Pilots run on hand-picked data, hand-picked people and no governance, because a pilot with governance attached is slower and less likely to produce the result its sponsor wanted. Then it comes time to put it in front of real customers with real data, and every question that governance would have answered up front gets asked at once, by people with veto power. The pilot does not fail on the model. It fails on nobody having decided who signs.

The RAND breakdown of enterprise AI failure puts numbers on where it actually goes wrong: 80.3% of enterprise AI projects fail to deliver promised business value, with 33.8% abandoned before production, 28.4% reaching production but underdelivering, 18.1% running but never recovering their investment, and 19.7% delivering (AI Assembly Lines). A third are abandoned before they ever face a customer. That is a decision-making failure, not a technology one.

Governance before purchase is cheaper for the same reason data quality before purchase is cheaper. Fixing it later means unpicking commitments people have already made publicly. If you want the data version of that argument, dirty data is the cheapest AI mistake to fix first.

What good looks like at 500 people

Four things, written down, reviewed quarterly.

A register of every AI tool in use, with the accountable owner’s name against each. A rule for what has to be escalated and to whom, which should be short enough to remember without looking it up. A standing agenda item at exec level, fifteen minutes, where those owners report what is working and what is not. And a clear statement of what you will not use AI for, which is the thing most companies skip and the thing that protects you most when someone proposes a use case that feels clever and is actually indefensible.

None of that requires a consultant. It requires someone senior enough to insist the names get written down and stay written down.

If you want to know where governance sits relative to the rest of your position, the free AI readiness audit asks 30 questions across Data, Process, People, Technology, Strategy and Governance, takes 7 minutes, and gives you a score out of 120 with a band for each pillar. The Governance questions include who is accountable when an AI tool produces a bad outcome, which is the same question as step two above. Most people answer it slower than they expect to.