Ask your model provider which country processed yesterday's 40,000 customer support summaries. Many enterprise buyers can't answer, and their contracts often don't answer either. Standard API terms describe what the service does. They rarely say where the work happens, and capacity scarcity in 2026 means "where" depends more and more on which site has power and interconnect available this quarter.
National security analysts have been asking this question about frontier AI for a while. Research groups such as Georgetown's CSET and RAND's AI program have published work that treats overseas training and inference sites as strategic assets. Those sites can be attacked physically, pressured legally, and disrupted in ways that cut off whoever relies on them. Most companies are not worried about state adversaries going after their invoice classifier. The framework still carries over cleanly, and it produces a checklist that procurement and engineering teams can use this quarter.
Why Compute Location Now Matters to Enterprise Buyers
Until recently, region selection was a latency setting and a GDPR checkbox. You picked us-east or eu-west and moved on. Three changes have made it a business risk.
First, capacity is following power instead of customers. CBRE's Global Data Center Trends 2026 and JLL's 2026 Global Data Center Outlook both describe markets where power availability decides where new capacity can land. Markets look very different from one another. West Texas is drawing purpose-built AI training campuses because of energy and land. Sydney and Singapore are consolidating as Asia-Pacific hubs. Tokyo's growth is limited by tight geographic controls on development and by power bottlenecks. When a provider's home region fills up, new inference capacity often comes online somewhere else.
Second, capital has gotten tighter. DataBank's 2026 forecast describes a return to fundamentals: constrained power, harder financing, and more scrutiny of which projects get built. In that environment, providers and the neoclouds they rent from will put workloads wherever the economics work, and your traffic is one of those workloads.
Third, the legal structures around these facilities are getting more complicated. Clifford Chance's 2026 data centre and AI compute insights covers the legal and financing structures that now sit around AI compute projects. Each layer of ownership, leasing, and operation adds another party with a say in whether your workload keeps running.
None of this means overseas compute is bad. Singapore offers political stability and strong infrastructure, and its push toward AI-ready, low-carbon facilities is a real advantage. The problem is running somewhere you never chose and never priced. For the upstream picture of who builds this capacity and what they depend on, see our map of the AI compute buildout.
The Three Exposures Security Analysts Track
Policy work on offshore frontier compute generally sorts risk into three groups. Each translates directly to enterprise terms.
| Exposure | National-security framing | Enterprise translation | Question to ask |
|---|---|---|---|
| Physical | Facility could be damaged, seized, or cut off by conflict or sabotage | Region outage, grid event, cable cut, natural disaster | Which buildings, in which countries, serve my endpoint? |
| Legal | Host government can compel access, impose export controls, or block operation | Data access orders, local retention laws, sanctions, sudden licensing rules | Whose courts and regulators have authority over the hardware and the logs? |
| Continuity | Loss of the site halts a capability the nation depends on | Loss of the endpoint halts a workflow your revenue depends on | What breaks, how fast, and where does traffic go instead? |
Physical exposure is the easiest of the three to picture and the least likely to hurt you. Mature providers already engineer for single-facility loss. The more realistic case is correlated loss. Power constraints push capacity into the same few markets, so a regional grid event or a fiber disruption can take out more of the market's capacity than your provider's status page implies. Our post on AI data center power constraints explains why grid availability now sets the capacity plan.
Legal exposure is the one buyers underestimate most. If your prompts include customer PII, contract terms, or health data, the processing location decides which government can demand access and which retention rules apply. A model that runs in your home region but writes abuse-monitoring logs in another jurisdiction has two legal exposures. You may only know about one of them.
Continuity exposure is about you more than the site. Two companies can call the same endpoint and carry very different risk. A company that uses it for weekly marketing drafts can wait out an outage. A company that routes every inbound support ticket through it cannot.
What Provider Documentation Says About Data Residency
The good news is that the major clouds now document routing behavior in detail. The less good news is that the defaults often favor capacity over location.
AWS Bedrock's cross-region inference documentation describes inference profiles that route requests across multiple regions to absorb traffic bursts. The profile you select determines how far a request can travel. Azure's deployment types documentation separates Global deployments, which can process in any Azure region, from Data Zone deployments, which stay within a defined geography such as the US or EU, and from Standard regional deployments. Google's Vertex AI data residency page separates regional endpoints from global ones in the same way.
The pattern is consistent across all three. The cheapest and most available option is usually the most geographically flexible one, and engineers chose it during a prototype because it didn't throttle. Nobody in procurement saw that choice. It lives in an infrastructure-as-code file.
Neocloud and GPU-as-a-service agreements are harder to read. Many of these providers lease space from colocation operators, and some resell capacity from other clouds. The service agreement may name a "primary" data center and keep the right to move workloads for maintenance, capacity, or "operational reasons." TierPoint's 2026 trends overview points out that established enterprise colocation customers put reliability and operational expertise first. That preference only protects you if your contract makes the provider commit to it. If you're comparing rented and owned capacity, our breakdown of GPU-as-a-service contract economics covers the commercial terms that tend to hide relocation rights.
The Borrowed Checklist: Map, Price, Notify
The national-security version of this exercise boils down to three disciplines. Enterprise buyers can copy them almost word for word.
1. Map every inference endpoint to a physical jurisdiction
Build an inventory with one row per model call path in production. That includes the vendor tools your teams adopted without a procurement review, such as a transcription service, a contract-review SaaS, or an embedded copilot.
For each row, capture:
- Provider and deployment mode (regional, geography-scoped, or global)
- Permitted processing regions according to the provider's documentation for that mode
- Log and retention location, which may differ from the processing location
- Operating entity: the cloud, a neocloud, or a reseller sitting on someone else's hardware
- Business workflow that depends on it and the cost of one hour of downtime
Most teams find something they didn't expect, usually a global deployment mode chosen for throughput or a vendor that subprocesses through a model API in another region. If you use open-weight models served by third parties, also note where the weights are hosted. Our post on mapping a model hub dependency walks through that inventory.
2. Price the failover before you need it
A failover plan without a price is a wish. For each critical workflow, decide where traffic goes if the primary endpoint becomes unavailable or legally unusable, and what it costs to keep that path warm.
The following is an illustrative example, not a client result. Say a support triage workflow spends $40,000 per month on inference in one region with one provider. The team considers three options:
| Option | Monthly cost | Recovery time | Notes |
|---|---|---|---|
| No standby | $0 | Unknown, likely days | Workflow stops; humans absorb the full queue |
| Cold standby (second provider, configured but unused) | ~$500 in eval and test runs | Hours, if prompts still work | Prompts and tool schemas drift; first real failover is a gamble |
| Warm standby (10% of live traffic on second provider) | ~$4,000 | Minutes | Continuous evidence that the path works |
The warm standby costs 10% of primary spend, which is $4,000 against $40,000. You compare that number to downtime cost, not to zero. If one day of stopped triage costs more than a few months of standby, the decision is easy.
The second provider also needs real engineering. Different models fail differently on the same prompts, tool-calling formats differ, and output schemas drift. Our analysis of second-sourcing accelerators makes the hardware-level version of this argument. The software version is cheaper but still not free. Our model deprecation runbook covers the eval and migration work that a standby path needs.
3. Require notice before workload relocation
This control costs almost nothing, and buyers rarely ask for it. Governments negotiating for sovereign compute ask for notice and consent before workloads move. Enterprises can ask for a smaller version of the same thing.
Contract Language That Closes the Gap
Most standard API terms don't address workload location beyond a general data processing addendum. For anything your operations depend on, push for clauses like these at renewal:
| Clause | What it says | Why it matters |
|---|---|---|
| Named processing regions | Workload processes only in listed countries or regions | Turns a documentation default into a commitment |
| Relocation notice | Provider gives written notice (for example, 60 to 90 days) before moving processing to a new jurisdiction | Gives you time to assess legal exposure and adjust routing |
| Right to refuse | You can decline relocation and exit without penalty or stranded commitments | Keeps "notice" from being a formality |
| Subprocessor disclosure | Provider names the operators of the physical hardware, including colocation and neocloud partners | Exposes the real legal chain |
| Log location parity | Abuse-monitoring and debugging logs stay in the same jurisdiction as processing, or the exceptions are listed | Closes the most common hidden exposure |
| Continuity commitment | Provider documents its own regional failover and what happens to your traffic during it | Tells you whether their failover silently becomes your relocation |
Large clouds may not change their master terms for a mid-market buyer. Neoclouds and specialized inference providers often will, especially on multi-year commitments. Even when the answer is no, asking forces a written statement of current behavior, which you can then design around. Healthcare and financial services teams are already doing similar work for PHI and audit requirements. See our guide to building a BAA-ready agent stack for the parallel controls.
If you sell into the EU or operate there, workload location also affects your obligations as a deployer. The August 2026 EU AI Act enforcement changes make documentation of your AI supply chain more than an internal exercise.
How Much of This Your Company Needs
This framework scales down. You don't need a sovereign compute strategy to run a marketing copy tool. Tier your effort by what the workflow touches and what its failure costs.
Tier 1: Light touch. Internal productivity, drafting, and summarization of non-sensitive content. Map the endpoint, note the deployment mode, and move on. Global routing is fine here and usually cheaper.
Tier 2: Contractual controls. Workflows that process customer PII, contracts, or financial records. Pin the deployment to a geography-scoped or regional mode, get log location in writing, and add the relocation notice clause at renewal.
Tier 3: Full checklist. Workflows where downtime stops revenue or breaks a regulatory obligation, such as support triage, claims intake, or transaction monitoring. Do everything above, run a warm standby in a second jurisdiction or with a second provider, and review the map every quarter. Capacity moves faster than annual audits.
A company with a dozen production AI workflows will usually find two or three in Tier 3. Those few are where the effort belongs. Spreading the same controls evenly across all twelve costs more and leaves the critical ones under-protected.
Concentration deserves a separate check. If all of your Tier 3 workflows depend on one provider in one geography, you have a single point of failure even when each workflow looks fine on its own. That aggregate view is what national-security analysts care about most, and it's the view enterprise risk registers most often lack. A model-agnostic routing layer is the usual engineering answer, because it makes switching providers a configuration change instead of a rewrite.
Turning the Endpoint Map Into Running Failover
Writing the inventory takes about a week of spreadsheets. Making failover real is engineering work: a routing layer that can shift traffic by workflow, eval suites that prove the standby model handles your prompts, traces that show which endpoint served each request, and runbooks that operators have rehearsed.
OpenNash does that build. In an audit, we map each production model call to its jurisdiction, deployment mode, and downtime cost, and sort workflows into the tiers above. The design phase sets routing policy and the eval gates a standby path must pass. The build and deployment phases deliver a routing layer and failover runbooks that your team owns outright, with no ongoing platform fee on top of your model spend.
If your inventory shows a Tier 3 workflow running on a global deployment mode with no standby, book a call with OpenNash and bring that one workflow. We'll work out what a warm second path would cost and how long it would take to stand up.