A foundation-model API call looks like a single HTTPS request. Behind it sits a chain of jurisdictions: the keystrokes originate in Frankfurt, the load balancer routes through Dublin, the inference happens in a US-east-region GPU cluster, the response is logged in a vendor's North-Virginia observability platform, the backup snapshot replicates to Oregon, and the long-term audit log lands in a SaaS LMS hosted in Singapore. Each hop is a potential cross-border personal-data transfer under GDPR Articles 44-49: and after the Court of Justice's 2020 Schrems II judgment (Case C-311/18), each hop demands a Transfer Impact Assessment (TIA), a Standard Contractual Clauses (SCCs) instrument or adequacy decision, and a documented set of additional safeguards. This is the lesson where a Data Protection Officer who has been told "the vendor is EU-US Data Privacy Framework certified, so we are fine" discovers that the DPF certification covers a narrower scope than the inference path her engineering team actually wired up. Lesson 039 is the inference-endpoint geography map, the per-vendor residency catalogue for the major foundation-model providers, the Schrems II TIA template, the sector overlays, and the six common mistakes that turn a 2026 DPIA into a 2027 enforcement action.

The Inference Transfer Problem - Why AI Reopens Schrems II

GDPR Article 44 sets the general principle: any transfer of personal data to a third country (a country outside the EEA) or international organization may take place only if the controller and processor comply with the conditions in Chapter V. The conditions are sequenced. Article 45 covers adequacy decisions (the European Commission has decided the third country provides an adequate level of protection). Article 46 covers appropriate safeguards (Standard Contractual Clauses, Binding Corporate Rules, approved codes of conduct, certification mechanisms). Article 47 covers Binding Corporate Rules specifically. Article 49 covers derogations for specific situations (explicit consent, contract necessity, important reasons of public interest, vital interests, legal claims).

Pre-2020, the EU-US Privacy Shield was the primary adequacy framework for transfers to the United States. In Schrems II, the Court of Justice invalidated Privacy Shield, holding that US surveillance law (Section 702 of FISA, Executive Order 12333) provided neither essentially equivalent protection nor effective judicial redress for EU data subjects. The judgment also clarified that Standard Contractual Clauses remained valid in principle but required a case-by-case Transfer Impact Assessment of the destination country's law and an evaluation of additional safeguards needed to bring the transfer up to the EU's essentially-equivalent standard.

The European Data Protection Board's Recommendations 01/2020 on measures that supplement transfer tools to ensure compliance with the EU level of protection of personal data (final version 18 June 2021) operationalized Schrems II with a six-step roadmap: (1) know your transfers; (2) identify the transfer tool relied upon; (3) assess whether the transfer tool is effective in light of the destination-country law; (4) adopt supplementary measures where needed; (5) take formal procedural steps for supplementary measures; (6) re-evaluate at intervals.

The EU-US Data Privacy Framework (DPF), adopted by Commission Implementing Decision (EU) 2023/1795 on 10 July 2023, restores adequacy for transfers to US organizations that self-certify with the Department of Commerce. The DPF addresses Schrems II's concerns through Executive Order 14086 (signals-intelligence necessity-and-proportionality limits) and the Data Protection Review Court (binding-decision redress mechanism). Max Schrems / noyb filed a challenge to the DPF; the case (commonly referred to as Schrems III) is pending before the CJEU as of May 2026. Until the CJEU rules, the DPF remains the operative US adequacy basis, but every Data Protection Officer must plan for the contingency that the DPF is invalidated, the same way Privacy Shield was.

AI inference adds three new dimensions to the Schrems II analysis that pre-2020 controllers did not have to confront. First, prompts and outputs travel as personal data when they contain identifiers, quasi-identifiers, or special categories under GDPR Article 9, a sales-team prompt containing a customer name or an HR-team prompt containing an employee evaluation triggers Chapter V analysis. Second, inference may happen in a different region than the user, the application, the storage, or the logging, the inference endpoint geography becomes a distinct residency question. Third, the model weights themselves may carry training-data residency implications (especially for fine-tuned models containing extracted memorizations of EU personal data). The lesson sequences these dimensions explicitly.

Five Residency Questions for Every AI System

The inference-endpoint geography problem is not solved by asking the vendor "are you EU-resident." It is solved by mapping five distinct residency questions per AI system:

