Storage, inference, and endpoint processing are different boundaries
This is the first place teams compress the problem too early. OpenAI’s current data controls split regional storage from regional processing and make clear that some selected regions support storage without full regional inference. Anthropic’s current data residency controls separate `inference_geo`, which controls where model inference runs on a request, from `workspace_geo`, which controls where data is stored at rest and where endpoint processing such as image transcoding or code execution happens. Google draws the same distinction explicitly with at-rest data residency zones and machine-learning processing commitments. If the architecture deck only says “EU ready” or “regionalized,” it is probably hiding at least two different boundaries.
Global routing is a product choice, not a networking detail
The operating promise changes when the endpoint changes. Anthropic’s first-party API is global by default and lets teams force US-only inference on supported models, while AWS Bedrock now exposes three distinct routing modes: in-region, geographic cross-region, and global cross-region. Google similarly distinguishes location support by endpoint and by model. The common story is that global routing is just the faster default. The less obvious reality is that a choice between global, geo, and in-region execution changes the compliance posture, the failover behavior, the availability tradeoff, and sometimes the price. That is not a transport detail. It is part of the product decision.
Feature and model exceptions break blanket rollout claims
This is where “we already solved residency” usually falls apart. OpenAI requires additional approval steps for non-US data residency and documents feature-specific regional limitations such as `background=true` not being available in the EU for Responses and tracing for Realtime not being EU data residency compliant today. The same OpenAI guidance also notes that remote MCP servers are third-party services with their own residency policies. Google warns that some regional endpoints, especially those serving older models, do not guarantee machine-learning processing in a specific location. Anthropic’s current first-party controls only offer `global` and `us` inference geos, and only newer models support the `inference_geo` parameter. In other words, the provider might support residency, but not for every model, tool, or workflow shape your rollout assumes.
Global rollout has to be mapped workload by workload
NIST’s AI RMF keeps the governance obligation on the operator, not the platform. Govern and Manage both push organizations to address third-party risk, document controls, monitor deployed systems, and keep named ownership for the risk decisions being made. That means the right unit of planning is the workload, not the vendor contract. A customer-support summarizer, a code assistant, a cross-border search agent, and a contact-center voice workflow may all sit on the same model family and still require different residency rules because they touch different data classes, regions, tools, and exception paths. The map has to live at that level or it becomes meaningless during deployment review.
Executive move: publish the residency map before you approve the expansion
Before the global launch meeting ends, require one artifact: a residency map per production workload. It should name the provider, model, endpoint type, storage region, inference region, unsupported regional features, third-party tools or MCP paths, retention mode, reviewer, and escalation owner. Then ask one simple question: if this exact workflow moves from the US into the EU, Japan, or Australia next quarter, what changes in the endpoint, model eligibility, approval flow, or third-party path? If the team cannot answer that from one sheet, the program is not ready for a global rollout. It is only ready for another internal debate after launch.
Key takeaways
- Do not collapse storage location, inference geography, and endpoint processing into one “residency” checkbox.
- Treat global, geographic, and in-region routing as different operating products with different control implications.
- Publish a workload-level residency map before region expansion so model exceptions, third-party paths, and ownership stay explicit.
Related surfaces
- Enterprise delivery model — See how LockedIn Labs frames governed rollout, control gates, and named operating ownership.
- Trust Center — Inspect the site-level data handling, retention, and review posture behind production AI delivery.
- Method — Review the Governed Delivery Loop and the artifacts that should exist before global rollout.
- Trusted-runtime briefing — Pair regional rollout questions with runtime ownership, network reachability, and execution boundaries.
- Connector-entitlement briefing — Connect region planning to the third-party scopes and external data paths that still need explicit ownership.
- Contact LockedIn Labs — Discuss one workflow that needs a real residency map before it goes from local pilot to global rollout.