Cross-border data transfer is no longer a footnote in the privacy programme — it is one of the highest-friction points in global AI operations, because training data, model serving, and analytics platforms routinely cross borders while the laws governing them diverge. The answer for most enterprises is not to hoard data in one region but to build a transfer framework that combines the EU's Standard Contractual Clauses (SCCs), Binding Corporate Rules (BCRs) where scale justifies them, adequacy decisions where they apply, and China's dedicated transfer routes — and to keep that framework under continuous review, because the legal foundations keep moving. This article walks through the current transfer landscape and the concrete choices your organisation will face in 2025.
How Has the AI Regulatory Landscape Evolved in 2025?
For cross-border transfers, the pivotal event of the past half-decade remains the Court of Justice of the European Union's Schrems II ruling of July 2020, which invalidated the EU-US Privacy Shield that more than 5,000 organisations had relied on to move data from Europe to the United States (US Department of Commerce). The ruling forced companies onto SCCs overnight and required them to assess the law of the destination country case by case — a transfer impact assessment — because the court held that standard clauses alone could not guarantee protection against foreign surveillance law. The EU responded in June 2021 with a new set of SCCs, and the European Data Protection Board set a transition deadline of 27 December 2024, after which contracts relying on the old clauses ceased to be valid.
The US relationship was rebuilt in stages. In July 2023 the European Commission adopted an adequacy decision for the EU-US Data Privacy Framework, and within its first year more than 2,000 organisations self-certified under the new programme (US Department of Commerce). But adequacy is a political instrument as well as a legal one: the framework faces legal challenge, and the pattern of the last decade is that companies cannot treat any single transfer mechanism as permanent. Meanwhile, GDPR enforcement has made transfers an audit priority. DLA Piper's GDPR Fines & Data Breach Survey reported cumulative fines under the regulation of more than €4 billion by early 2024 across more than 2,000 decisions, and transfer-related findings appear regularly in supervisory authority guidance, including the EDPB's recommendations on supplementary measures for transfers to third countries.
Outside the EU, the direction of travel is the same: more jurisdictions are restricting transfers and demanding localisation or explicit legal bases. China's PIPL and Data Security Law, Brazil's LGPD, India's DPDP Act, and a growing list of Asia Pacific laws all contain transfer provisions with their own mechanisms, so a global AI estate now has to satisfy dozens of overlapping regimes rather than one.
How Does China's PIPL Shape AI Compliance?
China's PIPL, in force since November 2021, treats cross-border transfer as a regulated act with three permitted routes: passing the Cyberspace Administration of China's security assessment, signing the CAC's standard contract, or obtaining security certification. The security assessment route applies automatically when a data processor transfers important data, when it is a critical information infrastructure operator, or when it processes the personal information of more than one million individuals; the standard contract route is the default for most commercial operators below those thresholds. Both routes come with mandatory filing obligations and ongoing responsibilities — a security assessment, once approved, is not a one-time permit but a basis for supervision and re-assessment.
For AI specifically, the stakes are higher than for routine HR or CRM data. Training datasets frequently aggregate personal information across multiple business lines, which can push a company past the one-million-individual processing threshold without any single project intending it; model serving through a centralised cloud in another region can constitute a transfer even when the model itself contains no raw personal data, if outputs or fine-tuning data include identifiable information. The interplay with the Data Security Law's classification of "important data" adds a further layer: sectors such as finance, telecoms, and healthcare face sectoral localisation rules that can make a centralised global AI platform legally impossible for certain datasets. Enterprises that design AI systems to minimise personal data at the source — through aggregation, pseudonymisation, and on-premises inference for sensitive workloads — substantially reduce the surface area these rules govern.
How Do You Choose Between Adequacy, SCCs and BCRs?
The choice of transfer mechanism follows a decision tree rather than a default. Adequacy is the cheapest option but applies only where the EU has formally recognised the destination — Japan (2019), South Korea (2021), the UK (2021), and the EU-US Data Privacy Framework among them — and only to data moving into that jurisdiction. Where adequacy does not apply, SCCs are the workhorse: the current EU SCCs cover controller-to-controller, controller-to-processor, processor-to-processor, and processor-to-controller transfers in one modular document, and the UK has its own International Data Transfer Agreement for transfers out of the UK. BCRs are a more ambitious instrument — a binding internal code of conduct approved by a lead supervisory authority that covers the whole corporate group and removes the need for SCCs on each intra-group transfer — but they take months or years to draft and approve, so they make sense only for groups that move significant volumes of personal data internally.
Several practical rules keep the choice manageable:
- Map the flows first — build a transfer register of every destination country, data category, purpose, and mechanism before choosing instruments, because SCCs are only as good as the inventory they cover
- Pair every mechanism with a transfer impact assessment — Schrems II requires you to verify that the destination's law gives the transferred data essentially equivalent protection, and to document the assessment
- Add supplementary measures where the TIA fails — technical safeguards such as end-to-end encryption, pseudonymisation, and access controls can bridge gaps that contract terms cannot
- Review annually — adequacy decisions can be revoked (as Privacy Shield was), SCCs are re-issued periodically, and new laws change the analysis, so the register needs a scheduled review, not a one-off exercise
How Do You Operationalise Transfer Compliance With TIAs, Contracting and Monitoring?
With the mechanism chosen, the real work is operational: embedding transfer compliance into procurement, cloud architecture, and incident response. In procurement, every vendor contract that touches personal data must name the transfer mechanism, annex the current SCCs, and carry obligations that survive the contract term; in practice, standard vendor questionnaires and clauses fall behind the December 2024 deadline, so in-house counsel should maintain a current clause library. In architecture, the transfer surface can be shrunk deliberately: regional data residency, in-region model serving, and data-minimising pipelines that send aggregates rather than raw records reduce the number of regulated flows. And because supervisory authorities increasingly ask for evidence rather than promises, the monitoring layer matters: a live transfer register, automated alerts when a vendor changes its hosting region, and documented TIAs for each high-risk flow.
The same operational discipline applies to AI suppliers. A foundation model hosted in one region but trained with data from another creates transfers that the model vendor may not disclose; due diligence must therefore ask where training, fine-tuning, and inference physically occur, and what the vendor's own transfer basis is. For global AI estates, the pragmatic standard is to build for the strictest regime in your footprint — the EU's transfer rules and China's filing regimes are both de facto global standards for multinationals — and treat transfer compliance as a continuous process, not a pre-launch checkbox. Companies that do this convert a regulatory liability into a procurement advantage, because they can demonstrate, in a single dashboard, exactly where every dataset resides and under what legal authority.
How Do You Build a Proactive AI Compliance Programme?
Proactive transfer compliance is a programme with five moving parts: a complete data-flow map that is updated when systems change; a transfer mechanism register that records adequacy, SCC, BCR, or PIPL route per flow; a TIA pipeline with templates and review owners; a contract library that keeps clauses current with EDPB and national guidance; and an escalation path that triggers an assessment whenever a destination country's law changes materially — new surveillance legislation, a new adequacy decision, or a court ruling such as Schrems II.
The programme also needs governance to survive. Transfer risk should be owned by a named individual — typically the DPO or privacy counsel — with a board-level reporting line, because transfer failures are enforcement and business-continuity events, not administrative slips. Reviews should run on a fixed calendar aligned with the regulatory cycle: the EDPB's guidance updates, the annual adequacy review cycle, and the CAC's supervision of security assessments all follow predictable rhythms that a scheduled programme can absorb. Finally, the programme should be tested: run a transfer drill — simulate a regulator requesting your transfer documentation, or a vendor announcing a hosting-region change with 30 days' notice — and fix whatever breaks, because the drill is far cheaper than the enforcement action it rehearses. Enterprises that treat cross-border transfer as a designed, monitored, and rehearsed process will find that data movement becomes a business enabler; enterprises that treat it as paperwork will keep rediscovering the cost in stalled launches and regulator inquiries.
How Do You Run a Transfer Impact Assessment That Holds Up?
The transfer impact assessment (TIA) is the document regulators expect when data leaves a jurisdiction, and most organisations write it once and never revisit it. A TIA that holds up is a living artefact: it maps the exact data flows, identifies the lawful mechanism (adequacy, SCCs, or BCRs), and assesses the real risk that the receiving country's law could compel disclosure despite the contract. For AI systems that ship training or inference data across borders, the TIA must cover not just the stored records but the derived datasets, embeddings, and model weights that may themselves be personal data in some regimes.
The practical discipline is to keep the TIA close to the architecture. When a new model or a new region is added, the data team should be able to regenerate the affected portion of the TIA from the lineage graph rather than reconstructing it by hand. We couple the TIA to the same catalogue that drives integration, so that a cross-border flow cannot go live without a recorded mechanism and an owner. Regulators in the EU and China alike have shown they will ask for the mechanism and the evidence on short notice; the organisations that answer quickly are the ones that treated the TIA as infrastructure, not paperwork.
What Should You Do When Rules Conflict Across Regions?
Conflicting regimes are the normal state, not the exception. China's PIPL emphasises separate consent and localisation for important data; the EU's GDPR stresses transfer mechanisms and individual rights; sector rules such as HIPAA add their own constraints. The error is to build a different system per regime and hope they never meet. The more robust approach is a single data-governance core — classification, purpose limitation, consent records, and deletion rights — with jurisdiction-specific policy expressed as configuration on top, so the same platform behaves correctly whether a record is in Frankfurt, Singapore, or Shenzhen.
Where rules genuinely conflict, default to the stricter control for the affected data class and document the reasoned decision. We advise clients to maintain a publicly defensible position: which regime they build to first (usually the strictest they operate under), and how they reconcile the rest. That position, backed by lineage and audit, is what survives a regulatory inspection and what lets the business expand internationally without re-architecting for every border it crosses.
How Do You Train Teams to Stay Compliant?
Compliance training fails when it is a once-a-year slide deck. Cross-border transfer compliance sticks when it is built into the engineering workflow: a developer who adds a new cross-border flow is prompted for the mechanism, the TIA fragment, and the owner before the change ships, and the catalogue rejects the flow without them. The training is then just-in-time and contextual, delivered at the moment the decision is made, which is when people actually absorb it.
The second lever is making the rule legible. Most engineers do not know whether a dataset is "important data" under Chinese rules or warrants a transfer impact assessment under EU rules, so the governance layer should state it in plain language next to the data asset. When the system tells the builder "this flow needs an SCC" rather than expecting them to recall it, compliance becomes a property of the pipeline instead of a prayer. We pair this with short, scenario-based refreshers tied to real incidents, because people learn transfer compliance from near-misses, not abstracts.
What Does a Maturing Transfer Programme Look Like?
A maturing programme moves from reactive to predictive. Early on, teams scramble to document transfers after a regulator asks; maturing teams have the transfer inventory current by construction, because nothing crosses a border without a recorded mechanism. Further along, the programme uses the lineage graph to flag a proposed new flow that would conflict with an existing position, and the DPIA or TIA is regenerated automatically rather than rewritten by hand.
The sign of maturity is that compliance accelerates the business rather than blocking it. When a new region or model is proposed, the team can see in minutes which transfers are already sanctioned and which need a new assessment, instead of a weeks-long archaeology project. Organisations that reached this state treated transfer compliance as part of the integration platform from the start; those that bolted it on later paid for the retrofit in both budget and a period of unavoidable exposure.