• API endpoint geography, Where is the request physically processed? The customer-facing API URL (e.g., api.openai.com, api.anthropic.com, regional Bedrock endpoints) determines the entry point. Many vendors offer regional endpoints (EU, US, APAC) and route inference within the selected region. Some vendors offer a single global endpoint with internal routing. These require contractual residency commitments to constrain geography.
• Model-weight residency, Where are the model weights stored at rest? For SaaS API products, the weights live on the vendor's infrastructure; for self-hosted or single-tenant deployments (Azure OpenAI Service in a specific Azure region, AWS Bedrock single-tenant deployments, Google Cloud Vertex AI in a specific GCP region), the weights live in customer-selected geography.
• Training-data residency, Where did the training happen? This question rarely has a clean answer for foundation models trained globally on public-web data. For fine-tunes, the fine-tune dataset residency is a separate question that the customer controls.
• Logging residency: Where are prompts and outputs logged for vendor abuse-monitoring, vendor product-improvement, or customer observability? Vendor abuse-monitoring logs often replicate to the vendor's home region regardless of the inference region. Customer observability (Datadog, New Relic, Splunk, internal SIEM) adds another residency question.
• Backup and disaster-recovery residency, Where are backup snapshots stored? DR may replicate logs and inference data to a different region than the primary processing region. Cross-region DR is a common Schrems II oversight.

The customer must answer all five questions per AI system and document the answer in the Article 30 record of processing activities (RoPA) and the DPIA. A vendor's claim of "EU residency" without specifying which of the five layers it covers is incomplete.

Per-Vendor Residency Analysis - The Major Foundation-Model Providers

OpenAI - Direct API, ChatGPT Enterprise, Azure OpenAI Service

OpenAI's direct API (api.openai.com) historically defaulted to US processing. OpenAI introduced European data residency for API customers on the ChatGPT Enterprise and Team plans, and Zero Data Retention (ZDR) endpoints became available on opt-in basis. ChatGPT Enterprise EU data residency commits to inference, storage, and logging within the EU for enterprise customers; ChatGPT Team and consumer ChatGPT continue to route through US infrastructure. OpenAI is EU-US DPF certified at the Department of Commerce (Active status as of May 2026), so US-routed processing has a DPF transfer basis, but the controller still owes the underlying DPIA and the inference-geography documentation.

Azure OpenAI Service, a Microsoft-operated re-hosting of OpenAI models on Azure infrastructure, offers EU regions (Sweden Central, France Central, North Europe / Ireland, Switzerland North, Germany West Central). When the customer selects an EU region, inference, storage, and prompt logging are constrained to that region. Microsoft's EU Data Boundary commitment (which expanded to cover paid Microsoft cloud services including Azure OpenAI Service) provides additional residency assurance for EU customers. Azure OpenAI Service is the most common path for EU enterprises that want OpenAI models with EU residency commitments.

Anthropic - Direct Claude API, AWS Bedrock, Google Cloud Vertex AI

Anthropic's direct Claude API (api.anthropic.com) processes inference in US regions by default. Anthropic is EU-US DPF certified; the DPF supports US-routed processing as the transfer basis. EU residency for Claude is available through two cloud channels: AWS Bedrock and Google Cloud Vertex AI. AWS Bedrock supports Claude models in EU regions (eu-west-1 Ireland, eu-west-3 Paris, eu-central-1 Frankfurt, eu-north-1 Stockholm), when the customer invokes the Bedrock Claude endpoint in an EU region, inference and storage are constrained to that region under AWS's Customer Agreement and Data Processing Addendum. Google Cloud Vertex AI similarly offers Claude in EU regions. The model weights for cloud-hosted Claude are deployed by Anthropic to the cloud provider's infrastructure under a controlled deployment; the customer's data does not leave the customer-selected region during inference.

Google Gemini - Vertex AI and AI Studio

Google Cloud Vertex AI offers Gemini models in EU regions (europe-west1 Belgium, europe-west4 Netherlands, europe-west9 Paris, europe-west3 Frankfurt). When the customer invokes Vertex AI Gemini in an EU region, inference is constrained to that region. Google is EU-US DPF certified for transfers to its US infrastructure. Google AI Studio (the consumer-developer entry point) historically routed through US infrastructure regardless of the developer's location. Google Workspace Gemini integrations are governed by the Workspace Data Processing Addendum and Workspace region commitments. The Vertex AI path is the production-grade EU-residency path for Gemini.

