Sending data to OpenAI, Anthropic, or Google? The 2026 state of EU-US AI transfers

Section 702 of FISA sunsets on April 20, 2026. That is in ten days. The vote that decides whether it gets a clean reauthorisation, a short extension, or briefly lapses is happening this week. As of early April, Speaker Johnson does not have the math for a clean extension. The Congressional Progressive Caucus has bound 98 House Democrats to oppose any reauthorisation without dramatic reforms, a dozen or so GOP holdouts want warrant requirements, and President Trump wants a clean 18-month extension. Nobody has the votes for what they want.

If you ship AI features to EU users, this matters. Section 702 is the specific provision that has driven every past CJEU invalidation of EU-US data transfers: Safe Harbor in Schrems I, Privacy Shield in Schrems II, and the Latombe challenge that is now sitting at the Court of Justice. The Data Privacy Framework you tick a box for in your OpenAI Data Processing Addendum is built on top of the executive orders that constrain Section 702 collection. If those executive orders shift before May, the DPF's adequacy assumption shifts with them.

This is the operational layer for that situation. If you want the strategic question of whether to call US AI providers at all, read EU vs US data processing for AI: how to decide. If you want the residency picture, read Data residency and AI. What follows assumes you have already decided to transfer and need to do it correctly through a perishable window.

What sunsets on April 20

Section 702 is the FISA provision that authorises warrantless surveillance of foreign targets located outside the United States. In practice it is the legal basis for most US intelligence collection from US tech companies. The Brennan Center tracks the votes in real time and the picture as of April 10 is that none of the three plausible outcomes neatly preserves the DPF's adequacy assumption.

A clean reauthorisation lets the framework sit. Privacy advocates lose the moment but the DPF rests on the same surveillance posture the European Commission already accepted in 2023.

