Seven articles in, the practical question is still the one the series opened with, only sharper. Not why does AI keep costing money — that has been answered — but which AI do we pay for, for which need, and when do we say not yet?
This article is the one-page version. It assumes nothing from the previous seven.
Read the row, then decide
Four common needs, four different purchases.
Staff doing existing work faster. This is per-user AI: a packaged assistant, licensed per head, working inside the tools your people already have open. Predictable, forecastable, boring in the good sense. Pilot it with one or two teams before licensing everybody, because the honest finding from a pilot is usually that some roles transform and others barely notice — and that finding is worth a great deal of money at renewal.
A customer or citizen service. This is consumption AI built into something you own. Start on demand, start small, instrument it from the first day so you know what one interaction costs. Do not license your way into this; there is no product that does it for you.
High, steady, proven volume. Same service as above, now with evidence behind it. This is when reserved capacity becomes the right call — after the volume is real, sized to what the data shows rather than to the optimistic scenario, and reviewed monthly.
Personal or regulated data. This is not a separate product so much as a constraint that reshapes the other three. It decides where the processing may happen, which narrows your model and pricing options and raises the floor. Settle it before design, and price the option you are actually permitted to use.
Most of the expensive mistakes in this series come from mismatching a row to a column: buying a row-one product for a row-two need, or committing to row three before row two produced any evidence.
It is a portfolio, not a purchase
The framing that makes all of this manageable is that there is no such thing as "the AI investment".
There is a set of investments, of different shapes, each matched to a job:
- A licence estate that scales with headcount, reviewed annually, owned by whoever owns software asset management.
- One or more live services with variable running costs, reviewed monthly, each owned by the person accountable for the journey it sits in.
- Occasionally a capacity commitment, entered into on evidence and reviewed on a schedule.
- And a set of constraints — residency, sectoral rules, board policy — that apply across all of it and belong in every business case rather than in a footnote.
Those are managed differently and should be funded differently. An organisation that runs them as one budget line will never be able to explain its own AI spend, because the line contains four things that move for four unrelated reasons.
Four questions before the next line item
The matrix says what to buy. This says whether to buy it yet.
Is there a named person whose problem this actually solves? Not a department, not a strategic theme — a person you could go and speak to this afternoon who would notice if it existed. AI initiatives without one of those tend to produce impressive demonstrations and no adoption.
Can we start small enough that being wrong is cheap? One journey, one team, one region. If the smallest viable version of the proposal is still large, the proposal has not been thought through hard enough, and you are being asked to bet more than you need to.
Do we know what one unit of this costs to serve? Not the total. The unit. If nobody can produce that number, the business case rests on an estimate nobody has tested, and you will find out its true value in about six months.
Would we still want it if usage tripled next quarter? This is the success test, and it is the one that gets skipped. Model the case where it works. If the answer at three times the volume is uncomfortable, the design needs changing now, while changing it is a decision rather than an emergency.
Four yeses means fund it — and instrument it from day one, because a service without cost attribution cannot be governed later. Any no means not yet, which is a different answer from no. It is an instruction to come back with the missing half.
When to say not yet
Worth being explicit, because "not yet" is the most useful and least used answer available to a leader here.
Say not yet when the sponsor cannot name who benefits. Say not yet when the only proposed version is the full one. Say not yet when the residency question has not been settled and the costing assumes the convenient answer. Say not yet when nobody has modelled the success case. And say not yet when a reserved commitment is being requested before any traffic has been observed.
None of those are rejections of AI. Every one of them is a request for the piece of information that makes the decision defensible — and in most cases the team can supply it within a fortnight.
What the series has been arguing
Pulled together, it is a short argument.
There is no single AI bill because there is no single AI purchase. There is per-seat AI for your people and per-use AI in your products, and buying one does not give you the other. Per-use AI is metered because it does work continuously, and a live service is powered rather than purchased. Reserved capacity is a bet on volume that should only be placed once the volume exists. Data residency is a legitimate constraint with a real price that belongs in the business case rather than in a surprise. And all of it is governable, provided somebody owns the number and a handful of honest metrics get presented every month.
Do that, and the AI bill stops being mysterious. It becomes what it always was: a set of ordinary operating costs, attached to a set of capabilities, that can be defended or cut on the evidence.
The organisations that will do well with AI over the next few years are not the ones that spend the most or the least. They are the ones that can say, in a sentence, what each line of their AI spend is for and what it produced.
How CloudNala can help
We run this as a single session with the people who hold the budget: sorting the organisation's AI ambitions into the four rows, applying the four questions to each, and producing a one-page portfolio view with a costed next step for the ones that pass and a specific missing piece named for the ones that do not. It usually results in fewer things being funded, sooner, with better numbers behind them — which is a considerably better outcome than a long list nobody can defend.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book an AI Readiness Workshop or write to us at consult@cloudnala.co.za