GDPR and the CLOUD Act in the Age of AI: Data Security for Businesses

An employee wants to summarise a customer email. She copies the full text into an AI chat and uploads the attached invoice as well. A developer is investigating a bug and sends source code and configuration to a coding assistant. Both simply want to work faster. Yet customer data, personal data, or confidential company information may now be transferred to an external service.

Situations like these are no longer unusual. In the past, many companies could focus their privacy reviews on centrally procured software and clearly defined systems. Today, AI services also enter everyday work through browsers, development environments, plugins, APIs, and private user accounts.

In the age of AI, data protection does not begin with choosing a provider. It begins with the question of which data leaves the company in the first place.

Anyone who takes customers, employees, and company knowledge seriously should look more closely. The data may include personal information, credentials, source code, contracts, calculations, and trade secrets.

This article explains the relevant legal and technical foundations. It is not legal advice for a specific case.

The input is what matters

Public product copy needs a different assessment from a personnel file, a customer invoice, or a medical report. Source code is not automatically harmless either. It may reveal internal processes, security mechanisms, credentials, or features that have not yet been released.

Before a company chooses an AI provider, it needs to know which information will be sent to the model:

• public content,
• internal documents and communications,
• customer and personal data,
• source code, configurations, and credentials,
• contracts, quotations, and calculations,
• trade secrets and strategic information.

Data protection, data security, and the protection of trade secrets are not the same thing. In this context, however, they lead to the same first question: Which inputs reach which model?

The GDPR prohibits neither AI nor US providers

The GDPR does not impose a general ban on AI systems or services from the United States. It requires personal data to be handled lawfully and transparently. Among other things, a company must clarify the purpose, legal basis, companies involved, and any international data transfers.

The model name does not answer these questions. GPT and Claude can be used through consumer products, business plans, and APIs, each with different terms. OpenAI states that data from its business products and API is not used for training by default. Anthropic provides a comparable commitment for Claude for Work and its API.

These commitments matter for business use. With a closed service, however, the customer still has to trust that the provider honours them. The customer has no direct control over model operation.

A European server location does not solve every problem

A server location in Germany or elsewhere in Europe makes sense. It can be an important part of a GDPR-compliant solution. What still matters is which company controls the service and which jurisdiction applies to that company.

Where the provider is based, the server location, and the model must be assessed together.

A US company remains a US company even when it operates an additional location in Europe. OpenAI, for example, offers data storage and processing in Europe. That can be relevant for data protection. It does not automatically change the provider’s origin or remove the possible application of US law.

This is precisely where the CLOUD Act becomes particularly relevant.

What the CLOUD Act allows

The CLOUD Act was enacted in the United States in 2018. It clarifies that a provider subject to US jurisdiction must disclose data in its possession, custody, or control when served with valid legal process. According to the US Department of Justice, this can apply regardless of the country in which the data is stored.

The law does not give US authorities arbitrary direct access to European servers. A valid legal order is required. One important issue nevertheless remains for affected companies: under US law, notice may be delayed under certain conditions. A court may also temporarily prohibit the provider from informing others about the order.

The CLOUD Act does not override the GDPR. The two legal frameworks apply from different jurisdictions. Article 48 GDPR and the final guidelines of the European Data Protection Board make clear that an order from a third country does not simply replace the requirements of the GDPR.

Claims such as “GDPR-compliant” or “servers located in Europe” therefore do not fully address this potential conflict.

Provider, location, and route to the model

At first glance, the choice seems simple: German provider, German server location, problem solved. In practice, the same provider may offer several very different paths to a model.

T-Systems operates open models such as Llama, Mistral, and DeepSeek in its own data centres in Germany, Switzerland, and the Netherlands. At the same time, its platform can provide access to models from OpenAI or Anthropic through Microsoft, AWS, or Google Cloud. The interface may look similar. The path taken by the input is not.

When an open model runs in a German data centre, the input remains within infrastructure controlled in Europe. When a closed US model is used, the German provider works with American companies or their cloud platforms. A European server location does not then automatically remove the possibility of access under US law.

A German provider alone is therefore not a sufficient answer. Companies need to assess three points together:

1. Provider: Where is the company that controls the service established, and which law applies?
2. Location: Where is the specific service operated?
3. Route to the model: Is an open model genuinely operated there, or is the input forwarded to an external provider?

The visible provider name is only one layer. The combination reveals which company actually receives the input. Created with AI assistance.

German alternatives for sensitive inputs

For sensitive inputs, options may include STACKIT AI Model Serving, the open models available through T-Systems AI Foundation Services, or plusKI from plusserver. These services provide access to open models operated by German providers in German or European data centres.

The specific choice within each platform remains important. Some platforms provide both locally operated open models and closed US models. The platform provider’s name alone is therefore not enough. It must be clear which model actually receives the input.

Large German companies have also been exploring these alternatives for some time. Siemens documents its internal use of open-weight models. SAP offers locally hosted models and sovereign options, including Mistral. Deutsche Telekom provides open models through its own European data centres. This does not demonstrate a complete switch. It does show that location, model choice, and digital sovereignty now influence real architecture decisions.

I explain the technical differences between closed models, open weights, and open source in “Closed Models, Open Weights, and Open Source in the Enterprise”.

My recommendation

For public or low-risk information, a professionally managed AI service may be the best economic and technical option. For personal, confidential, or business-critical data, “GDPR-compliant” is not a sufficient basis for a decision.

Before approving a service, companies should answer five questions:

1. What information is sent to the AI service?
2. Which provider receives these inputs?
3. Where is the specific service operated?
4. Which model actually processes the inputs?
5. Could the operator or model provider be subject to US law?

The decision path does not provide automatic approval. It shows where a closer assessment is required. Created with AI assistance.

Most data does not leave a company because somebody has bad intentions. Usually, someone simply wants to work faster. That is exactly why companies need clear rules and approved tools before sensitive information reaches an external AI service.