A short extension with cosmetic reforms (the Trump administration's preferred version) runs into the warrant-requirement holdouts in both parties. If it passes anyway, the substance does not change; if it fails, you get a brief lapse.

A longer extension with substantive reforms (warrant requirements, narrowing the data broker loophole, real PCLOB oversight) would arguably strengthen the DPF, but the substantive reforms are exactly what the executive branch is fighting. The reforms that would help your transfer position are the ones least likely to pass.

A brief lapse is the scenario that scrambles everything. Section 702 collection does not technically stop the day the authority expires. Existing certifications continue under transition rules. But the European Commission's adequacy decision rests in part on the assumption that the US surveillance regime is the regime the Commission analysed in 2023, and a lapse followed by re-passage with material changes invalidates that assumption in fact even if the DPF is still formally in force.

Set a calendar reminder for April 20. If anything moves materially that week, your TIAs and your fallback contracts are the documents that decide whether you need to act.

What the DPF actually rests on

The Data Privacy Framework is an adequacy decision under GDPR Article 45. The European Commission adopted it in July 2023 after Schrems II struck down the previous Privacy Shield framework. As of March 2026 more than 3,500 US entities are self-certified, including OpenAI, Anthropic, and Google.

The DPF rests on three things, and any of them shifting moves the framework.

Executive Order 14086. EO 14086 commits the US intelligence community to proportionality and necessity standards on Section 702 collection that the European Commission found "essentially equivalent" to GDPR. This is the load-bearing piece. If a future administration revokes or narrows EO 14086, the adequacy decision's underlying premise disappears. The framework would not auto-invalidate, but the next CJEU challenge would have a much shorter route.

The Data Protection Review Court. The DPRC is the redress mechanism that lets EU individuals challenge US surveillance access. It is the main thing the DPF added that Privacy Shield did not have.

PCLOB oversight. The Privacy and Civil Liberties Oversight Board is the US body that audits Section 702 collection and reviews how the DPRC handles complaints. PCLOB independence is part of why the European Commission was willing to call US adequacy "essentially equivalent" in 2023. As of January 20, 2025, the Trump administration removed the three Democratic members, leaving Beth Ann Williams as the only remaining member of a five-seat board. Statutory quorum is three of five. With one member, PCLOB cannot start investigations, cannot issue reports, and cannot conduct the annual review of DPF redress remedies that the European Commission was relying on as a sign of working oversight.

The General Court dismissed the Latombe challenge on 3 September 2025 and upheld the framework on the merits. Latombe filed his appeal to the Court of Justice in October 2025. WilmerHale tracks the pending appeal and notes that the CJEU has historically reached further than the General Court on US adequacy questions. A ruling is unlikely before late 2026 or 2027, and in the meantime the framework is valid. I am not convinced the CJEU will defer to the General Court here. The Schrems II Court already showed it was willing to invalidate a Commission adequacy decision when the surveillance framing did not satisfy it, and the structural critique in the Berkeley Technology Law Journal piece from February 2026, that the philosophical divide between US national security law and EU fundamental rights law cannot be bridged by executive orders alone, is the kind of argument the CJEU has bought before.

That is the floor your DPF tickbox is sitting on.

The TIA debate: legally optional under DPF, defensively essential

This is the part most articles get wrong, in both directions. Some say a TIA is universally required. Some say a TIA is unnecessary if your provider is DPF-certified. The accurate picture is more annoying.

The EDPB's July 2023 Information Note on Data Transfers under the GDPR to the US is the source. The note says transfers to organisations on the DPF list "may be based on the Adequacy Decision, without the need to rely on Article 46 GDPR transfer tools." Translation: if you are relying on the DPF, you are using Article 45 (adequacy), not Article 46 (SCCs and friends). The TIA obligation in EDPB Recommendations 01/2020 attaches to Article 46 transfer tools. No Article 46, no formal TIA requirement.

So if your provider is DPF-certified and your contract names the certified entity and you are relying on the DPF as the legal basis, you are not legally required to run a TIA today.

So the practical answer is: do the TIA anyway. Do it now, while the DPF is still your primary basis, so that the fallback is ready when you need it. Bird & Bird's analysis of the Latombe ruling calls this belt-and-suspenders, and it is now standard practice in EU privacy circles. I think it is the right answer in 2026 even though the strict EDPB reading does not require it for pure DPF reliance. A TIA is a quarterly maintenance task. Without one, the day the DPF moves is the day you have nothing on file, and "we'll write it next week" is not a defence the regulator accepts.

The CNIL published a Practical TIA Guide in January 2025 that walks through what each step of the EDPB six-step process should look like in writing. It is the most usable national-DPA template available right now.

A workable TIA structure for an AI vendor:

## Transfer Impact Assessment for [vendor name, contract ref]

### 1. Transfer description
- Exporter: [legal entity, EU establishment]
- Importer: [legal entity, country, group affiliation]
- Sub-processors: [list with countries, last reviewed date]
- Personal data categories: [identifiers, content, special category]
- Purposes: [training, inference, logging, fine-tuning]
- Frequency and volume: [continuous, batch, estimated records/month]

### 2. Transfer tool relied on
- Primary: [DPF | SCCs Module 2 | SCCs Module 3]
- Fallback: [if DPF, name the SCC Module that activates]

### 3. Effectiveness assessment
- Destination country laws relevant to public authority access:
  - Section 702 FISA: applicable
  - Executive Order 12333: applicable
  - CLOUD Act: applicable
- Practice of destination country authorities: [transparency report links]
- Provider's history of government requests: [link transparency report]
- Conclusion: [equivalent | equivalent with measures | not equivalent]

### 4. Supplementary measures
- Technical: [encryption in transit, encryption at rest with EU-held keys, pseudonymisation before sending]
- Contractual: [notification of access requests, transparency commitments, audit right]
- Organisational: [data minimisation in prompts, retention limits, audit logging]

### 5. Review cadence
- Next review: [date]
- Trigger events: [DPF invalidation, sub-processor change, new EO, new case law, Section 702 vote]

Fill it out per vendor. Keep it with the contract. When a regulator asks how you analysed the transfer, this is the answer.

What an AI-vendor-specific transfer setup looks like

Generic transfer guides assume you are sending HR records to a SaaS in Texas. AI vendors are messier because the entity you contract with, the entity that runs the model, and the entity that processes the data are often three different companies, and the cascade changes as the providers add new sub-processors.

The four AI-vendor situations that come up most often, with the actual entity and module each one needs.

OpenAI Inc. via the direct API. OpenAI Inc. is a Delaware C-corp. Your DPA is with OpenAI Inc., not OpenAI Ireland. The transfer tool is DPF + SCCs Module 2 (controller-to-processor) for direct API use, or Module 3 (processor-to-processor) if you are a SaaS calling the API on behalf of your customers. Verify the DPF certification covers the entity you contract with by searching the Data Privacy Framework List for "OpenAI." Both OpenAI Inc. and the OpenAI Global LLC parent are listed; pick the one your DPA names.

Azure OpenAI Service. Azure OpenAI is a Microsoft service. The contract is with Microsoft Ireland, the data processing terms are the Microsoft Product Terms, and the SCCs are pre-incorporated. If you select an EU region (West Europe, North Europe, France Central, Sweden Central, or one of the EU Data Zone deployments), the inference traffic stays in the EU and the transfer is intra-EU at the Microsoft level. The complication is that the Azure OpenAI sub-processor cascade still includes US-based components. Read the regional terms, not the marketing page, and remember that Azure OpenAI is legally separate from OpenAI Inc., even though it serves the same models.

Anthropic via the API. Anthropic PBC is a Delaware public benefit corporation. Anthropic is on the DPF list. The wrinkle is the Anthropic-Google Cloud TPU expansion announced in October 2025, which moved a significant portion of Anthropic's training and inference to Google Cloud TPU infrastructure. Google Cloud is a sub-processor on Anthropic's published list. Your TIA needs to walk through both the Anthropic relationship and the Google Cloud cascade underneath it. If your TIA is dated before October 2025 and does not mention Google Cloud TPUs, it is stale.

Google Vertex AI / Gemini. Vertex AI is delivered through Google Cloud entities that vary by region. Your contract is typically with Google Cloud EMEA Limited (Ireland). If you select an EU region for your Vertex AI deployment, the data stays in the EU and the transfer is intra-EU at the contract level. The same caveat as Azure OpenAI applies: read the regional terms.

The pattern across all four: the entity you contract with is not always the entity that processes your data, the sub-processor list moves between contract reviews, and the legal posture depends on the specific deployment configuration. A TIA that says "OpenAI" without naming the corporate entity, the region, and the sub-processor list as of the review date is not really a TIA.

The April 2026 contingency: Latombe, PCLOB, Trump v. Slaughter

Three things sit on the calendar for the next six months. None of them is decisive on its own, but any combination of two materially changes the picture.

The Section 702 vote. Already covered. The most likely outcomes are a short extension, a longer extension with reforms, or a brief lapse. Set the trigger.

The Latombe appeal. Filed October 2025, pending at the CJEU. Ruling unlikely before late 2026. The probability of CJEU invalidation is genuinely contested in the privacy bar. Bird & Bird thinks the framework will hold; the Berkeley Technology Law Journal piece thinks the structural divide is unbridgeable; the only honest answer is that nobody knows. If the CJEU strikes down the DPF, you have weeks not months to switch to SCCs as your operative basis.

Trump v. Slaughter. A separate US Supreme Court case scheduled for ruling in June or July 2026 that touches the legal foundations of the executive orders supporting the DPF redress mechanism. It is a less direct threat than Latombe but a real one. If the Court narrows the executive's authority in ways that affect EO 14086 or the DPRC's footing, the European Commission would be forced to revisit the adequacy decision regardless of what the CJEU does on Latombe.

The PCLOB sub-quorum problem sits underneath all three. PCLOB has been below quorum since January 2025. The longer it stays that way, the harder it is for the European Commission to defend the "essentially equivalent" finding in the next review.

Set a review trigger on your TIA. If any two of these move materially, update the document and re-evaluate the transfer. If the DPF is suspended or invalidated, the SCCs in your fallback annex become your operative basis the day after.

Where transfer setups go wrong

"We have DPF certification, so we're done." DPF certification is one transfer mechanism. The most common gap is that the DPA names a parent entity that is DPF-certified but the actual contracting entity is a US subsidiary that is not. Search the DPF list for the exact entity name on your contract, not the brand.

"Our DPA mentions SCCs." Mention is not enough. The SCCs need to be attached as an annex, the correct Module needs to be selected, and Annex I (parties), Annex II (technical and organisational measures), and Annex III (sub-processors) need to be filled in. Many AI vendor DPAs leave Annex II as a placeholder. Fill it in.

Module 2 when you should use Module 3. If you are a SaaS that processes customer data with the help of OpenAI, you are a processor and OpenAI is your sub-processor. The relationship is processor-to-processor, and Module 3 applies. Using Module 2 (controller-to-processor) is a contract defect that a regulator will spot in the first hour of an audit.

Old SCCs in legacy contracts. Pre-2021/914 SCCs are invalid for any transfer ongoing today. The transition deadline expired December 27, 2022. Search your contract management system for "Decision 2002/16" or "Decision 2010/87" and replace.

"We use Azure OpenAI, so the data stays in the EU." The Azure OpenAI EU regions process model traffic in the EU under the Microsoft contract, but the sub-processor cascade still includes US-based components. Whether your transfer is intra-EU or cross-border depends on the specific region, deployment type, and the entities your contract names.

A TIA dated 2024. Sub-processors change. Sub-processor lists update quarterly for most AI providers. An eighteen-month-old TIA does not reflect the current cascade, and the cascade is exactly what the TIA is supposed to assess. Subscribe to the provider's sub-processor change list and trigger a TIA review on every change.

"SCCs as a fallback, but no TIA on file." This is the failure mode the TIA debate creates. If you are relying on DPF as the primary basis and SCCs as the fallback, the TIA needs to exist now. The fallback only works if the document the fallback requires is already there.

The contract review for this week

Section 702 is in ten days. Open every AI vendor contract on your books and check four things in this order.

First, the DPF certification. Find the exact entity name on the contract and search the DPF list for it. If the parent is certified but the contracting subsidiary is not, you have a gap.

Second, the SCCs annex. Open Annex I, Annex II, Annex III. If any of them is a placeholder or "TBD," fill it in this week. The Module 2 vs Module 3 question is the one to check first. If you are a SaaS, Module 3 is almost always correct.

Third, the fallback clause. If the contract does not say what happens if the DPF is suspended or invalidated, add a one-line clause that activates the SCCs as the operative basis from the date of any suspension. Most AI vendor legal teams will accept the language by email; you do not need a renegotiation cycle to add it.

Fourth, the TIA. If a TIA exists and is dated within the last twelve months and the sub-processor list it walks through matches the provider's current cascade, you are in good shape. If it is older than twelve months or the cascade has changed, refresh it this week. If no TIA exists, write one. The CNIL guide is the easiest starting template.