If AI processing has to stay inside the EU, Azure gives a clear answer on residency through Data Zone deployments. It says nothing about capacity. On a new subscription we got zero quota for the model we needed, and all four requests for more were turned down.
Contents
What a Data Zone deployment actually promises
Microsoft’s documentation on deployment types keeps apart two things that planning often merges: where data is stored at rest, and where inference runs. For every deployment type, data stored at rest stays in the designated Azure geography.[1] The difference is in processing. Global types may process prompts and responses in any Azure region. Data Zone types process data only within the Microsoft-specified data zone (US, EU or APAC). Standard and Regional Provisioned types process prompts and responses within the Azure geography the customer picks, and processing may move between regions inside that geography for operational purposes.[1]
| Deployment type | Where inference runs | Availability order |
|---|---|---|
| Global | Any Azure region | First |
| Data Zone (EU) | Only within the EU data zone | Second |
| Standard, Regional Provisioned | Within the Azure geography you choose | Last, no guaranteed date |
For all three types, data stored at rest stays in the designated Azure geography. Source: Microsoft Learn, deployment types[1].
In the EU, the Data Zone follows the Azure EU Data Boundary. That boundary can include EFTA countries such as Norway and Switzerland as well as EU member states.[1] Microsoft also says it can add regions to a data zone without prior notice to improve capacity and availability.[1] Most GDPR assessments can live with that. But your records of processing should say “EU Data Boundary”, not name a single country or region.
Microsoft recommends Global Standard as the default starting point. It gets new models first, has the lowest price and covers the most regions.[1] New deployment types arrive in a set order: Global first, then Data Zone, then geography-based.[1] An EU-only rule therefore puts you one step behind by design.
What the EU Data Boundary covers, and what it does not
The EU Data Boundary is Microsoft’s commitment to store and process Customer Data and personal data for its enterprise online services, including Azure and Microsoft 365, in EU and EFTA countries.[2] For Azure, regional services deployed in an EU Data Boundary region are in scope.[2] For Microsoft 365, tenants whose sign-up location is in the EU or EFTA are in scope. Customers who have purchased Multi-Geo Capabilities are not.[2]
The commitment has documented limits that matter for an AI rollout:
- Customer Data does not include information used to configure resources, such as technical settings and resource names.[2]
- Only paid services that are generally available are included. Services in preview and free trials are not.[2]
- Microsoft does not block transfers that a customer starts. Examples are an administrator connecting a boundary service to another service under separate terms, or a user working from outside the boundary.[3]
- Some data still leaves the boundary for security operations, controlled remote access by Microsoft personnel, replication of limited directory data, and network transit that may sometimes route traffic outside the boundary.[3]
In practice, a Data Zone deployment controls where the model processes your prompts. Everything around it needs its own check, including any preview features you turn on and any connectors you add.
Quota is the part nobody puts in the compliance plan
Azure OpenAI quota is assigned to a subscription per region, per model and per deployment type, measured in tokens per minute (TPM).[4] Each deployment takes TPM from that pool. Once the pool is used up, you can only move TPM from other deployments of the same model or ask for more. Quota is not enforced at tenant level. The highest scope is the subscription.[5] Starting after 7 May 2026, Microsoft is moving quota to subscription-level pools, beginning with two realtime models and, it says, soon all models.[5] The change consolidates quota into shared pools: Data Zone Standard deployments of the same model and version share one pool per data zone.[5]
Quota tiers sit on top of this: a Free tier plus Tiers 1 to 6. Your starting tier depends on your current usage and your relationship with Microsoft, for example EA or MCA-E status. Upgrades are automatic and depend on consumption trends, that relationship and payment history.[5] You ask for more through a quota request form. Microsoft says requests are handled in the order they arrive, that customers who actively use their current quota get priority, and that other requests might be denied.[5]
Taken together, these rules leave a new subscription in a weak position. It has no usage history, sits on the lowest tier, and has nothing running that would justify an increase.
What happened on our new subscription
Our production SharePoint AI assistant runs entirely in Azure in the EU. The answer model is an EU Data Zone deployment in Sweden Central, and embeddings with text-embedding-3-large are also processed in the EU.
On 19 September 2026 we created a new Azure subscription on a partner benefit credit. Its EU Data Zone quota for the flagship model was 0. The smaller mini model had 200K TPM in the Data Zone. The embedding model, text-embedding-3-large, had 0 in the Data Zone and 350K in Standard (regional). The subscription started on the Free quota tier, and Azure scheduled an automatic upgrade to Tier 1 a few days later.
We sent four quota increase requests: three for the EU Data Zone and one for Global Standard. All four were rejected, two of them within four minutes, each with the same message: “The region you requested a quota increase in is not available to expand capacity at this time. Please expand your regional choices when submitting a new request or wait 30+ days before resubmitting for a quota increase within the same region again.”
A support case confirmed what the message suggests. Capacity-based denials are not caused by a misconfigured deployment. Renaming the deployment, changing its resource group or changing portal settings will not help. The realistic options are to deploy where quota already exists or to resubmit later.
Here is our workaround. The heavier in-depth answer mode now uses a separate Azure OpenAI resource, with its own key, in another subscription that already had EU Data Zone capacity. Processing stays in the EU. The price is operational: two resources, two keys and two quota pools to monitor.
Checklist for an EU-only AI rollout
- Write the residency requirement precisely. An EU Data Zone deployment processes data within the EU Data Boundary, which can include EFTA countries. Standard (regional) keeps processing inside one Azure geography, but new deployment types reach it last.
- Enforce the requirement technically. Microsoft documents an Azure Policy definition that disables a chosen deployment SKU.[1] Use it to block GlobalStandard in subscriptions that must stay in the EU.
- Check quota before you commit to a date. Use the quota view in the Foundry portal, the Usages API for limits and consumption per region, and the Model Capacities API for available capacity per location and deployment type.[4]
- Check every model, not only the chat model. In our case the embedding model had 0 quota in the Data Zone while regional Standard had capacity.
- Do not plan a production start on a brand-new subscription. Both tier assignment and priority for increases favour existing usage. Use a subscription with history, or plan for the wait. Our rejection text gave 30+ days before resubmitting in the same region.
- Design for more than one endpoint. Keep the model endpoint and key as configuration per answer mode. Then you can move a workload to a resource that has quota without changing code.
- Keep personal and confidential data out of resource and deployment names. Microsoft treats them as configuration, not Customer Data.
- Keep preview features out of workloads that must stay inside the boundary. Preview services are not included in the EU Data Boundary.
- Record each denial message with its date. The rejection text sets your earliest resubmission date for the same region.
At KSJ we build and run a SharePoint AI assistant on Azure OpenAI with EU Data Zone deployments, so the quota situation above is part of our day-to-day operations. The setup described here is what we run today: Data Zone processing in the EU, a separate endpoint per answer mode, and a second resource where capacity already exists. We work through this checklist before committing to a go-live date for this kind of deployment.
References
- ^ a b c d e f g h “Understanding deployment types in Microsoft Foundry Models”. Microsoft Learn. Retrieved 24 September 2026.
- ^ a b c d e “What is the EU Data Boundary?”. Microsoft Learn. Retrieved 24 September 2026.
- ^ a b “Continuing data transfers that apply to all EU Data Boundary Services”. Microsoft Learn. Retrieved 24 September 2026.
- ^ a b “Manage Azure OpenAI in Microsoft Foundry Models quota (classic)”. Microsoft Learn. Retrieved 24 September 2026.
- ^ a b c d e “Azure OpenAI in Microsoft Foundry Models Quotas and Limits”. Microsoft Learn. Retrieved 24 September 2026.