AI Data Residency by Provider 2026: Where OpenAI, Azure OpenAI, AWS Bedrock, Google Vertex AI, Anthropic, Cohere, Mistral, and Together AI Actually Run Your Inference

Procurement teams routinely conflate three things under the same phrase. **Billing residency** — your invoice comes from an EU entity, your contract is governed by Irish or Dutch law. This is the cheapest version to provide and the least meaningful to a regulator. **Storage residency** — customer metadata, account config, audit logs, and any cached prompts sit on disks physically located in a specified region. **Inference residency** — the GPU that runs the forward pass on your prompt sits in the specified region. Only the third matters for GDPR Article 44 transfer analysis, German BfDI guidance on US cloud providers, and FedRAMP boundary definitions.

**OpenAI direct** publishes its enterprise privacy commitments at https://openai.com/enterprise-privacy/ and now distinguishes between US default routing and the EU data residency option for ChatGPT Enterprise, ChatGPT Edu, and the API. Inference for the EU residency tier runs on EU-located infrastructure; without that opt-in, prompts and completions are processed in US data centers. The default is US, and most teams that signed standard OpenAI contracts before mid-2024 are still on US default routing whether they realize it or not.

**Azure OpenAI** does residency the simplest way: the resource you create is region-locked. A resource created in `swedencentral` runs inference in Sweden, stores associated metadata in Sweden, and returns errors if you accidentally call a global endpoint. Per https://learn.microsoft.com/en-us/azure/ai-services/openai/concepts/models the per-region model availability matrix tells you which exact GPT, o-series, embedding, and image model you can call from each region — a moving target month-to-month.

**AWS Bedrock** also region-locks by endpoint — `bedrock.eu-central-1.amazonaws.com` runs inference in Frankfurt — but adds a twist with cross-region inference profiles introduced in 2024, where Bedrock can route requests across multiple regions for capacity. You have to explicitly disable cross-region routing if you need hard residency. Documentation at https://aws.amazon.com/bedrock/ and the AWS regional services list spell out which Claude, Llama, Mistral, and Titan models are GA in which Bedrock region.

**Google Vertex AI** offers three modes documented at https://cloud.google.com/vertex-ai/generative-ai/docs/learn/locations: region-locked endpoints (one specific region), multi-region endpoints (which stay within a continent — the `eu` multi-region stays in EU member states), and the global endpoint (which can route to any Google region including the US). For EU procurement, the `eu` multi-region is usually the right answer — it gets you capacity flexibility without crossing the Atlantic.

**Anthropic direct** documents its supported regions at https://docs.anthropic.com/en/docs/about-claude/regions and supports both US and EU inference for direct API customers. Workspaces are configured to a region at creation time and zero data retention is the default for direct API customers per https://www.anthropic.com/legal/commercial-terms. The practical upshot: Anthropic direct is now a credible EU vendor where it was US-only as recently as 2023.

Every vendor on this list uses TLS 1.2 or higher in transit and AES-256 at rest. That story is well-told. The story most enterprise buyers do not pressure-test is **in-use** encryption — what happens to your prompt while it is loaded into GPU memory during inference. By default, the prompt is plaintext in memory on the GPU. Anyone with administrative access to the hypervisor or host OS could, in principle, read it. For most workloads this is acceptable. For regulated health, finance, and government workloads it is increasingly not.

The remediation is **confidential computing** — running inference inside a hardware-attested Trusted Execution Environment (TEE) where memory is encrypted and the host operator cannot peek. As of June 2026, native confidential-compute inference is partial across the providers. **Azure** offers Azure Confidential Computing on AMD SEV-SNP and Intel TDX VMs, but Azure OpenAI inference itself does not yet GA on confidential VMs — verify status at https://learn.microsoft.com/en-us/azure/confidential-computing/. **AWS** Nitro Enclaves are mature but Bedrock native TEE inference is still limited; AWS Nitro System guarantees provide a different model of operator-isolation that some buyers accept in lieu of full TEE attestation.

**Google Vertex AI** has confidential VMs for training widely available and confidential inference in preview for select models per https://cloud.google.com/confidential-computing. The trajectory across all three hyperscalers is the same — confidential GPU inference is shipping incrementally on H100 confidential mode and Blackwell confidential mode hardware, but you cannot assume it for any specific model in any specific region today. Ask the vendor in writing.

