Last updated:
Data residency is the requirement that data be stored and processed in a particular country or region. In AI systems it applies to training data, prompts, model outputs and inference logs, and it constrains which models a firm can call, since sending a prompt to a model hosted elsewhere is a cross-border transfer.
How is residency different from sovereignty and localisation?
The three terms get used interchangeably and mean different things. Residency is a commitment about where data physically sits, often contractual and not legal. Localisation is a legal requirement that certain data must remain within a jurisdiction, as under some Indian, Chinese and Russian rules. Sovereignty goes further and concerns which government can compel access to the data, which is why an EU-hosted service operated by a US-headquartered provider can satisfy residency while still raising sovereignty questions. Procurement questionnaires frequently ask about one and mean another.
Why does AI make this harder?
Traditional data governance can map storage locations and control them. AI introduces movement that is easy to miss. A prompt containing customer data sent to a hosted model is a transfer, and so is the response and any log the provider retains. Retrieval systems pull documents from one region into a context window processed in another. Fine-tuning copies data into a training pipeline that may run elsewhere. Vendor-embedded AI inside a SaaS product moves data without the customer configuring anything. The result is that residency commitments made at the database layer are often broken at the inference layer.
What does GDPR require?
The GDPR does not impose data localisation. It restricts transfers of personal data outside the EEA unless a lawful transfer mechanism applies, which is a different and more flexible thing. Those mechanisms include an adequacy decision for the destination country, standard contractual clauses with a transfer impact assessment, or binding corporate rules. Firms that read GDPR as requiring EU-only storage often over-constrain their architecture; firms that ignore the transfer rules end up relying on a mechanism they never documented.
Which controls hold up under audit?
Region-pinned deployment of both storage and inference endpoints, so that the model call stays in the same jurisdiction as the data. Contractual commitments from AI providers covering processing location, retention of prompts and outputs, and whether inputs are used for training. Configuration that disables training on customer data where that option exists. Records of the transfer mechanism relied on for each cross-border flow. Logging that captures which model handled which request in which region, since this is the evidence a regulator asks for and the part that is usually missing.
How does it show up in AI governance?
Residency is a property of the system and belongs in the AI inventory next to owner and risk tier. Recording the hosting region, the provider, the transfer basis and the retention terms for each AI system turns residency from a periodic manual exercise into something answerable at any time. It also surfaces the cases that matter most, which are the vendor-embedded features and the shadow AI that nobody registered, where data is crossing borders with no assessment behind it.
Real world example:
A German insurer deploys an assistant that drafts claims correspondence. Policyholder data sits in a Frankfurt database, satisfying its residency commitment. The assistant calls a large language model hosted in a US region, so every prompt containing claim details is a transfer of personal data outside the EEA. The firm pins the model endpoint to an EU region, obtains contractual terms confirming prompts are not retained or used for training, documents standard contractual clauses with a transfer impact assessment for the residual vendor support access, and records the region and provider against the system in its AI inventory. When the supervisory authority asks which systems process policyholder data outside the EEA, the answer comes from one query.
