Data residency and sovereignty

The questions that establish it

Ask these before designing anything. Ask them of the person who owns the obligation, not the person who repeated it.

1. ·Which specific regulation or contract imposes this, and can I read the clause? Frequently there is no clause and it is a policy someone set, which is a different conversation with different flexibility.
2. ·Does it apply to all data or to a defined class? Usually a class: customer personal data, or account records. Everything else may be free to move.
3. ·Is processing restricted or only storage? These are very different requirements and are constantly conflated.
4. ·Is data that has been de-identified still in scope? Often not, which opens the tokenisation option below.
5. ·Does an approved region satisfy it, or must it be on-premise? A large gap in cost and capability.

The most common outcome: the strict requirement covers one field class, and it turns out to be satisfiable by keeping that class in the client tenancy while the rest of the workflow runs normally.

Four architectures, cheapest first

In-region hosted

A hosted model in an approved region, in the client’s own cloud account, with training disabled contractually. Satisfies most residency requirements and keeps the frontier.

Tokenised

Sensitive fields replaced with tokens before the call, restored after. The model reasons over structure, never over identifiers. Satisfies a surprising number of requirements.

Split

Sensitive extraction on-premise, general reasoning hosted on de-identified content. The boundary is a documented interface, which is what an auditor wants.

Fully on-premise

Open weights in the client’s data centre. The only answer for genuinely air-gapped work, and the most expensive in engineering and in capability.

Work down that list, not up. Teams that begin at the bottom often spend a quarter building something the second row would have satisfied.

What people forget to include

Residency applies to the whole system, not to the model call, and this is where reviews find problems.

1. ·Prompt and response logs contain the data. So do error traces with payloads attached.
2. ·The vector index is a copy of the corpus in another form, and it lives wherever you put it.
3. ·Your monitoring vendor may be receiving payloads in metadata.
4. ·Backups, and where they replicate to.
5. ·The support path. If your engineers can see production data from another country, that is data movement whatever the diagram says.

Write it down before you build

Produce a one-page data-flow statement and have the client’s compliance owner sign it. It lists each data class, where it is stored, where it is processed, who can see it, and how long it is kept.

This does two things. It surfaces disagreement while it is cheap, and it becomes the document you hand to the auditor eighteen months later, which is a far better position than reconstructing it from the code.