If you take one thing from this series, take this article. Everything else is detail hanging off it.
There is a single distinction that resolves most confusion about AI investment, and it is not technical. It is a question about who the AI is for.
Are you buying AI to help your people do the work they already do? Or are you building AI into your products and services, for people who do not work for you?
Those are two different purchases. They are bought differently, priced differently, governed differently, and owned by different parts of the organisation. Get them mixed up and every budget conversation afterwards is confused.
AI for your people
This is the one most organisations bought first, and it is the easier of the two to reason about.
It is a packaged product. Microsoft 365 Copilot, ChatGPT Enterprise, Gemini in Google Workspace — the specific name matters less than the shape. Someone else built it, someone else runs it, and you buy access for your staff.
It works inside tools your people already have open: the email client, the document, the spreadsheet, the meeting. It works on content the organisation already holds and that the individual already has permission to see. And it is sold per person, per month, in the same way as any other seat licence in your estate.
What it buys you is time back on existing work. A first draft instead of a blank page. A summary of a forty-page document. Notes from the meeting you could not attend. The value is real, and it is also diffuse — spread thinly across a lot of people doing a lot of small things, which is why measuring its return is genuinely hard and why nobody has a satisfying answer to "what did we get for that licence spend?"
What it does not buy you is a product. It does not appear on your website. It cannot serve someone who has no account with you. It has no place in your service catalogue.
AI in your products
This is the one that generates the second bill, and it is a fundamentally different activity.
Here, AI is a component inside something you build and own: a support assistant on your website, a guide that walks an applicant through a form, an assistant inside your own app that answers questions about a customer's own account. The public interacts with it. Your name is on it. When it gets something wrong, it is your problem, not a vendor's.
You do not license this. You assemble it — a model you rent access to, your own content and rules, your own interface, your own guardrails about what may and may not be said, your own logging so that someone can reconstruct what happened when a complaint arrives.
And you pay for it by how much work it does. Not by how many staff you employ. If nobody uses it, it costs very little. If it becomes the front door to a service used by tens of thousands of people, it costs accordingly. That is the property that makes leaders uneasy, and it is covered properly in the next article.
The sentence that settles most arguments
Here is the line I keep coming back to in these conversations:
Copilot can draft a staff member's email. It cannot be the assistant on your public website.
Not "it would be difficult to make it do that". Not "we would need to negotiate". It is not that kind of product. The licence is scoped to a signed-in employee working inside your tenant, and a member of the public is not one.
The reverse is just as true, and gets less attention: a bespoke customer assistant you build is a poor way to give three thousand staff a drafting tool. You would be rebuilding, at considerable expense, something that already exists and is heavily supported. Organisations do occasionally attempt this, usually out of a preference for building over buying, and it rarely ends well.
Two jobs. Two tools. Two bills.
Where the two do meet
To be fair to the confusion: there is a real overlap, and pretending there is not would be dishonest.
Both may be running on the same family of models underneath. Both may draw on the same organisational content. And there is a genuine middle ground — the platform vendors all sell "build your own assistant" tooling that sits somewhere between the packaged product and full custom development, and some of that tooling is licensed in ways that blur the line.
But the overlap is in the plumbing, not in the purchase. Two houses can be connected to the same water main and still have separate meters and separate bills. The shared infrastructure underneath does not make them one purchase, and it will not make one invoice go away.
Deciding which one a need actually is
The practical value of the distinction is that it can be applied before anyone builds a business case. Three questions do it.
Who is on the other side of the screen? If it is your own employee, signed in, working on internal material, you are in the first column. If it is a customer, a citizen, an applicant, a supplier — anyone who does not have a staff account — you are in the second. This one question resolves most cases outright.
Whose name is on the answer? If the AI produces a draft and a staff member reviews it before anyone else sees it, there is a human in the loop by design and the risk profile is modest. If the AI's output goes straight to the public, your organisation is answerable for every word of it, and the governance, testing and logging you need are of a different order.
Does it need to exist in a place you control? Inside Outlook and Teams is the vendor's territory. Inside your own portal, app or service journey is yours — and everything in your territory you have to build, run and pay for by the unit.
The budgeting consequence
Once you have sorted a need into one of the two columns, the budgeting follows almost automatically.
Column one is a headcount-driven fixed cost. It goes in the same mental bucket as any other per-seat software: forecast it from staff numbers, review it against actual usage, reclaim licences from people who never open it. Boring, predictable, and manageable by existing means.
Column two is a usage-driven variable cost, attached to a specific service, with a specific owner, that should be measured against the value that service produces. It does not belong in the software line at all. It belongs with the service it powers, in the same way the electricity for a building belongs to the building.
Most of the "why are we paying twice" arguments I have watched were really arguments in which someone was trying to fund a column-two need out of a column-one budget, and everyone in the room was talking past everyone else because nobody had drawn the line.
Draw the line first. The numbers get much easier afterwards.
How CloudNala can help
Most of the value we add here happens before any technology is chosen: sorting a list of "AI ideas" into the two columns, and being straight about which ones do not need AI at all. It is not a long exercise — usually a workshop — but it changes what gets funded, and it stops organisations buying a per-seat product to solve a per-use problem, which is the most common and most expensive way this goes wrong.
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