Showing Posts From
Data transfer
- 25 Jun, 2026
Sending European Data to US AI Models: The Risks That Outlast the Contract
The legal team signed off. The data processing agreement is in place. Standard contractual clauses are attached to the vendor agreement. The European company is operating under the EU-US Data Privacy Framework. From a compliance documentation standpoint, the boxes are ticked. Three specific risks persist that none of those documents fix. This isn't an argument against using external AI models. European companies are running AI programmes on US-hosted infrastructure because those models are currently the most capable available, and the business case for using them is real. The argument here is narrower: the compliance documentation that most European companies have in place for cross-border AI data transfers is necessary but not sufficient. Understanding what it doesn't cover — and why — is the starting point for an honest risk assessment. What signing the contract actually achieves Standard contractual clauses (SCCs) create binding obligations on the data importer — the US-based AI vendor receiving European data. The vendor commits to handling the data in accordance with GDPR requirements, to notifying the European company of any requests from authorities, and to applying appropriate technical and organisational security measures. This is genuine legal protection. It creates enforceable obligations. It is also the minimum requirement for a cross-border transfer to be lawful under GDPR, not the complete solution. What SCCs do not do: they do not change the jurisdiction of the vendor's infrastructure. They do not change the legal obligations a US-incorporated company is subject to under US law. A US-incorporated AI vendor that receives a lawful demand from US law enforcement is subject to that demand whether or not it has signed an SCC with every European customer it serves. The SCC creates a contractual conflict — the vendor may be obliged to notify the European customer and resist disclosure where legally possible. It does not create a legal mechanism that overrides US law. The data processing agreement operates in the same space. It defines how the vendor handles the data, what it can do with it, what happens in a breach. It is a contract between two private parties. It cannot bind US law enforcement. The political fragility underneath current EU-US transfers The EU-US Data Privacy Framework (DPF) is the current mechanism that provides an adequacy basis for transfers of personal data from the EU to US companies that have self-certified under the framework. Most major US AI vendors have self-certified. This is what allows European companies to transfer data to those vendors without relying solely on SCCs. The DPF was adopted in July 2023. It is the third iteration of a transatlantic data transfer agreement. The first two — Safe Harbor and Privacy Shield — were both invalidated by the European Court of Justice, in 2015 and 2020 respectively. The conditions that produced those rulings — US surveillance laws, specifically FISA Section 702 and Executive Order 12333, which permit broad data collection on non-US persons — have not materially changed. The DPF was adopted alongside a US executive order (EO 14086) that introduced new redress mechanisms for EU data subjects, but whether those mechanisms are sufficient to satisfy the ECJ's adequacy requirements remains contested. A challenge to the DPF is already working through the European legal system. Privacy rights organisations have filed complaints in several EU member states. The pattern from Safe Harbor and Privacy Shield — challenge filed, referred to ECJ, adequacy decision struck down — is a known sequence. European companies whose entire cross-border transfer strategy depends on the DPF holding are carrying a risk they may not have quantified. The practical position: SCCs should be in place independently of the DPF, as a fallback mechanism. But SCCs alone don't resolve the structural issues the ECJ has identified in prior rulings — which brings us to the third problem. The US CLOUD Act: a structural gap no SCC closes The Clarifying Lawful Overseas Use of Data Act (CLOUD Act), enacted in 2018, allows US law enforcement to compel US-incorporated companies to produce data stored on their servers — regardless of where that data is physically stored. A US-based AI vendor with a data centre in Frankfurt is still subject to a CLOUD Act order for data held in that Frankfurt facility, because the obligation runs to the company, not to the data's location. This is not a theoretical risk or an unlikely scenario. It is the structural architecture of US data law. European companies that have negotiated data residency commitments from their US AI vendors — contractual guarantees that data stays in EU data centres — have obtained a meaningful operational control and a genuine security benefit. They have not obtained protection from CLOUD Act orders. SCCs require vendors to notify the European customer of government access requests and to resist such requests where legally possible. In practice, where US law enforcement has obtained a valid CLOUD Act order, the vendor's ability to resist is limited and the notification may be subject to a gag order that prevents it. The SCC provision exists; the real-world protection it provides against a valid CLOUD Act order is narrow. The only structural approach that avoids CLOUD Act exposure entirely is infrastructure that is not subject to US jurisdiction — EU-incorporated companies, with EU-domiciled infrastructure, and no US parent company with control over the entity. Several European AI infrastructure providers market this explicitly as a selling point for regulated industries. It is a legitimate differentiator for use cases where the CLOUD Act risk is assessed as unacceptable. What actually reduces exposure — and what just creates paperwork For European companies that need the capability of major US-hosted foundation models and have concluded the business case outweighs the residual risk, the realistic risk reduction available is a layered approach, not a single mechanism. The most practical technical control is pseudonymisation before data leaves the organisation. If the data reaching the AI model doesn't contain directly identifying information — names, identification numbers, email addresses, and other direct identifiers have been replaced with tokens, and the re-identification key stays on-premise — then what the vendor receives, and what any CLOUD Act order would compel them to produce, is pseudonymised data. Pseudonymised data is still personal data under GDPR, so this doesn't eliminate GDPR obligations. But it significantly reduces the impact of a disclosure event. Combined with this: SCCs in place as a fallback, a documented assessment of the DPF's continued validity as a transfer mechanism, a clear record of what data categories are permitted to enter the AI model and which are not, and a written acceptance of the residual CLOUD Act risk at the appropriate seniority level in the organisation. That last point matters. The risk assessment is not complete until someone with authority has reviewed and signed off on the residual risk — not because sign-off eliminates the risk, but because undocumented accepted risks are a different regulatory problem from documented ones. What doesn't reduce exposure: signing the SCC addendum in the vendor's standard contract pack without reading it; obtaining a data residency commitment without understanding it doesn't address CLOUD Act; and treating DPF certification as equivalent to a permanent adequacy finding. These create documentation. They don't close the exposure. What to take from thisHave SCCs in place as a baseline, but treat them as necessary rather than sufficient. Understand what they actually obligate the vendor to do and where US law creates limits on what those obligations can achieve. Assess the EU-US Data Privacy Framework as a risk position, not a permanent mechanism. Build SCCs as a fallback and document the contingency position for the scenario where the DPF is challenged successfully — which is not an unlikely scenario given the historical pattern. Understand that data residency commitments from US vendors do not provide CLOUD Act protection. A contractual guarantee that data stays in EU infrastructure is a meaningful operational control; it is not a jurisdictional change. Implement pseudonymisation before data exits the organisation for AI processing. This is the most practical technical control available for reducing the impact of any disclosure event — whether that's a CLOUD Act order, a vendor breach, or a DPF invalidation. Document the accepted residual risk at the appropriate executive level. A risk that has been assessed, quantified, and signed off by someone with authority is a different compliance position from a risk that has been ignored. Regulators distinguish between the two. For use cases where CLOUD Act exposure is genuinely unacceptable — particularly in regulated industries, defence-adjacent work, or cases involving highly sensitive personal data — evaluate EU-incorporated AI infrastructure providers as the structural answer, not a contractual workaround.Cross-border data transfers in AI are a live compliance question with no clean answers at present. The honest position is that European companies using US-hosted AI models are operating in a legal environment that is less stable than the documentation in their procurement files suggests. That's not a reason to stop — it's a reason to understand the actual risk clearly, document what has been accepted and why, and hold a position that survives scrutiny when examined. The organisations that have done that work are in a defensible position. The ones that assumed the vendor's standard agreement covered everything are not.
Read full article