AWS Bedrock - Multi-Model Foundation-Model Hosting

AWS Bedrock hosts Claude (Anthropic), Llama (Meta), Mistral, Cohere, Amazon Titan, Amazon Nova, and other models. EU regions for Bedrock include eu-west-1 (Ireland), eu-west-3 (Paris), eu-central-1 (Frankfurt), eu-north-1 (Stockholm). AWS is EU-US DPF certified; the AWS GDPR Data Processing Addendum binds the per-region commitments. AWS announced the AWS European Sovereign Cloud (planned launch by end of 2025 in Brandenburg, Germany) for customers with sovereign-cloud requirements; the European Sovereign Cloud has a separate operating boundary from the standard AWS commercial regions. Sector regulators in highly-regulated industries (defense, intelligence, certain public-sector) increasingly require sovereign-cloud commitments beyond the standard DPF + SCCs posture.

Microsoft Azure OpenAI - EU Data Boundary and Sovereign Cloud

Microsoft Azure OpenAI Service, covered above for OpenAI residency, sits under Microsoft's broader EU Data Boundary commitment. The EU Data Boundary commits to processing and storing customer data and Microsoft-generated logs for paid Microsoft cloud services (Microsoft 365, Dynamics 365, Power Platform, Azure including Azure OpenAI Service) within the EU and EFTA. The EU Data Boundary was completed in February 2025 and expanded to cover technical support data in March 2025. Microsoft is EU-US DPF certified. Microsoft Cloud for Sovereignty offers sovereign-cloud configurations for public-sector and regulated customers. Bleu (Microsoft + Capgemini + Orange) is the announced French sovereign-cloud joint venture offering Microsoft 365 and Azure under a French-regulated entity.

Meta Llama - Self-Hosted or Cloud-Hosted

Meta Llama models (Llama 3.1, Llama 3.3, Llama 4) are typically deployed via cloud-provider hosting (AWS Bedrock, Azure AI Foundry, Google Cloud Vertex AI, Together AI, Anyscale, Replicate, etc.) or self-hosted in customer infrastructure. The cross-border data transfer analysis depends on the chosen hosting path. Self-hosting in customer EU infrastructure removes the third-country-transfer question entirely (no transfer occurs). Cloud-hosted Llama inherits the hosting cloud's residency posture (AWS Bedrock EU regions, Azure EU regions, Vertex AI EU regions). Meta-direct API access is not the typical enterprise deployment path for Llama.

DeepSeek and Chinese-Hosted Models - Significant Restrictions

DeepSeek, Qwen (Alibaba), and other Chinese-hosted foundation models present a meaningfully different cross-border data-transfer profile. Inference on DeepSeek's hosted API routes through China-based infrastructure. China has no EU adequacy decision; transfers to China rely on SCCs + additional safeguards under Schrems II, and the TIA for China must consider the National Intelligence Law of the People's Republic of China (2017), the Data Security Law (2021), and the Personal Information Protection Law (PIPL, 2021). PIPL Article 38 governs cross-border transfers out of China; PIPL Article 39 imposes notice obligations on data subjects. Many EU enterprises restrict or prohibit use of China-hosted models for personal-data processing; self-hosting open-weight Chinese models (DeepSeek-V3, Qwen 2.5) in EU infrastructure removes the transfer-to-China question but does not address the model-provenance and training-data-residency questions that some regulators may treat as separate concerns.

Schrems II TIA Template Applied to AI Inference

The Transfer Impact Assessment is the centerpiece of post-Schrems II documentation. EDPB Recommendations 01/2020 set out the six-step roadmap; the controller's TIA must operationalize the roadmap per transfer. A practical Schrems II TIA template for an AI inference transfer has six sections:

Section 1 - Mapping the transfer. Identify the exporter (the EU-based controller / processor sending the data), the importer (the third-country recipient processing the data), the categories of data (prompts, outputs, embeddings, metadata, telemetry, logs), the categories of data subjects (employees, customers, third parties), the purposes of processing, the recipients of the data (sub-processors of the importer), the storage location, the transfer mechanism (HTTPS API, file upload, batch export), and the retention period. For an AI inference transfer this section documents all five residency layers (API endpoint, model weights, training data, logging, backup).