**OpenAI direct** and **Anthropic direct** do not offer customer-controlled confidential-compute options on their public APIs as of June 2026. They run their own infrastructure and you trust their operator-isolation. For some buyers that is fine — the OpenAI SOC 2 Type II and Anthropic SOC 2 Type II reports cover those operator controls. For other buyers (financial services with prompt-injection-as-data-exfiltration threat models, defense contractors) it is not fine, and the answer is to use Azure OpenAI, AWS Bedrock, or Vertex with vendor-side confidential compute as it rolls out.

**Mistral** is the cleanest answer on confidential compute today — on-prem and dedicated deployments give you full physical control of the host hardware, and Mistral partnered with Bleu (the Capgemini + Orange joint venture) for SecNumCloud-aligned hosting in France. Per https://mistral.ai/security, the enterprise tier supports both customer-managed keys and customer-controlled deployment topology. This is the path for FR / EU sovereign workloads where the GDPR Article 44 transfer analysis cannot tolerate any US-headquartered processor.

Whatever your in-use story is, write it into the data processing agreement (DPA), not just the security one-pager. Encryption-in-transit, encryption-at-rest, KMS configuration, and confidential-compute commitments belong as contract obligations, not as marketing claims that change at the next platform release.

A common procurement mistake is asking "where is the model trained" when the question that matters is "where will my prompts and outputs be processed." Foundation models from OpenAI, Anthropic, Google, Meta, Mistral, and Cohere were trained on infrastructure the customer does not control and that has nothing to do with the residency of the customer's runtime data. Once a model exists as weights, it can be served from anywhere a GPU lives. Training residency does not constrain inference residency.

The relevant residency question for inference is therefore: which physical region runs the forward pass on my prompt, and is any version of my prompt or completion persisted anywhere outside that region. **Azure OpenAI** answers this cleanly per https://learn.microsoft.com/en-us/azure/ai-services/openai/concepts/data-privacy — for the abuse-monitoring opt-out tier, no prompt or completion data leaves your resource's region and none is persisted beyond the immediate inference call. **AWS Bedrock** answers similarly per https://aws.amazon.com/bedrock/ — prompts are not stored, completions are not stored, and model invocation logs only fire if the customer explicitly enables them.

**Google Vertex AI** documents its generative AI data governance at https://cloud.google.com/vertex-ai/generative-ai/docs/data-governance — prompts to Vertex Gemini and partner-model endpoints are not used to train models and are not persisted beyond the inference call when the customer has not opted into prompt caching or logging. The region commitment ties to the endpoint's region or multi-region.

**OpenAI direct** answers this in https://openai.com/enterprise-privacy/ — API inputs and outputs are not used to train models, and ZDR (zero data retention) is available for eligible customers. **Anthropic direct** answers it in https://www.anthropic.com/legal/commercial-terms — customer inputs and outputs are not used to train models and are not retained beyond the inference call on the direct API. **Cohere** answers it at https://cohere.com/security with similar commitments — and Cohere explicitly markets its data isolation as a differentiator, including the option to deploy in a customer's own cloud account through the Cohere Private Deployments program.

The thing none of the vendors will give you in writing is a guarantee that training data was geographically segregated by the user's jurisdiction. The training corpus is global. If your compliance framework requires that no training data ever originated outside a specific region, no commercial foundation model on this list satisfies that requirement and you should be looking at customer-trained or jurisdiction-trained open-weights models — Mistral, Llama, or a sovereign-cloud-hosted equivalent. **Mistral**'s European positioning makes this the cleanest fit for sovereign training-data requirements, though even Mistral does not publish a per-token geographic-origin manifest.

Practical advice: write the inference-residency commitment into the contract and write the training-data commitment as a separate clause. They are different facts and they need different language. Procurement teams that bundle them together end up with weaker contracts than teams that separate them.

Sovereign cloud sits above ordinary region-locked commercial cloud. It adds operator nationality controls, separate authentication boundaries, and (in the US fed case) FedRAMP High and DoD IL4/IL5 accreditations. The catch with sovereign cloud and AI models is that model availability lags commercial regions by 6 to 18 months. The shiny new model you want is rarely available in the sovereign region you need.

