The value case for an AI project: baseline, calculation, sensitivity and the non-AI alternative

In short. A value case is defensible when it holds four things an outsider to its drafting can verify: a baseline measured over a stated period, an expected value calculation with every assumption spelled out, the three-year total cost including ongoing oversight, and the non-AI alternative costed with the same arithmetic and ruled out in writing. Without that last item the comparison stays between doing the project and doing nothing, which is a comparison that always wins.

This article sets out how the document gets built, with the measurement method, the formulas, a full worked example and the calculation errors that recur in the business cases we review.

The eight elements of a defensible value case

Element	What has to be there	Who provides it
Measured problem	The starting number, with period and data source	Process owner
Baseline	Volume, time per unit, rework rate	Whoever runs the process
Non-AI alternative	The simplest option, costed with the same method	Whoever proposes
AI option	Scope, data, integrations, share of cases covered	Whoever designs
Expected value	Formula, assumptions, a range rather than a single number	Proposer, with finance
Three-year total cost	Build, consumption, integration, oversight, exit	Designer, with IT
Risk and classification	Where the system lands and which obligations follow	Risk or compliance function
Stop criteria	Numeric thresholds and a review date	Whoever signs

The right-hand column is the one most often missing, and its absence explains why many documents don't survive the first hard question. A number without an owner is a number nobody will defend in committee.

The baseline, before any promise

The baseline is the measure of the process as it stands today, and it has to be collected before the project is announced, because the announcement changes the behaviour of the people doing that work.

Three quantities and a period are needed. Volume, as the number of units handled in the chosen interval. Time per unit, measured on a sample rather than recalled by the manager. Rework rate, the share of units that come back or need a second pass.

The observation period deserves care. Four weeks is the minimum for a process with weekly seasonality, while a process with monthly peaks needs at least two full cycles. A baseline taken during a peak inflates the expected value, one taken in a quiet stretch depresses it.

On sampling, a practical rule: thirty units timed by two different people give a more defensible measure than an internal survey of a hundred, because perceived time spent is systematically biased upward for unpleasant tasks.

Finally, record who collected the data and with what instrument. A baseline pulled from system logs carries different evidentiary weight than one gathered on a spreadsheet, and that difference matters when the final result is challenged.

How expected value is calculated

Gross expected value comes from volume times time saved per unit times the fully loaded hourly cost of the function involved. Fully loaded means including contributions and indirect costs, because using gross pay understates the saving materially in most Italian organisations.

Three reduction factors then apply to that number, and each has to be declared.

The share of cases the system covers, because no solution handles the entire flow. Residual verification time, the minutes a person still spends checking the output, high in the early months and falling as trust builds. The adoption rate, which in the first year rarely reaches the theoretical potential, because habit around the previous process holds.

The result belongs in a range. A value case declaring an annual saving of 56,000 euro is less credible than one declaring a range between 38,000 and 61,000 with the assumptions producing each end, because the second shows the unfavourable scenario was considered.

One distinction finance will raise anyway is worth addressing upfront. Freed time becomes a saving only if it converts into lower costs or into additional capacity actually sold. In staff functions, where nobody will be replaced, the benefit belongs in the document as recovered capacity, tied to what those hours will do in place of the eliminated work.

Three-year total cost

Line	Nature	Estimating note
Design and build	One-off	Includes data preparation, the most underestimated line
Integration with existing systems	One-off	Grows with the number of downstream systems receiving the output
Model consumption or licences	Recurring	Size it on worst-case behaviour rather than the average
Internal validation time	Recurring, decreasing	High in the first three months, budget it anyway
Oversight and maintenance	Recurring	Between 10 and 20% of build cost per year
Documentation and compliance work	Variable	Depends on the system's classification
Exit cost	Contingent	Return to the manual process, data migration, reverse training

The three-year horizon makes the weight of the recurring lines visible. A project costing 45,000 euro to build and 18,000 a year to run carries a three-year cost of 99,000, and comparing the annual benefit against the initial 45,000 alone produces a decision taken on a third of the numbers.

A worked example

The figures below are illustrative and serve to show the mechanics of the calculation.

A services company handles 1,400 case files a month. The completeness check takes 11 minutes per file on average, around 257 hours a month. At a fully loaded hourly cost of 32 euro, that process is worth roughly 8,200 euro a month, a little under 99,000 a year.

The hypothesis is a system that checks completeness and flags anomalies. The share of standard, therefore treatable, files is estimated at 70%. Residual verification time on the output is 2 minutes per treated file. The first-year calculation comes out as follows.