Section 2 - Identifying the transfer tool. Adequacy decision (Article 45), does the destination country have an adequacy decision (US under DPF; UK; Switzerland; Japan; Korea; New Zealand; Canada commercial; Andorra; Argentina; Faroe Islands; Guernsey; Isle of Man; Israel; Jersey; Uruguay)? Standard Contractual Clauses (Article 46(2)(c) or (d); Commission Implementing Decision (EU) 2021/914)? Binding Corporate Rules (Article 47)? Approved codes of conduct (Article 46(2)(e))? Certification mechanisms (Article 46(2)(f))? Derogations (Article 49)? For an AI inference transfer to a US-DPF-certified vendor, the transfer tool is the DPF adequacy. For an AI inference transfer to a non-DPF-certified vendor or to a non-adequate country, the transfer tool is typically SCCs Module 2 (controller-to-processor) or Module 3 (processor-to-processor).

Section 3 - Assessment of the destination-country law. Identify the surveillance laws, the legal framework for government access to data, the available redress mechanisms, the encryption regulations, the data-localization requirements, and the documented practices of the destination-country authorities. For US transfers, document Section 702 FISA, Executive Order 12333, the CLOUD Act, the Foreign Intelligence Surveillance Court framework, Executive Order 14086 (post-Schrems II signals-intelligence reform), the Data Protection Review Court (DPF redress mechanism). For UK transfers, document the Investigatory Powers Act 2016 and the UK adequacy decision (Commission Implementing Decision (EU) 2021/1772, expiring 27 June 2025; subject to renewal review). For China transfers, document the National Intelligence Law, Data Security Law, and PIPL Articles 38-39. For other destinations, document the equivalent surveillance and access frameworks.

Section 4 - Assessment of effectiveness of the transfer tool in light of destination-country law. Evaluate whether the SCCs or the adequacy decision, in light of the destination-country surveillance framework, provide an essentially-equivalent level of protection. If yes, document the conclusion and the supporting analysis. If no, proceed to Section 5 for supplementary measures.

