Cross-Border LLM Data Transfers: SCCs After Schrems II

Prompts carrying personal data to a US-run model API leave the EEA somewhere in the chain unless inference, storage and support access all stay inside it. In September 2026 that transfer can rest on the EU-US Data Privacy Framework (DPF) if the importing entity is certified; otherwise it needs the 2021 Standard Contractual Clauses plus a transfer impact assessment.

Which one applies turns on details most transfer guides skip: which legal entity signs your data processing addendum (DPA), where inference actually runs, and whether the provider’s US parent is your processor’s sub-processor. The tables and worked example below settle those, checked against each provider’s own DPA, terms and documentation on 30 September 2026.

The transfer tools that apply to a model API call

Chapter V (Articles 44 to 49 GDPR) allows a transfer on three bases:

1. Adequacy (Article 45). The Commission’s adequacy list includes the UK, Switzerland, Japan, South Korea, Canada, Israel and Brazil. For the US it covers only organisations participating in the DPF, under Implementing Decision (EU) 2023/1795 of 10 July 2023.
2. Appropriate safeguards (Article 46). In practice, the SCCs of Implementing Decision (EU) 2021/914 of 4 June 2021: Module 2 for controller-to-processor and Module 3 for processor-to-processor transfers. Certification is newer; the EDPB approved the first scheme usable for transfers, Europrivacy, in April 2026 (EDPB).
3. Derogations (Article 49). Narrow and occasional, not a basis for continuous API traffic.

Schrems II lives in two clauses. Under Clause 14 both parties warrant, after a documented assessment, that they have no reason to believe local law prevents compliance; under Clause 15 the importer must notify the exporter of public-authority requests, challenge any it has reasonable grounds to consider unlawful, and disclose the minimum.

For US importers, the Commission says the DPF’s national-security safeguards “apply to all data transfers under the GDPR to companies in the US, regardless of the transfer mechanisms used” (Commission). That makes a US TIA far easier to close than in 2020, and ties it to the DPF: if those safeguards fail, every US TIA needs rewriting.

Where the legal status stands in September 2026

• Upheld, now on appeal. On 3 September 2025 the General Court dismissed Philippe Latombe’s challenge (T-553/23), finding the Data Protection Review Court (DPRC) independent and bulk collection acceptable given ex post judicial review, as things stood at adoption (CJEU, eucrim, IAPP). Latombe appealed on 31 October 2025 (C-703/25 P).
• Review cycle. The Commission’s first periodic review (9 October 2024) found the necessary US structures in place; the next is due three years later (IAPP).
• FTC independence. On 29 June 2026 the US Supreme Court held 6–3 in Trump v. Slaughter that FTC commissioners are removable at will (Cornell LII). Arguing that the DPF depends on an independent FTC, noyb asked the Commission to withdraw it and said it would sue (noyb); the EDPB wrote to the Commission about the judgment on 31 July 2026 (EDPB). The US remains on the adequacy list.
• Redress and oversight. The DPRC operates under Executive Order 14086, with rules of procedure in force since 19 May 2025 (DOJ). The Privacy and Civil Liberties Oversight Board, “an integral component of the DPF’s redress prong” in IAPP’s words, “has one Member and is operating in sub-quorum status” (PCLOB).
• Surveillance law. Section 702’s statutory authority lapsed in June 2026, but existing certifications keep collection running at least until March 2027 (CBS News, Brennan Center). The CLOUD Act requires US providers to disclose data in their “possession, custody, or control, regardless of whether” it is held inside or outside the US (18 U.S.C. § 2713).

A TIA written now should name three rewrite triggers: a Court of Justice ruling in C-703/25 P, Commission action on the DPF after Trump v. Slaughter, and Section 702’s position when the certifications expire in March 2027.

Provider by provider, checked 30 September 2026

Each cell comes from the linked document; these change often, so re-check before copying anything into Annex I. “Not named” means the DPA relies on SCCs and never mentions the DPF; confirm on the DPF List either way.

Three patterns follow. OpenAI, Google and Microsoft put an EEA entity in front of you and move data to the US themselves. AWS makes Amazon Web Services, Inc. a party to your DPA, so the SCCs run between you and it. Mistral is an EU company. Anthropic’s importer is whichever entity signed, which for EEA customers is its Irish company.

Who signs which module: a decision table

Take the first row that matches your contract.

(a) EEA entity in front, US parent behind. OpenAI’s DPA has OpenAI Ireland pass EEA and Swiss data to affiliates “on the basis of agreements containing SCCs” (OpenAI); Microsoft’s SCCs run from its Irish company to Microsoft Corporation; Google relies on Google LLC’s certification. Under EDPB Opinion 22/2024 the processor prepares the transfer documentation and the controller should “assess and be able to show” it. Ask Anthropic for the documents covering its Irish company’s onward transfer.

