Azure AI Foundry in the EU – The Configuration That Decides
Azure AI Foundry keeps data in the EU only with the DataZone or Standard deployment types – Global is the default and leaves the EU even from EU resources. Configured correctly, Azure gives the most control of the major options: EU Data Boundary, RBAC via Entra ID, customer-managed keys, Customer Lockbox, and Defender for AI.
Among the major paths to generative AI, Azure AI Foundry is the one that offers the most control: identity, keys, access, and auditing all tie into the rest of your Microsoft environment. But that control only holds if the configuration is right – and the default points the wrong way.
Three deployment types – only two keep data in the EU
When a model is deployed in Foundry, a deployment type is chosen, and that choice decides where the calls get processed:
| Deployment type | Data stays in the EU? | Comment |
|---|---|---|
| Global | No | Default. Calls can be processed anywhere – even from EU resources |
| DataZone | Yes – within the EU data zone | Processing within the data zone's EU data centers |
| Standard | Yes – in the resource's region | Processing in the selected region |
Two things make Global a trap. It’s the default, so residency disappears unless someone actively opts out of it. And new models are often released as Global first – the pressure to “just try the new model” thereby becomes pressure to leave the EU, without anyone having made a conscious decision about it. Set policy in Azure that blocks Global deployment in environments where residency is required. Also make the deployment type a mandatory column in your internal service catalog: whoever orders a model states type, region, and justification, so the residency decision gets made at order time instead of discovered afterward.
The strengths: the most control among the major options
Configured correctly, the Foundry path is hard to beat on control:
- EU Data Boundary on the right SKU – Microsoft’s framework for keeping data flows within the EU/EFTA.
- RBAC via Entra ID – permissions in the same model as the rest of your Azure environment.
- Customer-managed keys (CMK) in Key Vault for data at rest.
- Customer Lockbox – an approval flow for when Microsoft support needs access.
- Defender for AI – threat detection for the AI workloads.
For organizations already living in Azure, this is home turf: the same identities, the same logging, the same audit tools. The strength isn’t the individual features but that they connect – the compliance work becomes an extension of what you’re already doing instead of a parallel track.
The nuances an audit will find
Two points deserve special attention. CMK protects data at rest, but not necessarily the plaintext during the inference itself – when the model processes a call, the content sits unencrypted in the compute environment. Write that in as a residual risk instead of letting “customer keys” sound like total protection.
And a classic miss: API key authentication bypasses the RBAC model. As long as key auth is on, whoever holds the key can call the resource regardless of role governance. Turn off key authentication and run Entra identities – otherwise the permission model is a paper exercise. While you’re at it, go through the diagnostic settings: which logs get sent where, and whether content data can end up in flows that leave the region.
The regional reality: Sweden Central first
For advanced models, Sweden Central is the broadest EU region, with France Central second. But availability and capacity fluctuate, and that’s where the next trap lies.
A scenario: a team runs Standard deployment in an EU region. A capacity spike means the quota isn’t enough, the deadline is approaching, and someone “temporarily” switches to Global to move forward. Residency quietly slips away, and no one documents the deviation. The countermeasure is to build failover to a second EU region from the start – then there’s an approved fallback when capacity runs short, instead of a shortcut that breaks the DPIA. The fallback also needs to be exercised, not just exist in a document – a failover that’s never been tested is, in practice, no failover at all.
Verify the region matrix before every decision
Model availability by region and deployment type changes often. Make the region availability documentation a mandatory checkpoint before every deployment and every model upgrade, and save a dated copy in the decision record. What applied at the last release isn’t guaranteed to apply at the next. The same discipline applies to quotas: request capacity well in advance in your chosen region, so a capacity shortage never becomes the argument that breaks residency.
Building AI features on Azure and want help getting the governance and architecture right from the start? At Weapp we work on AI solutions and cloud architecture in exactly these environments – get in touch for a conversation about your setup.
Frequently asked questions
Why is Global deployment the default if it leaves the EU?
Global gives Microsoft the most freedom to allocate capacity and is therefore both the cheapest and first to get new models. That's good for availability but wrong for residency – calls can be processed anywhere, even when the resource sits in an EU region. Residency requires an active choice of DataZone or Standard.
Is EU Data Boundary sufficient as GDPR proof?
No. EU Data Boundary is Microsoft's framework for keeping certain data flows within the EU/EFTA, but it only applies on the right SKU and doesn't remove US jurisdiction via the CLOUD Act. Use it as one building block in your documentation, not as the whole answer.
Do customer-managed keys protect all our data?
They protect data at rest – stored data the provider can't read without your key. During the inference itself, data is processed in plaintext in the compute environment, so the keys don't eliminate all exposure. Document that as a residual risk in the DPIA.
Which EU region should we choose for Azure AI Foundry?
Sweden Central has the broadest range of advanced models among the EU regions, with France Central second. Choose based on model needs and latency – but build failover to a second EU region from the start, since capacity and availability fluctuate.
What is Customer Lockbox?
An approval flow that gives you the final say when Microsoft support needs access to your environment for troubleshooting. Every access request must be explicitly approved by you, is logged, and can be denied – a piece of the puzzle for governance and traceability in regulated environments.