Export controls and the geopolitics of your AI coding stack

Most of this blog treats model choice as an engineering decision — capability, price, context. But in 2026 the model behind your agent is also a geopolitical artifact, subject to export controls, regional availability, and supply-chain risk. Ignoring that is fine right up until the day a hosted model you depend on becomes unavailable in your region. Here's the part of model selection that isn't on the benchmark.

Why this is suddenly an engineering concern

Two forces collided:

• Compute is controlled. The chips that train and serve frontier models are export-restricted, which shapes who can build what and where it can be served. The infrastructure under your API call has a nationality.
• Open weights changed the map. The strongest open models on the benchmark — DeepSeek, Qwen, GLM, Kimi, MiniMax — come overwhelmingly from Chinese labs, released as downloadable weights. That's a genuinely new dynamic: frontier-adjacent capability you can run anywhere, from a different geopolitical pole than the closed US frontier.

So your stack now spans a fault line: closed, hosted, mostly-US frontier models on one side; open, self-hostable, mostly-Chinese models on the other. Where you sit on it is a decision, whether or not you make it deliberately.

The question used to be "which model is best." It's now also "which model can I still call next quarter, and where does my code go when I do."

The risks that aren't about quality

• Continuity. A hosted model can be restricted, deprecated, or made unavailable in your jurisdiction with little notice. If your product hard-depends on one closed endpoint, that's an unhedged single point of failure that no SLA covers.
• Data residency. Every prompt is data leaving your building. Where it lands, under whose jurisdiction, and whether that's compatible with your compliance obligations is a real constraint for regulated work.
• Provider concentration. Coupling your whole stack to one vendor's model, pricing, and policy is the same supply-chain risk you'd never accept in any other dependency.

Open weights as the hedge

The strategic value of open weights isn't only cost or privacy — it's un-cuttable-off-ability. Export controls can restrict chips and gate hosted APIs, but a weight file, once released, is out; you can run it on hardware you own. That makes a local model the natural continuity hedge:

• Keep a capable open model as a fallback for the day a hosted dependency blinks. Even a quality step down beats an outage.
• Run the private or high-volume workloads locally by default, where data residency and zero marginal cost both favor it.
• Use the hosted frontier for the hard 20% where its capability genuinely earns the dependency.

The practical posture

You don't need a geopolitics desk — you need to stop hard-coupling:

• Abstract the provider. Route through an interface, not a single vendor's SDK, so swapping models is a config change, not a rewrite. The model-routing lever doubles as your portability layer.
• Keep a local fallback warm. Validate that an open model on your own hardware clears your bar before you need it.
• Know your data residency. For regulated or sensitive code, "where do these tokens go" is a question with a compliance answer, not a vibe.

Treat model sourcing the way you'd treat any critical supplier: diversified, abstracted, with a fallback you've actually tested. The geopolitics will keep shifting; an architecture that can swap providers without flinching is how you stay out of the blast radius.

Inspired by the policy-and-governance coverage at vibecoding.cz.