(b) Importer already under the GDPR. The EDPB’s Guidelines 05/2021 (version 2.0, 14 February 2023) still count this as a transfer and call for a tailored tool. The Commission says the 2021 SCCs “do not work for importers whose processing operations are subject to the GDPR pursuant to Article 3” (Q&A); its SCC page still describes the replacement set as being developed, two years after a consultation planned for late 2024 (Covington). Uber dropped its SCCs on the strength of that FAQ, and the Dutch authority held that Chapter V “is not subordinate to Article 3” (Arthur Cox). Keep a tool in place.

(c) EU region, US parent. Processing that stays with an EEA-established processor is not a transfer, but the controller must weigh whether third-country law could stop the processor meeting its obligations; obeying a foreign disclosure request would be a transfer, making the processor an independent controller (Guidelines 05/2021). The CLOUD Act’s “possession, custody, or control” test makes that concrete. Then map what still leaves: OpenAI’s residency excludes system data, Mistral’s the control plane, and Anthropic routes globally by default. The CNIL treats remote access as a transfer (CNIL), so support access from outside the EEA needs a tool.

Worked example: a support chatbot through an integration vendor

Illustrative set-up, fictional parties. A Dutch online retailer (controller) with EU and UK customers adds a chatbot run by ChatVendor Inc., a US-incorporated platform hosting in a US region and not on the DPF List. ChatVendor calls a model on Amazon Bedrock in a US Region from its own AWS account.

Annex I for hop 1:

Annex II then lists the measures the TIA relies on: TLS, the redaction step, named-staff access to transcripts, an AWS organisation policy denying any Bedrock retention mode but none (AWS), and deletion at 90 days.

TIA excerpt for hop 1:

Tool. Module 2 SCCs; ChatVendor not on the DPF List (record the date checked).

Law and practice. Section 702 collection continues to at least March 2027, and the CLOUD Act reaches stored transcripts. EO 14086 safeguards, which the Commission applies to every US transfer, and DPRC redress are in place, but the PCLOB lacks a quorum and Trump v. Slaughter puts the DPF’s FTC pillar in question. Record ChatVendor’s transparency report and any Clause 15 notices.

Measures. Redaction, a model-free medical queue, zero retention at AWS, 90-day deletion. Free text still identifies people, so this is not pseudonymisation in the EDPB’s sense.

Conclusion. Proceed for general support queries: at the date of assessment the US safeguards support essential equivalence for low-sensitivity content, and the measures shrink what could be reached. Not for the medical queue. Re-assess on a ruling in C-703/25 P, Commission action on the DPF, the March 2027 certification expiry, or ChatVendor joining the DPF.

For UK customers, add the UK Addendum or rely on the UK Extension if ChatVendor certifies to it. Were ChatVendor EU-hosted and calling Bedrock through an EU cross-Region profile, hop 1 would not be a transfer and hop 2 would become case (c). File all of this in the DPIA for the deployment; if the bot starts deciding refunds, GDPR Article 22 applies too.

Supplementary measures for inference, and where they stop

Under the EDPB’s Recommendations 01/2020, inference is the hard case: where a processor needs data in the clear and the destination’s access powers go beyond what is necessary and proportionate, the EDPB found no effective technical measure, and contractual measures alone will generally not stop public-authority access. For the US, EO 14086 keeps inference out of that corner for now. The measures below matter most if that changes, and for destinations without such safeguards, such as the DeepSeek case in AI chat assistant privacy risks.

What works for inference:

• Pseudonymise before sending. Swap names, emails and account numbers for keyed tokens and keep the mapping in the EEA. It meets the EDPB’s pseudonymisation use case only if the rest of the prompt cannot be tied to a person even with information authorities may hold, which free text rarely allows, but it shrinks what is exposed. See pseudonymization vs anonymization under GDPR and open source de-identification tools.
• Zero retention. It shortens how long prompts sit where a CLOUD Act order could reach them, and does nothing about access during processing.
• Minimal retrieval context. Pass the order fields the answer needs, not the customer profile, and enforce the allow-list in the retrieval layer so a prompt injection cannot widen it.
• In-region inference, then deal with whatever still leaves.
• Routing sensitive queues away from the model, as in the example.

What does not work: encryption at rest or in transit with EEA-held keys, since the model reads cleartext; hashing identifiers without a secret key, which a dictionary reverses; and contract clauses on their own.

Fine-tuning and evaluation sets are a separate transfer

Fine-tuning ships a historical corpus that stays with the provider until you delete it: Mistral keeps fine-tuning data until deletion or account closure (Mistral), and Azure keeps training files in your geography and fine-tuned models exclusive to you (Microsoft). Give it its own Annex I entry, retention and TIA, since volume and special-category content run higher than in chat. OpenAI lists /v1/fine_tuning/jobs and /v1/evals among endpoints with EU regional processing (OpenAI). De-identify the corpus first (how to anonymize training data), build evaluation sets from synthetic records where possible, and delete uploaded files after the job.

