Azure OpenAI: the deployment type, not the region, decides where prompts are processed
Bottom line. Putting an Azure OpenAI resource in an EU region does not keep processing in the EU. With the default Global Standard deployment type, Microsoft may process prompts in any Azure region; only Data Zone (EU Data Boundary) or regional Standard keep inference inside the zone or geography. Write every "your data stays in …" sentence from the SKU your deployment script actually creates.
Ve zkratce. Prostředek Azure OpenAI v evropském regionu ještě neznamená zpracování v EU. U výchozího typu nasazení Global Standard může Microsoft dotaz zpracovat v kterémkoli regionu Azure; zpracování v zóně nebo geografii drží jen Data Zone (EU Data Boundary) nebo regionální Standard. Každou větu „data zůstávají v …“ piš podle SKU, které nasazovací skript opravdu zakládá.
Symptom
An app's help page, website or privacy text says something like "Data stays in Azure in the region
you chose (EU, US, …)" or "the AI model runs in your Azure subscription in the EU". The deployment
script — like many samples, and in line with Microsoft's own advice to start with Global Standard —
creates the model deployment as GlobalStandard. Nobody notices, because everything works and the resource really is in
swedencentral.
Cause
The region is only the resource's address. Microsoft documents three processing scopes (Deployment types):
| Type (SKU) | Where prompts are processed | Data at rest |
|---|---|---|
GlobalStandard |
may be processed in any Azure region | stays in the resource's geography |
DataZoneStandard |
only within the Microsoft data zone (EU zone = EU Data Boundary, which can include EFTA countries such as Norway and Switzerland) | geography |
Standard (regional) |
within the chosen Azure geography | geography |
New models launch as Global first; Data Zone follows, regional Standard comes last and only for a small set of models. So "pick a regional deployment for residency" is often not available for the model you actually use.
Fix
- Choose the type on purpose. For EU customers
DataZoneStandardin an EU region is usually the practical choice: most current models have it, and in September 2026 it cost about 10 % more per token than Global. Check the model's row under Data Zone Standard in Region availability. - Quota is separate per type. Quota is granted per subscription, region, model and deployment
type — a pre-flight check for
GlobalStandardquota says nothing aboutDataZoneStandard. - Treat a type change as a new deployment. Create the new deployment next to the old one, repoint the app setting that names the deployment, smoke-test, then retire the old one. A provisioning script that finds an existing deployment should leave its type alone and just report it.
- Print the type. End the deploy script with a line such as
Prompt processing: DataZoneStandard – only within the data zone (EU region = EU), read fromaz cognitiveservices account deployment show … --query sku.name. - Write texts from the SKU. Help pages, websites, privacy policies and security documents must match the type actually deployed — and when only new deployments change, describe both states until existing ones are migrated.
Notes
- Data at rest stays in the geography in all three cases; the difference is inference.
- Abuse monitoring may store prompts and completions that its automated checks flag for human review, in the resource's geography, unless modified abuse monitoring is approved — which is available only to customers managed by a Microsoft account team or in an eligible program. Microsoft's current documentation no longer states a retention period (older versions said "up to 30 days"). This is a separate question from where processing happens.
- For comparison: Microsoft 365 Copilot is an EU Data Boundary service, but its flex routing (inference in the US, Canada or Australia at peak load) is on by default for eligible EU tenants created after 25 March 2026 (Flex routing).
- Related: a pinned model+version is a time bomb, 429 on a single request is a TPM ceiling.