Registry / Residency
Which AI providers offer EU data residency?
Region-pinning and EU residency options across major AI model offerings. The cell answers: Can data be pinned to a region (especially the EU)? Statuses below are evidence grades, not endorsements, “no public evidence” means we could not verify it from public sources, not that the answer is no.
Data residency is configured per Project at creation only (existing Projects cannot be migrated). Non-US regions additionally require OpenAI approval for modified abuse-monitoring controls and execution of a Zero Data Retention amendment, so EU residency effectively bundles ZDR and is approval-gated rather than purely self-serve.
Residency is deployment-type dependent, hence default:requires_config. Standard deployments keep prompts/responses in the customer-specified geography; "DataZone" EU deployments confine processing to EU member states; "Global" deployments may process anywhere the model is deployed (data at rest, including the abuse-monitoring store, stays in the designated geography). Azure regional services deployed in EU/EFTA regions are additionally in scope for Microsoft's EU Data Boundary commitments (learn.microsoft.com/en-us/privacy/eudb/eu-data-boundary-learn). For EEA deployments, abuse-monitoring human reviewers are located in the EEA.
Region pinning exists but is US-only. The inference_geo API parameter ("us" or "global", default global) controls where inference runs, self-serve at 1.1x pricing on Opus/Sonnet 4.6 and later; workspace geo (data at rest + endpoint processing) currently supports only "us". No EU residency option is offered on the first-party API, so this fails the "esp. EU" test; graded partial, not yes.
Bedrock FAQ: "Any customer content processed by Amazon Bedrock is encrypted and stored at rest in the AWS Region where you are using Amazon Bedrock." Claude is offered in EU regions, so EU pinning is achievable by selecting an EU region and in-region model profiles. default=requires_config because cross-region inference, if enabled, stores retained inputs/outputs in destination regions (per the data-retention and abuse-detection pages), residency holds only if you keep inference in-region or restrict routing to an EU geography.
Vertex AI documents data-at-rest residency by region and a separate ML-processing residency commitment supported only in US and EU locations. Claude models are reachable via regional endpoints (including EU regions), US/EU multi-region endpoints that keep processing within the chosen geography (per Google Cloud's announcement of multi-region endpoints for Claude), and a global endpoint that explicitly does NOT guarantee processing location - customers with residency requirements must choose regional/multi-region endpoints. Confidence medium because the residency page could not be fully retrieved and Claude-specific region lists were corroborated via Google Cloud announcements rather than quoted from the docs page.
"Data stored at rest in the customer selected location remains at rest in that location" and "ML processing for Agent Platform services occurs within the specific region or multi-region where the request is made." Per-model residency tables cover Gemini models across US/EU multi-regions and many country regions. Endpoints not listed (e.g., some Middle East regions / older models) carry no ML-processing guarantee. Customer must select regional endpoints (requires_config). Cached in-memory data also "adheres to all Data Residency requirements for the selected location."
Bedrock FAQ states customer content processed by Bedrock "is encrypted and stored at rest in the AWS Region where you are using Amazon Bedrock." Bedrock endpoints exist in Frankfurt, Ireland, London, Paris, Zurich, Milan, Spain and Stockholm (not every model/feature is in every region). requires_config: the customer chooses the region, and enabling cross-region inference moves processing/retained data to destination regions, so residency depends on configuration.
EU hosting is the default (no configuration needed), a genuine differentiator for a first-party API. Caveats: specific EU country/cloud provider not named, and data may be temporarily transferred to non-EU subprocessors (listed in Trust Center) under SCCs; enterprise customers can disable certain features involving non-EU transfers.
Two documented residency levers - (1) serverless API deployments: "Prompts and outputs are processed within the geography specified during deployment, but they might be processed between regions within the geography"; (2) Mistral models sold directly by Azure offer "Data zone standard (US and EU)" deployments alongside Global standard (which may process data in any Azure location, with data at rest in the designated geography). Graded partial - pinning is geography/data-zone level rather than single-region for these deployment types, and Microsoft's EU Data Boundary commitments are not publicly confirmed to cover third-party (non-Microsoft-product) models.
No region pinning on the first-party hosted API: the trust center states all infrastructure is on Google Cloud Platform servers in US-Central with no servers outside the US. Cohere's pitched "deployment flexibility" (EU or in-region residency) is achieved via private deployments or cloud-partner platforms (Bedrock, Azure, OCI, SageMaker), which are separate offerings - hence yes_platform_only.
Platform-level (AWS Bedrock). Bedrock is a regional service, customers pick the region and content is encrypted and stored at rest in-region. Cohere models are available in EU regions, but availability varies by model; verify the specific Command/Embed model's regions on the AWS 'models at a glance' page. Caveat: optional cross-region inference profiles process (and, where retention applies, store) data in other regions within the chosen geography, keep it disabled or EU-scoped for strict residency.
Platform-level pinning is real: Bedrock stores customer content at rest in the region of use (Bedrock FAQ), and Geo inference profiles never route outside their geography. But value=partial because for Llama specifically, current-generation models (Llama 3.3, Llama 4) are served only in US geography (no EU in-region or EU geo profile on their model cards as of 2026-07-05); EU-geography routing exists only for legacy Llama 3.2 profiles (Frankfurt/Ireland/Paris), which AWS lists as Legacy with a model EOL date of 2026-07-07, i.e. EU-pinned Llama on Bedrock is effectively disappearing. default=requires_config because residency depends on choosing the right region/profile and keeping cross-region inference within the intended geography.
Commitment is geography-level, not region-level: "Prompts and outputs are processed within the geography specified during deployment, but they might be processed between regions within the geography for operational purposes." Serverless MaaS deployments are regional (customer picks the region at deployment), but Llama serverless availability is limited to a subset of regions. Global-standard deployment types process data in any Azure location (only data at rest stays in the designated geography). Public docs do not explicitly confirm EU Data Boundary applicability to third-party MaaS model inference. Graded partial: region pinning exists but with in-geography cross-region processing and model-dependent region availability.
Regional endpoints are publicly documented: the default api.x.ai routes to the lowest-latency region, and requests can be pinned to a region via https://<region-name>.api.x.ai (e.g. eu-west-1 for Europe). This is in-region request processing, not a full at-rest residency guarantee: for stricter requirements (data at rest in a specific region) the docs direct customers to [email protected], with possible additional cost. Direct fetch of the docs page was blocked (verified via search-indexed text and Wayback snapshot), hence medium confidence. [source updated 2026-07-05] The dedicated regions doc page (docs.x.ai/developers/regions) now returns 404 after a docs restructure; the eu-west-1.api.x.ai endpoint remains live (confirmed) and the evidence is retained in the archived snapshot. Live source repointed to the docs root pending the relocated page URL.
No region-pinning or EU-residency option exists. The privacy policy (last update Feb 10, 2026) states: "To provide you with our services, we directly collect, process and store your Personal Data in People's Republic of China." It also notes: "The Personal Data we collect from you may be stored on a server located outside of the country where you live." The Italian Garante's 30 January 2025 press release (docweb 10097450) records that DeepSeek's privacy policy showed personal data stored in China.
The core point of this row: Fireworks, a US-based company, serves open-weight DeepSeek models entirely on its own infrastructure (AWS, GCP, Oracle Cloud data centers per its DPA, US, Japan, and EU locations). There is no data path to DeepSeek the company: DeepSeek is not a subprocessor and inference does not call DeepSeek's API; the "China data path" of DeepSeek's first-party service does not apply here. Region pinning (including EUROPE: Frankfurt and Iceland) is available for on-demand/dedicated deployments; the region of default serverless inference is not publicly specified, and DPA clause 6.1 permits processing anywhere Fireworks or its sub-processors maintain facilities, hence partial. Enterprise page claims "full support for data residency" via sales.