EU Data Residency for AI APIs in 2026: Provider Guide

The main EU-residency options for AI APIs in 2026 are OpenAI's Europe region, Azure OpenAI EU Data Zone deployments, Mistral's EU-default platform, AWS Bedrock EU inference profiles, and self-hosting on EU infrastructure such as Hetzner. OpenAI now documents both regional storage and regional processing for eligible European API projects through eu.api.openai.com. Azure and AWS tie processing location to the deployment or inference-profile type. Mistral defaults to EU hosting but documents feature-specific subprocessor transfers. Self-hosting gives the most direct control and the most operational work.

This is an engineering view, not a legal opinion or vendor pitch. Claims were re-checked on 7 August 2026 and have a short shelf life. Before signing, verify storage, processing, retention, subprocessors, support access, and governing jurisdiction as separate contract fields.

First, get the words straight

Most confusion in EU AI procurement comes from mixing up terms that mean different things. Pin these down before you compare anything.

• Data residency is a location claim: where data physically sits. It is a convention, not a term defined in the GDPR.
• Data sovereignty is a jurisdiction claim: whose laws govern the data. EU data on a US-owned cloud can be EU-resident and still reachable under the US CLOUD Act. The legal anchor here is GDPR Chapter V on transfers, not the word "residency."
• Storage at rest is where your data is persisted. Processing or inference is where the GPU actually runs the call. Under GDPR Article 4(2), "processing" explicitly includes both storing and using data, so an inference call in a non-EU region is itself a processing event even if storage stays in the EU.
• Zero data retention (ZDR) means the provider does not persist your request or response at all. "No training on your data" only means they will not train on it; it says nothing about whether it is logged or stored. These are independent. A provider can refuse to train on your data while still keeping it 30 days for abuse monitoring.

The one sentence to remember: a vendor's "EU residency" label does not by itself prove EU-only inference. Some products now include both storage and processing, while others scope them separately. Verify the exact endpoint, deployment type, eligible services, retention mode, and exceptions.

The comparison at a glance

How the main options stack up across the dimensions that actually decide a procurement. All entries were reviewed on 7 August 2026 and should be re-verified per provider and feature.

Mistral and Hetzner are EU-headquartered, which removes the direct US-parent-company exposure of OpenAI, Microsoft, and AWS. That does not eliminate every transfer: review Mistral's current subprocessors and any optional feature that leaves its default hosting path. For US providers, customer-managed encryption keys can be a supplementary measure, not a complete answer.

OpenAI API

OpenAI's Europe region covers the EEA and Switzerland and now documents regional storage and regional processing for supported API endpoints. Create an eligible project in that region and send traffic to https://eu.api.openai.com; a regional project using the default global domain does not establish the same processing path. Non-US data regions also require approval for Modified Abuse Monitoring or Zero Data Retention. Supported endpoints and models differ, and system data or excluded services may follow separate rules, so verify the current control table rather than treating one regional toggle as universal. API data is not used to train OpenAI models by default.

Azure OpenAI

Azure gives the clearest in-region processing story of the hyperscalers, because the deployment type decides where inference runs. Global deployments may process in any Azure region worldwide. Data Zone deployments process only within a specified zone, and the EU Data Zone confines processing to the EU Data Boundary. Regional deployments stay in the deployment region. Storage at rest stays in your chosen geography across all of them. Two traps worth flagging: Batch jobs default to Global processing unless you pick the Data Zone batch variant, and the EU Data Zone (a processing scope of several regions) is not the same as the broader EU Data Boundary residency commitment. Human reviewers for EEA deployments are EEA-located, which is a genuine selling point. Azure OpenAI does not call OpenAI's own services and does not share your data with the model provider.

Mistral

Mistral is EU-headquartered and states that, by default, your data is hosted in the European Union; using the US endpoint is an explicit opt-in. Two things to get right. First, the official wording says "European Union," not a specific country, so do not write that it is "hosted in Sweden" because the Swedish facility is a future inference center, not where La Plateforme data sits today. Second, training defaults differ by plan: paid and Scale plans are opted out of training by default, while the free tier is opted in unless you change it. ZDR exists on the Scale plan for stateless calls and is request-gated. For maximum control, Mistral also offers self-hosted and dedicated-VPC deployments, and its open-weight models can be self-deployed. One caveat: on cloud marketplaces such as Bedrock or Azure, residency follows the cloud region you pick, not Mistral's EU default.

Hetzner and self-hosting

Hetzner is general-purpose hosting, not a managed LLM API, so you bring your own model and inference stack. What you get is full control of both storage and processing, all inside the EU, under an Article 28 data processing agreement, with no third-party model provider in the loop. Its owned EU data centers are in Germany (Nuremberg, Falkenstein) and Finland (Helsinki), and it offers single-GPU dedicated servers: roughly a 20 GB card for inference of smaller models, and a 96 GB card for training or running a quantized 70B model. The parks are ISO 27001 certified. The cost of this control is real: you now own capacity planning, quantization choices, batching, autoscaling, uptime, patching, and monitoring.

If you go fully self-hosted on open weights, watch the licenses. Most Mistral open models are Apache 2.0 and the least encumbered. Llama is not OSI open source; its community license carries a large monthly-active-user clause and an attribution requirement, and EU teams should check the current acceptable-use policy carefully before relying on multimodal variants. Qwen licensing is mixed by model. Self-hosting wins on control, not on cost or quality at low volume, where a dedicated GPU sits idle.

The decision tree

Pick the first branch that matches your hard constraint, not your preference.

1. No US entity may ever be able to access the data. Self-host open weights on Hetzner, or run Mistral self-hosted or on-prem. These are the only EU-jurisdiction options.
2. You need EU storage and processing, low ops, and a US provider is acceptable with the required transfer safeguards. Compare Azure OpenAI's EU Data Zone with an eligible OpenAI Europe-region project using eu.api.openai.com. Confirm model, endpoint, retention mode, support access, and exceptions.
3. You want an EU-headquartered managed API with minimal effort. Mistral on a paid or Scale plan, training off by default, ZDR added if needed.
4. You already live in AWS and want EU-contained inference. Bedrock with EU cross-region inference profiles, plus zero data retention if you need it.
5. You have high sustained volume and in-house MLOps and want to own everything. Self-host open weights on Hetzner, sized to the model, with the license caveats above.

"Do not procure an EU label. Procure a named endpoint, deployment type, processing boundary, retention mode, subprocessor list, and exception policy. That is the evidence an architecture review can test."

Where residency fits the bigger picture

Residency is one input into a defensible EU AI system, not the whole answer. The harder problems tend to be retrieval quality, per-user permissions, evals, and cost, which we cover in our RAG production-readiness checklist for the EU. And residency sits inside a wider compliance stack of RAG data flows, GDPR, and the AI Act, which we untangle in how GDPR and the AI Act stack for a DACH SaaS. Get the residency model right early, because retrofitting data location after launch is one of the more expensive things you can do.

Residency also does not minimize the payload. Use the PII redaction pipeline for LLM prompts to compare local Presidio and Privacy Filter with cloud DLP, then keep unnecessary identifiers out of the model request in the first place.

A bought pseudonymization platform is the packaged version of that minimisation, and it raises a separate legal question: does a pseudonymization gateway take the prompt out of GDPR scope? The short answer is that it can change the model provider's status, never yours, and only against the EDPB conditions for a third-country transfer.

Mapping the data flow before choosing where anything runs is the first step in AI software development in Austria, and taking on the retrieval, permissions and evaluation layers around it is our AI enablement service. Twinsoft AI is a worked example of the production system those constraints end up shaping.