EU / European Union / revised 28 Oct 2026
GDPR Chapter V and AI Inference: A Transfer Guide
Every prompt that carries personal data and leaves the EEA for a model endpoint is a restricted transfer, even if the provider deletes it a second later. Chapter V gives you four lawful routes: an adequacy decision, an Article 46 safeguard, binding corporate rules, or a narrow Article 49 derogation. Inference traffic rarely fits the derogations, so the practical choice is between in-region processing and a documented safeguard backed by a transfer impact assessment.
- Citation
- Regulation (EU) 2016/679, Chapter V, Articles 44 to 49
- Regulator
- European Data Protection Board and national supervisory authorities
- In force
- 25 May 2018
- Maximum penalty
- EUR 20 million or 4% of worldwide annual turnover, whichever is higher (Article 83(5)(c))
Article 44: the general principle
Article 44 makes any transfer of personal data to a third country or international organisation conditional on compliance with the rest of Chapter V, and extends the same condition to onward transfers. Nothing in the text exempts transient processing. A prompt that is decrypted, tokenised and run through a model in Virginia has been transferred, regardless of whether the provider stores it.
The EDPB Guidelines 05/2021 on the interplay between Article 3 and Chapter V set out when a disclosure counts as a transfer: the exporter is subject to the GDPR for that processing, it discloses or makes data available to another controller or processor, and the importer is in a third country. Sending a prompt from an EU application to a US-hosted model API meets all three.
Article 45: adequacy decisions
Where the Commission has found that a country ensures an adequate level of protection, transfers need no further authorisation. Adequacy covers jurisdictions such as Switzerland, the United Kingdom, Japan, the Republic of Korea, Canada (commercial organisations) and New Zealand. For the United States, adequacy applies only to organisations self-certified under the EU-US Data Privacy Framework, so the importing entity, not the country, is what you check.
Articles 46 and 47: appropriate safeguards and BCRs
Without adequacy, Article 46 permits transfers subject to appropriate safeguards, provided enforceable rights and effective remedies are available. The workhorse is the set of standard contractual clauses adopted by Commission Implementing Decision (EU) 2021/914, with Module 2 (controller to processor) and Module 3 (processor to processor) covering most model API contracts. Article 47 binding corporate rules suit intra-group routing to a parent's own GPU cluster. Since Schrems II, both must be paired with an assessment of the destination's law and, where needed, supplementary measures.
Article 49: derogations are not an architecture
Article 49 allows transfers on explicit consent, contract necessity, important public interest, legal claims and a few other grounds. The EDPB reads these restrictively: they are for occasional, non-repetitive transfers. Thousands of daily inference calls are systematic by definition, so a production LLM integration cannot rest on Article 49.
- 01
Resolve the processing location before the request leaves
The gateway must know the provider region, legal entity and facility for each upstream endpoint before it forwards a byte. Routing decisions taken after DNS resolution to a global anycast hostname are too late to evidence where processing happened. - 02
Jurisdiction-bound failover
Availability incidents are where unplanned transfers happen. Failover pools must be constrained to endpoints in the same legal regime (Frankfurt to Dublin or Amsterdam), and a regional outage should fail closed rather than spill traffic to a US region. - 03
Importer identity per endpoint
Chapter V attaches to the receiving entity. Record for every endpoint whether the importer is DPF-certified, covered by SCCs, or bound by BCRs, so a policy can decide on the legal tool rather than on a hostname. - 04
Per-request transfer evidence
Supervisory authorities ask controllers to demonstrate compliance (Article 5(2)). A signed receipt naming the resolved endpoint, provider region and policy version for each call turns a contractual promise into evidence an auditor can sample. - 05
Minimise before you route
Mask or pseudonymise direct identifiers in the prompt when the destination is outside the EEA, keeping the re-identification key in-region, so what crosses the border carries less risk.
| # | Rule | Legal rationale |
|---|---|---|
| 01 | Deny egress to non-adequate countries when X-YTT-Policy is eu-gdpr-strict. | Article 44 conditions every transfer on Chapter V. The strict pack removes the need for an Article 46 assessment by keeping processing inside the EEA or adequate destinations. |
| 02 | Permit US endpoints only when the importing entity appears as active on the Data Privacy Framework list with non-HR data in scope. | The Article 45 adequacy decision of 10 July 2023 covers certified organisations only, and only for the data categories they certified. |
| 03 | Restrict failover to endpoints sharing the origin jurisdiction tag. | An outage does not create an Article 49 derogation. Cross-border failover would be an unassessed systematic transfer. |
| 04 | Require an attached TIA reference for any route that relies on Article 46 SCCs. | After Schrems II, SCCs alone are insufficient without an assessment of the destination's law under Clause 14 of the 2021 SCCs. |
| 05 | Reject requests that cite Article 49 as the transfer basis in policy metadata. | Derogations are for occasional transfers. Inference traffic is repetitive, so a derogation basis signals a design error. |
eu-gdpr-strict
The rules above, written as Open Policy Agent Rego (v1 syntax). The gateway evaluates the pack in-process in every regional data plane before forwarding a request; YTT Secunet measures median evaluation under 3 ms in production.
Packs are versioned and signed. The version that decided each request is named in the residency receipt, so an auditor can match the decision to this exact text.
How the policy engine workspackage yttsecunet.policies.eu_gdpr_strict
import rego.v1
adequate := {"AD", "AR", "CA", "CH", "FO", "GB", "GG", "IL", "IM", "JE", "JP", "KR", "NZ", "UY"}
eea_or_adequate(country) if input.eea_countries[country]
eea_or_adequate(country) if adequate[country]
dpf_certified if {
input.endpoint.country == "US"
input.endpoint.importer.dpf_status == "active"
"non-hr" in input.endpoint.importer.dpf_scope
}
default allow := false
allow if eea_or_adequate(input.endpoint.country)
allow if dpf_certified
deny contains msg if {
not allow
msg := sprintf("chapter v: no transfer tool for %s", [input.endpoint.country])
}Each item is verifiable against configuration, signed receipts or contract records. Tick through it with your DPO.
If the provider uses zero data retention, is it still a transfer?
Yes. Chapter V turns on access and processing in the third country, not on storage. Zero retention reduces what could later be disclosed, which helps the transfer impact assessment, but it does not remove the need for a transfer tool.
Is an EU region of a US-parented hyperscaler a transfer?
Processing in an EU region is not a Chapter V transfer in itself. The separate question is whether the parent can be compelled to produce the data under US law, which belongs in your risk assessment and is covered in our CLOUD Act guide.
Does YTT Secunet decide which transfer tool applies?
No. Your DPO or counsel selects the legal basis. YTT Secunet enforces the routing consequence of that decision and produces evidence that each request followed it.
Sovereign route ready
Stop risking 4% global turnover GDPR fines on AI inference.
Deploy sovereign, cryptographically proven AI routing in 15 minutes.