"Data residency" sounds like one question, but legal teams are usually asking three different ones: where is data stored, where is it processed, and how long is it retained. LLM API calls make these distinctions unusually important, because a typical Claude request involves very little storage at all: your prompt goes in, a response comes out, and unless you have enabled features that persist data, the interaction is transient. Answering the three questions separately, with evidence, is what makes your legal review go smoothly.
Question 1: Where is the data processed?
Processing location is what region selection is mostly about. When you call Claude through a third-party platform, you typically choose where your requests are served: on Amazon Bedrock you specify an AWS region when you create the client (for example aws_region="us-east-1"); on Google Vertex AI you configure a project and region; Microsoft Foundry resources are created in an Azure region; and Claude Platform on AWS uses an AWS_REGION setting alongside your workspace ID.
Two honest caveats belong in any answer you give legal. First, some platforms offer "global" endpoints that route requests for availability rather than pinning them to one geography; Vertex AI's region="global" option is an example. If residency matters, ask your provider what a global endpoint means for processing location before using one. Second, region availability differs by model and platform, so verify that the model you want is actually served in the region you need. Do not assume; check the provider's current documentation.
Question 2: What is stored, and where?
Distinguish between what the platform might retain and what you retain. Your own logging is usually the larger footprint: if you log full prompts and responses for debugging or quality review, that log store is where your data resides, and it is entirely under your control. Decide deliberately what you log, where those logs live, and who can read them.
On the platform side, retention practices (for example, whether requests are retained for abuse monitoring, and for how long) are defined by each provider's terms and data-handling documentation. These terms differ between providers and change over time, so this guide will not summarize them for you. The right move is to have legal read the current data-processing terms for the specific platform you chose, and to get answers in writing for anything ambiguous.
Question 3: Is our data used to train models?
This is the question executives ask most often, and the one where precision matters most. Model-training and data-use commitments are set out in each provider's terms for their Claude offering. Rather than repeating any version of those commitments here (which could go stale), the guidance is procedural: locate the specific clause in your platform's terms that addresses training use of customer content, confirm it covers your account type and any beta features you use, and keep a dated copy. Beta features sometimes carry different terms than generally available ones, which is worth noting if you are on Microsoft Foundry, where some Claude features are still in beta.
Framing the answer for legal, honestly
A strong residency answer for a Claude 3P deployment looks like this. First, name the platform and region: "We call Claude Sonnet 5 via Amazon Bedrock in eu-central-1" is a checkable claim. Second, describe the data flow in one sentence: prompts and responses transit the platform's API in that region; we persist nothing except our own logs, which live in our cloud account in the same region. Third, cite the provider's data-handling terms for retention and training-use commitments, with document version and date. Fourth, state what you verified versus what you inherited: running inside your existing cloud means Claude largely inherits that cloud's compliance posture, but inheritance is not a certification for your specific use case, and your legal team should confirm specifics with the provider.
What you should not do is equally clear: do not claim "the data never leaves country X" unless your provider documents that for your exact endpoint, model, and features; do not treat encryption in transit as a residency answer (it is a security answer); and do not let a proof of concept run in a convenient region and quietly become production in the wrong one.
Where to go next
For the mechanics of region choice and global endpoints, read Regions, the Global Endpoint, and Data Location Basics. For how cloud certifications do and don't transfer to your Claude workload, see Compliance Inheritance, and for the broader picture, Claude 3P Data Flow Basics.