How much will AI cost, and what's the ROI?

Where AI money actually goes

Every AI business case I have reviewed starts the same way: a vendor quote for the software, and nothing else. That number is real, but it is rarely more than a third of what the project ends up costing. Boards approve the invoice, then get blindsided twelve months later by the rest of the bill.

A proper cost breakdown for any AI initiative has five buckets:

1. Technology. Model access (APIs, licences), infrastructure, storage, monitoring tools.
2. Data. Acquisition, cleaning, labelling, pipeline build, and the ongoing cost of keeping it current.
3. People. Salaries for internal time — the project lead, the subject matter expert who reviews outputs, the engineer who wires it into existing systems. Usually the largest line, and the one nobody books.
4. External services. Consultants, delivery partners, specialist agencies, training.
5. Ongoing operations. Monitoring, retraining, incident response, governance, the on-call rota when it breaks at 2am.

Worked example. Say a mid-sized firm buys an AI tool to automate first-line customer responses. The vendor quote is £30,000 a year. Add data cleaning and integration work (a contractor, six weeks, £18,000). Add internal time: two days a week from a product owner and a support team lead reviewing edge cases for four months, roughly £22,000 in salary cost once you price their time properly. Add external help wiring it into the CRM, £12,000. Add ongoing monitoring and periodic retraining once live, £8,000 a year. The invoice said £30,000. The true first-year cost is closer to £90,000. That is not a failure of planning — it is what happens when only one bucket gets counted.

Estimating ROI without lying

You cannot precisely forecast ROI on a project built around a probabilistic model. Anyone who gives a board a single confident number is either guessing or hiding the guess. What you can do is give three honest ranges, each tied to a named assumption:

• Worst case: £15,000 net benefit in year one. Assumes adoption stalls at 40% of the target team, and accuracy sits low enough that a human checks every output.
• Expected case: £45,000 net benefit. Assumes 70% adoption within six months and accuracy good enough that spot-checks replace full review.
• Best case: £80,000 net benefit. Assumes 90%+ adoption, accuracy holds without retraining, and the freed-up capacity is actually redeployed into billable or higher-value work.

Then state the break-even point plainly: in this example, the project pays for itself once it handles roughly 1,200 queries a month at the assumed accuracy rate. Below that, it is a cost centre. That single number gives the board something concrete to track, and gives you a trigger for the 6- and 12-month review you should already have scheduled. Ranges with named assumptions are something a board can interrogate and sign off on. A single invented percentage is not — it is a guess wearing a suit.

The run-cost trap

The most common budgeting error is treating go-live as the finish line. A model in production costs money every month it runs: API calls scale with usage, monitoring needs someone watching it, and most models need periodic retraining as the world it describes moves on. A tool that looked cheap at launch can quietly become one of the more expensive line items in the department a year later, simply because nobody budgeted for month 13 onward. Build the run-rate into the business case from day one, not as an afterthought once the pilot succeeds.

The productivity trap

The second most common error is more dangerous because it looks like good news. A team reports the AI tool saves each person four hours a week. Someone multiplies that by headcount and salary and presents it as cash saved. It is not. Freed-up time only becomes money if you actually reduce headcount, redeploy people onto revenue-generating work, or grow output without adding staff. If the four hours get absorbed into longer lunch breaks and slower afternoons, the saving is real but invisible on the P&L. Before you put a productivity figure in front of a board, ask what specifically will change in the org chart or the output numbers as a result. If the honest answer is "nothing yet," say that, and treat it as a leading indicator rather than a return.

Other pitfalls worth naming

• Underestimating labelling and data preparation — it is skilled, slow work and usually takes longer than the technical build.
• Assuming the pilot's costs scale linearly. Production data volumes, edge cases, and support demands are rarely the same shape as a pilot's.
• Comparing AI cost against doing nothing, rather than against the next-best alternative (hiring, outsourcing, or a simpler tool).

Where Florence helps

Florence's project briefs break every cost down into service provider, salaries, and technology, and localise the currency to your organisation — so the number your board sees is the one you will actually be billed for, not the one on the vendor's homepage. Next step: before you approve anything, ask whoever is proposing the project to show you all five buckets and a break-even point. If they can only show you the invoice, send them back to do the sum properly.