Section 5 - Supplementary measures. EDPB Recommendations 01/2020 lists three categories: technical measures (encryption in transit and at rest with controller-held keys; pseudonymization; split-processing / multi-party computation; ephemeral data with short retention); contractual measures (notification obligations on the importer when a government access request is received; cooperation obligations on the importer for the data subject's redress; pass-through of obligations to sub-processors; choice-of-law and forum clauses); organizational measures (policies for handling government access requests; transparency reports; staff training; access controls; segregation of duties). For an AI inference transfer the typical supplementary measure stack is: TLS 1.3 in transit + envelope encryption at rest + customer-managed keys via cloud KMS (KMS in EU region) + pseudonymization of prompt content where possible + Zero Data Retention configuration on the inference endpoint + SCCs + DPA + sub-processor flow-down language + incident-notification obligations.

Section 6 - Procedural steps and re-evaluation. Execute the SCCs; update the Article 30 RoPA; brief the DPO; complete the Article 35 DPIA where the transfer is part of a high-risk processing operation; communicate to data subjects under Articles 13-14; calendar re-evaluation at least annually or upon any change to the destination-country legal landscape (e.g., a Commission decision invalidating an adequacy; a court ruling on surveillance law; a new sub-processor in a different country).

Sector-Specific Overlays

The Schrems II TIA is the GDPR base. Sector-specific overlays add further constraints:

Financial services. The European Banking Authority's Guidelines on outsourcing arrangements (EBA/GL/2019/02) require financial institutions to assess country risk for outsourced material activities; cloud and AI outsourcing in a third country must demonstrate that effective supervision is possible. The Digital Operational Resilience Act (DORA, Regulation (EU) 2022/2554, applicable from 17 January 2025) adds ICT third-party risk-management requirements, including a register of information for ICT contractual arrangements, concentration-risk monitoring, and the new Critical ICT Third-Party Provider (CTPP) oversight regime supervised by the ESAs (EBA, ESMA, EIOPA). National banking regulators (BaFin in Germany, ACPR in France, De Nederlandsche Bank in the Netherlands, etc.) issue further guidance on cloud and AI outsourcing. The combination of EBA + DORA + national-regulator guidance often pushes financial institutions toward sovereign-cloud or EU-resident deployments for AI inference involving regulated data.

Healthcare. The EU Medical Device Regulation (MDR, Regulation (EU) 2017/745) and In Vitro Diagnostic Regulation (IVDR, Regulation (EU) 2017/746) apply to medical-device AI. The European Health Data Space Regulation (EHDS, Regulation (EU) 2025/327) entered into force on 26 March 2025 and is phased through 2031; the EHDS imposes secondary-use data-residency and access-control requirements for electronic health data. National health data laws (the German Patientendaten-Schutz-Gesetz, the French Code de la santé publique, etc.) overlay further constraints. US healthcare data brings HIPAA into the picture, and state laws (California CMIA, Washington My Health My Data Act, etc.) add further obligations.

Public sector. National sovereignty requirements vary by member state and increasingly by use case. France's SecNumCloud qualification (managed by ANSSI) is required for sensitive public-sector workloads. Germany's BSI Cloud Computing Compliance Controls Catalogue (C5) is the German federal benchmark. The European Cybersecurity Certification Scheme for Cloud Services (EUCS) under the Cybersecurity Act is in development; the proposed High+ assurance level included sovereignty requirements (HQ in EU, ownership control, immunity from third-country law) that have been the subject of significant industry debate. Public-sector AI deployments often require sovereign-cloud or on-premises hosting beyond what the standard DPF + SCCs posture provides.

UK. The UK has its own version of GDPR (UK GDPR) following Brexit. The UK adequacy decision from the European Commission (Commission Implementing Decision (EU) 2021/1772) provides EU-to-UK transfer basis, subject to renewal review (the decision expires 27 June 2025 and the Commission is reviewing renewal). UK-to-US transfers use the UK International Data Transfer Agreement (IDTA) or the UK Addendum to the EU SCCs, alongside the UK-US Data Bridge that extends the EU-US DPF to UK transfers. UK enterprises operating in the EU run dual UK GDPR and EU GDPR analyses.

China PIPL and Other Outbound-Transfer Regimes

China's Personal Information Protection Law (PIPL, in force 1 November 2021) imposes outbound-transfer requirements that mirror but do not mirror GDPR Chapter V. PIPL Article 38 sets out three primary outbound-transfer mechanisms: (1) Cyberspace Administration of China (CAC) security assessment for critical information infrastructure operators and high-volume processors; (2) certification by a specialized institution; (3) Standard Contract for cross-border transfers of personal information (the China SCCs, finalized June 2023). PIPL Article 39 imposes notice obligations on data subjects. The CAC published Provisions on Regulating and Facilitating Cross-Border Data Flows on 22 March 2024, raising thresholds and creating exemptions but maintaining the core regime. EU enterprises with China operations need a separate outbound-transfer compliance program for data leaving China, including AI inference data routed to non-China cloud providers for processing.

Other jurisdictions impose data-residency or outbound-transfer rules that intersect with AI inference: Russia (Federal Law 242-FZ data-localization for personal data of Russian citizens); India (Digital Personal Data Protection Act, 2023, with cross-border transfer rules to be specified by central government notification); Saudi Arabia (PDPL with localization preferences for certain data); UAE (federal Data Protection Law 45/2021 plus sector regulations); Brazil (LGPD with cross-border transfer rules); various national data-localization laws in Indonesia, Vietnam, Nigeria, Kenya, etc.

Six Common Schrems II Mistakes for AI Deployments

Mistake 1 - Treating Vendor DPF Certification as Blanket Coverage

A vendor's EU-US DPF certification covers the vendor's processing of personal data under the certified scope. It does not automatically cover every sub-processor, every region, or every use case the customer wires up. The customer must verify the vendor's certified scope (Department of Commerce DPF list), the sub-processor chain, the inference-endpoint geography actually used, and the supplementary measures appropriate for the specific data categories and processing operations.

Mistake 2 - Missing the Inference-Endpoint Geography

The customer-facing API URL is not always the processing geography. Vendors may route requests across regions for load-balancing, cost optimization, or model-availability reasons. The customer must verify the contractual residency commitment, the technical enforcement (regional endpoint vs. global endpoint with internal routing), and the operational monitoring. A documented inference-endpoint geography per system is the artifact the DPO needs.

Mistake 3 - Missing Logging Residency

Inference geography is often well-controlled; logging geography is often not. Vendor abuse-monitoring logs (the vendor's own observability of customer prompts and outputs for safety and policy enforcement) may replicate to the vendor's home region regardless of the inference region. Customer observability platforms (Datadog, New Relic, Splunk SaaS, etc.) add further residency exposure. The customer must inventory logging destinations and apply the residency analysis to each.

Mistake 4 - Missing Backup and DR Residency

Disaster recovery routinely replicates data to a different region than the primary. The DR region may be in a different country, a different jurisdiction, or even a different continent. The customer must inventory DR replication targets and apply the residency analysis to each. A primary EU-region deployment with a US DR target has a US transfer that needs Chapter V analysis.

Mistake 5 - Static TIA

The TIA is not a one-time artifact. Destination-country law evolves; vendor sub-processors change; new model regions become available; new logging integrations are added; the Schrems III ruling may invalidate the DPF. EDPB Recommendations 01/2020 Step 6 requires periodic re-evaluation. A static TIA from 2024 is increasingly stale; quarterly review is the prudent cadence for high-risk processing operations, annual review for lower-risk.

Mistake 6 - Missing the Sector-Specific Overlay

The GDPR Schrems II analysis is the floor, not the ceiling. Financial-services EBA + DORA + national-regulator guidance; healthcare MDR + EHDS + national-health-data laws; public-sector national sovereignty requirements; sector-specific localization mandates. These layer on top of the GDPR base and may force a different residency posture (sovereign cloud, on-premises hosting, prohibition of certain vendors) than the GDPR base alone would suggest. The TIA should sequence the sector overlay explicitly.

Cross-Walks - GDPR, EU AI Act, ISO 42001, NIST AI RMF

The cross-border AI data transfer regime crosses multiple frameworks:

• GDPR Articles 44-49 (Chapter V), The transfer-of-personal-data regime. Article 45 adequacy; Article 46 appropriate safeguards (SCCs, BCRs); Article 47 BCRs; Article 49 derogations. The Schrems II baseline.
• GDPR Article 28, Processor obligations; the Article 28 Data Processing Agreement is the contractual instrument that carries the SCCs and the supplementary measures.
• GDPR Article 30: Record of processing activities; the RoPA documents the categories of data, recipients, third-country transfers, transfer mechanisms.
• GDPR Article 35, Data Protection Impact Assessment; the DPIA is the high-risk-processing assessment that often runs alongside the TIA. The Article 27 EU AI Act FRIA is a distinct artifact that may share inputs with the GDPR Article 35 DPIA.
• GDPR Articles 13-14, Information to data subjects; cross-border transfers must be disclosed in privacy notices.
• EU AI Act Article 10, Data governance for high-risk AI systems; the data-governance documentation interlocks with the Article 30 RoPA on data sources and categories.
• EU AI Act Article 26, Deployer obligations including Article 26(8) GDPR compliance for DPIA purposes; Article 26 deployers running high-risk AI systems must ensure the GDPR overlay is operationalized.
• EU AI Act Article 50, Transparency obligations; cross-border AI processing should be reflected in the Article 50(1) chatbot disclosure and Article 50(3) emotion-recognition / biometric-categorization notices where applicable.
• EU AI Act Article 27, Fundamental Rights Impact Assessment for high-risk deployers; the FRIA documents data flows and may incorporate the TIA findings.
• EU-US Data Privacy Framework, Commission Implementing Decision (EU) 2023/1795; US adequacy basis; Department of Commerce certified-organization list; pending Schrems III challenge.
• UK International Data Transfer Agreement (IDTA), UK equivalent to the EU SCCs; UK-US Data Bridge extending the DPF.
• PIPL Article 38 / 39: China outbound-transfer mechanisms (CAC security assessment, certification, China SCCs) and data-subject notice.
• ISO/IEC 42001 Annex A control A.10, Third-party relationships; the third-party catalogue and the per-third-party assessment are the operational anchor for the AI vendor residency posture.
• ISO/IEC 27701, Privacy Information Management System extension to ISO 27001; the PIMS framework includes transfer-impact documentation requirements.
• NIST AI RMF GOVERN-6 (third-party), Third-party AI risk management; cross-border transfer is a GOVERN-6 sub-category.
• NIST AI 600-1 GenAI Profile, Risk #6 (Data Privacy) addresses cross-border data flows for generative AI specifically.

The L2 artifact for lesson 039 is a per-system inference residency map: API endpoint, model-weight residency, training-data residency, logging residency, backup/DR residency; transfer mechanism (adequacy / SCCs / BCRs); supplementary measures (encryption, KMS region, ZDR, pseudonymization); applicable sector overlays; TIA last-review date; next-review date. The map is the joint artifact of the DPO, the AI Officer, and the cloud-security team. Procurement carries it into every renewal. Audit uses it as ISO 42001 A.10 evidence and as GDPR Article 30 RoPA supporting documentation.

Key Takeaways

• AI inference reopens Schrems II. Every prompt and output that contains personal data triggers GDPR Chapter V analysis; the inference-endpoint geography becomes a new residency question alongside storage and logging.
• Five residency questions per AI system. API endpoint geography; model-weight residency; training-data residency; logging residency; backup and DR residency. Document all five; "the vendor is EU-resident" without specificity is incomplete.
• The EU-US Data Privacy Framework is the operative US adequacy basis as of May 2026. Commission Implementing Decision (EU) 2023/1795; Department of Commerce certified-organization list; Executive Order 14086 + Data Protection Review Court address the Schrems II surveillance and redress concerns; the Schrems III challenge is pending at the CJEU and prudent controllers plan for DPF invalidation contingency.
• Major foundation-model providers offer EU residency through specific channels. OpenAI via Azure OpenAI Service EU regions and ChatGPT Enterprise EU residency; Anthropic via AWS Bedrock and Vertex AI EU regions; Google Gemini via Vertex AI EU regions; AWS Bedrock with EU regions and AWS European Sovereign Cloud; Microsoft via Azure EU regions and EU Data Boundary. Meta Llama inherits the hosting-cloud residency. Chinese-hosted models (DeepSeek, Qwen) require separate analysis under PIPL and Schrems II.
• The Schrems II TIA has six sections per EDPB Recommendations 01/2020. Mapping the transfer; identifying the transfer tool; assessing destination-country law; assessing effectiveness; supplementary measures; procedural steps and re-evaluation. For AI inference, the TIA documents all five residency layers and the technical / contractual / organizational supplementary measures.
• Supplementary measures are the post-Schrems II differentiator. TLS 1.3 in transit; envelope encryption at rest with controller-held keys; pseudonymization of prompt content; Zero Data Retention configuration; sub-processor flow-down; incident-notification obligations; transparency reporting. The supplementary-measure stack moves the transfer toward essentially-equivalent protection.
• Sector overlays often dominate the GDPR base. Financial services (EBA outsourcing guidelines + DORA + national-regulator guidance); healthcare (MDR + EHDS + national health-data laws); public sector (SecNumCloud, BSI C5, EUCS, sovereign-cloud requirements). The sector overlay can push toward sovereign-cloud or on-premises hosting beyond what the GDPR base requires.
• UK and China bring their own regimes. UK GDPR + UK IDTA + UK-US Data Bridge; China PIPL Articles 38-39 outbound transfer mechanisms (CAC security assessment, certification, China SCCs) with separate compliance program for data leaving China.
• Six common mistakes recur in 2026 AI deployments. Treating vendor DPF certification as blanket coverage; missing the inference-endpoint geography; missing logging residency; missing backup and DR residency; static TIA; missing sector-specific overlay. The L2 inference residency map and quarterly TIA refresh are the defenses.
• The L2 artifact is the inference residency map. Per-system five-layer residency documentation; transfer mechanism; supplementary measures; sector overlay; TIA review cadence. Joint DPO + AI Officer + cloud-security ownership; carried into procurement and audit. Cross-walks to GDPR Articles 30 + 35, EU AI Act Articles 10 + 26 + 27 + 50, ISO 42001 A.10, NIST AI RMF GOVERN-6, NIST AI 600-1 Risk #6.