Checks to run and record before sign-off

Run these on your own accounts, and record the date, the evidence and who checked.

1. DPF status. Search the DPF List for the exact importer entity in your DPA, such as “Google LLC” or “Amazon.com, Inc.”, not the brand. Record active or inactive status, frameworks (EU-US, UK Extension, Swiss-US), HR-data coverage and the date, as the EDPB and GOV.UK guidance describe.
2. Where inference ran. On supported models, Anthropic reports usage.inference_geo in each response. Bedrock writes additionalEventData.inferenceRegion to CloudTrail in the source Region for cross-Region calls. Mistral recommends logging hostname, SDK server value, model ID, timestamp and request ID per regional call. For OpenAI, confirm calls go to eu.api.openai.com; for Vertex AI, that the hostname is regional or eu; for Azure, record the deployment type.
3. Retention. On Bedrock, GET /data-retention on the control plane returns the Region’s mode, and a service control policy can deny anything but none. On Azure, after approval for modified abuse monitoring, az cognitiveservices account show -n <resource> -g <group> lists ContentLogging as false. For OpenAI and Anthropic, file the ZDR approval.
4. Read the result. A global inference value, a global endpoint, an inactive DPF record, a missing retention setting or pre-2021 SCCs means Annex I or the TIA is wrong. Fix it before go-live.

UK and Swiss transfers

• Tools. The ICO’s International Data Transfer Agreement (IDTA), or its Addendum letting EU SCCs cover UK transfers; the ICO plans new versions “in the course of 2026” and says to keep using the current ones (ICO). OpenAI’s and Anthropic’s DPAs use the Addendum.
• Test. The Data (Use and Access) Act’s transfer schedule has applied since 5 February 2026 (legislation.gov.uk): protection after transfer must not be “materially lower” (ICO).
• UK-US data bridge. Since 12 October 2023 UK organisations can send data to US companies certified to the UK Extension (GOV.UK). On 30 July 2026 the ICO clarified that the UK’s US adequacy regulations are independent of the EU’s finding (ICO), so an EU ruling against the DPF would not, by that logic, end the bridge.
• EU to UK. The Commission renewed its UK adequacy decisions in December 2025 (Commission).
• Switzerland. The Federal Council recognised US companies certified under the Swiss-US DPF as adequate from 15 September 2024 (Federal Council); Google adopted it the next day. Anthropic’s DPA pairs SCCs with a Swiss addendum naming the FDPIC.

What enforcement shows

Three transfer decisions since 2023 total €2.02 billion:

• Meta, €1.2 billion. The DPC’s decision of 12 May 2023 found SCC-based transfers to the US breached Article 46(1) and ordered them suspended within five months, as the EDPB’s binding decision required (DPC).
• Uber, €290 million. The Dutch authority’s decision of 22 July 2024 found more than two years of transfers without a tool after Uber stopped using SCCs in August 2021 (EDPB): case (b).
• TikTok, €530 million. The DPC’s decision of 2 May 2025 included €485 million under Article 46(1) because TikTok failed to “verify, guarantee and demonstrate” essential equivalence for EEA data accessed remotely from China (DPC): case (c)‘s remote-access point.

None involved an LLM, but each maps onto a row of the decision table.

FAQ

Is the EU-US Data Privacy Framework still valid in 2026?

Yes. The adequacy decision of 10 July 2023 remains in force and the General Court upheld it in September 2025, but Philippe Latombe’s appeal (C-703/25 P) is before the Court of Justice and the US Supreme Court’s June 2026 ruling on FTC independence has prompted calls for withdrawal. Keep SCCs in your DPA as a fallback.

Does an EU data residency option mean no GDPR transfer?

Only for the data that genuinely stays in the EEA. Processing by an EEA entity with no outside access is not a transfer, but support access, abuse review, account and usage data, or global routing defaults can still send data out. A US parent’s exposure to the CLOUD Act remains a risk to assess under Articles 28 and 32.

Do I need a transfer impact assessment if the provider is DPF certified?

No, not for a transfer made under the DPF, because it rests on an adequacy decision. Check that the exact importing entity is active on the DPF List and that its certification covers your data. Many DPAs still incorporate SCCs as a fallback, and a TIA prepared now saves time if the DPF falls.

Do I need SCCs if my LLM provider has an EU entity?

Not for your own hop. If your DPA is with the provider’s EEA entity, handing it data is not a transfer, so your contract is an Article 28 DPA. The transfer happens when that entity passes data to its US parent under its own SCCs or the DPF, and you must obtain and assess that documentation.