There is a moment in a lot of AI conversations where a leader asks, entirely reasonably, "so what does it cost?" — and the honest answer is another question: for how long?
That exchange is the whole of this article. The instinct behind the question is a capital-purchase instinct: find the price, approve it, own the thing. It is a good instinct. It has served finance functions well for a century. It does not fit what is being bought here.
The photocopier and the electricity
The mental model most people bring to technology procurement is the photocopier. You evaluate options, you agree a price, you sign, it arrives. Thereafter it is an asset. It depreciates on a schedule. There is a maintenance contract, sure, but the shape of the thing is: bought, owned, done.
AI is not the photocopier. AI is the electricity that runs it.
You do not buy electricity. You connect to it, and then you pay for it every month, forever, in proportion to how much of it you use. Nobody in any organisation finds this outrageous. Nobody asks when the electricity will be paid off. It is simply understood that the building consumes power as a condition of being a working building.
The same is true of a live AI service. It is not an artefact you acquire. It is a capability you power. Every question it answers consumes something, and that consumption is what appears on the bill.
Why this feels worse than cloud did
Organisations already went through this shift once, with cloud. Servers used to be bought, racked and depreciated; now compute is rented and metered. Most finance functions have made peace with that.
So why does AI provoke the reaction again? Three reasons, and they are worth naming because they are all fixable.
The hype set the wrong expectation. AI was sold as a transformation, and transformations sound like projects — things with a beginning, a middle and a completion. Nobody said "this is a utility you will pay for indefinitely", because that is a less exciting sentence.
The bill grows when things go well. Cloud consumption for a stable application is reasonably flat. An AI service that is genuinely useful gets used more, and the cost follows. Success looks, on the invoice, exactly like a problem. That is deeply counter-intuitive and it catches experienced people out.
Nobody can say what it will be next year. A server had a price. A licence has a price. A consumption service has a rate, and the total depends on adoption nobody can forecast confidently. Finance functions are not being difficult when they push back on this; they are being asked to plan against a genuinely unknown quantity.
The question that actually works
If "what does it cost to buy" is the wrong question, the right one is not much harder.
What does it cost to run, per unit of value it produces?
That single reframing does more work than any cost-cutting exercise, because it makes the number interpretable. A monthly figure on its own says nothing. The same figure set against what it produced says everything.
Concretely — using round, illustrative numbers — suppose a customer assistant costs in the region of R60,000 a month to run, and in that month it resolved 30,000 queries that would otherwise have reached the contact centre. That is roughly R2 per resolved query. Whether that is good news depends entirely on what a contact centre interaction costs to handle, which every organisation with a contact centre already knows.
Now the conversation is a normal business conversation. It is not about AI at all. It is about unit economics, which finance functions are extremely good at.
Three levers, and only three
Once the equation is on the table, it becomes obvious what can actually be changed, and it is a short list.
Volume — how many times it is used. This is usually the least appropriate lever to pull. Reducing usage of a service people find useful, in order to reduce its cost, is a decision to have less of the thing you paid to build. It is sometimes right, but it should be a deliberate choice rather than an accident of budget pressure.
Cost per use — what one interaction costs to serve. This is where the engineering work lives: choosing an appropriately sized model rather than the largest available, trimming what gets sent with each request, caching answers to questions that repeat, and eliminating retries and waste. Meaningful reductions are usually available here, and they change nothing about the user's experience.
Value per use — what one interaction is worth. The most neglected lever and often the largest. Increasing the proportion of queries the assistant resolves completely, rather than escalating, changes the denominator without touching the numerator. So does pointing it at higher-value work.
A rising bill is only a problem when the third lever is not rising with the first. That sentence is the difference between a cost that needs cutting and a cost that is working exactly as designed.
What changes in practice
The shift from capital thinking to running-cost thinking has consequences beyond vocabulary.
Budgeting. Consumption AI belongs in operating expenditure, attached to the service it powers, not in the capital line where the project that built it lives. Build cost and run cost are separate, and both need approving.
Approval. A capital decision is made once. A running cost needs a standing review — monthly is right — where someone is accountable for the number and can explain the movement.
Business cases. A case that shows only the build cost is incomplete and will be embarrassing within a year. Show the first-year run cost, the steady-state monthly figure, and what happens at three times the expected volume.
Decommissioning. A photocopier you no longer need sits in a corner costing nothing. An AI service you no longer need keeps billing. Somebody has to be responsible for turning things off, and in most organisations nobody is.
The uncomfortable part
There is no version of this where the AI is finished and the payments stop. That is not a negotiating position and it is not a failure of procurement — it is what the thing is.
The good news is that this is not new territory. Every organisation already runs on things that cost money continuously: power, connectivity, cloud, premises, people. Nobody finds those mysterious. They are budgeted, metered, reviewed and occasionally cut. AI simply joins that list, and once it is on the list rather than being treated as a project that has overrun, it stops being alarming and starts being managed.
How CloudNala can help
Most of the AI business cases we are asked to review contain a build number and no run number. We add the missing half — the steady-state monthly cost, the cost per unit of output, and the figure at three times expected volume — and we set up the monthly review that keeps it honest afterwards. It is unglamorous work, and it is the difference between a service that gets renewed and one that gets quietly switched off after an awkward quarter.
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.
Request a Cloud Review or write to us at consult@cloudnala.co.za