GDPR-Compliant AI Hosting: How to Choose a Provider

GDPR-compliant AI hosting depends on four factors: who operates the service and which law governs them, where prompts are processed and stored, whether data is used for training, and the Art. 28 GDPR processor contract. Selecting an EU region from a US provider only addresses the processing location and potentially the storage. It does not remove the legal reach of the US government or the dependency on shifting adequacy frameworks.

What makes AI hosting GDPR-compliant?

Four questions decide it:

1. Who operates the service? This determines which national laws can compel the provider to hand over data.
2. Where are prompts processed and stored? This defines the physical location of the data and whether it leaves the EEA.
3. Is your data used for training? You must ensure the provider does not use your input or output to improve their models.
4. Is there a valid Art. 28 GDPR contract? You need a legally binding agreement that limits the processor to your documented instructions.

Does an EU region on a US provider solve the CLOUD Act problem?

No. The CLOUD Act (18 U.S.C. § 2713) requires a US provider of electronic communication or remote computing services to disclose data in its possession, custody, or control regardless of whether such information is located within or outside of the United States. If a US company operates the service, the data remains within reach of US legal process even if the servers are in Frankfurt or Paris.

The current legal basis for transferring data to the US is the EU-US Data Privacy Framework (DPF), a Commission adequacy decision from July 2023. On 3 September 2025, the EU General Court dismissed the annulment action Latombe v Commission (T-553/23). We covered the self-hosting answer to this in EU data sovereignty for AI. However, an appeal (C-703/25 P) was filed on 31 October 2025 and goes to the Court of Justice; check its status before you rely on the DPF.

Historically, the two predecessors to the DPF, Safe Harbor and Privacy Shield, were both struck down by the Court of Justice, in 2015 and in 2020. While the DPF is a valid legal basis today, there is a known revocation risk. The practical approach is to use these services if necessary but maintain an exit plan that you can execute if the DPF falls.

Which hosting options are there?

US providers with EU residency

OpenAI announced data residency in Europe on 5 February 2025 for the API Platform, ChatGPT Enterprise and ChatGPT Edu. For API requests through a Project with Europe selected, OpenAI handles requests to eligible endpoints in-region with zero data retention. This means requests and responses are not stored at rest on their servers. This can only be configured for new Projects. On 16 January 2026, OpenAI added in-region GPU inference in Europe for eligible ChatGPT Enterprise, Edu and Healthcare customers. These fit when you need the strongest reasoning models and accept the legal risks of the CLOUD Act.

EU-operated model APIs

These are services provided by European companies using their own infrastructure. The German cloud provider STACKIT offers AI Model Serving in region EU01, stating that data and queries are neither stored nor used to train models. Available models include Google Gemma 4 31B, gpt-oss-120b, gpt-oss-20b, Llama 3.3 70B and Qwen3 VL 235B. For example, Gemma 4 31B is priced at 0.45 Euro input and 0.65 Euro output per million tokens.

OVHcloud AI Endpoints are hosted and run in the EU. They hold ISO 27001, SOC 2 Type II and HDS certifications for health data. They offer zero data retention except for billing and more than 20 open-weight models. Scaleway Generative APIs are hosted in a secure datacenter in Paris only, featuring models like Llama 3.3 70B and Mistral Small 3.2. IONOS AI Model Hub is hosted in IONOS Cloud data centres and provides models such as Mistral Nemo and Qwen3.5 variants. These fit when you want an EU operator instead of a US one and want to avoid the complexity of managing hardware. In our experience, open-weight models on EU clouds trail frontier closed models on hard reasoning tasks, and for drafting, extraction and summarising the gap rarely matters. How we pick a model for that kind of work is in choosing a local LLM for business writing.

Self-hosting open-weight models

This involves running models on your own hardware or rented bare metal. You have full control over where the data sits and how it is logged, and no model provider sees the prompt. On rented servers the hosting company still has physical access, so its contract matters too. The cost side is in self-hosted AI vs cloud APIs, the hardening in securing self-hosted AI infrastructure. This fits when you handle highly regulated data or have the internal engineering capacity to manage the GPU stack and patching.

How to choose by data class

You should decide the hosting tier per use case rather than applying one rule to the whole company. Most setups we build end up with two tiers. They use frontier models for non-sensitive internal tasks and EU-based or self-hosted models for customer and employee data.

The contract checklist before you sign

A standard API terms-of-service is not an Art. 28 GDPR contract. You must ensure the processor agreement explicitly covers the following eight duties:

1. Processing only on your documented instructions.
2. Ensuring all staff are bound by confidentiality.
3. Implementing security measures required by Art. 32.
4. Following strict conditions for any sub-processors.
5. Assisting you in answering data subject requests.
6. Helping with security, breach notification and DPIA duties under Art. 32 to 36.
7. Deleting or returning all data at the end of the service.
8. Providing information to prove compliance and allowing audits.

Beyond the Art. 28 GDPR minimum, add AI-specific clauses:

• A written no-training clause. This must state that your data is not used to improve the model. A default setting in a privacy policy can change; a contract clause cannot change without you. What “we cannot rule out” means in practice.
• Specific retention periods. Define how long prompts, outputs and abuse monitoring logs are kept.
• A full list of sub-processors. This should include the specific GPU provider or the model maker if the host is just a wrapper.
• Data access clarity. For open-weight models hosted by an EU cloud, the model maker does not see the data. Ensure this is documented.
• Deletion of backups. Ensure that the end of the contract includes deletion from backups and snapshots.
• Breach notification timing. Set a concrete window for when you must be notified of a leak.

If you process employee or customer data at scale, a Data Protection Impact Assessment (DPIA) under Art. 35 GDPR is often required.

Where the data actually leaks: the logs around the model

In the systems we build, the model API is the easiest part to secure. The actual leak path is rarely the API call itself. The danger lies in the observability and persistence layers surrounding the model.

A typical stack copies the data into four places:

1. Observability stacks: Prompt and response logs are often stored in logging tools for debugging and monitoring. These logs often bypass the zero-retention settings of the model API.
2. Vector databases: When you use RAG, you store embeddings and chunks of your documents in a vector database. This is a permanent copy of your data, and an attack surface of its own, see securing RAG pipelines.
3. Frontend history: Chat interfaces often store history in a database to allow users to see previous conversations.
4. Debugging exports: Developers often export logs to local files or external tools during the development phase.

Each of these components requires the same retention rules and access controls as the model call. If you choose an EU provider for the API but store the prompt logs in a US-based logging tool, you have not solved the compliance problem. Self-hosting the model does not fix this on its own because you still have to decide where the logs go.

Order of work

To implement this, follow these five steps:

1. Classify your data into the four classes mentioned above.
2. Pick a hosting tier for each data class.
3. Sign the processor contract using the Art. 28 and AI-specific checklist.
4. Configure the retention and access rules for the logs, vector database and frontend.
5. Document the flow in your record of processing activities and the DPIA.

Your DPO or legal counsel signs off the result. The work before that, classifying data and fixing the logs, is engineering, and it is where most projects we see are behind.

Related reading

• EU data sovereignty for AI: post-Schrems II self-hosting
• Self-hosted AI vs cloud APIs
• Securing self-hosted AI infrastructure
• A private AI pilot, week by week
• AI Act Article 50: how to label your chatbot