Key takeaways
Most organisations cannot show AI's financial impact because they didn't measure the process before AI touched it. There is no baseline and no proof, only whatever the demo happened to show.
A shared platform, data layer, or integration team gets judged on its own weak return, while the use cases that depend on it get judged on theirs. Both numbers are wrong.
Pilots often scale not because they proved themselves, but because nobody wrote down what success meant before the results came in. Without that threshold, almost any outcome can be narrated as a win after the fact.
Business cases built around a single optimistic number are usually borrowed from someone else's benchmark. Working in a range instead, a best case and a conservative case, and planning around the conservative end is a much better discipline.
The organisations converting AI into EBIT price it as a portfolio, with one person accountable for the financial outcome, not a stack of independently defended pilots.
The single decision that determines whether AI transformation compounds or stalls is ownership: who is accountable for the portfolio's financial result, with the authority to stop what isn't working.
For mid-to-large enterprises modernising legacy systems, adopting AI/ML, and optimising cloud operations across sectors such as finance, insurance, utilities, media, automotive, and healthcare, that gap is expensive. It turns promising pilots into fragmented investments that fail to translate into enterprise-level EBIT impact, even when delivery quality improves.
BARC and Domino Data Lab put a number on it: 57% of enterprises still report that AI returns fail to outpace investment, a figure that hasn’t moved since 2025, even as 93% say their AI is now running in production more reliably. McKinsey found that only 39% of organisations can attribute any enterprise-level EBIT impact to AI at all, and most of that group is attributing less than 5%. While production quality went up, the line connecting it to profit didn’t move.
Why does strong use-case AI ROI so rarely add up to enterprise return?
Why does strong use-case AI ROI so rarely add up to enterprise return?
These days, I rarely see a client walk in with a list of successful pilots. More often it’s a list of pilot ideas, alongside the harder task of identifying which use cases across the organisation are worth piloting. What I do see a lot of is fragmented, ungoverned experimentation: teams trying tools independently of IT oversight, often without a clear plan to calculate AI ROI, or anyone above them knowing the scale of it.
When a pilot has already run, my first question isn’t about the result. It’s simpler: show me the state of the process before the pilot started, measured, with a source. If that baseline doesn’t exist, there’s no way to prove the pilot moved the financial result, only that it made a good impression. That distinction matters because there are three warning signs worth watching for early, and none of them require waiting for a quarterly report.
Three warning signs a pilot won’t scale:
- Success measured in activity, not outcome. “80% of the team is using it” describes adoption, not value.
- The pilot is owned by IT or an innovation function, rather than the process owner who carries P&L responsibility for the workflow.
- The benefit is expressed purely in hours saved, with nothing said about what happens to those hours.
That last one trips up more programmes than people expect.
A pilot proves the technology works, but it doesn’t prove the organisation can benefit using it. Those are two different proofs, and most organisations only collect the first.
Research from MIT’s Project NANDA adds a useful complication here. Their widely cited finding, that 95% of generative AI pilots show no measurable profit-and-loss impact, is often read as a verdict on the technology. It isn’t quite that. The researchers point to a learning gap (tools that don’t retain feedback and need constant re-briefing) and poor integration with existing workflows as the dominant causes, alongside the missing baseline. Put those together and you get a fuller picture: the tools frequently aren’t wired into how work gets done, and even where they are, nobody wrote down what “before” looked like.
Why do shared capability costs make every AI business case look better than the portfolio really is?
Why do shared capability costs make every AI business case look better than the portfolio really is?
Here’s a pattern I see repeatedly in organisations that later say AI “isn’t paying off”: they defund exactly the initiatives that were never supposed to carry their own return. These were meant to be the foundation everything else stood on.
A foundational capability, a shared data platform, an integration layer, a clean system of record, rarely shows an impressive ROI on its own. It’s infrastructure, and its real cost is usually wider than it looks on paper, once you count data preparation, employee training, licensing, and ongoing maintenance alongside it. Its job is to make several other use cases faster, cheaper, or possible at all. When it gets evaluated with the same yardstick as a standalone use case, it loses, and it’s often the first thing cut in a cost review, precisely because nobody can point to a P&L line that’s exclusively its own.
Cost data backs this up. FinOps Foundation research found that 98% of practitioners now actively manage AI spend, up sharply from 63% a year earlier, yet on average they can only attribute 40 to 60% of that spend to a specific team, product, or use case. The organisation knows the total. It doesn’t know who’s accountable for it.
In practice, the clearest tell isn’t the invoice, it’s who’s asking about it:
- Who’s asking the cost question. When “how much are we actually spending on AI?” comes from the CFO rather than the CTO, the organisation is already behind; a healthy one knows that figure before anyone has to ask.
- Cost that can’t be traced to an owner. If an invoice can’t be linked to a team or process, nobody can decide what to switch off, and cost management degenerates into renewing subscriptions on autopilot.
- The same task, built three times. An example of this would be an OCR (Optical Character Recognition) step or a document classifier duplicated across teams who never compared notes, visible on a use-case inventory long before it shows up in the numbers.
- Nobody can name who retires a tool. Ask who has the authority to shut down something nobody’s using. Silence is your answer.
How does toolchain fragmentation quietly erode ROI of AI initiatives as you scale?
How does toolchain fragmentation quietly erode ROI of AI initiatives as you scale?
The maths here is unforgiving. One use case might need integrations across five tools. Ten use cases create roughly fifty integration points. A hundred becomes something no organisation maintains without a dedicated team, and by then the fragmentation isn’t a cost centre, it’s a constraint on everything else.
Deloitte’s 2025 research on this is blunt: organisations lagging on AI ROI share fragmented toolchains that need constant manual intervention, while the ones seeing measurable returns have invested in integrated platforms instead. That’s the direct mechanical result of the combinatorics above, and it’s why fragmentation shows up not as a flat plateau but as a reversal: every additional point-to-point integration is another thing that can break silently, another place where cost stays invisible until someone reconciles it, another reason the same task gets rebuilt because nobody trusts, or can find, the existing version.
Why does the "impressive pilot" trap keep ROI of AI investments trapped at the use-case level?
Why does the "impressive pilot" trap keep ROI of AI investments trapped at the use-case level?
The most common reason a pilot scales when it shouldn’t isn’t that the pilot itself was bad. Instead, it’s a success criterion written after the results were already in. If the threshold wasn’t recorded at the start, almost any outcome can be narrated as a win, and often is.
There’s a related pattern worth naming carefully, because it’s less about any one person’s judgement and more about how optimism compounds through a programme. When a business case is built around a single target number rather than a range, that single number is usually a sign nobody calculated it, it was borrowed from a competitor’s press release or an industry benchmark and presented as a plan.
Deciding on the conservative end of that range, rather than anchoring to the best case, is a small discipline that prevents a great deal of downstream disappointment. It also leaves visible room to keep improving the result through better adoption, better data, and better tuning, rather than treating the first outcome as the ceiling.
This isn’t only an AI-industry problem, either. Reports on enterprise AI programmes describe organisations running dozens, sometimes hundreds, of parallel pilots with no shared evaluation criteria between them, more activity than accountability. And the well-known case of Klarna is a useful cautionary tale for the opposite failure mode: a pilot that scaled successfully by one measure (resolution volume, cost per interaction) while the metric that mattered to customers, service quality, went unmeasured until it had visibly degraded.
The company later walked part of it back and rehired staff. The lesson isn’t that the pilot was wrong to scale. It’s that “success” was defined narrowly enough that the real cost only became visible after the fact.
What separates the enterprises that convert AI ROI into EBIT from those that don't?
What separates the enterprises that convert AI ROI into EBIT from those that don't?
BCG’s research on the AI value gap found that “future-built” companies, just 5% of the 1,250 firms surveyed, show 1.7 times the revenue growth and 1.6 times the EBIT margin of slower-moving organisations. Many assume the edge comes from running more pilots. It doesn’t. What actually separates future-built companies from the rest is integrated data environments, a defined roadmap, formal governance, and a culture that’s actually ready to adopt the change, not just approve it.
AI Readiness Assessment
Gain a clear view of how prepared your data is to support and scale AI initiatives in your organisation.
JPMorgan is the scale example most people already know, running several hundred AI use cases on a single unified data platform, with a stated goal of reaching a thousand by the end of 2026. DBS Bank is a less-cited but sharper illustration of the mechanism: a shared data and reusable-AI infrastructure that cut time-to-market for new use cases from roughly fifteen months to under three, precisely because each new case wasn’t starting from zero, with shared capabilities reused rather than rebuilt for each one.
What we see in the organisations that pull this off, at the scale we typically work with, mid-sized and larger businesses rather than sprawling multinational corporations, comes down to three habits:
- They count in portfolios, not individual cases. One list, one consistent structure for valuing each entry (baseline, value, impact on EBITDA, whether it sits in OPEX or CAPEX), so cases are genuinely comparable rather than each defending its own narrative.
- They treat enablers as enablers. A foundational case (data quality, integration, a clean registry) doesn’t get ranked below the cases that depend on it, even when its own standalone return looks weak on paper.
- Accountability sits with the process owner, not the technology owner. The same person who signs off on scaling is the person who answers for the result a year later.
What governance and measurement changes actually shift AI ROI to the enterprise level?
What governance and measurement changes actually shift AI ROI to the enterprise level?
Sixty-five percent of CEOs already say their organisation prioritises use cases based on ROI. Yet in the same survey, only 25% of AI initiatives actually delivered the expected return, and just 16% scaled enterprise-wide. Saying the right thing about prioritisation and actually doing it turn out to be two different disciplines.
The metrics worth tracking split cleanly by altitude:
- Company level, quarterly: consolidated EBITDA impact from the AI portfolio (not a sum of individual promises); total AI cost alongside the percentage of it actually attributed to an owner; the count of use cases in production versus deliberately stopped; average time from idea to a scale-or-stop decision.
- Portfolio level: payback period per case, the OPEX-to-CAPEX structure, and the share of cases resting on a hard, system-derived baseline rather than a declared one.
- Use-case level: what most teams already track, accuracy, handling time, volume. This layer was never the problem, but measuring ROI here means separating technical performance from operational impact, so model quality doesn’t get mistaken for business value.
£1B+ in bookings, 90% of campaign parameters automated
ITV needed an ad management platform that removed manual work without adding complexity. We built Planet V with two cross-functional teams. It now serves 1,000+ monthly users and 200+ agencies, with ML forecasting that beats human predictions by 20%.
How do you calculate AI ROI at portfolio level?
How do you calculate AI ROI at portfolio level?
The formula itself is simple: net financial gain from AI, divided by total cost of implementation. What trips organisations up isn’t the maths, it’s what goes into each side of it, and whether it’s applied consistently.
Applied to a single use case, this calculation is straightforward and most teams already do it reasonably well. Applied to a portfolio, it means running the same calculation across every case with one consistent structure, so a foundational capability’s real cost and a dependent use case’s real benefit aren’t double-counted or missed entirely. That consistency, more than the formula itself, is what turns a collection of individually plausible numbers into a business objective the organisation can be held to.
What should leadership do differently to stop AI ROI stalling at the use-case level?
What should leadership do differently to stop AI ROI stalling at the use-case level?
If I had to name one decision that determines whether all of the above happens, it’s this: assign ownership of the outcome. Business leaders should treat AI as a portfolio decision, not a loose collection of pilots: a named person, with P&L accountability, responsible for the AI portfolio’s financial result, and with the authority to stop initiatives that aren’t earning their place.
The reason this decision matters more than strategy documents, platform choices, or governance frameworks is straightforward. Strategy can be written. A platform can be bought.
Everything in this piece points back to that same decision, in different clothes:
- Fund the shared platform as infrastructure, not as a use case competing for its own ROI line.
- Apply a real gate before scaling, built on evidence rather than a good demo and a confident sponsor, and account for shared and duplicated costs honestly.
- Treat the whole AI estate as a portfolio with one accountable owner, not a collection of pilots each defending its own existence.
The organisations that get past the use-case ceiling aren’t the ones with the most AI activity. They’re the ones that decided, early, who has to answer for the result.
FAQ
What counts as a good baseline for measuring AI ROI?
A baseline is the process’s performance measured before AI touched it, with a source you can point to, not a recollection or an estimate. It should be specific enough to compare against later, using the same KPIs before and after deployment so any change can be tied back to a cause: cost per unit of work, cycle time, error rate, or whatever the process’s core output actually is. Without it, any post-implementation number is a claim, not a result.
Why do AI pilots succeed technically but still fail to show ROI? hat role does AI play in digital transformation?
Most often because success was measured in activity (adoption, usage, hours saved) rather than a financial outcome tied to cost or revenue, and because there was no baseline to compare against. IBM’s 2025 CEO study found that only 25% of AI initiatives delivered their expected ROI in recent years, and just 16% scaled enterprise-wide. A pilot can prove the technology works perfectly and still leave the organisation unable to demonstrate what that was worth.
How is portfolio-level AI ROI different from use-case ROI?
Use-case ROI asks whether one initiative paid for itself in isolation. Portfolio ROI asks whether the AI estate as a whole, including shared infrastructure that individual cases lean on but don’t pay for directly, produced a net financial result, calculated by weighing total costs against total benefits across the estate, not just one pilot. A portfolio view is the only way to avoid foundational capabilities being cut for lacking a return they were never meant to show alone.
What AI ROI metrics should leadership track?
At minimum: consolidated EBITDA impact from the AI portfolio, total cost tracked consistently across licensing, cloud infrastructure and maintenance, the share of that cost attributed to a named owner, the number of use cases in production versus deliberately stopped, and average time from idea to a scale-or-stop decision. The number of pilots stopped on purpose is a particularly good signal of whether measurement is real.
Who should own AI ROI in an enterprise?
Ideally a single person with P&L accountability for the AI portfolio’s financial outcome, and the authority to stop initiatives that aren’t earning their place. Ownership sitting with the process owner rather than the technology function tends to produce more honest, more durable results, especially when that owner also oversees adoption and the full cost of running what’s been built, not just the cost of building it.
