Azure Policy to Block Global LLM Deployments and Keep Data in Europe

If your organization operates in Europe, using Azure AI is not only a technical decision. It is also a data residency decision.

This matters a lot when teams start deploying models in Azure AI Foundry or Azure OpenAI and simply pick the default or most convenient option. In many cases, that ends up being a Global deployment type. From an operational perspective that sounds great. From a compliance perspective, it can be exactly the wrong choice.

Microsoft documents that Global deployment types can process prompts and responses in any Azure region where the model is deployed. If your requirement is to keep data processing in Europe, that is not acceptable. The better option is to use Data Zone deployments in the EU, or if you need even stricter control, use a regional deployment type.

In this post I show a simple Azure Policy that blocks Global model deployments, forcing teams toward EU-aligned options.

Why Global deployments are a problem

Microsoft Foundry deployment types are not only about pricing and quota. They also define where inferencing traffic can be processed.

• Global Standard and Global Provisioned use Azure’s global infrastructure.
• Microsoft states that prompts and responses for Global deployment types might be processed in any geography where the model is deployed.
• Data Zone deployment types keep prompts and responses inside the selected data zone, such as the European Union.
• Standard and Regional Provisioned keep processing in the selected Azure region.

That distinction is the key point.

Even if data at rest is tied to your selected geography, inferencing traffic for Global deployments can still leave Europe. If your internal policy says sensitive prompts, completions, or business context must stay in Europe, allowing Global deployment types creates unnecessary risk.

If your goal is EU-wide data residency, use Data Zone EU. If your goal is a single Azure region only, use Standard or Regional Provisioned instead.

What Microsoft says about data residency

Microsoft’s documentation is fairly direct here:

• In Azure data residency guidance, Microsoft states that Azure OpenAI in Foundry Models stores customer data at rest in the selected geography, but Global deployments may process prompts and completions in any Azure OpenAI region globally.
• The same guidance states that Data Zone deployments process prompts and completions within the selected data zone.
• In the deployment type documentation, Microsoft explicitly recommends Data Zone Standard or Data Zone Provisioned for EU data zone requirements.

For Europe-based organizations, this gives a clean design rule:

• Do not allow Global* deployment types for production or sensitive workloads.
• Prefer DataZoneStandard, DataZoneProvisionedManaged, or DataZoneBatch when EU-wide processing is acceptable.
• Prefer Standard or ProvisionedManaged when the requirement is stricter and processing must stay in one Azure region.

Does data leave Europe with non-Global deployments?

This is where the wording in the documentation matters.

The short answer is: not in the same way.

• Global deployments may process prompts and completions anywhere globally.
• DataZone deployments keep prompts and completions inside the selected data zone, so with EU Data Zone the processing stays within the European Union.
• Standard and ProvisionedManaged deployments are the strictest option because processing stays in the selected Azure region.

However, DataZone should not be confused with single-region processing.

If you choose EU Data Zone, Microsoft can process the inference traffic within the EU data zone, not necessarily in only one specific Azure region. For many organizations that is acceptable, because the data stays in Europe. For stricter requirements, regional deployments are the better choice.

There are also important exceptions for advanced scenarios:

• When using Custom Topics, training data may be transmitted to other geos within the same Data Zone.
• When using fine-tuned models with Global or DataZone deployment types, training data, validation data, and custom model weights may be stored temporarily outside the selected Geo.

That means blocking Global deployments is a strong first step, but it does not automatically make every AI scenario residency-safe. If the requirement is strictly “keep processing in Europe,” EU Data Zone is usually the right compromise. If the requirement is “keep processing in one specific region,” use regional deployment types and review fine-tuning features separately.

The Azure Policy

The following custom Azure Policy blocks deployment creation for Azure AI model deployments when the SKU is Global-based or the location is set to global.

{
  "displayName": "Block Global OpenAI Models",
  "policyType": "Custom",
  "mode": "All",
  "description": "This policy prevents the deployment of Global Standard and Global Provisioned models.",
  "parameters": {
    "effect": {
      "type": "String",
      "metadata": {
        "displayName": "Effect",
        "description": "Deny (block) or Audit (log only)"
      },
      "allowedValues": [
        "Deny",
        "Audit",
        "Disabled"
      ],
      "defaultValue": "Deny"
    }
  },
  "policyRule": {
    "if": {
      "allOf": [
        {
          "field": "type",
          "equals": "Microsoft.CognitiveServices/accounts/deployments"
        },
        {
          "anyOf": [
            {
              "field": "Microsoft.CognitiveServices/accounts/deployments/sku.name",
              "contains": "Global"
            },
            {
              "field": "location",
              "equals": "global"
            }
          ]
        }
      ]
    },
    "then": {
      "effect": "[parameters('effect')]"
    }
  }
}

How the policy works

The logic is intentionally simple.

• It targets Microsoft.CognitiveServices/accounts/deployments resources.
• It checks whether the deployment SKU name contains Global.
• It also checks whether the resource location is global.
• If either condition matches, the configured effect is applied.

With Deny, the deployment is blocked immediately.

With Audit, the deployment is still allowed, but it will appear as non-compliant. That is useful if you want to measure impact before enforcement.

Important detail: this blocks more than two SKUs

The display name and description mention Global Standard and Global Provisioned, but the actual rule is broader than that.

Because it matches any SKU containing Global, it can also catch other Global deployment types, such as GlobalBatch, if they are exposed through the same resource type and SKU naming.

That is usually the right design for a Europe-first environment, but it is worth documenting clearly so nobody is surprised later.

If you only want to block specific SKUs, replace contains: Global with explicit equals checks for the exact SKU names you want to deny.

Recommended rollout

My recommendation is to roll this out in two phases.

Phase 1: Audit

Assign the policy with the Audit effect first.

This gives you answers to the questions that actually matter:

• Which subscriptions are still using Global deployments?
• Which teams are relying on Global quota or availability?
• Which applications need to be redesigned to use EU Data Zone or regional deployments?

Phase 2: Deny

After the impact is understood, switch the assignment to Deny.

At that point, new Global deployments are blocked by platform control instead of relying on documentation, manual review, or good intentions.

What developers should use instead

If you block Global deployment types, developers still need a clear alternative.

Use this rule of thumb:

• Need data processing to remain within the European Union: use DataZoneStandard, DataZoneProvisionedManaged, or DataZoneBatch in an EU-supported region.
• Need the strongest regional boundary: use Standard or ProvisionedManaged in a specific Azure region.
• Need the highest quota and do not have residency restrictions: that is the only scenario where Global types make sense.

This keeps the platform team in control while still giving application teams a supported path forward.

Final thoughts

Security and compliance controls work best when they are boring, predictable, and enforced automatically.

If Europe-only processing is important for your organization, this should not depend on whether someone remembers to avoid GlobalStandard in the portal. Azure Policy is exactly the right place to enforce that decision.

Block the unsafe deployment types, point teams to EU Data Zone or regional deployments, and make the compliant path the default path.

References

• Deployment types for Microsoft Foundry Models
• Data residency in Azure