AI data residency requirements come from the laws that already govern the data an AI system touches, not from AI law itself. GDPR Chapter V, DORA, PRA SS2/21, China's PIPL and India's DPDP Rules each ask where prompts, outputs, logs and embeddings go. The EU AI Act imposes no residency requirement. The hard part is proving where an inference ran.

What is the difference between data residency, data sovereignty and data localization?

A residency program that treats the three terms as synonyms answers the wrong question.

Data residency is where data is physically stored and processed. It is normally a choice the organization makes and fixes through contract and configuration, and it can be true without any law requiring it. Enzai's data residency glossary term gives the AI-specific definition.

Data sovereignty is which state's laws, courts and compulsory access powers reach the data. It follows the legal reach of the provider as well as the location of the hardware. A US-headquartered provider running an EU region satisfies residency while remaining subject to US legal process, which is the data sovereignty question.

Data localization is a legal mandate that a defined category of data stay inside a country's borders, with export permitted only through a prescribed procedure or not at all. It is the only one of the three that is a requirement in itself. China's PIPL Article 40 is a localization rule; GDPR is not, because it regulates transfers and a compliant transfer is lawful. Enzai's glossary entry on localization uses the word in its product sense, adapting AI systems to local markets.

Why does AI make data residency harder to prove?

Traditional residency was settled at the database layer. AI moves data at the inference layer, where paths are less visible and often default to the vendor's global routing.

Two of these paths are routinely missed. Embeddings can be recovered to something close to the source text, so a vector store in a second region is a second copy of regulated data. And default routing on several major platforms is global, so a system designed for one region can run in another the first time capacity is short. Enzai's guide to third-party AI vendor risk assessment covers the vendor-side questions.

What do GDPR and UK GDPR require for AI processing outside the region?

GDPR does not require personal data to stay in the EEA. Chapter V (Articles 44 to 49) restricts transfers to third countries unless one of three routes applies: an adequacy decision under Article 45, appropriate safeguards under Article 46 such as standard contractual clauses or binding corporate rules, or a derogation under Article 49, which the EDPB says should be a last resort. A prompt containing personal data sent to a US-hosted model is a transfer.

For US-hosted models the adequacy route is the EU-US Data Privacy Framework, adopted July 10, 2023. The General Court upheld it in Latombe v Commission (T-553/23) on September 3, 2025. Philippe Latombe lodged an appeal to the Court of Justice as Case C-703/25 P on October 31, 2025, and as of September 14, 2026, that appeal is pending, so DPF transfers should be documented with an SCC fallback.

UK to EEA flows rest on the Commission's renewed UK adequacy decisions, adopted December 19, 2025 and running to December 27, 2031. For transfers out of the UK, the ICO's guidance requires an adequacy regulation, an appropriate safeguard (the IDTA or the Addendum) with a transfer risk assessment, or an exception. The Commission's adequacy list has included Brazil since January 26, 2026.

Does the EU AI Act impose data residency requirements?

No. Regulation (EU) 2024/1689 contains no provision requiring data to be stored or processed in the Union, and the Digital Omnibus on AI (Regulation (EU) 2026/1744) did not add one.

Two Articles still interact with residency for high-risk systems. Article 10 (data and data governance) requires training, validation and testing data sets to be subject to data governance practices, which is where a residency policy is recorded. Article 12 (record-keeping) requires high-risk systems to "technically allow for the automatic recording of events (logs) over the lifetime of the system," and Article 26(6) requires deployers to keep those logs for at least six months. Logs containing personal data fall under GDPR Chapter V, so where a vendor stores AI Act logs is a transfer question. These obligations apply from December 2, 2027, for Annex III systems and August 2, 2028, for Annex I systems; Enzai's EU AI Act compliance guide has the deadline table.

The Data Act (Regulation (EU) 2023/2854), applicable since September 12, 2025, is a related lever: Chapter VI gives customers a right to switch data processing services, with switching charges abolished from January 12, 2027, and Article 32 obliges providers to resist third-country governmental access to non-personal data held in the Union.

What do financial services regulators expect on location of processing?

Financial regulators do not mandate residency either. They require the firm to know, record and contract for the location of every material ICT service, which for an AI system means the endpoint, the logs and any fine-tuning pipeline.

