Data residency requirements are multiplying. In the past six months, nine countries have enacted or strengthened laws that restrict where certain categories of data can be stored and processed. Five more have draft legislation moving through their legislative processes. The direction is unambiguous: governments want data about their citizens and their industries to stay within their borders, and they are writing laws that make it expensive and risky to do otherwise.
For data teams running AI systems that process data across borders, this is not a theoretical concern. It is a constraint that is already affecting architecture decisions and will affect more of them over the next 18 months. The teams that plan for it now will avoid expensive rearchitecting later. The teams that assume the current permissive environment will continue will find themselves scrambling when enforcement actions begin.
The regulatory landscape by region
The European Union’s GDPR remains the most comprehensive data residency framework, but its enforcement is tightening. Recent guidance from the European Data Protection Board has clarified that AI model training on EU citizen data constitutes processing under GDPR, which means the training must either occur within the EU or under an adequacy framework that many non-EU countries do not satisfy. This has direct implications for companies that train models on data that includes EU citizen records.
China’s data localisation requirements have expanded to cover AI training data explicitly. Companies that train models on data containing Chinese citizen information must store the training data within China and must not transfer it outside the country without government approval. The practical effect is that any company serving the Chinese market with AI features must maintain separate training infrastructure within China.
India’s Digital Personal Data Protection Act, which took full effect this year, requires that personal data be stored and processed within India for specified categories, with limited exceptions. The law is less restrictive than China’s but more restrictive than the pre-2026 framework. Companies that have been processing Indian data in global data centres need to evaluate whether their current architecture complies.
Brazil, South Korea, Indonesia, Nigeria, and Saudi Arabia have all enacted or strengthened data residency laws in the past 12 months. The specifics vary, but the direction is consistent: more data must stay within national borders, and the penalties for non-compliance are increasing.
This diagram requires JavaScript.
Enable JavaScript in your browser to use this feature.
What this means for AI architecture
The core architectural implication is that you cannot assume a single global deployment for AI systems that process data from multiple jurisdictions. You need jurisdiction-aware data routing that directs data to processing infrastructure within the appropriate jurisdiction, and you need model serving infrastructure that can operate in multiple jurisdictions.
For training, the implications are more complex. If your training data includes records from jurisdictions with strict residency requirements, you may need to train separate model instances on data from different jurisdictions. This is operationally expensive but may be legally necessary. Alternatively, you can train on jurisdiction-specific data subsets and combine the resulting models through ensemble or routing approaches that keep the raw data within jurisdictional boundaries.
For inference, the challenge is simpler but still significant. When a user in India sends a query that includes personal data, the inference must happen on infrastructure within India, or under a data transfer mechanism that satisfies Indian law. This means deploying inference infrastructure in each jurisdiction where you have users who send personal data through your AI system. For companies with global user bases, this means inference infrastructure in multiple regions.
The cost implications are real. Running inference infrastructure in multiple regions costs more than running it in a single region, because you cannot share capacity across regions. Each region needs enough capacity to handle its own peak load, which means total capacity across regions exceeds what a single centralised deployment would need. The overhead varies by workload pattern but is typically 30 to 60 percent more than centralised deployment.
A practical compliance approach
Start with a data inventory. For each category of data your AI systems process, document where it comes from, where it is stored, where it is processed, and which jurisdictions’ laws apply. This inventory will be incomplete on the first pass. That is acceptable. The goal is to identify the categories that carry the highest residency risk, not to achieve comprehensive coverage immediately.
Next, map your AI workloads against the data inventory. For each workload (training, fine-tuning, inference, evaluation) identify which data categories it uses and whether current processing locations comply with applicable residency requirements. Flag workloads where compliance is unclear or where current processing locations are in jurisdictions that do not satisfy the data source jurisdiction’s requirements.
Then, prioritise remediation based on enforcement risk. Jurisdictions with active enforcement and significant penalties should be addressed first. Jurisdictions with enacted but not yet enforced laws should be addressed on a timeline that aligns with expected enforcement dates. Jurisdictions with draft legislation should be monitored but not yet remediated.
For architecture decisions, adopt a jurisdiction-first design principle. When designing new AI systems, determine data residency requirements before choosing infrastructure. Do not choose infrastructure and then try to retrofit compliance. The retrofit is always more expensive and more fragile than the original design.
The bounded recommendation
Conduct a data residency audit of your AI workloads within the next 90 days. Identify the three highest-risk jurisdiction combinations in your current architecture. For each, determine whether a deployment within the appropriate jurisdiction is technically and economically feasible. If it is not feasible for any of the three, escalate to legal and executive leadership, because the enforcement risk is real and growing.
