Claude Is GA on Azure Foundry — but Not for EU Data Residency

Sophie Laurent Legal & Compliance Lead, YuSMP Group · Advises US and EU teams on GDPR, the EU AI Act and cross-border data flows

The short answer

What reached general availability?

Anthropic and Microsoft moved Claude models to general availability in Microsoft Foundry in early July 2026, giving Azure customers Opus 4.8, Haiku 4.5 and Sonnet 5 through the same authentication, billing and governance they already use for the rest of the platform. Sonnet 5 arrived at promotional pricing of $2 per million input tokens and $10 per million output through 31 August 2026. On paper, it is exactly what an Azure-standardised enterprise wants: a frontier model family available inside its existing controls, procurement and identity stack.

The nuance sits one layer down, in how the models are actually hosted. Microsoft Foundry offers two options for Claude — "Hosted on Azure" and "Hosted on Anthropic Infrastructure" — and Microsoft's documentation is explicit that for both, "Anthropic… acts as an independent data processor for prompts and outputs." Anthropic is a US company, which means the code and prompts your team sends to Claude through Foundry are handled by a US processor reachable under the US CLOUD Act, regardless of the Azure region shown on your subscription.

That distinction is easy to miss when the console says "hosted on Azure," and it is the whole story for anyone with an EU data-residency requirement.

Why is there no EU data residency?

Microsoft's Foundry documentation states that even under the "Hosted on Azure" option, "processing is scoped to applicable ‘Global’ or ‘DataZone’ deployment options available on Microsoft Foundry" — and, as reported by InfoQ, there is no European data zone for Claude models today. In practice that means a Claude request from an EU endpoint can be routed to US infrastructure for inference. Anthropic's own regional-compliance material lists a European Foundry option as "coming 2026" without committing to a date.

The reason is architectural, not a policy oversight. Claude on Foundry is a third-party Marketplace offering: Anthropic operates the inference and remains the data processor, rather than Microsoft running the model first-party inside an Azure EU region. So the residency guarantees an EU customer expects from a first-party Azure service — data at rest and in process staying inside a chosen European geography — are not yet available for Claude on this platform. For a workload governed by GDPR or subject to sectoral rules in HealthTech, that gap is the difference between "approved for production" and "blocked at review."

Practitioners are already treating it that way. In enterprise discussions surfaced by InfoQ, a Dutch financial-services engineer reported that their bank "does not allow the use of Anthropic models through Foundry," and several users noted that access still requires form-based approval rather than self-service deployment — a capacity and governance signal on top of the residency question.

How Foundry compares to Bedrock and Vertex AI

The important context is that this is a platform gap, not a Claude gap. The same models can meet EU residency needs elsewhere, because the hosting architecture differs. Here is the shape of it — confirm current terms with each provider before you commit, since regional availability changes.

On AWS Bedrock and Google Vertex AI, Claude inference can run inside the cloud provider's own EU-region infrastructure, so the residency and processing guarantees EU customers rely on are available in the usual way. On Foundry, with Anthropic as the processor and no EU data zone yet, they are not. By contrast, OpenAI's models on Azure offer EU data zones and first-party Microsoft operation, which is why they clear European approval more easily today. The lesson is not "avoid Claude" — it is that, for an EU workload, the platform decides residency as much as the model does.

What it means for US & EU software teams

Strip away the launch framing and three practical signals remain. First, "hosted on Azure" is not a residency guarantee — the deployment option and the identity of the data processor are what matter, so read the platform's data-processing documentation before you assume a model call stays in-region. Second, the same model can be compliant on one platform and blocked on another, which means your architecture should let you choose the platform per workload: route EU-regulated traffic to a provider with EU-region inference, and keep everything behind one internal interface so the choice is configuration, not a rewrite.

Third, treat this as a standing governance item, not a one-off. Availability is moving — a European Foundry option is expected later in 2026 — so record which region and processor each model dependency actually uses, and revisit it on a cadence. For teams under EU AI Act obligations or serving regulated FinTech customers, "the vendor says it's on Azure" is not an answer an auditor accepts; the documented deployment region and the data-processing agreement are. Building that discipline in is exactly the kind of guardrail work our AI agents team puts around model access.

None of this is a verdict on Claude, which remains a strong choice for many workloads and is already usable with EU residency on other platforms. The discipline is the familiar one: match the tool to the constraint, keep the freedom to switch platforms cheaply, and make sure the place your data is actually processed is one you can defend in every market you serve.

A practical procurement checklist

Nothing here is a new deadline. It is the work that turns a fast-moving model-platform market into a routine review rather than a surprise:

1. Read the data-processing docs, not the console label. Confirm the named data processor and the deployment option ("Global," "DataZone," EU region) for every model you use.
2. Map each model to a region. Record where inference actually happens for each dependency; never assume "on Azure" means "in the EU."
3. Route EU-regulated traffic to EU-region inference. Where residency is required, use a platform that offers it (Bedrock or Vertex AI) until Foundry ships an EU zone.
4. Add an abstraction layer. Send every model call through one internal interface so provider, platform and region are configuration, not code.
5. Get residency in writing. Confirm deployment region and processing terms in the data-processing agreement before production, not after.
6. Re-check on a cadence. Availability and terms change; schedule a review so a "coming 2026" option is picked up when it actually lands.

This is not legal or procurement advice, and the right platform mix depends on your workloads, your data classification and your markets. But the signal from Claude's Foundry GA is clear: capability is arriving everywhere fast, while the part that actually gates an EU deployment — where the data is processed — is the part that never shows up in a launch headline.

Frequently asked questions

Sources

InfoQ — Claude Reaches GA on Microsoft Foundry: European Enterprises Cannot Deploy It (5 July 2026)
Microsoft Learn — Data, privacy, and security for Anthropic Claude models in Microsoft Foundry
Microsoft Azure Blog — Claude in Microsoft Foundry is now generally available