Most conversations about AI data residency are conducted at the wrong level. Someone asks where the data lives, someone answers with a region name, and everybody writes it down. Then a year later a regulator asks a sharper question and the answer turns out to have covered storage while saying nothing about the thing that actually reads your documents.

Anthropic has now split those apart in a way I have not seen another vendor do this cleanly, and the Enterprise console reduces the whole thing to one line.

All inference for this organization is processed in US regions. Usage is billed at 1.1x the standard rate. That is the entire user interface, and it is a fair summary for a company that just needs the box ticked. It is also hiding a structure worth understanding before you tick it.

Start with what the setting’s own page says it does not do, because that list is shorter than the list of things people assume. It does not control storage: “Where your organization’s data is stored is separate from where inference runs.” It does not reach connected services: when Claude works with something like Slack or Google Drive, that service “processes data on its own infrastructure, which may be located outside the US.” And it is only offered on usage-based Enterprise plans, so a Team tenant or a legacy seat-based Enterprise agreement does not see it at all.

Worth separating the two surfaces before going further, because they use overlapping words. The toggle above lives in the claude.ai Enterprise console and governs where inference runs for the organisation. The inference_geo parameter, allowed_inference_geos, and workspace geo are Claude Platform controls, which is a different admin surface with its own objects. The concepts rhyme. The screens are not the same screen.

One switch in the console, two settings underneath

Anthropic’s data residency documentation opens by naming two independent settings, and the word independent is doing a lot of work.

Inference geo controls where model inference runs, on a per-request basis. Set it to us and the model runs on US infrastructure. Leave it global and requests go wherever performance and availability point.

Workspace geo controls where data is stored at rest, and where what the docs call endpoint processing happens. Image transcoding. Code execution. The parts of the product that are not the model but still touch your bytes.

Those are two different questions and a contract clause usually only anticipates one of them. When consulting with companies on this, the clause I meet most often reads roughly “customer data shall not be processed outside the United States”, and processing is a broad enough word to cover both. A vendor answer that names a storage region satisfies a reader who was thinking about databases and satisfies nobody who was thinking about GPUs.

The console toggle sets the first one org-wide. The API gives you the same control per request, through an inference_geo parameter you can put on any single call, plus workspace-level allowed_inference_geos and default_inference_geo settings that stop a stray key from opting out. There is a version of this question with no good answer, and it is worth naming so nobody spends a quarter hunting for the setting. If your requirement is European residency rather than American, there is no dial for it on the first-party platform. us and global are the only inference values, and workspace geo accepts only us. The one geography control you are handed points the wrong way for a Frankfurt or London data-protection officer, which turns a settings question into a procurement one. The toggle itself lives under Data and privacy, alongside inference hooks, if you want the rest of the console tree.

What does 1.1x actually cost you?

More than 10 per cent, in two places people rarely add up.

The surcharge itself is the easy part. It applies across all four token pricing categories, input, output, cache writes and cache reads, so there is no clever caching strategy that dodges it. It lands on usage only: the docs are explicit that “your seat fees don’t change and the 1.1x rate applies only to usage.” So the finance answer is ten per cent of a line item rather than ten per cent of the contract, which is why most teams sign it off in a meeting.

The second cost is the one to raise before anybody signs. If you hold a Priority Tier commitment, each token consumed with US-only inference draws down 1.1 tokens from your committed throughput, the same way prompt caching affects burndown. So you are paying the multiplier once in dollars and once again in the reserved capacity you already bought. A team that sized its commitment against global routing and then flips this on has quietly cut its own headroom, and the symptom is a rate limit rather than an invoice, which is a much more annoying way to find out.

The third cost is not money at all, and it is next.

Workspace geo is a one-way door

This one belongs to the Platform surface rather than to the console toggle above, and it is the reason the two are worth holding apart. Read this sentence from the docs twice: workspace geo is set when you create a workspace and cannot be changed afterwards.

There is no migration path in the product. If you need a workspace in a different geo later, you create a new workspace and move the work, with everything that implies for keys, integrations and whatever has accumulated inside it. And because us is currently the only available workspace geo, a company that will one day need EU storage is not choosing between options today. It is choosing when to find out that it cannot have one yet.

Mind you, that is a limitation stated plainly rather than a trap, which is more than most vendors manage. But it changes what workspace creation is. In building Tallyfy I have watched teams treat a workspace as a folder, something you spin up for a project and forget. Here it is a compliance boundary with an immutable field on it, and the person who creates one in a hurry on a Tuesday has made a decision the company cannot revisit.

Write down which workspaces exist and why, and put the geo on that list. It takes ten minutes and it is the only record you will have.

Read your contract clause before you read the price

The order matters, because the price is the thing that makes people decide and the clause is the thing that makes them right.

Three checks, and they take an afternoon.

One: is anything of yours running on a model old enough to refuse the parameter? inference_geo is supported on Claude 4.6 and later. On earlier models a request carrying it returns a 400, which is at least loud. The quiet case is the pipeline that never sends the parameter, because it was written before the control existed. That one is not running in the US, and it is not erroring either. Nobody ever applied the control to it.

Two: where does this not reach? Start with the one Anthropic names itself, because it is the one a data-protection officer will care about: a connected service processes your data on its own infrastructure, wherever that is, and this setting does not change that. Turning it on and leaving a Drive connector live means a US-only inference claim with a non-US processor attached to it. Then the mechanical gaps. On Amazon Bedrock and Google Cloud the parameter does not apply at all, because the region comes from the endpoint you called. That is not a gap so much as a different mechanism, but it means an org-level toggle in the Anthropic console governs nothing about the half of your workloads running through a cloud marketplace. It is also unavailable through the OpenAI SDK compatibility endpoint, which is exactly the sort of migration shim a team leaves in place for a year.

Three: did you already have this and forget? Organisations that previously opted out of global routing were migrated automatically to allowed_inference_geos: ["us"] with a matching default. No action was needed, which is good engineering and bad institutional memory. Somebody may be about to buy a control you have held for years.

Proving it, rather than trusting it

Here is the part I like, and it is rare enough to be worth the whole post.

The response usage object carries an inference_geo field telling you where inference actually ran. Not where you asked for it to run. Where it ran.

That turns a policy claim into a measurement. You can sample production traffic, count the values, and put a real number in front of an auditor instead of a screenshot of a toggle. Almost nothing else in enterprise AI governance gives you that. I have sat in enough vendor reviews where the entire evidence pack was a settings page to know how much stronger a per-request receipt is.

So the actual work is small and worth doing properly. Turn it on if your contracts need it. Say out loud that the multiplier hits your Priority Tier headroom as well as your bill. Note which workloads sit on Bedrock or Vertex and are governed by something else. Record the geo of every workspace, since you cannot change it later. And then log inference_geo from your responses, because a control you can prove is a different asset from a control you have merely bought.

The toggle is one click. The other four things are what make the click mean anything.