“We can’t get budget approval because we can’t prove ROI.”
If that sentence has appeared in a slightly desperate Teams chat in your organisation, you are not alone. Over the past two years we have seen a strange paradox: AI is everywhere in strategy decks and almost invisible in the P&L. Vendors talk about “transformational potential” and “strategic value”. Boards nod, pilots get funded, and six months later the CFO quietly shuts them down.
The models are not the main problem. The issue is that most AI proposals are written as strategy essays, not as financial instruments. The business case is simply not engineered to survive contact with finance.
This issue is about fixing that.
Why CFOs reject AI business cases#
From a distance, AI projects sound irresistible. They promise better customer experience, faster decisions, and new products. That language works well in the boardroom. In the CFO’s office, it falls flat.
Most AI business cases fail for three simple reasons.
First, the value is vague. “Improved decision-making”, “enhanced productivity”, “better customer experience” are aspirations, not cash flows. They do not map directly to any line in the income statement.
Second, the baseline is missing. Slides talk about a “30% efficiency gain”, but rarely define 30% of what. Against which current process? At what cost per transaction? With what current error rate and rework? Without a baseline, the uplift is storytelling.
Third, the proposals ignore unit economics. In the on‑prem era, software felt almost like a fixed asset: you bought licences and servers, then ran them for years with little visible marginal cost. SaaS already chipped away at that illusion. Seats, API calls and usage‑based pricing moved a meaningful share of spend from capex to opex. AI takes this one step further. Every prediction, every call to a model, every “AI‑assisted” decision has an explicit variable cost attached, and brings a second, less visible variable cost with it: the cost of human verification.
The CFO’s position is straightforward. The proposal presents AI as a strategic initiative. Finance has to treat it as a financial instrument. If the document never gets down to cost per transaction, volumes, and downside protection, it will not make it past the inbox.
The unit economics of intelligence#
The way out is to stop selling “AI” and start selling unit economics: the cost per decision, per transaction, per interaction.
There are only two numbers that really matter. The first is the cost per transaction in the current, human‑driven process. The second is the cost per transaction in the proposed AI‑supported process, including any human verification. If the second number is not lower than the first, at realistic volumes and quality levels, the proposal has no legs.
This is where most AI decks quietly fall apart. They talk about licence fees and implementation budgets, but skip the three cost lines that dominate long‑term economics.
The first is inference. Every call to a model consumes compute. If you use external APIs, the bill scales with usage. If you run models yourself, you are paying for GPUs, energy and cooling. The long‑term trend is clear: cost per token is falling, and newer architectures are more efficient. The problem is that organisations do not hold everything else constant. As models get cheaper and more capable, they increase context windows, add more retrieval, and apply AI to more workflows. Cheaper tokens get immediately reinvested into “heavier” use, so total spend still ends up tracking adoption and complexity rather than dropping gracefully.
The second line is verification debt. The AI drafts the answer; a human still has to decide whether to trust it. If a lawyer spends twenty minutes reviewing a one‑minute AI‑generated contract, the labour arbitrage is not twenty‑to‑one. It may well be negative. If an underwriter has to re‑check thirty per cent of AI‑scored applications manually, the effective cost per decision is not the model API price, it is “API plus underwriter”. Unlike compute, senior human time does not get cheaper every time a new model comes out. Unless you deliberately design the workflow to reduce the verification rate, this line will dominate the economics.
The third line is maintenance and drift. Models do not age gracefully. Regulations change, products change, fraud patterns change, and the data landscape shifts under your feet. You have to fund data engineering, evaluation, retraining, monitoring and incident response. Even if GPU efficiency improves and data‑centre operators squeeze more work out of each kilowatt‑hour, the people and process overhead rarely shrinks in the same way. A reasonable rule of thumb is to budget fifteen to twenty per cent of initial build cost per year just to keep accuracy and compliance at the level you promised when you launched.
When these three lines are missing, or treated as one‑off “project costs” rather than long‑term commitments, the CFO is being asked to sign a blank cheque in the name of “innovation”. In 2026, that cheque does not get signed.
A simple way to make it concrete#
None of this requires exotic finance. It does require a slightly different way of framing the conversation.
Instead of starting with model names and architecture diagrams, start by writing down, in plain language, the decision or transaction you want to improve, who owns it today, and what it currently costs. That means actual numbers: volumes per month, average handling time, fully loaded cost per case, error rate and rework. If you cannot get those numbers within a few days, you do not yet have a business case. You have a wish.
Then sketch the target state in the same units. For the AI‑supported process, what would cost per transaction look like if you include tokens, infrastructure and human verification? At what adoption level does the new line really start to move the P&L? What error rate and escalation rate would still be acceptable to risk and compliance?
A simple, honest worked example in one domain beats ten pages of abstract benefits. Take the customer service case. Suppose the full cost of a human agent is about €6 per ticket. Suppose an AI assistant costs €0.50 in compute per ticket. If a human has to step in to fix or complete half of those tickets — and each intervention costs about the same as handling a ticket manually — your true cost is roughly €3.50, not €0.50. That is still a meaningful reduction, but much smaller than the original estimate suggested. If you can reduce human intervention to ten per cent of tickets without damaging quality, the effective cost drops to around €1.10. Now you have a line you can point to in a budget meeting.
The point is not the precise numbers; you will adjust them for your own context. The point is that the single most sensitive variable in the business case is the verification rate. The conversation about model choice and token prices is secondary. You can always renegotiate a cloud contract. It is much harder to renegotiate how much senior time you burn checking half‑baked outputs.
From slide deck to validation canvas#
This is where it helps to formalise the business case as a canvas rather than a loose collection of slides.
A good canvas forces you to write, on one page, the current process and its owner, the baseline economics, the target economics with AI, the architecture in just enough detail to understand the cost drivers, the verification and control design, and the staged investment plan with clear kill points. Each box needs a sentence or two and a number or two. If you find yourself filling it with adjectives, that is a useful warning.
You do not need to show that one‑page canvas to the whole organisation. You do need it for yourself. It is the place where you make trade‑offs explicit: for example, “we choose a more expensive model because it lets us cut verification from thirty per cent to ten per cent, which is worth far more than the token savings”, or “we cap the context window because the marginal value of extra documents is lower than the marginal cost”.
Once you have that canvas, all the standard failure modes are much easier to see. “Strategic value” slides with no link to a P&L line stand out immediately. Promises of “full automation” in high‑risk use cases look implausible the moment you write down who will be called when something goes wrong. Integration plans that say “we will plug a model into the existing process” raise the obvious question: is that process actually fit for purpose, or are we about to put a jet engine on a horse cart?
The Briefing#
Gartner predicts 40%+ of agentic AI projects will be canceled by end of 2027
Gartner forecasts that more than 40% of agentic AI initiatives will be shut down before reaching production. The pattern is familiar: projects launched on strategic enthusiasm, scaled without unit economics, then quietly killed when the numbers fail to materialise. Business case engineering is not a nice-to-have — it is the difference between the 40% that get cut and the rest.
Finland becomes first EU state to fully enforce AI Act
VinciWorks reports that as of 1 January, Finland has a fully operational AI Act enforcement regime — with Traficom as the AI regulator, a Sanctions Board for fines above €100K, and sandbox rules coming in February. Other member states are lagging, but obligations remain directly applicable via courts. For business case engineering, this means regulatory compliance is no longer “future work” — it is a line item in your cost model today.
NIST issues draft Cyber AI Profile merging security and AI risk frameworks
NIST has published a preliminary draft Cyber AI Profile integrating AI-specific risks into the Cybersecurity Framework (CSF 2.0) and AI Risk Management Framework. AI governance is no longer a side project for data science teams — it is converging with enterprise security and audit. If your AI business case does not include evidence, traceability, and control design, you are building for yesterday’s compliance landscape.
The shift in tone#
The Business Case Validation Canvas exists to improve the odds of delivering projects that actually benefit the organisation.
Instead of asking the CFO to back “innovation”, you are offering a specific trade: at these realistic assumptions, for this well‑defined workflow, we can move cost per decision from here to there; we know which variables matter; and we have clear points at which we walk away if the economics do not materialise.
The most persuasive line in that conversation is not “we need to invest in AI to stay competitive”. It is something much more prosaic: “At these assumptions, this system reduces cost per transaction from €6 to just over €1.”
At that moment you are no longer asking for belief in a trend. You are offering a financial instrument that can be bought, held or sold on numbers the CFO already understands.
Before you approve the next AI proposal, it is worth asking one simple question:
For this initiative, what is our current cost per transaction, what is the target cost per transaction with AI — including verification — and what decision gates will tell us whether our assumptions were right?
If the room answers with adjectives instead of numbers, you do not have a business case.
You have a story.