**Azure Government** runs in dedicated US-fed regions with Azure OpenAI availability at https://learn.microsoft.com/en-us/azure/azure-government/documentation-government-cognitiveservices. As of June 2026, Azure Government has GPT-4-class models GA and newer GPT-5 models rolling in, lagging commercial Azure by a quarter or two. **Azure China** is operated by 21Vianet under separate Chinese data-protection law. **Microsoft Cloud for Sovereignty** layers sovereignty controls on standard Azure regions for EU public sector — verify OpenAI inclusion at https://www.microsoft.com/en-us/industry/sovereignty/cloud.

**AWS GovCloud (US)** runs Bedrock with a limited model subset per https://aws.amazon.com/govcloud-us/ — specific Claude, Llama, and Titan models, but not everything GA in commercial Bedrock. **AWS European Sovereign Cloud** is the dedicated EU sovereign instance with first region in Brandenburg, Germany, operated by AWS European personnel and EU-headquartered legal entities. Confirm Bedrock service inclusion and timeline at https://aws.amazon.com/blogs/security/.

**Google Sovereign Cloud** is structured as partner-operated cloud — T-Systems in Germany, Thales in France (S3NS), and PSN in Italy. These partners run Google Cloud services on EU-located infrastructure under EU operator control. Vertex AI availability varies by partner and by service — confirm at https://cloud.google.com/sovereign-cloud-and-trust-portal and ask the partner directly which Gemini and partner-model endpoints are live in the sovereign offering.

**Mistral** is in some sense the native sovereign answer for EU buyers — the company is French, the infrastructure is French, and the Bleu partnership with Capgemini and Orange targets SecNumCloud-aligned hosting. SecNumCloud is the French ANSSI certification that goes beyond standard ISO 27001 for sensitive public sector data. For French public sector and regulated industry, Mistral on Bleu is the cleanest single-vendor sovereign story available today.

What sovereign cloud cannot give you: the latest frontier model the moment it ships. If your buyer profile is "latest GPT-5 capabilities, EU sovereign, today," that combination does not exist as a single product in June 2026. Pick two of three: latest capability, EU sovereign, immediate availability. Most regulated buyers settle for a one-quarter-lag model in the sovereign region; some run a hybrid where exploratory work happens on commercial cloud and production on sovereign.

**Buyer profile one: EU-only SaaS startup with GDPR-conscious customers.** You want the simplest "customer data never leaves the EU" story. The cleanest answer is Azure OpenAI with a resource in `swedencentral` or `francecentral` plus abuse-monitoring opt-out. Per https://learn.microsoft.com/en-us/azure/ai-services/openai/concepts/data-privacy this gives region-locked inference, no prompt persistence, and the same GPT-5 family models. Second choice: Anthropic direct with EU routing, which gives Claude in the EU with ZDR by default per https://docs.anthropic.com/en/docs/about-claude/regions.

**Buyer profile two: US federal contractor or US healthcare with strict FedRAMP / HIPAA boundaries.** You want a sovereign-cloud answer with an audited compliance boundary. The default is Azure OpenAI in Azure Government for FedRAMP High and DoD IL4/IL5 workloads, or AWS Bedrock in AWS GovCloud (US) if you are already AWS-shop. For HIPAA-only workloads, commercial Azure OpenAI, commercial AWS Bedrock, and Google Vertex AI all sign HIPAA business associate agreements — verify the exact BAA language with vendor counsel.

**Buyer profile three: Japanese financial services or Japanese government.** You want Tokyo or Osaka inference under Japanese FSA expectations. Azure OpenAI in Japan East (Tokyo) or Japan West (Osaka) is the broadest model menu. AWS Bedrock in `ap-northeast-1` has a smaller model set but covers Claude and Llama. Google Vertex in `asia-northeast1` or `asia-northeast2` covers Gemini natively. OpenAI direct and Anthropic direct do not offer JP residency as a primary commitment as of June 2026 — you go through one of the three hyperscalers.

**Buyer profile four: Australian healthcare, financial services, or government.** You want Sydney or Melbourne inference under APRA CPS 234 and Australian Privacy Principles. Azure OpenAI in Australia East is the broadest. AWS Bedrock in `ap-southeast-2` and Google Vertex in `australia-southeast1` or `australia-southeast2` are the alternates. Same caveat as Japan — neither OpenAI direct nor Anthropic direct lists AU as a primary residency commitment, so you go through a hyperscaler.

