Choose geography across the processing chain

Learning objective

Meet data residency and transfer requirements through inference geography, deployment platform, and subprocessor choices.

Core idea

“In the EU” is incomplete until you specify what must stay there: inference, stored prompts, endpoint processing, application logs, tool execution, or access by subprocessors. A regional endpoint can answer one of these questions while leaving others unresolved.

Separate the customer’s geographic requirement from the legal basis for an international transfer. GDPR Chapter V governs transfers; it does not impose a universal EU-only hosting requirement. A contract can impose a stricter location requirement than the legal transfer mechanism alone. The organization’s privacy and legal owners approve the interpretation and transfer assessment; the architect selects and constrains the routes that satisfy it.

How it works

Turn location language into a routing requirement

Record the permitted inference geographies, storage locations, endpoint processing locations, recipients, and approved transfers for each data category. Include the application’s retrieval store, logs, memory, exports, and failover paths. Define whether the customer permits a broad geography such as the EU or requires one named region.

Use this record to evaluate the deployment platform before comparing latency or price. An architecture that depends on a single-region service has a different availability constraint from one permitted to route among several regions in the same geography. An outage does not itself authorize a global fallback; the fallback must satisfy the same approved requirement.

Distinguish Claude API inference from workspace geo

Inference geo and workspace geo govern different processing stages, and the Claude API’s inference_geo values provide no EU-only option. The workspace’s allowed_inference_geos enforces the permitted set; a default does not, and usage.inference_geo is an observation rather than proof of every copy’s location. See 2.1.4 for the controls, model support, and pricing mechanics.

Select the platform’s own routing mechanism

The following choices affect routing, but do not certify an entire application’s residency:

Treat each permitted endpoint or profile as an entry in the approved route list, including the geography it can reach and the model it serves. Verify the selected model’s availability and residency support before committing the design; see 2.1.4 for platform-specific mechanics.

Claude Platform on AWS is distinct from Amazon Bedrock; buying through AWS does not create an EU inference choice. If another regulatory requirement applies, recheck that platform’s eligibility too; HIPAA service selection belongs to 5.4.3.

Review processors and subprocessors separately

Anthropic’s retention documentation identifies Anthropic as data processor for the Claude API, Claude Platform on AWS, and Claude in Microsoft Foundry. On Amazon Bedrock and Google Cloud’s Agent Platform, it identifies the cloud provider as processor. Changing platforms therefore changes the documentation and contractual commitments you must review; do not carry a direct API agreement across by assumption.

GDPR Article 28 addresses processor agreements and prior specific or general written authorization for additional processors. Articles 44–46 address transfers and safeguards, including standard data-protection clauses. A data processing addendum (DPA) or Standard Contractual Clauses (SCCs) does not create a geographic restriction missing from the selected product configuration.

For the transfer assessment, record the exporter and recipient, data categories, purpose, destination, onward disclosures, selected Chapter V mechanism, and the privacy owner’s decision. Article 44 includes onward transfers, so assess a proposed support export or subprocessor change even when the inference endpoint remains unchanged. Keep that decision with the approved processing inventory and revisit it when recipients or destinations change.

Anthropic’s DPA Section C provides general subprocessor authorization and prior notice of an additional subprocessor. It allows an objection based on reasonable privacy or security concerns within 15 days of notice; otherwise the customer is deemed to consent. Schedule 4 points to the subprocessor list. Assign procurement and privacy owners to review that list and notices against the approved data flow, service purpose, location requirements, and transfer assessment.

That process is the subprocessor choice mechanism, not a request parameter selecting individual companies. Preserve the applicable agreement and review decision. If a proposed processor chain fails the approved requirements, resolve it contractually, choose another suitable platform, or withhold that data class. An SCC alone cannot satisfy a customer contract requiring EU-only processing.

Keep failover inside the approved route list

Test the route list under capacity failures as well as successful calls. If the approved EU route is unavailable, the proposed application policy must either select another approved EU route or return a deferred or unavailable outcome. It must not remove the geography constraint to recover service. Assign the platform owner to verify routing and the service owner to decide the acceptable customer outcome; any additional transfer requires the privacy owner’s approval before activation. Record the rejected global-fallback alternative in the deployment decision.

When the approved EU route is unavailable, the application policy stays inside the approved route list or returns a deferred or unavailable outcome.

Key distinctions and trade-offs

Inference versus storage: usage.inference_geo reports where inference ran. It does not establish where your logs, exports, memory, or vendor-retained artifacts reside.

Global versus geographic versus regional routing: Global routing offers a wider capacity pool. Geographic routing can retain flexibility inside an approved area. A single region narrows the failure and capacity options further.

Legal transfers versus contractual residency: An approved transfer mechanism may permit an international flow; an EU-only contract may still prohibit it. Satisfy both requirements before optimizing cost.

Architecture / decision scenario

A technology company has two enterprise customers. Customer A permits US processing. Customer B requires inference and retained application content to stay in the EU. The release budget permits a 10% inference premium, but Customer B forbids global failover.

The tempting proposal uses Claude API inference_geo: "us" for both and relies on SCCs for Customer B. The architect rejects it: SCCs do not satisfy that customer’s EU-only contract. Customer A uses an approved supported model, workspace allowed_inference_geos: ["us"], and checks of usage.inference_geo. Its application stores follow the separately approved US design.

For Customer B, the architect evaluates a supported Google Cloud eu multi-region route against an EU regional route, verifies model availability and price against the budget, and selects the multi-region option if the customer’s wording permits it. The platform owner configures that route and tests that failure cannot switch to global. The data owner keeps logs, memory, and exports in approved EU stores. Procurement and privacy review the cloud provider’s processor terms and subprocessor chain before release. If the complete chain cannot meet the contract, Customer B remains excluded from the feature.

Common exam traps

• Treating inference_geo: "us" as proof of EU residency or FedRAMP authorization.
• Setting a default without restricting permitted overrides.
• Dropping inference_geo after a model-support error and silently accepting global routing.
• Confusing Claude Platform on AWS with Amazon Bedrock.
• Assuming SCCs override an EU-only contract or that a regional model endpoint governs every copy.

What to remember

Specify location per processing stage and copy. Use the selected platform’s actual routing control, constrain failover, and verify model support. Review the processor and subprocessor chain independently from geography, with privacy and legal owners approving transfers and contractual fit.

Knowledge check

References

• Anthropic, Data residency
• Anthropic, Claude in Amazon Bedrock
• Anthropic, Claude on Google Cloud
• Anthropic, API and data retention
• Anthropic, Data Processing Addendum
• European Union, Regulation (EU) 2016/679 (General Data Protection Regulation)