The Cloud Act and the GDPR: Where Your AI Data Should Be Stored

The CLOUD Act and the GDPR are rarely mentioned in the same sentence when it comes to AI projects, even though they may pertain to the same dataset once a language model is running in a U.S. cloud. Under certain conditions, the U.S. CLOUD Act allows U.S. authorities to access data from U.S. providers, even if the servers are located in the EU. Anyone planning AI applications that involve personally identifiable information or sensitive business data must consider both legal frameworks together from the very beginning—not just when the legal department starts asking questions after the system goes live.

The Cloud Act and the GDPR: The Legal Framework for AI Data

The U.S. CLOUD Act of 2018 requires U.S. providers to disclose data upon government order, even if that data is technically stored on servers in the EU. This does not change the actual GDPR obligation. In any case, a cloud provider needs a data processing agreement that specifies how personal data may be processed and who is involved as a subprocessor.

In 2020, Schrems II invalidated the EU-U.S. Privacy Shield because the European Court of Justice deemed U.S. authorities’ access to European data to be disproportionate. The EU-U.S. Data Privacy Framework is the successor to this arrangement, but according to an assessment by noyb from June 2026 is once again under pressure. This is due to decisions regarding the independence of the U.S. regulatory agency, the FTC, which, according to this assessment, undermine the foundation of the agreement.

Data Classes and Routing Rules

In practice, a simple classification is more helpful than a legal distinction for each individual case. Personal data and data critical to competition—such as design data or unpublished financial figures—belong in a separate category with a clear rule regarding which systems are permitted to process them. According to this rule, general data that is publicly available anyway can be sent to an international cloud API, while sensitive data remains with a European provider or in an in-house environment. This article describes how a language model can be fully self-operated for precisely this sensitive data. On-Prem LLM for Business: Private AI Models for Sensitive Data.

According to an analysis of gosign As of February 2026, companies typically process 60 to 70 percent of their AI requests through international cloud providers, 25 to 35 percent through German IaaS, and 5 to 10 percent on-premises. This breakdown generally follows the data class rather than the technical convenience of the respective team.

How the routing rule can be implemented technically

In most architectures, the rule is located in a single place—a gateway or a small piece of middleware—through which every request to a language model passes. There, a tag on the data set—such as „public“ or „confidential“—determines which provider receives the request. This means application teams don’t have to make this distinction themselves; they simply select the data class when creating a new use case.

This feature is also useful for logging. If you need to verify later which request reached which provider, you can find the answer in a single log rather than in several scattered applications.

The Data Processing Agreement as a Point of Review

A data processing agreement is mandatory in all cases under Article 28 of the GDPR, regardless of where the provider is located. With a U.S. provider, it is important to note which subprocessors are listed in the agreement and whether any of them are companies that are themselves subject to the U.S. CLOUD Act. A European contractual partner with a U.S. parent company usually does not provide protection against such access. A second or third subprocessor in the chain also counts—for example, a data center operator or a support service provider with access to production data.

In our own projects, we always evaluate this chain before selecting a system, not after. In practice, switching subcontractors in the middle of a project takes more time than conducting a thorough evaluation at the outset, especially if training data or embeddings are already stored on the system in question.

From Data Class to Architecture

A well-defined data class serves as the foundation for the technical architecture that follows. Our article on hybrid AI architecture demonstrates how cloud and on-premises processing can be combined in practice without having to make a new decision for every single request. Those who want to jointly classify their own data environment from both a legal and technical perspective will find guidance on this in a Initial Consultation on AI Consulting a structured introduction.

Frequently Asked Questions

Is one EU data center enough?

An EU data center meets the GDPR’s requirement regarding the location of processing, but does not automatically prevent access under the U.S. CLOUD Act. What matters is the provider’s nationality and corporate structure, not just the server’s location. A U.S. company with a data center in Frankfurt remains subject to the U.S. CLOUD Act, even if the data never leaves the EU.

What data should never be sent to the cloud API?

There is no one-size-fits-all answer, but the highest level of caution applies to unpublished patents, design data relevant to competition, and particularly sensitive personal data under Article 9 of the GDPR, such as health data. For these categories, local or European processing is worthwhile regardless of the additional technical effort involved. When in doubt, it helps to consider whether a loss of this data would seriously harm the company. For such categories, the highest protection level takes precedence over the convenience of the development team.

What will change if the framework collapses?

If the EU-U.S. Data Privacy Framework collapses, as the Privacy Shield did before it, companies will lose the simplest legal basis for data transfers to the U.S. and will have to fall back on standard contractual clauses with additional safeguards. Those who already segregate data by class will then only need to adjust the routing rule for a single class—not rebuild the entire architecture. This is precisely why the groundwork is worth the effort, even if it initially seems like extra work in the midst of an ongoing project.

Why torck

torck develops and operates AI systems with its own teams in Maxhütte-Haidhof, Vienna, and Rabat, and defines the data class for each project before the first line of code is written. The contractual partner is the German company torck GmbH; a single contract replaces a chain of subcontractors, which significantly streamlines the vetting process for subprocessors described in this article. This approach prevents the need for costly modifications should the legal landscape surrounding transatlantic data transfers change. Anyone who wants to ensure their own architecture is legally and technically sound can do so in a Initial Consultation on AI Consulting discuss.

Schedule a meeting