**Cross-cutting note:** the vendor capability to weight more than any other is the per-region model availability matrix — it changes monthly. A region that does not have the specific GPT-5, Claude Sonnet 4.7, or Gemini 2.5 model you need is functionally useless even if residency is perfect. Bookmark the matrices at https://learn.microsoft.com/en-us/azure/ai-services/openai/concepts/models, https://aws.amazon.com/bedrock/, and https://cloud.google.com/vertex-ai/generative-ai/docs/learn/locations and check before every model decision.

**Cohere** deserves a separate mention for the buyer who wants EU plus Japan natively from the model vendor rather than from a hyperscaler. Per https://cohere.com/security, Cohere offers US, EU (Frankfurt), and Japan deployments directly. If you are standardizing on Cohere Command and Embed for RAG plus retrieval, the multi-region native story is competitive with the hyperscaler-mediated alternatives and you avoid one layer of vendor relationship.

The most useful single document in any AI vendor procurement is the data processing agreement (DPA). Get the latest version, get it reviewed by counsel, and verify three clauses. First: the precise list of regions where customer data — prompts, completions, embeddings, fine-tuning data, and metadata — may be processed and stored. Vague phrases like "OpenAI may process data in OpenAI's data centers" are not acceptable. Specify regions.

Second: the sub-processor list, with countries and the right to object to new sub-processors with reasonable notice. Every cloud-mediated AI service has a long sub-processor chain — the model vendor, the hyperscaler, any third-party safety filter, any logging or observability vendor. Audit the chain. Per https://openai.com/policies/subprocessor-list, https://www.anthropic.com/legal/subprocessors, https://aws.amazon.com/compliance/sub-processors/, https://www.microsoft.com/en-us/trust-center/privacy/data-processing-agreements, and https://cloud.google.com/terms/subprocessors, each vendor publishes a current list — those lists are the starting point, not the final word.

Third: the data residency commitment as a contractual obligation, not a marketing claim. Specifically, "Provider shall not process Customer Data outside of [region]" with named regions and a breach-notification clause. Vendors will push back on absolute language; settle on language that is specific enough to be enforceable. For Azure OpenAI, AWS Bedrock, and Google Vertex AI, the region-locked architecture makes this language easier to negotiate; for OpenAI direct and Anthropic direct, it requires explicit opt-in to a residency tier.

