Data residency for AI inference: pick a boundary, not a region

Your obligation is jurisdictional. A region is not.

Whatever your data-protection commitment actually says — to a regulator, to a customer in a contract, to your own policy — it is expressed in terms of a jurisdiction. Personal data stays in the EU. Records stay in Germany. Nothing leaves North America.

A cloud region is not that. It is one vendor implementation of a place, it means nothing to your second provider, and pinning to one is simultaneously too strict (you have needlessly excluded three other compliant regions) and too vague (a region name is not a legal commitment about where processing happens).

The right user-facing primitive is the boundary: you declare the jurisdiction, and the platform resolves it to whichever locations satisfy it. That indirection is what lets the same declaration keep working when the platform adds a second cloud, without you changing a line.

How boundaries actually work

A single region can satisfy several boundaries at once, from coarse to fine. Modelling that as a set of tags per location covers both broad jurisdictions and strict single-country residency with one mechanism:

A job declares one boundary, or none. With none, it runs wherever capacity is cheapest — which for non-sensitive work is the point. With one, it runs only where that tag is present.

The question that separates a real lock from a label

Here is the scenario that matters: your job is locked to the EU, and right now there is no available capacity in the EU. What happens?

There are only two honest answers. Either the job waits within its deadline and ultimately expires unrun, or it runs somewhere else. A system that quietly does the second under load has no residency guarantee at all — it has a preference, which is a different product.

This is also the right thing to probe in an evaluation. Ask what happens when the locked region has no capacity, and treat any answer involving "falls back" as a disqualification for regulated workloads.

Where the lock has to be enforced

A residency guarantee is only as strong as the narrowest point it is checked at, and there is exactly one point that counts: the moment work is handed to a machine.

• At dispatch, server-side. A worker asks for work and the control plane decides whether this job is allowed to go to that location. The check belongs on the side that cannot be tampered with.
• Not on the worker's say-so. A machine that self-reports its jurisdiction and self-selects eligible work is asserting the thing you are trying to verify.
• At provisioning too. A system that launches capacity in a location, then discovers it cannot legally serve the queued demand, wastes money and creates pressure to relax the rule.

Keeping the region-to-jurisdiction mapping on the control plane rather than in the workers has a practical benefit as well: disposable machines need to know nothing about compliance, and the mapping can be corrected centrally when a jurisdiction changes.

What a lock costs you

Residency is not free, and any provider telling you otherwise is not being straight. Narrowing where a job may run shrinks the pool of capacity competing for it, and a smaller pool means less price variation to exploit and a higher chance of waiting.

The tighter the boundary the sharper the trade: eu has many locations to choose from, eu-de has one. For deadline-flexible work that is often an acceptable price, because a wide deadline absorbs a thin capacity pool. It is worth deciding deliberately rather than locking everything by default — most workloads contain a mix, and only some of it is regulated.

What to ask a provider

1. Do I declare a jurisdiction or a region, and what does that declaration bind?
2. If capacity in my boundary is unavailable, does my job wait, expire, or run elsewhere?
3. Where is the constraint enforced — at dispatch, or by trusting the machine?
4. Does the boundary cover everything, including intermediate storage of inputs and outputs, not just the GPU?
5. How do stricter, single-country boundaries work, and what do they cost me in price or in waiting?
6. What happens to my locked jobs when you add a new cloud provider or region?

The answers tell you whether residency was designed in or bolted on. On Otium, boundaries are the declared unit, the lock is fail-safe by design, and eligibility is resolved on the control plane when work is leased rather than trusted to the worker.

Sources

This guide deliberately argues from the shape of the obligation rather than from any single regime, because the shape is what survives a change of jurisdiction. If you want the underlying text, the transfer rules are the part that makes "which jurisdiction processes this" a legal question rather than a preference.