A dataset can sit in a Frankfurt facility, never leave it, and still be reachable by a foreign authority, because the company operating that facility answers to a legal system outside the European Union.
Residency describes where data sits, whereas jurisdiction decides who can compel its production and the two are set by different things.
That gap is where most compliance work actually happens, and AI training opens it wider than any other workload. Our guide to data sovereignty in AI maps the full regulatory picture.
This post covers three narrower questions: when a compute step legally becomes a cross-border transfer, how secure the mechanism permitting those transfers currently is, and what to ask a provider before accepting a residency claim.
When a compute step becomes a transfer
The GDPR never defines “transfer”, which is why vendor material can describe identical architectures in incompatible terms. The European Data Protection Board closed that gap in Guidelines 05/2021, setting three cumulative criteria. All three must be met:
- The exporter, whether controller or processor, is subject to the GDPR for that processing
- The exporter transmits or otherwise makes the personal data available to another controller, joint controller or processor
- That importer is in a third country
The second criterion is broader than it first appears. The EDPB states plainly that remote access from a third country, or storage in a cloud outside the EEA, is enough to satisfy it. Since processing under the GDPR covers using data as well as storing it, a training or inference call executed by a third-country processor is a transfer even where the dataset at rest never moves. A persisted copy staying in Europe settles nothing on its own.
The first and third criteria are narrower than many teams assume. A transfer requires two separate parties, so an engineer employed by the EU controller who accesses data while travelling is not making a Chapter V transfer. There is no importer. The test turns on legal entities, not on passports or coordinates.
Trained weights sit awkwardly across this. Models can memorise fragments of their training data, so a checkpoint derived from EU personal data is a live question under the transfer regime rather than an inert file, and the same three criteria apply to it. Pre-training on public web data raises little.
Fine-tuning on customer records produces an artefact whose legal character depends on what it retains, which means a pipeline can be fully resident at every storage step and still leak jurisdiction twice, once at the compute step and once at the model it produces.
The bind that Article 48 creates
The usual framing is that a US provider can be compelled to produce EU data under the CLOUD Act. The half of the picture that gets left out is that European law forbids it from complying.
Article 48 GDPR provides that a judgment or administrative decision from a third country requiring disclosure is recognisable or enforceable only where it rests on an international agreement, such as a mutual legal assistance treaty, in force between that country and the Union or a member state.
The CLOUD Act was drafted specifically to bypass the MLAT route. The EDPB has published dedicated guidance on Article 48, and its position is that a foreign court order does not by itself make a transfer lawful.
A provider caught between the two faces a choice with no clean side:
- Comply with the US order and breach Article 48, exposing itself to supervisory action and its customer to a documented unlawful transfer
- Refuse and face contempt proceedings in the United States
Contractual language does not resolve this. Standard Contractual Clauses record an intention to protect data and cannot override a lawful order in the importer’s jurisdiction.
What removes the bind is structural: if no entity in the chain is subject to third-country compulsion, the conflict never arises.
The mechanism most transfers rely on is under appeal
Transatlantic transfers remain lawful. The EU-US Data Privacy Framework provides an adequacy basis, and on 3 September 2025 the General Court dismissed the first direct challenge to it in Latombe v Commission, Case T-553/23.
The reassurance is narrower than the headline, for three specific reasons:
- The judgment was time-limited – The Court assessed the framework only as it stood when the Commission adopted the adequacy decision in 2023, expressly declining to consider anything after that date.
- It is under appeal – Latombe appealed to the Court of Justice on 31 October 2025 as Case C-703/25 P, on four grounds including the independence of the US Data Protection Review Court and the absence of prior judicial authorisation for bulk collection.
- Both predecessors were struck down – Safe Harbour fell in Schrems I, Privacy Shield in Schrems II, and a third challenge is widely expected.
An architecture with a decade of life in it is being built on a mechanism invalidated twice and now before the Court of Justice a third time.
That is a risk to price into the design. Binding Corporate Rules and SCCs remain available as fallbacks, though each still requires a transfer impact assessment documenting the importer’s national law, which is the same analysis that produced the problem in the first place.
Auditing a residency claim
Most residency disputes come down to two parties using one word for different guarantees. Four distinctions separate a commitment from a marketing line:
- Storage at rest against in-region processing – Residency usually refers to where the persisted copy lives. The guarantee that data is also used inside the region is separate, narrower and often newer. A provider can hold data at rest in Europe while routing the inference call that reads it elsewhere.
- No training against no retention – Independent claims. A provider can commit to never training on your data while still logging it for weeks under a foreign jurisdiction, and neither commitment is a residency guarantee.
- Support and administrative access – Data can sit in the EU while the engineers with production access sit outside it. Where those engineers belong to a separate legal entity, the third EDPB criterion is met and a transfer is taking place.
- The subprocessor chain – The entity on the contract is frequently not the entity operating the hardware, and a residency commitment inherits the weakest link in that chain.
One question resolves most of them: which legal entity operates each layer, and under whose law can it be compelled to act? Where the answer names a US parent, the CLOUD Act reaches the data wherever it sits, a point developed in our companion post on why the EU AI Act demands localised compute infrastructure.
What the AI Act adds
The AI Act’s high-risk obligations, particularly data governance under Article 10 and automatic logging under Article 12, assume the underlying personal-data processing is locatable and lawful under the transfer rules.
Compliance dates moved under the Digital Omnibus, which entered into force in July 2026, while the substance stayed as drafted, and biometric and identity systems remain inside the Annex III high-risk list. The companion post covers those obligations and the revised dates in full.
The practical effect is that residency documentation which passed as a filing exercise now gets read by an auditor alongside a logging requirement, against a system the auditor may have no standing to inspect.
Residency is a floor
Choosing an EU region does genuine work. It keeps most of a workload clear of Chapter V’s transfer machinery and satisfies the question procurement usually asks first. It settles nothing about who controls the infrastructure, which is what decides whether a foreign production order can reach the data and whether Article 48 puts your provider in an impossible position.
Where every processor in the chain answers only to EU law, there is no third-country importer to assess, no transfer impact assessment to defend, no conflict of laws to manage, and no dependency on an adequacy decision currently before the Court of Justice.
Working out which AI workloads can tolerate a cross-border transfer and which need a genuinely sovereign perimeter is where this stops being a legal exercise and becomes an infrastructure decision.
Neurotechnology Cloud operates private AI cloud services and engineers AI factory environments on EU-resident infrastructure, with the operating entity, the subprocessors and the engineers holding production access all inside the European Union.