Ask for the latest **SOC 2 Type II** report (Type I is not enough — verify at vendor's trust center), the **ISO 27001** certificate with current validity date, the **ISO 27018** certificate where you handle EU personal data, **HIPAA BAA** if applicable, and **PCI DSS** attestation if you transmit cardholder data through prompts. For EU public sector, ask about **ENS** (Spain), **C5** (Germany), and **SecNumCloud** (France) where relevant. The vendor trust centers — https://trust.openai.com, https://trust.anthropic.com, https://aws.amazon.com/compliance/, https://servicetrust.microsoft.com, https://cloud.google.com/security/compliance/ — index the current set.

Verify **ZDR status** explicitly. Zero data retention is a contractual posture, not a checkbox. For OpenAI direct, ZDR requires customer eligibility approval and opt-in per https://openai.com/enterprise-privacy/. For Azure OpenAI, the analog is abuse-monitoring opt-out via a Microsoft form. For AWS Bedrock and Google Vertex AI, no-retention is closer to the default but customer-enabled logging will defeat it. For Anthropic direct, ZDR is the default for the API.

Finally, get the **incident notification** clause right. The DPA should commit the vendor to notify you within 72 hours of any confirmed data breach affecting your data — aligned with GDPR Article 33 timelines. Verify the notification channel (email to a security@ address you control, in-product banner, etc.) and the escalation contacts. The 72-hour clock is regulatory and you cannot meet it if the vendor does not meet a shorter clock.

For the strictest residency requirements — air-gapped government, classified workloads, certain financial-services data that contractually cannot transit any third-party cloud — the only credible answer is self-hosted open-weights models. Llama 3 and 4, Mistral Large 2 and the open Mixtral family, Qwen, and DeepSeek can be deployed entirely inside the customer's network on customer-owned GPUs. Download the model once; no prompt ever leaves the customer's data center.

Realistic cost of self-hosting in 2026: an 8x H100 or 8x H200 node lists at roughly $250,000 to $400,000 in capex per https://www.nvidia.com/en-us/data-center/h100/ and partner pricing, plus power, cooling, networking, and 24x7 ops headcount. For models above 70B parameters you typically need at least two nodes. Per-token economics only beat hyperscaler API pricing at 30 to 50 percent sustained GPU utilization across the year. Most teams that benchmark honestly find Bedrock or Vertex cheaper for their actual usage.

Where self-hosted open weights wins decisively: environments where the contract simply prohibits any third-party processing, regardless of region. Examples include EU national security agencies, US DoD classified workloads above IL5, and Swiss private banking. The choice is "self-host or do not use LLMs at all."

The hybrid pattern that increasingly works in 2026: use hyperscaler Bedrock or Azure OpenAI for the broad bulk of LLM workloads where the residency story is good-enough, and reserve self-hosted Mistral or Llama for the narrow set of workloads where regulation prohibits any vendor processing. This gets you the capability breadth of frontier models for 95 percent of workloads and the residency airtightness of self-hosted for the 5 percent that actually requires it. Use the RAG cost per query calculator and the vector DB cost per 1M embeddings calculator to model the per-workload economics honestly before you decide which side of the line each use case lands on.

**Cohere** sits interestingly in the middle of this build-vs-buy axis. Cohere Private Deployments per https://cohere.com/private-deployments deploy Cohere models inside the customer's own AWS, Azure, GCP, or Oracle Cloud account. The model weights stay under Cohere's commercial license but the inference runs entirely in customer-controlled infrastructure. For buyers who want frontier model quality with customer-controlled infrastructure — particularly common in EU financial services — this is a uniquely compelling middle path.

Whatever you decide, write the deployment model into a one-page architecture decision record (ADR) and circulate it through security and legal before procurement signs. The most expensive mistake in 2026 AI procurement is buying the wrong deployment model and being locked in for 24 months. The least expensive mistake is taking three extra weeks to verify the architecture against the actual compliance requirement.

If I were CTO of a 200-employee EU SaaS company with German and French enterprise customers asking pointed GDPR questions, I would buy **Azure OpenAI** in `francecentral` or `swedencentral` with abuse-monitoring opt-out, plus **Anthropic direct** with EU routing. Azure gives me region-locked GPT-5 with a clean Microsoft DPA. Anthropic gives me Claude with EU inference and ZDR by default per https://docs.anthropic.com/en/docs/about-claude/regions. Two vendors, two clean residency stories.

If I were a US federal systems integrator working on a FedRAMP High program, I would buy **Azure OpenAI in Azure Government**, full stop. The accreditation paperwork is the value. Yes, the model set lags commercial Azure by a quarter or two; that lag is a feature, not a bug, because it means the FedRAMP boundary is stable. For models not yet in Azure Government, I would either wait or run a self-hosted Llama on GovCloud-equivalent infrastructure.

If I were the head of engineering at a Japanese megabank, I would buy **Azure OpenAI in Japan East** and **Google Vertex AI in `asia-northeast1`** as a two-vendor strategy. Azure for the GPT and o-series families, Vertex for Gemini and any partner-model needs. Both keep inference inside Japan under FSA-compatible operator controls. I would not route any prompts through OpenAI direct or Anthropic direct because neither offers JP residency as a primary commitment.

If I were running an Australian regulated workload, I would buy **AWS Bedrock in `ap-southeast-2`** because the AWS Sydney region has the deepest AU enterprise footprint and the Bedrock model menu in Sydney covers Claude, Llama, and Mistral. Azure Australia East is the credible alternate. Google Vertex in `australia-southeast1` works equally well if Gemini is the primary model. The pick is more about your existing hyperscaler relationship than about a residency differentiator at this point.

If I were a French defense or critical-infrastructure operator with strict ANSSI guidance, I would buy **Mistral on Bleu** and stop there. The vendor is French, the infrastructure is French, the operators are French, the legal entity is French. No GDPR Article 44 transfer analysis, no FISA 702 worry, no Schrems III hypothetical. Capability is slightly behind frontier OpenAI and Anthropic models, but the sovereignty story is the cleanest available in 2026.

The one thing I would not do in 2026 is route customer-regulated data through OpenAI direct on US default routing while telling my European customers that their data "stays in OpenAI's secure infrastructure." That sentence is not a residency commitment, and the moment a German works council, an Irish DPC investigation, or an enterprise customer's procurement team asks a pointed question, the answer will not survive. Pick a deployment that matches the residency commitment you are making, and write it into the contract.