"Regional" doesn't mean your data stays there

There is a conversation I have had enough times now to recognise it from the first sentence.

Someone explains that their AI deployment is compliant because they selected the local region. Data stays in-country. The box is ticked, the architecture diagram says so, and the vendor’s marketing page agrees.

Then I ask where the embeddings live, and the room goes quiet.

Selecting a regional cloud instance governs one thing well: where primary data is stored at rest. It does not, on its own, govern where inference runs, where control-plane telemetry lands, what derived artefacts still contain, or whether a vendor’s contract actually commits to any of it. Those are four separate questions, and every one of them has bitten someone.

One: storage is not processing

No major LLM vendor guarantees region-locked inference. All of them offer regional storage. Processing is a different commitment, and it is routinely not made.

Microsoft 365 Copilot is the clearest example because Microsoft documents it honestly: content is stored in the tenant region, but inference can be processed outside that region when capacity requires it. Storage and processing are governed separately, and both matter for a residency obligation.

This is not a vendor being evasive. It is a capacity-management reality across the industry — peak load has to go somewhere. The failure is on our side: we read “data residency: South Africa” as a statement about the whole pipeline, when it is a statement about a database.

If your obligation is about where personal data is processed rather than merely where it rests, a regional storage commitment does not discharge it.

Two: the control plane leaves by default

This one is genuinely easy to miss because it is not in the AI layer at all.

AWS CloudTrail global service events route to us-east-1 regardless of which region your workload runs in. Deploy your entire AI stack in af-south-1, and a category of your control-plane logs still exits to Northern Virginia unless you explicitly configure otherwise.

Those logs are not your customer records. But they are metadata about your processing — who called what, when, from where — and under several of the regimes I work with, metadata about the processing of personal data is not obviously outside scope.

I raise this not because it is the biggest exposure but because it is the most invisible. Nobody’s architecture diagram has an arrow to us-east-1 on it. You find this by reading the cloud provider’s documentation on default behaviours, not by looking at your own design.

Three: embeddings are not anonymised

This is the one I would push hardest on.

There is a widespread working assumption that once text has been converted to a vector, it has become mathematics and stopped being personal data. That assumption does not survive contact with the inversion literature — research indicates roughly 40% of sensitive content is recoverable from embeddings through inversion attacks.

Forty per cent recovery is not anonymisation. It is compression with a lossy decode. If the source text was personal data, the embedding should be treated as personal data: same residency rules, same retention limits, same deletion obligations, same place in the RoPA.

Which raises the practical question most RAG deployments have not answered: where is your vector database, actually? Pinecone serverless offers US and EU regions. Weaviate requires self-hosting or bring-your-own-cloud for regional control. Azure AI Search does have a South Africa North presence. These are meaningfully different answers, and the choice was often made by whoever built the prototype.

Then there is fine-tuning, which has a sharper edge. Once personal data is in model weights, it cannot be deleted. Not slowly, not expensively — the operation does not exist. A right-to-erasure request against a fine-tuned model has no compliant answer other than retraining without that data. Any organisation fine-tuning on personal data should have decided in advance what it will say when that request arrives, because it will.

Four: the contract usually doesn’t say what the page says

The marketing page and the enterprise agreement are different documents, and the gap between them is where the risk sits.

Two patterns recur. The split-DPA problem: residency commitments live in one instrument and AI-specific processing terms in another, and the AI terms do not inherit the residency guarantee. And “regional processing” carve-outs: language committing to regional processing under normal conditions, with an exception for capacity, failover, or abuse investigation — which is precisely when you would most want the commitment to hold.

Worth knowing on coverage, too. Microsoft explicitly supports South Africa data residency. That commitment does not extend to Kenya, Nigeria, Rwanda or Ghana. Salesforce Einstein Copilot is US-only, which means it cannot lawfully be used with personal data from any of those five markets. One of five has a commercial commitment. The other four are assertions.

The thing nobody has that everyone assumes

Here is the finding I did not expect and which changes how I frame the whole conversation.

No regulator across Kenya, Nigeria, Rwanda or Ghana has published an approval of any cloud vendor’s regional deployment.

Not a rejection. An absence. When an enterprise says its regional deployment is compliant, that is the enterprise’s own legal assessment. It is not a regulator’s confirmation, because no such confirmation exists to point at.

That does not make the assessment wrong. It does mean the risk of it being wrong sits entirely with the enterprise, and that “we used the compliant region” is not the defence people think it is.

Two jurisdictional specifics follow from this:

• AWS af-south-1 is in South Africa, not Kenya. Kenya’s Data Protection Act section 50 localisation requirement contemplates a serving copy on a server physically in Kenya. A South African region does not satisfy it on its own, however geographically reasonable that feels.
• No hyperscaler has a Nigeria region. NITDA’s Cloud Policy requires Level 3 and Level 4 sovereign data — government, financial, health, security — to be hosted in Nigeria. That requirement cannot currently be met through AWS, Azure or Google Cloud. There is no compliant at-scale path, which is a structural gap, not an implementation failure.

What to do about it

Stop asking “which region is this in” and start asking a longer question, once, per system.

Inventory the artefacts individually: prompts, outputs, embeddings, prompt logs, telemetry, control-plane logs, fine-tuning data, and any cached intermediate state. For each, establish where it physically rests, where it is processed, and which contractual instrument commits to that — with a clause reference, not a webpage.

Then read the exception language. Every capacity, failover and investigation carve-out is a documented circumstance in which the commitment does not apply.

And treat any artefact you cannot place as a blocker rather than a residual risk. That is the whole content of the second governance non-negotiable, and it is deliberately absolute: a system whose residency you cannot confirm should not go to production. Not because something will definitely go wrong, but because you have no answer to a regulator who asks a specific question — and the questions are getting specific.

---

Findings drawn from technical assessment work conducted for a board-level AI governance baseline across South Africa, Nigeria, Kenya, Rwanda and Ghana. Vendor positions are as assessed in April 2026 and should be re-checked against current terms before relying on them — this is a fast-moving area and the exception language is where the movement happens.