Is Your AWS EU Region Actually GDPR-Safe? The CLOUD Act Problem

Location and control are different questions

An EU region does not answer every access question. Under the CLOUD Act, covered providers can be required through valid legal process to produce data within their possession, custody or control, including data stored abroad. Jurisdiction, access and available challenges matter. This is a disclosure-risk assessment, not proof that every EU workload on a US-owned platform is an international transfer.

• Location: confirm which processing and storage operations the selected region covers
• Control: identify entities with access and assess applicable disclosure powers
• Transfer: apply the EDPB criteria to actual disclosures or availability of personal data

What does "subject to US jurisdiction" mean when a US-headquartered parent contracts through an EU subsidiary? The honest answer is that it is a fact-specific question: US jurisdiction is not limited to US-headquartered companies, but neither is it unlimited; it turns on the entity's contacts with the United States and on whether the court can reach the entity that has possession, custody or control of the data, the same hook the CLOUD Act uses to attach its disclosure obligation. In other words, an EU subsidiary is not automatically outside reach, and it is not automatically inside it. It is a fact-specific question your assessment has to answer for your specific provider. GDPR Article 44 frames the obligation on your side: any transfer of personal data to a third country may take place only if the conditions in Chapter V are complied with, including for onward transfers. We cover what that assessment looks like for LLM inference in more depth in our guide to GDPR-compliant LLM inference in Europe.

What the Schrems II reasoning actually turns on

The controlling judgment is Case C-311/18, Data Protection Commissioner v Facebook Ireland and Maximillian Schrems, decided by the Court of Justice of the European Union on 16 July 2020. The Court upheld the validity of standard contractual clauses as a transfer tool. That is the part most vendor compliance pages quote. The operative part for your assessment is what the Court said about the limits of contracts: because standard contractual clauses are contractual in nature, they cannot bind the public authorities of third countries, since those authorities are not party to the contract.

The consequence the Court drew is that the exporter must verify, case by case, whether the law and practice of the third country impinge on the effectiveness of the safeguards the transfer tool provides. The EDPB turned that holding into Recommendations 01/2020, which set out the structured assessment exporters are now expected to run. The Court's specific finding on US surveillance law matters here: it held that Section 702 of the US FISA does not respect the minimum safeguards resulting from the principle of proportionality under EU law, and that programmes authorised under it are not essentially equivalent to EU safeguards.

1. Schrems II upheld standard contractual clauses as a transfer tool
2. Contracts do not bind a foreign public authority
3. For transfers relying on those safeguards, assess effectiveness and any supplementary measures
4. Check current adequacy arrangements separately rather than treating the 2020 judgment as a verdict on every current service

What an EU region does resolve

An EU region can meet a location requirement for the operations it covers. It does not authorise physical access without legal process or automatically establish Article 28 compliance. Review processor terms, support access, logs and failover independently.

The EDPB transfer test requires a GDPR-subject exporter making personal data available to another controller or processor in a third country or international organisation. A named processing site can support that assessment, but cannot prove the absence of remote access or onward disclosure.

Foreign ownership may prompt further questions about control and disclosure powers. It does not by itself establish that a parent can access the data. Assess the legal and technical arrangements for the service you intend to use.

Running the transfer impact assessment

First determine whether the data flow is a Chapter V transfer. Then identify the applicable mechanism. A transfer covered by an adequacy decision does not need an additional Article 46 safeguard; transfers relying on standard contractual clauses require an effectiveness assessment.

1. Map recipients, locations and remote access. A separate overseas support entity can be an importer; an employee of the same entity is a different case
2. Check whether an adequacy decision covers the recipient and processing
3. Otherwise identify an appropriate transfer tool and assess its effectiveness
4. Document any supplementary measures, decision owner and review triggers

