If you’re building AI applications on Microsoft Foundry from Europe, there’s a question you need to answer before writing a single line of code: where is your data actually processed when you call a model? I’ve spent the past few months working through this with customers, and the answer isn’t as straightforward as the marketing material suggests.

Getting this wrong has real consequences for GDPR compliance, EU AI Act alignment, and your organization’s risk posture. This post covers how deployment types work in Foundry, why they matter from a European perspective, and how to pick the right one based on what your workload actually handles.

Deployment Types Define the Boundary

Microsoft Foundry (formerly Azure AI Foundry) gives you access to over 11,000 models from Microsoft and third-party providers. When you deploy a model, you pick a deployment type. This single choice determines where your inferencing data (prompts and completions) is processed, how you’re billed, and what performance you get. It’s the most important governance decision in the deployment process, and in my experience, it’s often left at the default.

Three standard deployment types matter most for European data governance:

• Global Standard – Inferencing data can be processed in any Azure region worldwide. You get the highest quota and broadest model availability, but no geographic restriction on where prompts and responses go.
• Data Zone Standard – Inferencing stays within the designated data zone. For EU customers deploying in a European region, that means processing is restricted to EU member nations.
• Standard (Regional) – Inferencing is processed in the single Azure region where the model is deployed. Strictest boundary, suitable when national data residency is required.

For all deployment types, data at rest stays in the designated Azure geography. The deployment type only controls where inferencing happens. Foundry also offers provisioned variants for reserved throughput and batch variants for large-scale async processing at reduced cost.

Not All Data Needs the Same Boundary

A common mistake is to slap the strictest deployment type on everything. It sounds safe, but it reduces your available quota, limits model availability, and drives up cost without adding compliance value. I’ve seen organizations restrict everything to a single region “just in case,” then wonder why their developers can’t access the models they need.

GDPR applies when personal data is processed. If your workload handles only non-personal data, GDPR residency requirements don’t apply. Business-sensitive data may still need boundary enforcement, but that’s a policy decision, not a regulatory one. Know your data, then pick your boundary.

Model Endpoints Are Not Uniform

Not all models in Foundry use the same API endpoint.

OpenAI models use the legacy Azure OpenAI path (/openai/deployments/<name>/chat/completions)

Anthropic models get a vendor-specific route (/anthropic/v1/messages)

Everything else (Llama, Mistral, Phi, DeepSeek) uses the unified endpoint (/models/chat/completions).

If you’re planning for model portability or substitution, expect code changes when switching between families.

Anthropic is the odd duck here, and not just because of the endpoint. While OpenAI and other models run on Microsoft-managed Azure infrastructure, Claude runs on Anthropic’s own infrastructure. Foundry handles authentication via Entra ID and billing through your Azure subscription, but the actual inferencing happens outside Azure. The consequence: Anthropic models are excluded from the EU Data Boundary, regardless of which deployment type you select. Anthropic operates as a Microsoft subprocessor under the DPA, so enterprise data protection applies, but the data residency guarantees you get with Azure-hosted models don’t. If your workload touches personal data under GDPR, don’t default to Claude without a deliberate governance decision. The same applies to Microsoft 365 Copilot: enabling Claude for Copilot Cowork or Agent Mode moves inferencing outside the EU Data Boundary, and it defaults to off for EU/EFTA tenants for exactly this reason.

Three Use Cases: Matching Deployment to Data

How does this play out in practice? Here are three scenarios I keep running into.

Use Case 1: Internal Knowledge Assistant (Non-Sensitive Data)

A team builds an assistant that answers questions about publicly available product docs and internal process guides. No personal data, no contractual restrictions.

Suggested deployment: Global Standard. No residency constraints apply, so you get the best quota and widest model selection.

Use Case 2: Financial Reporting Agent (Business-Sensitive, Non-PII)

An agentic system extracts data from internal financial reports, runs variance analysis, and generates quarterly summaries. Commercially sensitive, but no personal data.

Suggested deployment: Data Zone Standard (EU). GDPR doesn’t apply, but organizational policy may require European processing. The EU data zone gives you a compliant boundary without single-region quota limitations.

Use Case 3: HR Support Agent (PII and Sensitive Personal Data)

An AI agent integrated with HR answers employee questions about benefits, leave balances, and salary. Names, employee IDs, compensation, and in some cases health-related leave information. This is personal data under GDPR.

Suggested deployment: Standard (Regional) or Data Zone Standard (EU), depending on whether national residency requirements apply. Complete a DPIA before deployment, and document the model selection decision with risk classification, boundary justification, and risk owner approval.

The EU AI Act Adds Another Layer

Data residency isn’t the only regulatory consideration. The EU AI Act introduces risk-based classification that applies regardless of where data is processed. That HR agent from Use Case 3? If it influences employment decisions, it could land in the high-risk category, triggering requirements for documentation, human oversight, and transparency. The most capable model isn’t always the right choice; the most governable one often is.

Takeaways

• Deployment type is a governance decision. Pick it based on data classification, not defaults.
• GDPR applies to personal data, not all data. Don’t over-constrain workloads that don’t need it.
• Anthropic is the exception. Claude runs outside Azure and outside the EU Data Boundary. Factor that in.
• The EU AI Act goes beyond residency. Risk classification and oversight requirements should inform model selection.
• Enforce with Azure Policy. Governance by design beats governance by instruction.

Model selection in Foundry isn’t just a technical decision. It’s a governance decision with regulatory, financial, and operational implications. Treat it as one.

---

Reidar J. Boldevin is a Principal Engineer at Fortytwo, specializing in Microsoft Identity and Security services. The views expressed here are his own.

Image source: Microsoft Learn, “Understanding deployment types in Microsoft Foundry Models”, accessed March 2026.