Where Data May Live and Move

Three terms that are not the same

Used interchangeably in sales conversations and meaning different things:

Data residency — where data is physically stored. A commitment that records sit in a particular country.

Data sovereignty — which country's law governs the data, and which government can compel access to it. Data stored in Frankfurt but controlled by a company subject to another country's disclosure laws is resident in Germany and arguably sovereign elsewhere. This is the distinction customers increasingly probe, and answering the residency question when you were asked the sovereignty one damages credibility.

Data localisation — a legal requirement that certain data must remain within a country's borders. Some sectors and jurisdictions impose it outright.

Every model request is a data transfer

The point product teams most often miss.

When your product sends a customer's document to a model API, you have transferred that customer's data to wherever that endpoint runs, and to whoever operates it. It does not feel like a transfer — it feels like calling a function. Legally it is the same event as uploading the document to a third party in that country.

This has three consequences:

Your provider is a sub-processor, and typically must be disclosed to customers, listed in agreements, and covered by whatever transfer mechanism applies.

The region matters, and defaults are often not your region. Many APIs default to processing wherever capacity exists unless you explicitly select otherwise.

Retention is a separate question from processing. Whether the provider stores the request, for how long, and whether it may be used for training are distinct questions with distinct answers, and all three appear in enterprise reviews.

A decade of instability, briefly

Transfers of personal data from the EU to the United States have relied on successive legal frameworks, and the pattern is instructive for anyone architecting a product.

Two earlier frameworks were invalidated by the EU's highest court following challenges brought by the privacy campaigner Max Schrems. The current arrangement, the EU–US Data Privacy Framework, rests on a European Commission adequacy decision adopted in 2023.

Its recent history:

As of writing, the framework remains in force. But the architectural lesson does not depend on how the current case resolves: the legal basis for this particular data flow has been struck down twice and is under active challenge a third time. A product architecture that assumes it will hold indefinitely is making a bet on litigation.

That is the transferable point. Not "the framework is invalid" — it is not — but "design so that a change in this framework is a configuration change rather than a rebuild." Module 6.3 is about exactly that.

Which of your flows carry exposure

Work through your product and mark each flow:

The third row is where products most often have an unexamined problem. Teams carefully consider where documents are stored and then send the customer's name, the matter reference and three paragraphs of their situation in a prompt to an endpoint nobody assessed.