Enterprise & Compliance — Where Your Data Actually Goes

← Back to the decision map

In the decision map you met a caveat: Foundry's data-residency promise is strong for Azure-hosted models but not for Claude, which runs on Anthropic's own infrastructure. That wasn't a footnote — it's the single most important compliance distinction in the whole platform. Let's make it precise.

The reframe: two tiers of model, two sets of promises

Foundry's catalog splits into two legal/operational tiers, and every compliance guarantee below depends on which tier a model is in^1,2:

Tier	What it means	Examples
Models sold by Azure	Hosted in Microsoft's Azure environment. Governed by the Azure Data Protection Addendum. Do not interact with the provider's own services (e.g. OpenAI's API). This is where the strong promises live.	Azure OpenAI (GPT-5/4.1…), and other first-party-hosted models
Azure Direct Models	A commercial / billing integration. The model runs on the provider's infrastructure; you're subject to the provider's data-use terms, with Anthropic acting as an independent processor.	Claude (Opus/Sonnet/Haiku) via Foundry

So "is my data safe on Azure?" has no single answer. The correct question is always: "Is this specific model 'sold by Azure' or a 'direct model'?"

The strong promises (for "models sold by Azure")

For models in the first tier, here's what Microsoft contractually commits¹. These are exactly the assurances a direct API can't wrap in your cloud's governance:

Your prompts, completions, embeddings, and training data are not available to other customers, not available to OpenAI/the provider, and not used to train any foundation model without your instruction.
The models are stateless — nothing is stored in the model; prompts/completions aren't used to retrain the base models.
Stored data (fine-tuning files, Responses/Threads history) lives at rest in your Azure tenant, in your geography, encrypted with AES-256 by default — with an optional customer-managed key (CMK), and deletable any time.
Covered by the Azure DPA, GDPR (Microsoft as processor), and a HIPAA Business Associate Agreement.

Data residency: it's the deployment type, not just the region

A subtlety that trips people up: where your data is processed depends on the deployment type you choose, even though data at rest always stays in your designated geography.¹

Regional

Processing stays within your chosen geography (may move between regions inside it for capacity).

Tightest residency. Pick this when "processed in-region" is a hard requirement.

Data Zone

Processing may occur anywhere within a defined zone — e.g. an EU Data Zone processes within the EU Data Boundary.

Balance. Residency at the zone (e.g. EU-wide) level, better capacity/latency.

Global

Processing may happen in any geography where the model is deployed. Best capacity & price.

Loosest residency. Data at rest still in your geo, but processing is worldwide.

The decision-grade takeaway: a colleague saying "we're on Azure so we're EU-resident" is only right if they chose a Regional or EU Data Zone deployment. A Global deployment processes prompts anywhere the model lives.¹

The thing people miss: abuse monitoring stores your prompts

By default, to police misuse, Foundry's abuse-monitoring system may store a sample of your prompts and completions and subject them to automated and, where flagged, human review.^1,3 Microsoft fences this carefully:

The abuse-monitoring store is logically separated per customer resource and sits in your geography, within the service boundary.
Human reviewers are authorized Microsoft employees using Secure Access Workstations and Just-In-Time approval; for EEA deployments, reviewers are located in the EEA.
They can only see data already flagged by the system — not browse at will.

The lever for sensitive data — "modified abuse monitoring"

Handling highly sensitive/confidential data and can't have prompts stored for human review at all? Managed customers can apply for "modified abuse monitoring" (you must meet Limited Access eligibility and submit a form). Once approved, no data storage and no human review happen — only at-the-time automated checks remain.^1,3 You can verify it's off: in the Azure portal or CLI, the resource shows "ContentLogging": "false".¹ This is exactly the kind of concrete control a strategy doc should cite.

Identity, network, and safety — the Azure fabric advantage

Beyond data handling, this is the genuine pull of going via Azure: AI folds into the same controls your org already runs.^1,4

Microsoft Entra ID + Azure RBAC — token-based auth and fine-grained roles instead of a shared provider API key.
Private networking (VNet) — keep the endpoint off the public internet; agents can run inside your virtual network.
Guardrails / content filters with cross-prompt-injection (XPIA) mitigation, applied synchronously and not stored in the classifier.
Customer-managed keys, Trust Center certifications, and the Azure compliance offering catalog (SOC, ISO, FedRAMP, etc.).

Decision table: three ways to consume a frontier model

The same compliance question, answered three ways. Note the middle and right columns are *both* "via Foundry."
Concern	Direct API Anthropic/OpenAI	Foundry — model sold by Azure	Foundry — Claude (direct model)
Runs on	Provider infra	Microsoft Azure	Provider (Anthropic) infra
Data terms	Provider's	Azure DPA	Provider's (Anthropic, independent processor)
In-region processing	Provider-dependent	Yes (Regional/Data Zone)	Not automatic — verify; EU-native was "coming"
Identity	Provider key	Entra + RBAC or key	Entra + RBAC or Azure key
Abuse-monitoring opt-out	Provider's policy	Yes — modified abuse monitoring	Anthropic's terms (incl. zero-retention options)
One bill / governance	No (separate vendor)	Yes — your Azure estate	Yes — Azure billing & identity

Check yourself — 3 scenarios

Judgement, instant feedback.

1. A regulated client says: "We'll use Azure so all our data stays in Microsoft's cloud and under the Azure DPA — including for Claude." What's the precise correction?

The two-tier distinction is the whole game. "Sold by Azure" = Microsoft's environment + Azure DPA. "Direct model" (Claude) = provider infra + provider terms.

2. A team deployed GPT on a Global deployment type and tells auditors "our prompts are only ever processed in the EU." Are they right?

Residency of processing follows the deployment type. Data at rest stays in your geography, but Global processing can happen worldwide. The claim requires Regional or EU Data Zone.

3. A health system must ensure prompts are never stored for Microsoft human review. Using a model sold by Azure, what's the right path — and how do you prove it?

By default a sample may be stored for human review. Modified abuse monitoring (gated by Limited Access eligibility) turns off storage + human review, and ContentLogging:false is the verifiable proof.

Where to go next

Three of four axes are now covered. The last is the commercial model — PTUs vs. per-token, reservations, and the break-even logic — which is published alongside this one (0004). After that, the natural move is to apply all four to a real decision: bring me your actual scenario and we'll reason it end-to-end.