The current US adequacy status, read from the European Commission's adequacy page: the United States is listed as providing adequate protection for commercial organisations participating in the EU-US Data Privacy Framework, and the Commission published its report on the first review of the framework's functioning on 9 October 2024. The coverage is conditional, which is the part that matters for your assessment: adequacy attaches to organisations that participate in the framework, so you must verify that your actual provider, the entity you contract with, is a certified participant, and that the adequacy decision is still in force when you rely on it. For an inference workload, also check it per model and per processing site, because a single provider can serve the same API from several jurisdictions.

What sovereign-cloud constructions change

EU operating entities and local personnel can reduce overseas access paths. Verify their actual authority, technical controls and exceptions. Neither a foreign parent nor an EU subsidiary alone settles whether data is accessible or subject to disclosure.

Contractual commitments to challenge orders have the same shape. The SCCs oblige the importer to inform the exporter of legally binding requests and to challenge them where lawful. These commitments have value: they create notice, they create a paper trail, and they give the exporter grounds to suspend. Their limit is the Schrems II reasoning itself: a contract cannot bind a foreign public authority that issues the order, so the commitment is a promise about litigation, not a guarantee of outcome.

The jurisdiction of the contracting party is the fact you can actually verify in this category, and it is the one we state about ourselves and nothing more: we contract through Lyceum Technology Germany GmbH, Berlin, with a second entity, Lyceum Switzerland GmbH, Zürich. That tells you which legal system governs the contract you sign. It is a meaningful data point for the assessment. It is not, by itself, a claim that any provider is outside all third-country legal reach, and we do not make that claim, about ourselves or anyone else. This is part of a broader shift described in the rise of the European GPU cloud, where jurisdiction of the operating entity is becoming a procurement criterion alongside price and hardware.

Encryption during inference needs a separate assessment

Encryption at rest and in transit protects different parts of the data path. Its value depends on key control and the attacker or disclosure scenario. Identify when data is decrypted and who can access it.

Conventional inference processes prompts in plaintext in system or GPU memory. Confidential-computing designs can reduce privileged access, while encrypted-computation approaches have different constraints. Neither should be assumed available for a particular model or service. Assess the implementation, attestation and threat model before relying on it.

Lyceum’s stated inference policy is that prompts and outputs are processed, not retained or used for training, with short-lived session caches in GPU memory. This is self-asserted and does not remove data exposure during processing. Retention controls and access protections answer different questions.

Documenting a decision rather than seeking a verdict

The honest answer to the question this article started with is that there is no verdict to buy. Processing location can be contracted per site and per model. Exposure to a foreign legal system depends on who controls the entity holding the data. No provider choice, European or otherwise, makes your processing operation GDPR compliant by itself; compliance belongs to the whole processing operation, and the regulation requires an assessment, not a badge. What you can produce is a documented risk assessment your DPO can defend, and that document has a known shape.

• The transfer: which data, to which provider, processed at which site, with which remote-access pathways.
• The transfer tool relied on: the SCCs or other Article 46 mechanism, and confirmation the provider participates where an adequacy route is claimed.
• The assessment of third-country law as applied to this provider and this data, following the EDPB roadmap.
• The supplementary measures adopted, and the residual risk that remains after them.
• The decision and its owner, dated, so it can be revisited when the law or the architecture changes.

Evidence to request from any provider, before you sign: the Article 28 processor-contract terms on documented instructions, onward transfers and notification of legally binding requests; the specific site or sites where your capacity runs, and who controls them; the retention policy for prompts, outputs and logs, stated per service; and the identity and jurisdiction of the contracting entity. Our DPA is available on request. Ask every provider on your shortlist for the same four items, and the comparison becomes factual rather than rhetorical.

If you need a named processing site, ask for written commitments for the exact model and service. Lyceum’s documented Dedicated Inference workflow accepts a Hugging Face model identifier, subject to supported models, hardware and access requirements. Confirm capacity, site and isolation terms with the team; the model-ID workflow does not promise arbitrary Docker-image deployment.