7 Governance Failures Quietly Undermining AI Returns
The spend is real and the capability works. The return is rarely defensible, because nothing was set up to prove it before the money was committed.
- Most mid-market firms cannot prove what their AI spend returned. Not because it returned nothing, but because nothing was measured before it started.
- The seven failures below all happen before a single line of code is written. Each one is cheap to fix at that point and impossible to fix afterwards.
- The position worth holding is not “the AI is working”. It is “we measured before, we measured after, and here is the difference”.
A board asks what the AI spend returned. The honest answer, in most mid-market firms, is that nobody can say with confidence.
That is not because the spend was wasted. Capability got built, people use it, things are faster than they were. The problem is evidential. Nothing was measured before it started, so there is nothing to measure against now.
This becomes uncomfortable at exactly the moment it matters most: when the next round of investment needs approving, when an investor runs diligence, or when a board that funded the first wave asks what it bought.
The seven failures below all happen before anything gets built. That is the important part — each is nearly free to prevent at the business case stage, and none can be repaired once the work is underway.
No baseline was taken before anything changed
The single most consequential failure, and the most common. The case says a process will improve. Nobody measures how that process performs today, in a way anyone would accept later.
So when the question comes, the comparison is against an estimate someone made at the time, or against a period that differed for other reasons, or against a general sense that things are better. All of that is arguable and none of it is evidence.
The fix costs almost nothing at the right moment: measure the current process for a few weeks before the build starts, record the method, and store it. Attempting the same thing afterwards is reconstruction, and reconstruction is exactly what a finance director is trained to be sceptical of.
The case names a benefit but not the number it moves
Business cases say improved efficiency, better customer experience, faster decisions. All plausible and none measurable.
What is usually missing is the specific line on the management accounts that should change, by how much, by when. Without that, the benefit cannot be tracked because nobody agreed what tracking would look like.
The fix is a rule at approval: every benefit line names the number it moves and the person who owns that number. Cases that cannot do it are not ready. It is a small piece of governance that removes most of the argument later.
Nothing separates the AI effect from everything else that changed
The number improved. So did several other things during the same period. A process was tidied up. A team was reorganised. A supplier changed. The market moved.
Attributing the whole improvement to the AI overstates it. Attributing none of it understates it. Without a way of separating the effects, both positions are defensible and neither is provable, which means the conversation becomes about who is more persuasive.
The fix is to design for comparison at the start: a group or region that gets the change and one that does not, running in parallel long enough to see a difference. It costs a little complexity and it is the difference between a claim and a finding.
You cannot prove a return you never set up to measure. Everything after that point is argument.
The full cost was never assembled in one place
The build cost is known. What frequently is not, in one number, is everything else: licences, infrastructure, the cost of running it at volume, the data work, the internal time, the change effort, the ongoing engineering.
Those sit in different budgets and different periods. So when someone asks what this cost, the answer is the build figure, which is often a minority of the total.
Any return calculated against a partial cost is wrong in a flattering direction, which is the worst kind of wrong to be caught in. The fix is a total cost of ownership view per use case, maintained rather than assembled on request.
The baseline has to exist before the build. After that, it is reconstruction.
A free Executive AI Opportunity Assessment. Forty-five minutes, online, with your leadership team. We arrive with a model of how firms in your sector make money and where AI has moved those numbers — and you tell us where it is wrong.
Book a free assessmentReleased time was counted as saved money
The benefit case says the tool saves each person an hour a day. Multiply by the number of people, by the loaded cost, by the working year, and the number is substantial.
It is also usually wrong. An hour released is not an hour saved unless something happened to it. Either headcount came down, or the released capacity went into work that produced something, or it quietly absorbed into the day.
Finance directors know this instinctively, which is why time-saving cases get discounted heavily in the review. The fix is to state what the released time will be used for and to measure that instead — more output, less overtime, deferred hiring. Cases written that way survive scrutiny; the others get halved on principle.
Nothing measured before the change, so there is nothing to compare against afterwards.
Several things changed at once and nothing separates the effect of one from the others.
The build figure is known. Licences, running cost, data work and internal time usually are not.
Nobody returns to the case a year later to see whether the benefits actually arrived.
This describes a pattern rather than a measured dataset. The test worth running is your own: take your largest AI investment and see how long it takes to produce a defensible before-and-after. If it takes more than a day, the measurement was never designed in.
Nobody goes back to the case a year later
The case is approved. The thing gets built. It goes live. The programme closes and the team moves on.
What almost never happens is a review twelve months later comparing what was promised with what arrived. Not to allocate blame — to find out whether the assumptions held, and to write better cases next time.
Without it the firm never learns. The same optimistic assumptions get used again because nobody checked the last set. The fix is a standing post-investment review, scheduled at approval, with the finance director in the room. It is the cheapest quality improvement available to any investment process.
Three rules worth applying to the next AI case
- No approval without a baseline. If the current position has not been measured, the case is not ready — and measuring it takes weeks, not months.
- Every benefit names the account line it moves and the director who owns that line. If neither can be named, the benefit is a hope.
- Released time only counts if the case says what it will be used for. Otherwise discount it to nothing and see whether the case still stands up.
Nobody owns the return once the programme closes
The most structural of the seven. The programme has a sponsor and a delivery lead. Both are accountable until go-live. After that the budget closes and the team disperses.
The benefits, though, arrive months later — if the process changes stuck, if people adopted them, if the thing kept working. By then nobody is accountable for whether any of that happened.
So the return becomes nobody’s number. It is not reported, not reviewed, and not defended when someone asks. The fix is a named owner for the benefits, separate from the delivery owner, with a small budget and a reporting line that survives the programme by at least a year. Almost no mid-market firm does this, which is why almost none can answer the question.
What this means
None of these seven are failures of delivery. The capability got built and it usually works. They are failures of measurement design, and all of them happen before anything is built.
That timing is the whole point. A baseline costs a few weeks to establish and is free at the start of a project. It is impossible at the end. The same is true of naming the account line, designing a comparison, assembling the full cost, and appointing someone to own the benefits after the programme closes. Each is nearly free before, and either expensive or impossible after.
What makes this urgent is that boards have stopped taking AI on faith. The first wave was funded on potential. The next round will be funded on evidence, and firms that cannot produce it will find the conversation harder than they expect.
Which is why we say it in this order. Change the work before you change the technology — and decide how you will prove the return before you commit the money, because afterwards you are not proving anything. You are arguing.
Could you produce a defensible before-and-after on your largest AI investment?
Forty-five minutes with your leadership team, online, at no cost. We bring a working model of how firms in your sector make money and where AI has moved those numbers. You tell us where it is wrong. Then we tell you what we think — including “don’t invest”, if that is the honest answer.
Book a free assessment45 minutes · online · no cost · nothing to prepare
Continue reading
10 Operating Model Signals That Your AI Is Producing Growth
What separates AI producing return from AI producing activity.
For IT and finance directors9 Signs Your AI Programme Is Creating Governance Risk
The risks building up inside programmes that still report green.
For finance directors11 Pressures Mid-Market CFOs Are Quietly Managing
Structural rather than personal, which is why working harder does not help.