Every article in this series so far has been about paying for AI efficiently. This one is about a constraint that stops you doing that, and about being honest that the constraint costs money.
The conversation usually goes like this. Someone presents an AI cost. Someone else, quite sensibly, asks whether there is a cheaper region or a cheaper model. And the answer, for a regulated organisation handling personal information, is often: yes, and we are not allowed to use it.
Why the constraint exists
South Africa's Protection of Personal Information Act, like the GDPR and similar regimes elsewhere, places real obligations on what happens to personal information — including when it is processed outside the country. It does not forbid cross-border processing outright, but it conditions it, and the conditions have to be satisfied and evidenced.
For many public-sector bodies and regulated institutions there is a further layer on top: sectoral rules, procurement conditions, ministerial directives, or simply a board that has decided, reasonably, that citizen data does not leave the country. Whether or not that position is legally required in a given case, it is frequently the position, and it functions as a hard constraint.
The engineering consequence is simple to state: the processing has to happen in an approved location. And approved locations are a smaller, more expensive market than the global one.
What the constraint actually costs
Four distinct costs, and they compound.
Fewer models to choose from. The newest and most capable models generally appear in a handful of large regions first, and reach smaller regions later — sometimes much later, sometimes never. An in-country deployment may mean using a model a generation behind, which can mean needing more of it to get the same result.
Less choice of pricing model. This is the one that catches business cases out. In smaller regions, the flexible on-demand option is sometimes not offered at all, and the only route to a given model is reserved capacity. That converts what should have been a variable cost that starts near zero into a fixed monthly commitment from day one — and, as the previous article on reserved capacity argued, paying for a lane before the traffic exists is exactly the thing you were trying to avoid. Here you may not have the choice.
Higher unit prices. Smaller regions frequently carry a premium, for ordinary reasons of scale and infrastructure cost.
More engineering. Keeping processing inside a boundary means designing for it — network controls, private connectivity, explicit configuration to prevent traffic drifting to a default region, and the evidence to prove all of that to an auditor. That is real delivery effort, and it is effort that produces no visible feature.
None of this is anybody behaving badly. It is what a constrained market looks like. But it means "just use the cheaper option" is not available, and a business case built on global pricing will be wrong by a margin that matters.
The exposure people miss
Here is the part that gets missed most often, and it is the reason this article sits in a series about cost rather than in a series about compliance.
Most organisations think carefully about the personal information they store. It has been classified. Somebody knows which database it is in, which country that database sits in, and who approved the arrangement. That work is usually done properly.
Almost nobody thinks about the personal information that arrives in what users type.
Consider what a member of the public actually types into an AI assistant. Not a tidy structured field — a sentence. "My ID number is X and I applied in March and I still haven't heard back about my grant." Or a description of a medical condition, in the course of asking about a benefit. Or a case reference, a bank detail, an address, a family circumstance.
That is personal information. It was created at the moment of typing. Nobody classified it, because nobody filed it. And it travels with the request to wherever the model runs.
The same is true internally, with a different flavour: a staff member pasting a customer's file into an assistant to get a summary has just sent that customer's information wherever the assistant processes it.
If your residency analysis covered only the database and not the prompt, it is incomplete — and the gap is not a technicality. It is the live, high-volume, unclassified flow of exactly the data the rules exist to protect.
What to do about it
Five things, in rough order of how early they should happen.
Decide residency before design, not after. This is the whole argument of the article. A residency requirement discovered during architecture is a constraint you design around. The same requirement discovered after a pilot is a rebuild, and rebuilds are where budgets go to die.
Price the constrained option, not the convenient one. Whatever the business case says, it should be costed against the region and pricing model you are actually permitted to use — including a reserved commitment if that is the only route available. A case built on global on-demand pricing will understate the real figure substantially.
Treat prompts as a data flow in the assessment. Whatever your organisation calls its privacy or data protection assessment, the prompt path belongs in it: what users may type, where it goes, how long it is retained, and by whom it can be read.
Reduce what needs protecting. A great deal can be done in design. Do not ask for identifying detail the assistant does not need. Detect and strip obvious identifiers before the request leaves your boundary. Keep sensitive lookups on your own systems and let the model handle only the language. Each of these shrinks the exposure and, incidentally, often shrinks the bill.
Write down what was decided and why. Not for its own sake — because in eighteen months somebody will ask why the expensive option was chosen, and "there was a rule" is a much weaker answer than a dated note naming the rule, the alternatives considered and the person who approved it.
The trade-off, stated plainly
There is a genuine trade-off here and it should be put to decision-makers as one, rather than smuggled in as a technical detail.
Keeping AI processing in-country buys compliance, sovereignty and — in the public sector particularly — a defensible position with citizens about where their information lives. It costs more, offers fewer models, and reduces flexibility.
That is a legitimate exchange, and plenty of organisations should make it without hesitation. What is not legitimate is making the exchange without anyone realising a choice was made, and then treating the resulting invoice as a technology overrun. It is not an overrun. It is the price of the constraint, and the constraint was correct.
Put it in the business case, on its own line, with a name.
How CloudNala can help
We do the residency work at business-case stage rather than at design stage: what is actually required for the data involved, which regions and pricing models that leaves available, what the difference costs, and where the prompt path creates exposure the storage analysis missed. It is a short piece of work. It routinely changes the number in the business case, and it is dramatically cheaper than discovering the same facts after a pilot has been built in the wrong place.
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.
Start a Digital Discovery Sprint or write to us at consult@cloudnala.co.za