2 of the 5 ways to run Claude can run inference in Europe.

Europe is a geography. The EU is a jurisdiction. The docs answer the first one.

Read the vendor pages as an engineer and both EU options look identical. Read them as a data protection officer and they are not. Anthropic's own region table for Amazon Bedrock lists endpoint type EU for eight regions, and two of them are eu-west-2 (London) and eu-central-2 (Zurich). Neither the United Kingdom nor Switzerland is in the European Union or the EEA. AWS states that for EU cross-region inference all destination Regions lie within the European Union; Anthropic's table is the list your policy has to match, and it is the wider of the two.

The second omission is quieter. AWS documents that input prompts and output results may move outside the source Region during cross-region inference, and that any copies kept for abuse detection are stored in the destination Region. So the profile governs where inference runs, which is not the same statement as where the data comes to rest. On this page we say inference, not data, deliberately — the docs answer the first question and are silent on parts of the second.

Our position, from the deployments we run: the profile name is not the control. An account can be pointed at an EU inference profile and still hold an IAM policy that permits every other one, and that policy is what an auditor reads. We enumerate the permitted destination Regions in the policy, drop the two non-EU entries when the requirement is EU or EEA, mirror the list in a service control policy, and treat picking the endpoint as the smallest of the three steps.

Region table and endpoint types: Anthropic, Claude in Amazon Bedrock. Movement of prompts and abuse-detection storage in the destination Region: AWS, Geographic cross-Region inference. Both read on 4 August 2026.

Seven answers to have in writing before Claude touches personal data

This is the checklist we work through in a readiness review. Each line is either answered by a document or it is not; none of them are answered by a vendor assurance in a sales deck. If you take nothing else from this page, take the list and send it to whoever is proposing the rollout.

• The exact endpoint identifier every application calls — the inference profile ID or the endpoint host, not the vendor's brand name.
• The enumerated list of destination regions that endpoint is permitted to route to, region by region, with each one checked against EU or EEA membership rather than accepted as a geography label.
• The legal entity that operates inference on that platform, and the contract that covers it.
• Where safety- or abuse-detection copies of prompts and outputs are stored — on Bedrock cross-region inference AWS documents that as the destination Region, not the source Region — and for how long.
• Whether human review of flagged content can happen outside the EU, and under whose terms.
• The IAM or Entra policy that makes every other endpoint unreachable rather than merely unused.
• The per-request log that proves where inference actually ran, written to an account your security team already audits.

Line two is the one that takes work, because a geography name is not a region list. On Amazon Bedrock the list is machine-readable, so start there rather than with a screenshot of the console:

aws bedrock list-inference-profiles --type-equals SYSTEM_DEFINED \
  --query "inferenceProfileSummaries[?starts_with(inferenceProfileId, 'eu.')].[inferenceProfileId, models[].modelArn]" \
  --output text

Returns every EU system-defined inference profile in the account together with the model ARNs it can route to. Those ARNs are exactly what belongs in the IAM policy and in your record of processing — the same list, in both places, produced by a command anyone can re-run.