Line	Value
Gross hours freed, 70% of 257	180 hours/month
Residual verification, 980 files at 2 minutes	33 hours/month
Net hours freed	147 hours/month
Gross annual value, 147 hours at 32 euro over 12 months	about 56,400 euro
Correction for 70% adoption in year one	about 39,500 euro
Recurring costs, year one	18,000 euro
Operating margin, year one	about 21,500 euro
One-off build	45,000 euro

Cumulative cash stays negative by around 23,500 euro at the end of year one. With adoption at full rate, year two generates a margin near 33,000 euro, putting breakeven around the twentieth month from start.

Sensitivity analysis is what separates a serious document from a hopeful one. If the share of treatable files drops from 70 to 50 per cent, the annual margin at full rate falls below 10,000 euro and breakeven passes four years, meaning the project should not be funded. The value case has to state that threshold, because it names the assumption the pilot must test first.

The non-AI alternative, costed with the same arithmetic

The alternative deserves the same method rather than a single dismissive line. In most processes two cheaper options exist before the model.

Option	Intervention	Indicative cost	Share of problem solved
A, process	Mandatory fields upstream, authorisation thresholds, forms	Low, weeks	Often between 30 and 50%
B, deterministic rules	Automated checks on known conditions, no model	Medium, 4-10 weeks	Between 40 and 70% on standard cases
C, AI system	Interpretation of unstructured input	High	The residue A and B don't cover

In the projects we assess, option B covers a substantial part of what the proposer attributed to AI, at lower build and oversight cost and with predictable behaviour. That doesn't cancel option C, it resizes it: the residual value of AI belongs on the delta against B, not against the manual starting process.

Writing the alternative down doesn't mean choosing it. It means stating why it was ruled out, and that sentence is the part of the document the committee will read most closely.

Regulatory risk in the arithmetic

The system's classification carries an economic effect that has to be estimated, because a system falling under Annex III of the AI Act brings risk assessment, technical documentation, structured human oversight, event logging and, for some deployers, a fundamental rights impact assessment.

In the cases we follow, that package adds a significant share to project cost and a recurring maintenance commitment, with the burden concentrated in control functions rather than the technical team. A value case ignoring this line understates cost precisely in the most sensitive use cases.

The practical consequence concerns the order of work. Classification belongs before the economic calculation, because it changes the denominator, rather than after approval, when the budget has already been committed.

Stop criteria written as thresholds

A useful stop criterion is a number with a date. Wording like review progress after a few months stops nothing, because it leaves the decision to the discretion of whoever has an interest in continuing.

A defensible formulation reads like this: if at week twelve the share of files handled without human intervention stays below 55 per cent, or the output correction rate exceeds 20 per cent, the project stops and option B is reconsidered.

Three elements are needed. The metric, already measured in the baseline. The threshold, derived from sensitivity analysis rather than chosen by feel. The date, fixed in advance and put in the calendar alongside the person with the authority to stop the project.

The calculation errors that recur

The first is counting the same time twice. When several initiatives each claim to free hours from the same function, the sum of benefits exceeds the hours actually available there, and the portfolio promises a saving that is arithmetically impossible.

The second is treating as a saving time that stays in the company. If nobody is reallocated and no additional volume is absorbed, the benefit is latent capacity, and declaring it as cost reduction exposes the project to a review it won't survive.

The third is ignoring verification time. A system handling seventy per cent of cases while forcing a full recheck produces a net saving close to zero, and that check belongs in the pilot measurement rather than in a desk estimate.

The fourth is using the pay rate instead of the fully loaded hourly cost, which understates the benefit and, perversely, makes the project easier to reject.

The fifth is discounting internal time to zero during the project. The hours of people sitting in interviews, validations and tests are a real cost, and belong in the document even when nobody invoices them.

Who signs, and what they sign

The signature establishes who answers for the starting number, who will decide on the agreed date whether the project continues, and with what authority.

That same person has to be able to close the project, because if whoever signs lacks that power the stop criteria stay decorative and the initiative runs on inertia until the budget is gone. It happens more often than people admit.

It is also worth fixing a materiality threshold. Below a certain figure the decision stays with the function head on a short form, above it the full document and the risk assessment go to committee. That rule cuts time spent on small initiatives and protects large ones from hasty approval.

Where to start

The method for selecting use cases is in how to choose the first use case and in prioritising AI use cases.

The decision criteria are described in go/no-go criteria, the six-dimension framework in AI Canvas, and the cost lines in what AI projects really cost and the AI cost nobody budgeted for.

For classification, which belongs before the calculation, see AI systems risk classification.

To build the value case for your own use cases you can book an assessment session.