We had the architecture, the pipeline and the access sorted. What stopped us was a question that had nothing to do with any of them: does this feature process personal information?
Everything else followed from the answer — the region, the deployment model, the cost structure, and whether we could hit the launch date at all. It took weeks to resolve, and looking back, almost all of that was because it had been framed as a technical question when it was a data-protection question wearing technical clothes.
The question that decides it
Under POPIA, if the processing involves personal information, transborder transfer is constrained. There are lawful routes across a border, but they require conditions to be met and — critically for a delivery timeline — documented and approved before you rely on them. The safe default position, and the one that avoids a launch-blocking approval cycle, is to keep the processing in-country.
So the whole architecture hangs off one question, and it is not a question an architect can answer. It belongs to whoever owns data protection.
The mistake almost everyone makes
Here is the part that caught us, and I have since watched it catch other teams.
The instinct is to assess the knowledge base. What is the assistant grounded in? For a citizen-facing service the answer is usually: published information about public services. Public documents. Nothing personal. From which the comfortable conclusion follows — no personal information involved, cross-border is fine.
That reasoning is wrong, and the error is on the input side.
On a citizen-facing assistant, the largest privacy exposure is what users type into it. People do not ask abstract questions. They describe their situation. They give their ID number because they think it will help. They explain their medical circumstances, their financial position, their immigration status, their children's details. They paste in a reference number from a letter. All of that goes to the model, in the prompt, regardless of what the knowledge base contains.
"Our source content is public" does not clear the transborder question. It answers a question nobody was asking.
Eugene Perumal's framing in ITWeb this month (Deploying AI agents safely) is the useful test: POPIA requires automated processing of personal information to be purposeful, proportionate and accountable. A free-text box on a public service is, in practice, a personal-information intake channel. Design it as one.
Three routes, decided deliberately
Once the question is framed properly, there are three honest options, and the value of laying them out this way is that it converts an open-ended technical debate into a choice someone can actually make.
Route A — full AI, in-country. Everything stays inside the border. Clears the transborder question outright. The constraint is availability and commercial model, below.
Route B — full AI, cross-border. Only viable if the data genuinely contains no personal information, and only with a documented transborder position agreed in advance by the people accountable for it. Not a decision the delivery team can take on its own.
Route C — retrieval only, in-country. No generative model call at all: search over approved content, returning relevant passages. Less impressive. Available in-country regardless of the answer to the personal-information question. This is the route that protects the launch date.
Route C deserves more respect than it usually gets. A well-built retrieval experience over good content is genuinely useful to a citizen looking for a service, and it removes an entire class of risk — no generation means no fabrication, no ungrounded answer, no residency question about the model. Having it as a designed fallback rather than a defeat means the launch is never hostage to an approval cycle.
The compliance choice is also a commercial one
This is the part that turns a legal question into a budget question, and it is where the decision usually gets stuck.
In-country AI capacity is frequently sold as reserved capacity — a fixed monthly commitment, paid whether or not you use it. Cross-border is typically pay-as-you-go. So the compliant option carries a standing cost, and the cheaper-per-call option carries an approval burden.
That is a genuine trade-off and it is not an architect's decision. It involves committed spend, so it belongs to whoever owns the budget. It involves regulatory exposure, so it belongs to whoever owns the risk. The delivery team's job is to lay the options out clearly enough that those people can choose — which is the subject of the last article in this series, and the reason it exists.
One caution on the arithmetic: cheaper per call is not cheaper overall once you count the work of obtaining, documenting and maintaining a transborder position, and the delay while it happens. That work is real, recurring and rarely in the estimate.
Decide it early, and in writing
The expensive part of this for us was not the eventual answer. It was that the question surfaced late, and then sat undecided because it had never been put to anyone in a form they could act on.
Three things we would now do by default:
Ask the personal-information question in week one, before the architecture is drawn, and put it to the data-protection owner rather than resolving it around a whiteboard.
Write the answer down, with the reasoning and the date and the person who gave it. When someone asks in month six why the service runs where it runs, the answer should be a document rather than a recollection.
Design Route C as the fallback from the start, so the launch date is never contingent on an approval you do not control.
Under the constitution approach described earlier in this series, data residency was a written non-negotiable rather than a preference — which meant the AI coding agent never quietly produced a configuration that would have breached it.
The short version
"Where does the model run" reads as an infrastructure question and is actually three questions at once: what data are we handling, what does the law permit, and what are we prepared to commit to commercially. Decide it deliberately, decide it early, and decide it in writing — because it determines the architecture, and re-deciding it after the architecture exists is expensive.
How CloudNala can help
This question comes up on nearly every AI engagement we run in South Africa, and it is almost always framed too narrowly at first — as a region-selection problem rather than a data-protection one. What we tend to do is get it in front of the right person early, in a one-page form they can act on, with the three routes costed and a recommendation attached. It is a small piece of work that regularly saves a launch date.
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