The Schrems II Landscape for AI Services
Schrems II means transfers of personal data to the US need a valid mechanism and a documented transfer impact assessment with supplementary measures. AI services rely on either the Data Privacy Framework or Standard Contractual Clauses with your own analysis. Since the adequacy decision faces a court challenge, build the architecture so a mechanism shift doesn't force a vendor switch.
Schrems II is the ruling that refuses to become history. It came down in 2020, but its logic still governs every contract where personal data meets a US AI provider – and since today’s transfer framework is once again being challenged in court, the ruling’s most important lesson is as relevant as ever: don’t build your AI architecture on the assumption that any single mechanism will last.
The Chain from Ruling to Your Contract
The EU Court of Justice struck down Privacy Shield and let the Standard Contractual Clauses (SCC) survive – but only on conditions. Anyone transferring personal data to the US under SCC must carry out a transfer impact assessment (TIA) and, wherever the protection falls short, put supplementary measures in place. The European Data Protection Board’s Recommendations 01/2020 spell out what qualifies: technical measures carry the most weight, and in practice everything points toward encryption where the customer controls the keys.
For AI services, though, there’s an honest limit the analysis has to acknowledge. Customer-controlled keys protect data at rest and in transit – but inference requires plaintext at the actual moment of computation. No language model can answer a question it can’t read. That’s why encryption gets combined with other measures: EU inference, zero data retention, contractually agreed access restrictions, and organizational controls. A TIA that claims encryption solves everything won’t hold up under scrutiny.
The Mechanism Landscape by Vendor Path
Which mechanism carries the transfer depends on which path you buy the AI service through. The situation as of this writing:
| Vendor path | Mechanism and your homework |
|---|---|
| Microsoft / Azure OpenAI | Participates in the Data Privacy Framework (DPF), with SCC as a common contractual complement – check which entities and services are covered |
| OpenAI direct | Participates in DPF – verify that the certification covers the service tier you're contracting for, and document the check |
| Anthropic direct | SCC as the primary mechanism – requires you to carry out and document your own transfer impact assessment with supplementary measures |
The difference is practical rather than principled. The DPF path means less analysis work on your end as long as the framework holds; the SCC path requires more documentation from you but is independent of the adequacy decision’s fate. Certifications and contract structures also change on an ongoing basis – check the provider’s current status before signing, and keep the evidence in your documentation.
Build for the Next Ruling, Not Just Today’s Situation
The adequacy decision behind DPF is being legally challenged and is under review at the EU Court of Justice. Nobody knows the outcome – but everyone knows what happened to the two previous frameworks. The conclusion for you is architectural, not legal: build so a mechanism shift becomes a contract update, not a rebuild.
Three things make up the hedge. EU inference as an active, verified configuration means data doesn’t leave the Union unnecessarily, regardless of the mechanism. Customer-controlled keys, where the service supports them, reduce exposure at rest and in transit. A documented exit plan – which provider or operating environment you’d move to, what it requires, and how long it takes – turns a ruling from a crisis into a project.
A concrete scenario: an insurance company builds its customer-service AI behind its own abstraction layer, runs inference in EU regions, and keeps prompts and evaluation data portable. When the legal situation shifts, they switch mechanisms in the contract and keep operating. The competitor who built directly against a single provider’s API without EU configuration faces a migration in the middle of a regulatory storm. Same ruling, two completely different weeks at the office. At Weapp, we build AI solutions following the first pattern.
Before You Sign: Check the Situation the Day You Sign
The legal situation and providers’ mechanism status are perishable. So make four things a routine at every new AI contract and every renewal:
- Verify the provider’s current mechanism – DPF certification or SCC – for exactly the legal entity and service you’re purchasing.
- Update or establish the transfer impact assessment, dated and with named sources.
- Document which supplementary measures are active: EU inference, retention settings, key management, access restrictions.
- Note the next review point and who owns tracking the legal situation.
That routine takes hours, not weeks – and it’s the difference between a contract that survives the next ruling and one that falls with it. Want help setting up the structure? Get in touch.
Frequently asked questions
What did the Schrems II ruling establish?
In 2020, the EU Court of Justice struck down the Privacy Shield transfer framework and ruled that Standard Contractual Clauses only hold up if the transfer is analyzed case by case and supplemented with additional measures wherever the protection falls short. The ruling is the basis for today's requirement to run transfer impact assessments on US transfers.
What is a transfer impact assessment (TIA)?
A documented assessment of whether the level of protection holds up in the recipient country: which data is transferred, what legislation the recipient falls under, the likelihood of government access, and what supplementary measures are put in place. It needs to be in place before the transfer starts and revised when circumstances change.
Is encryption enough as a supplementary measure for AI services?
Only partly. Encryption with customer-controlled keys protects data at rest and in transit, but a language model has to read plaintext at the actual moment of computation. That's why encryption is combined with measures like EU inference, zero data retention, and contractually agreed limits on the provider's access.
What happens to our contracts if DPF is struck down?
Transfers resting solely on DPF lose their mechanism and have to be switched quickly to Standard Contractual Clauses with a transfer impact assessment – just as happened when Privacy Shield fell. Providers with SCC as a fallback in their contracts give you a softer transition. Your own hedge is EU inference, your own keys, and a documented exit plan.
Our provider is DPF-certified – does that mean we're done?
No. Check that the certification covers the right legal entity and the right services, document the check, and monitor that the certification is maintained. DPF shifts responsibility for the mechanism, but responsibility for lawful processing, the data processing agreement, and risk assessment remains yours.