Geopolitical Model Risk Is an Engineering Constraint

Most model-risk planning budgets for the failures an engineer can see coming: the endpoint goes down, latency spikes, a version gets deprecated. The one that actually strands you looks like none of those.

A subsidiary in the wrong country sends its usual request to a frontier API and gets back a 403. Not a deprecation notice, not a rate limit, just a refusal, because overnight the provider geofenced traffic from a newly sanctioned jurisdiction. Nothing in the code is broken. The endpoint resolves, the contract parses. The team simply no longer has permission to make the call, and no retry logic fixes a permission you do not hold.

This part of model risk never looks like an outage. It arrives as a compliance email, and by the time legal forwards it, the dependency is already load-bearing. So model availability and jurisdiction belong next to latency and cost, reviewed as the same kind of architecture variable. The failure is structural, not transient.

These shapes are already on the table, not hypothetical. Advanced-accelerator export controls mean a model you can legally train and serve in one country cannot run on the same hardware in another. APIs refuse traffic from sanctioned jurisdictions. And open weights are a license, not a right: acceptable-use terms get rewritten, monthly-active-user thresholds get bolted on above which the free grant lapses, and the next checkpoint ships closed. You keep the weights you already downloaded. You lose the upgrade path, the security patches, and the legal cover to keep shipping them.

When concentration is actually the bet

The real question is not “avoid concentration.” It is when concentration is correct. Single-sourcing the clearly-best model is the right call when the switching cost is bounded and the surface is not load-bearing: an internal drafting tool, a feature you could dark-launch off for a week without losing a customer. The capability lead is real. Pay for it and move on.

Concentration becomes a board problem only where two conditions hold at once. The surface underwrites revenue, and the revocation lever sits in a jurisdiction you do not control. One without the other does not justify the hedge. A warm second source on every call is over-insurance. No second source under the model that backs your signed contracts is uninsured.

What “warm” costs

Where the hedge is justified, “warm” has to mean something you can measure. It comes down to three standing commitments: mirror 1-5% of live traffic to the second model, score both outputs against the same eval suite on every deploy, and alert when the delta moves. That last alarm is the whole point. It catches the day a quiet model update degrades your fallback, months before any gate closes, while you still have time to fix the adapter.

None of that is free, and pretending otherwise is how fallbacks rot. You pay inference twice on mirrored requests. You hold every prompt and tool schema down to what both models support, which taxes each new feature. And you have to name the capability delta out loud: if the primary scores 86 on your task eval and the warm fallback scores 78, you are buying continuity at a known eight-point discount, not equivalence. Decide in advance which features degrade to 78 acceptably and which should hard-fail rather than serve degraded. Multi-model routing is the plumbing; a build-and-buy portfolio is the structure. Neither helps if the fallback only exists in a runbook.

This needs one recurring question, not a committee: where are we single-sourced on a model whose availability we do not control, and is that surface load-bearing? Keep a one-page map (model, vendor, jurisdiction, revocation lever, measured fallback delta) and re-run it quarterly, because terms and capabilities both drift. Maintaining that map costs little next to the rewrite you would do under a closed gate, while a competitor keeps serving. The variable it tracks is availability: whether the switch that turns each model off sits in a jurisdiction you control.