Schrems II is unresolved. Here is what that means for your AI stack in 2026.

The background that has not resolved

The Schrems II ruling of July 2020 is not history. Its practical effects continue to shape technology procurement across Europe, and the legal challenge to the mechanism designed to resolve it — the EU-US Data Privacy Framework, which entered into force in July 2023 — will likely reach the Court of Justice of the European Union within the next eighteen months.

The ruling invalidated Privacy Shield, the previous legal framework governing data transfers from the EU to the US, on grounds that US surveillance law creates surveillance risk for EU data subjects that the framework did not adequately address. Section 702 of the Foreign Intelligence Surveillance Act allows US intelligence authorities to compel US companies to provide access to data belonging to non-US persons without judicial warrant — a power incompatible with the right to effective judicial redress that EU law guarantees. Standard Contractual Clauses, the alternative mechanism most organisations fell back on, were not struck down but were subjected to a case-by-case assessment requirement the CJEU specified and the EDPB subsequently issued detailed guidance on. The assessment asks whether the country of destination provides protection essentially equivalent to what EU law requires. The EDPB guidance, and subsequent enforcement by supervisory authorities, has consistently found that US law does not meet that standard for transfers subject to FISA 702.

The EU-US Data Privacy Framework addressed this through new executive commitments from the US government limiting intelligence gathering scope and establishing a redress mechanism for EU data subjects. NOYB filed a legal challenge in August 2023, arguing the structural problem was not resolved. That challenge is in the courts. It has not produced a ruling yet.

Where the AI stack intersects this problem

The data transfer question that governed cloud storage, email, and analytics decisions for five years applies with equal force to AI tools. Every SaaS AI product that processes EU personal data on US infrastructure creates a data transfer in the GDPR's meaning, and the relevant categories extend further than most procurement checklists reflect.

LLM API calls that include personal data in the prompt — a customer name and query processed through a support automation workflow, a CV uploaded to an AI recruitment screening tool, a patient note processed through AI clinical documentation — are transfers of personal data to US-based servers. Fine-tuning or model training on proprietary data that includes personal data creates a transfer with a longer retention footprint. AI tools that store user interactions for improvement purposes are transferring the data embedded in those interactions, at a volume and frequency that often exceeds the original transfer assessment.

For organisations using US-based AI APIs or SaaS platforms under the EU-US Data Privacy Framework, the current legal basis is valid pending the NOYB challenge. For organisations using SCCs, the case-by-case Transfer Impact Assessment requirement remains in place. In practice, a significant portion of organisations have not completed the TIA that the EDPB's supplementary measures guidance requires. The assessment is demanding, involves legal judgment about US law, and in many cases would reach conclusions about tools already in production that procurement teams would find uncomfortable.

Three questions worth asking of any AI vendor

The procurement conversation for AI tools has improved since 2021. Vendors now routinely include data residency options and DPA templates that were absent earlier. The questions that actually matter go further.

The first is where inference happens. A vendor whose model servers are in the US transfers data to the US on every API call containing EU personal data, regardless of what the DPA states. A vendor running inference on EU infrastructure does not create a transfer on that call. This is distinct from where the company is headquartered or where the contract is governed.

The second is where logs are stored. AI system logs — the records of what was processed, when, and what outputs were produced — are often stored separately from inference infrastructure, frequently in the jurisdiction of the observability tooling the vendor uses, which defaults to US-based services. Asking specifically about log storage and access controls produces answers that are often different from what the DPA and data residency marketing imply.

The third is where retrieval or fine-tuning data lives. AI tools using retrieval-augmented generation pull from an index built from organisational data. Where that index is stored and who can access it is a distinct question from where inference happens, and the answer is not always EU.

What EU-native infrastructure removes from the equation

An AI tool built and operated on EU infrastructure — with inference, logging, and data storage all within the EU — does not require a transfer mechanism, does not create Schrems II exposure, and does not require a Transfer Impact Assessment. The legal overhead is absent because the legal trigger, a transfer to a third country, does not occur.

This is the structural case for EU-native AI tools, distinct from and more durable than any preference-based argument. For a European operator running a procurement process, where data goes when a tool processes it is now a first-order criterion. The companies positioned to benefit from the clarity that the DPF litigation will eventually produce are the ones that have already removed the exposure, rather than the ones managing the risk through mechanisms whose validity depends on a judicial outcome.