This article provides practitioners with a practical understanding of how data localisation laws affect AI, maps the current localisation landscape, and introduces strategies for maintaining compliant data flows without sacrificing AI capability.
Why Data Localisation Matters for AI
AI systems are inherently data-hungry. A machine learning model trained on a single jurisdiction’s data may perform poorly when deployed in another jurisdiction with different population characteristics, language patterns, or cultural contexts. Conversely, a model trained on global data delivers better performance but may violate localisation requirements in every jurisdiction that contributed training data.
This creates a fundamental tension in AI governance:
Performance demands global data. The best-performing AI models are typically trained on the largest and most diverse datasets available. Restricting training data to a single jurisdiction often degrades model quality, particularly for tasks involving natural language, cultural understanding, or demographic diversity.
Regulation demands local control. Jurisdictions impose localisation requirements to protect privacy, assert sovereignty, ensure regulatory access to data, protect national security, and retain economic value from data generated within their borders.
For practitioners, the challenge is not whether to comply with localisation requirements — that is non-negotiable. The challenge is how to comply while maintaining the AI capability the organisation needs.
The Localisation Landscape for AI Data
Data localisation requirements vary by jurisdiction and data category. The three levels of restriction are:
Must store locally: The data must be stored and, in some cases, processed exclusively within the jurisdiction. Cross-border transfer is prohibited or requires government approval. Examples: China requires personal information of CII operators to be stored domestically (PIPL Article 40). Russia requires the primary database of Russian citizens’ personal data to be in Russia (Federal Law 242-FZ). India requires payment system data to be stored exclusively in India (RBI Circular 2018).
Can transfer with safeguards: The data may be transferred cross-border but only with specific legal mechanisms in place. Examples: The EU allows personal data transfers to countries with adequacy decisions or through Standard Contractual Clauses (GDPR Chapter V). Singapore allows transfers where the recipient provides comparable protection (PDPA Part 6A). Canada requires comparable protection levels (PIPEDA).
No restriction: The jurisdiction does not impose localisation requirements on the data category. Example: The United States has no general federal data localisation requirement for personal data, though sector-specific rules apply (FedRAMP for government data, ITAR for defence data).
Impact on AI Pipelines
Data localisation requirements affect every stage of the AI data pipeline:
Training Data Collection
When training data is collected from multiple jurisdictions, each jurisdiction’s data protection and localisation laws apply to the data collected within its borders. A multilingual NLP model trained on text data from EU, Chinese, and Indian users faces three distinct localisation regimes simultaneously.
Practical impact: Training data may need to be segregated by jurisdiction of origin. Centralised data lakes that aggregate global data for training may violate localisation requirements unless appropriate transfer mechanisms are in place for every data source.
Model Training
Model training typically occurs on centralised compute infrastructure — often in a cloud data centre in a specific jurisdiction. When training data from jurisdiction A is transferred to compute infrastructure in jurisdiction B for training, a cross-border data transfer occurs.
Practical impact: Organisations must ensure that every cross-border data flow in the training pipeline has a valid legal basis. This includes not just the raw data but also derived features, embeddings, and any intermediate representations that could constitute personal data.
Model Deployment and Inference
When a trained model is deployed for inference, user inputs and model outputs flow between the user’s jurisdiction and the model’s hosting jurisdiction. If the model hosts in the EU and serves users in China, inference queries from Chinese users may constitute a data transfer to the EU.
Practical impact: Model hosting location affects the localisation compliance of every jurisdiction where users interact with the model. Multi-region deployment — hosting model instances in multiple jurisdictions — can address this but increases operational cost and complexity.
Model Updates and Retraining
When production data is used for model retraining, the same localisation rules that apply to initial training data apply to production data. If production data from a jurisdiction with strict localisation requirements is used for centralised retraining, a compliance violation may occur.
Practical impact: Continuous learning and model improvement pipelines must be designed with localisation compliance built in, not bolted on.
Compliance Strategies
Strategy 1: Jurisdictional Segmentation
Deploy separate model instances in each jurisdiction, trained on local data and hosted on local infrastructure. This is the most compliant approach but the most expensive and typically produces lower-quality models due to smaller, less diverse training datasets.
When to use: When localisation requirements are strict (must store locally), when the data is highly sensitive, or when the performance impact of local-only training is acceptable.
Strategy 2: Federated Learning
Train models locally in each jurisdiction using local data, then aggregate model updates (not raw data) at a central coordinator. This preserves data locality while enabling model improvement from multi-jurisdictional data.
When to use: When cross-border data transfer is restricted but cross-border transfer of aggregated model parameters is permissible. Note: some jurisdictions may consider model updates derived from personal data to constitute a data transfer — legal assessment is required.
Strategy 3: Differential Privacy and Synthetic Data
Apply differential privacy techniques to training data before cross-border transfer, or generate synthetic data that preserves statistical properties without containing actual personal data. Truly anonymised data (data that cannot reasonably be re-identified) is typically not subject to data protection and localisation requirements.
When to use: When the data can be effectively anonymised or synthesised without losing the statistical properties needed for model training. Note: the bar for “truly anonymised” is high under GDPR and PIPL — pseudonymised data does not qualify.
Strategy 4: Transfer Mechanism Compliance
Where localisation requirements allow transfer with safeguards, implement the required mechanisms: Standard Contractual Clauses for EU data, security assessments for Chinese data, contractual protections for Singaporean data. This approach enables centralised training but requires legal infrastructure for every data flow.
When to use: When the transfer mechanism landscape is stable and the organisation can maintain the legal infrastructure across all applicable jurisdictions.
Strategy 5: Sovereign Cloud and Data Clean Rooms
Use sovereign cloud infrastructure (Gaia-X aligned providers, national cloud initiatives) or data clean rooms where data from multiple jurisdictions can be processed under controlled conditions without the data leaving its jurisdiction of origin.
When to use: When the organisation needs to combine multi-jurisdictional data for training but cannot transfer the data. Data clean rooms enable computation on data in situ, with only results (not raw data) leaving the controlled environment.
Building a Data Localisation Impact Assessment
Practitioners should conduct a data localisation impact assessment for every AI system that processes data from multiple jurisdictions:
-
Map data flows. For the AI system, trace every data flow from collection through training, inference, monitoring, and retraining. Identify every cross-border transfer.
-
Classify data. For each data flow, classify the data category (personal data, special category data, important data, government data, financial data) and identify the applicable localisation requirement.
-
Assess compliance. For each cross-border transfer, determine whether the current transfer mechanism satisfies the applicable localisation requirement. Document gaps.
-
Evaluate strategies. For each gap, evaluate which compliance strategy (segmentation, federated learning, differential privacy, transfer mechanisms, or sovereign cloud) is feasible and proportionate.
-
Implement and monitor. Deploy the chosen strategy and establish ongoing monitoring to ensure continued compliance as regulations, data flows, and system architecture evolve.
Data localisation is not a one-time compliance exercise — it is an ongoing operational requirement that must be maintained as systems change, regulations evolve, and the organisation’s jurisdictional footprint expands.
This article is part of the COMPEL Body of Knowledge v2.5 and supports the AI Transformation Practitioner (AITP) certification.