Azure OpenAI Data Zones: the best-documented EU processing commitment, with one footnote

Azure OpenAI is the path most DACH enterprises end up on, usually because they already have the Microsoft agreement and the security review is shorter. It also carries the most precisely documented European processing commitment among the large providers.

It has one detail that deserves reading rather than skimming, and it is in the definition of the zone itself.

The three deployment types

The choice that matters is made once, at deployment, and it is easy to make wrong.

Global routes requests to wherever capacity is, worldwide. Cheapest, fastest to get throughput, and no residency commitment at all.

Data Zone confines processing to a defined geography. The EU Data Zone processes within the Azure EU Data Boundary, with load balancing across regions inside that boundary.

Regional pins to a single Azure region.

Data at rest is stored in the region of your resource in all three cases. What changes between them is where the inference happens, which is the property that decides whether a transfer occurred, and the one most vendor claims quietly skip. We pulled that distinction apart in storage residency is not processing residency.

Most teams deploy Global by accident, because it is the default path of least resistance and the difference is one dropdown.

The footnote

As of May 2026 the EU Data Zone spans regions in France, Germany, Italy, the Netherlands, Norway, Poland, Spain, Sweden and Switzerland. Norway is EEA, not EU. Switzerland is neither.

This is not a trap and it is not a problem: it is a naming decision that people read past. Both countries are covered by adequacy arrangements, so processing there is lawful without additional safeguards, and for most companies the zone is exactly what they wanted.

It matters in one specific situation, and it is a situation that comes up in DACH: when a customer contract, a works council agreement or a public-sector tender says “within the European Union” rather than “adequate jurisdiction”. Then the zone name and the contractual wording do not match, and you find out during an audit rather than during procurement.

The fix is trivial if you know: use a Regional deployment pinned to Germany or France, accept slightly less capacity flexibility, and the wording matches.

What it costs

Per-token pricing applies as normal, with one thing to plan for.

A 2026 pricing uplift on data-residency endpoints applies to the newer models.

Residency is not free, and the premium sits on exactly the models people want

The larger cost is the same one as with any hyperscaler path: you are adopting a platform, not calling an API. Resource groups, quotas, deployment names, regional model availability. If your company already runs on Azure this is free. If it does not, you are taking on a stack to make one call, the same trade as Bedrock in Frankfurt, just with a different console.

The verification list

Check the deployment type, not the region. A resource in Germany with a Global deployment processes globally. This is the single most common misconfiguration in this product and it produces a screenshot that looks reassuring.

Confirm abuse monitoring separately. Azure OpenAI retains flagged prompts and completions for around 30 days for abuse analysis, with human review possible. Modified Abuse Monitoring is available on application and removes or limits both. That is a retention question, entirely independent of residency: the three promises get conflated constantly.

Ask about the side paths. Content filtering, logging and telemetry are where in-region deployments leak. The model can run in the zone while something adjacent does not.

Write the zone into the DPA. A deployment type is a setting anyone with console access can change. A contract is not.

Where it wins and where it does not

It wins when you are already on Azure, when the security review is the bottleneck rather than the technology, and when you need a documented processing commitment you can hand to a Datenschutzbeauftragter without a covering letter. That combination describes a large share of German mid-market and enterprise IT, and it is why this is so often the right answer.

It does not win when the requirement is about the operator’s jurisdiction rather than the data’s location. Microsoft is a US company operating EU regions; the EU Data Boundary is a strong contractual commitment and it does not change who the operator is. For requirements written that way, the European providers are a different conversationDE (auf Deutsch).

And it does not win on newest models. Model availability in EU zones lags the direct API. If your architecture keeps the model behind your own thin interface, that is an inconvenience. If it does not, it becomes a constraint on your roadmap.

What we would actually use it for

Production systems inside companies whose IT already lives in Azure, where the residency answer has to survive a formal review. In that setting it is the shortest defensible path, and the documentation is good enough that the review actually ends.

For a prototype, the direct API is faster and simpler. Move when the question becomes real, which, if you build behind your own interface, is a configuration change rather than a migration.

Frequently asked questions