Under DORA (Regulation (EU) 2022/2554), Article 28(3) requires a register of information on all ICT third-party arrangements, and the template in Commission Implementing Regulation (EU) 2024/2956 has fields for the country of provision and the location of data at rest, as the EIOPA Q&A on the template confirms. Article 30(2)(b) requires ICT contracts to specify "the locations, namely the regions or countries, where the contracted or subcontracted functions and ICT services are to be provided and where data is to be processed, including the storage location," with advance notice of change. A vendor that reserves the right to route inference globally cannot sign that clause without qualification. The EBA Guidelines on outsourcing arrangements (EBA/GL/2019/02) likewise require the register to record "the location (i.e. country or region) of the data" (paragraph 54).

In the UK, PRA SS2/21 applies to banks, building societies, PRA-designated investment firms and Solvency II insurers, current version effective December 31, 2024. Paragraph 6.4 requires material outsourcing agreements to state the regions or countries where the service is provided and where data is kept, processed or transferred, with notice of changes, and paragraph 7.7 says the PRA does not favor restrictive data localization. Enzai's third-party AI risk management page covers how these requirements map onto AI vendors.

What do public sector rules say about offshoring data to AI services?

The UK position is permissive at OFFICIAL and conditional for health data. The Government Cyber Security Policy Handbook states that OFFICIAL data, including the SENSITIVE marking, "can be stored and processed in data centres or Cloud regions overseas when satisfactory legal, data protection and security practices are in place." NHS England's off-shoring guidance of May 28, 2025, requires UK hosting by default, with EEA, adequate-country or US hosting only where risk is low and the SIRO approves. The NCSC's Cloud Security Principle 2 supplies the diligence questions on storage countries and legal jurisdiction.

Which non-EU regimes matter for AI data residency?

Three rows change architecture decisions. China's thresholds count individuals cumulatively per year, so a customer-service assistant sending transcripts to an offshore model can cross 100,000 quickly. India's Rule 13(4) puts "traffic data pertaining to its flow" in scope, not only the payload; the data categories it covers had not been notified in any source located for this draft. Brazil's mutual adequacy with the EU makes an EU-region endpoint a lawful destination for Brazilian personal data without clauses.

Which controls keep an AI system's data path in region?

Four controls do most of the work, and vendor documentation shows why "regional" needs close reading.

Region-pinned inference is available but not always the default. Microsoft's deployment types documentation states that data at rest stays in the designated Azure geography for every deployment type, but Global types may process prompts "in any Azure region," Data Zone types only within the US, EU or APAC zone, and Standard types within the customer-specified geography. AWS's cross-Region inference documentation explains that a geographic inference profile keeps routing within the US, EU or APAC, while a global profile lets Bedrock select any commercial Region. OpenAI's data controls page lists ten storage regions but supports regional processing only in the US, Europe and the UAE. Anthropic's Claude Platform documentation offers an inference_geo parameter with values us and global, global being the default, and a US-only workspace geo for data at rest. Each page is precise; each also makes the global option the path of least resistance.

Contractual commitments on logging, retention and training close the gaps configuration cannot. OpenAI, for example, documents that API content is not used for training unless the customer opts in, and that abuse-monitoring logs are kept for up to 30 days unless zero data retention is enabled. Those terms belong in the inventory record.

Bring-your-own-model and private deployment settle the question for the highest-risk systems, because the inference path becomes the firm's to log. Enzai's platform assumes customers bring their own model and guardrails and does not require a particular LLM provider, so the residency decision stays with the customer.

Evidence is the control regulators will ask for. A supervisor reading the DORA register or an auditor testing a transfer impact assessment needs, per system, the pinned region, the log showing requests stayed there, the retention clause and the transfer mechanism. That record is what the AI inventory holds: one entry per system with vendor and model references, mapped frameworks and evidence attached, so residency becomes a queryable attribute.

What this means operationally

1. Classify every AI data path, not every AI system. For each entry in the AI inventory, record where prompts are processed, where outputs and logs are stored, whether embeddings exist and where, and whether any data is used for training. A regional endpoint with a global fallback is two paths.

2. Fix the default. Where the platform offers a data zone, geographic profile or region parameter, set it in code, block the global option by policy and keep the configuration export as evidence.

3. Map each path to its regime: GDPR transfer route, DORA register and contract clause, SS2/21 paragraph 6.4 wording, PIPL threshold count. Enzai's compliance frameworks module carries GDPR alongside the EU AI Act, so evidence can be reused where obligations overlap.

4. Attach the contract terms to the system record: retention period, training exclusion, monitoring location, sub-processor and location-change notice, each with its verification date.

5. Re-test on change. A new model version, a vendor's new region, a Court of Justice ruling on C-703/25 P or a MeitY notification under Rule 13(4) should trigger a review of every affected path.

To see how residency attributes and transfer evidence attach to a system record, talk to the Enzai team.