Economists Anders Humlum and Emilie Vestergaard did something most AI ROI studies never bother with. They took the adoption survey answers of roughly 25,000 workers across 7,000 Danish workplaces and matched them against actual payroll records. The AI worked. It saved about 2.8% of working hours, near enough to an hour a week per person. Then they looked at what happened to earnings and hours.
Nothing. No significant impact, in any occupation.
That gap between the hour that was saved and the money that never appeared is the whole problem with how enterprises measure AI today.
How to measure AI ROI, and why most attempts collapse
Ask a room of IT leaders how to measure AI ROI and you get a variation on one answer: count the hours the tool saves, multiply by a loaded labour rate, present the total. It is the number that fits in a board slide, so it is the number that gets built.
It is also the number that gets picked apart the moment a CFO reads it carefully, and rightly so. MIT's Project NANDA reported in 2025 that 95% of organizations saw zero return against something like $30 to $40 billion of enterprise AI spend. That statistic gets quoted as an indictment of the technology. I read it as an indictment of the measurement. Plenty of those deployments genuinely worked in the narrow sense that the Danish study describes. They saved time. They just never converted the time into anything that showed up in a financial statement, and nobody had instrumented the workflow well enough to notice the difference.
You cannot fix that with a better slide. You fix it by changing what you count and when you start counting.
Hours saved is not value
Here is the claim I will defend, and I know it is not a popular one with anyone who has already presented an hours-saved business case: a saved hour is not a benefit. It is an option on a benefit, and most organizations never exercise it.
Think about where a recovered hour can actually go. It can be resold, if the person is billable and there is demand waiting. It can absorb work you would otherwise have hired for, which shows up as a role you did not open. It can raise throughput, if the constraint you relieved was the real bottleneck and not a step upstream of it. Or, and this is the common case, it can quietly dissolve into the working day.
The Danish payroll data is the cleanest evidence I have seen for that last outcome. The hour was real. The pay and the hours worked did not move. The value leaked out somewhere between the workflow and the ledger, and no dashboard in the company was pointed at the leak.
The customer support numbers cut the same way but land differently. In one field study of 5,179 agents, AI assistance raised resolved issues per hour by 14% on average, and by 34% for the newest agents. That is a genuine productivity gain, and it converts to money cleanly, because a support organization has a queue. Throughput against a queue is real. Throughput against an empty afternoon is not.
Same technology. Same hours saved. Completely different ROI. What separates them is not the model, it is whether a constraint existed on the other side of the saving.
The four tests an AI ROI number has to survive
Before you take a number to a board, run it through these. If it fails one, you do not have a result. You have an anecdote with a decimal point.
The baseline test. What was the metric before the AI, measured the same way, by the same instrument? Not remembered, not estimated afterwards. If you cannot produce a pre-AI number captured by the same method, you are comparing today's careful measurement against yesterday's impression, and that comparison always flatters the AI.
The attribution test. What else changed in the window? New process, new staff, a seasonal swing, a pricing change. AI is usually deployed into an organization that is busy doing five other things to the same workflow. If you cannot separate the AI's contribution from the rest, say so in the number rather than quietly absorbing the credit.
The leakage test. Where did the saving actually go? Name the destination: a role not backfilled, a queue drained faster, a contract absorbed without added headcount, revenue from capacity that was previously refused. If the honest answer is "people had more time," you have found the leak. That is a finding worth reporting, and it is more useful than a fabricated dollar figure.
The run-cost test. What does the thing cost to operate now that it is live? Inference, retries, the retrieval layer, the humans reviewing outputs, the engineers on call. Pilot economics almost never survive contact with production volume, and AI costs are unusually good at hiding across a dozen accounts. This is where AI tool sprawl turns into a measurement problem rather than a procurement one, because you cannot compute a return when the denominator is scattered across teams nobody has consolidated.
A number that clears all four is defensible. In my experience it is also smaller than the number the vendor gave you, and far more useful, because you can build a second use case on top of a number you trust.
Instrument the use case on day one, or argue from anecdote later
The single most consequential decision in an AI ROI story gets made before any model is chosen. It is whether the use case ships with measurement built into it.
Almost nobody does this. The pilot is scoped as a technical proof: can the model do the task. Measurement gets deferred to "once we see if it works," which means the baseline is never captured, and by the time someone asks for the ROI number the pre-AI world no longer exists to measure. So the team reconstructs it from memory, and reconstructed baselines are how you end up with an executive who does not believe you.
Retrofitting measurement onto a live AI workflow is not a small piece of work. It is a rebuild. You need per-request cost attribution, you need the workflow's business outcome joined to the AI's involvement in it, and you need the before-state, which by then is gone.
This is why Difinity starts an engagement at the use case and the proof rather than at the platform. We pick the workflow where a constraint genuinely exists, agree what the pre-AI number is and how it will be captured, then build the thing with that instrumentation in place from the first commit. The controls that make the AI safe to run in a regulated environment, the logging, the interception, the audit trail, are the same substrate that lets you prove what it did. Governance and value measurement are the same plumbing viewed from two ends. That is not a coincidence, and it is the reason a control layer belongs in the delivery path rather than bolted on after the fact. Teams who put it in afterwards are the ones who end up with an AI in production that nobody can account for, which is the same failure mode that keeps AI agents from ever shipping in the first place.
If you want a second pair of eyes on which of your use cases can actually carry a defensible number, that is most of what we do in the Free AI Value & Readiness Assessment: pick the workflow with a real constraint behind it, and map what it takes to get it into production with the measurement and the controls in place.
What good measurement looks like in practice
Take a claims triage workflow at an insurer, the kind of use case that comes up constantly in financial services and healthcare, where we do most of our work.
The weak version: AI reads the claim, drafts a summary, adjusters report it saves them twenty minutes each. Twenty minutes times the team times the year, times a labour rate. A large number, and a fragile one.
The version that survives a CFO: the queue had a measured backlog and a cycle time before the AI went in, captured by the claims system, not by a survey. After deployment, cycle time is measured by the same system. The AI's involvement is logged per claim, so you can compare handled-with-AI against handled-without in the same period, which handles attribution. The saving has a named destination, which is that the backlog cleared without the two contractors the team was about to hire. Against that sits the run cost, tracked per request, including the adjusters' review time on AI drafts, which turned out to be the second largest line.
Now you have a number. It is probably less than the twenty-minutes version. But it is a number the CFO can put in a plan, and that is the difference between one shipped use case and a programme.
The second version is only possible because someone decided, before writing any code, that the claims system would be the instrument. That decision costs almost nothing on day one. It is close to unrecoverable on day two hundred.
[YOUR TAKE: replace this paragraph with something you have actually seen. Prompt: think of the last time a client's AI business case fell apart in a room, or the last time one held up. What was the specific thing that made the difference? A missing baseline? A saving with nowhere to go? An executive who asked the one question nobody had prepared for? Keep it concrete and keep your edge; do not soften it.]
Frequently Asked Questions
How do you measure AI ROI?
Measure the business outcome the workflow exists to produce, not the time the AI saves inside it. That means capturing a baseline with the same instrument you will use afterwards, logging the AI's involvement per transaction so you can attribute the change, naming where the saving lands in the P&L, and subtracting the full run cost including human review. A time-saved figure multiplied by a labour rate is not an ROI calculation, it is a hypothesis about one.
What is a good ROI for an AI project?
There is no benchmark worth quoting, and any figure a vendor gives you for "typical AI ROI" is a marketing number. The useful question is whether the return is defensible and repeatable. A modest, well-instrumented return on one production workflow is worth more to your programme than a large speculative number, because you can fund the next use case with it.
Why do most AI pilots show no measurable ROI?
Usually because measurement was never designed into the pilot, so the pre-AI baseline no longer exists by the time anyone asks for the number. The second reason is leakage: the time was genuinely saved, but there was no constraint waiting to absorb it, so it never converted into money. The Danish payroll study is the clearest published example, with about 2.8% of hours saved and no detectable movement in earnings or hours worked.
How long does it take to see ROI from AI?
If the workflow has a real constraint and the instrumentation is in place at the start, you can have a defensible number within a quarter of going live, and often sooner. If measurement is retrofitted, the honest answer is that you may never get a number anyone believes, because the baseline is gone. The timeline is set by the instrumentation decision, not by the model.
Should we measure AI ROI in hours saved?
Track hours saved as a leading indicator, and never present it as the return. An hour saved is an option on value. Report it alongside the destination that hour reached, and if it did not reach one, that is the finding to bring to the room.
Does AI governance help or hurt the ROI case?
It helps, and not for the reason people expect. The logging, per-request cost attribution, and audit trail that let you govern an AI in production are the same machinery that lets you prove what it delivered. Teams who treat control as a compliance tax pay for that plumbing twice. It is worth understanding how the EU AI Act obligations overlap with the evidence you already need for your own business case.
Difinity partners with regulated teams in financial services, healthcare, and government to take AI from pilot into governed production, built by operators who have run AI at 300,000+ organization scale. If you have a use case you think can carry a real number, we will help you find out.
