Can you send source code to US AI services? Legally yes — and by default it leaves Europe

The EU-US Data Privacy Framework survived its first court challenge and is under appeal. Meanwhile GitHub's EU boundary is off by default and costs 10% more, and OpenAI's own docs say prompt caching can store outside your chosen region.

Every European engineering team asks this eventually, usually the week someone rolls out an AI coding assistant. The legal answer is yes. The operational answer is that unless somebody has explicitly changed a setting, your code is being processed in the United States right now — and even after you change it, the providers' own documentation describes ways it can still leave.

This is the question we get most often, and it is almost always answered badly: either "GDPR forbids it" (wrong) or "we're fine, they're DPF-certified" (incomplete). Both skip the part that actually decides it.

The legal answer is yes, resting on a foundation that has collapsed twice

Transfers of personal data from the EU to the US are lawful under the European Commission's 2023 adequacy decision for the EU-US Data Privacy Framework, provided the recipient is DPF-certified.

That decision was challenged, and on 3 September 2025 the General Court dismissed the action in Latombe v Commission (T-553/23). Notably, the Court chose to rule on the substance rather than dispose of it on procedural grounds: it found the Data Protection Review Court sufficiently independent, and US limits on bulk collection adequate. The Court's own press release is the primary record.

So the framework holds. With one caveat worth pricing in: Latombe appealed, and the appeal is pending before the Court of Justice as Case C-703/25 P. The General Court is not the court that killed Safe Harbour in 2015 or Privacy Shield in 2020 — the CJEU is, and it has been consistently more sceptical about US surveillance and the reality of redress than the lower court. Two predecessor frameworks have now been struck down on materially similar grounds.

That does not mean you should refuse to transfer. It means an architecture whose legality depends entirely on this one decision surviving is carrying a risk that has already materialised twice in ten years.

GDPR is only half the question

There is a habit of treating "is it GDPR-compliant?" as the whole analysis. For source code it covers maybe half the exposure.

Your repository almost certainly contains personal data. Author names and email addresses in every commit. Names in code comments and TODOs. Customer records in test fixtures and seed data. Personal data in log samples committed for debugging. Under GDPR's definition this is personal data being transferred, whatever you think of the repository as a whole.

And the part GDPR does not touch at all is usually the part that matters more. Your source code is a trade secret. Your architecture, your unreleased features, your security controls and the specific ways they are weak. The DPF governs personal data; it says nothing about whether your competitive position or your unpatched attack surface should sit in a third country's jurisdiction. A perfectly GDPR-compliant transfer can still be a bad idea, and for a lot of teams that is the actual decision — as we argued in Why your code never leaves Europe.

What the providers actually offer

This has improved a great deal in 2026, and credit where it is due. But the details are where teams get caught.

GitHub Copilot shipped data residency for the US and the EU Data Boundary on 13 April 2026, covering agent mode, inline suggestions, chat, the cloud agent, code review, PR summaries and the CLI. The EU boundary means EU plus EFTA — Iceland, Liechtenstein, Norway and Switzerland.

Three details from that announcement deserve attention. The policies are, in GitHub's own words, "off by default, so admins will need to explicitly opt-in". Data-resident requests carry "a 10% increase in the model multiplier". And Gemini models are excluded outright, because "GCP does not currently offer data-resident inference endpoints" — so a team standardising on Gemini has no EU-resident path through Copilot at all.

OpenAI offers regional processing for Europe (EEA + Switzerland), and their data controls documentation is unusually candid about the edges. Zero Data Retention forces store to false on /v1/responses and /v1/chat/completions regardless of what your request asks for — good. But ZDR does not apply to the Assistants API or conversation endpoints, non-US regions require approval plus "execution of a Modified Retention amendment", and — the line most worth reading twice — "extended prompt caching may require temporary storage outside selected regions."

That last one is the important sentence in this entire post. You can configure European data residency correctly, pass your audit, and still have prompt content cached outside your region as a documented behaviour of the platform. Not a breach. Not a misconfiguration. The product working as specified.

The three ways this goes wrong

Defaults. Residency is opt-in everywhere. Nobody is moved to the EU boundary automatically, and the surcharge means somebody had to consciously accept a cost increase. If you have not checked, assume it is off.

Scope gaps. Residency covers the inference endpoint, not necessarily every feature around it — caching, abuse-monitoring logs, some endpoints, some models. The boundary is drawn per feature, not per account.

The appeal. C-703/25 P is the tail risk. It probably resolves in favour of the framework. It has also gone the other way twice, and the remediation timeline when it does is measured in weeks.

What to actually do

1. Check what is on. In Copilot, that is an org or enterprise policy that is off unless someone turned it on. Do not assume, and do not take a salesperson's word for it — look at the setting.
2. Read the sub-processor list, not the marketing page. Where a provider says "EU data residency", find which regions and which features. Then find the exclusions.
3. Treat prompt caching as a transfer. It is described as one in the documentation. Include it in your Record of Processing Activities.
4. Separate the two questions. GDPR compliance and trade-secret exposure are different analyses with different answers. Do both.
5. Ask what breaks if the appeal succeeds. If the answer is "we would have to migrate every AI tool in the SDLC under time pressure", that is worth knowing before it happens, not after.

Where this lands

None of this makes US AI services unusable. The 2026 residency options are genuinely better than what existed a year ago, and a team that opts in, reads the exclusions and documents the caching behaviour is on defensible ground.

But it is worth being honest about the shape of it: you are configuring your way to compliance on a legal basis under appeal, with per-feature exclusions you have to track as the products change. That is a real, ongoing operational cost — and it is a different kind of cost from per-seat and per-token pricing, because it does not show up on an invoice.

The alternative is not doing without AI tooling. It is running models where the jurisdiction question does not arise — which, as the post-Mythos research showed, is now viable on models small enough to run on your own hardware. That is the bet Codelight is built on, and it is why our answer to this question is that we never had to ask it.

Verified against primary sources on 25 July 2026: the General Court judgment and press release, GitHub's changelog, and OpenAI's data controls documentation. Provider terms change frequently — check the current DPA and sub-processor list before relying on any of the above. This is not legal advice.

Topics: #gdpr #data-sovereignty #ai