Library How to read a pattern →
T9

Cross-border & Sovereignty

The model an agent runs on is trained in one place, hosted in another, and run wherever its provider puts it. A user’s data moves between those places, under whatever law holds in each. Government and user both have a stake in those locations, for different reasons. A government weighs them for national security and for the control it keeps over its own systems: a service built on a model another state can reach into is a dependency it cannot fully govern. A user mostly wants the task done, and the legal exposure behind the agent is neither shown to them nor easy to understand.

Neither party can read those locations off the interaction. Nothing in the exchange declares where the model runs, and supply chains run through layers of subprocessors. Even a full declaration would not settle the question, because an onshore host can be required to hand data to a foreign government. Agents calling tools across borders add further steps no one sees. Once a user’s benefits or health data has moved under another jurisdiction, the protection it had does not travel with it, and nothing the user does brings it back.

01

Policy challenge

When a user interacts with a government service through an AI agent, the model behind that agent may sit beyond the user's legal protection in several distinct ways: hosted in another country, operated by a foreign company, or subject to foreign legal compulsion even when hosted onshore. The user usually cannot see this, and the agency often cannot tell which legal regime governs the data and the interaction.

As agent-mediated contact becomes routine, that uncertainty determines whose data-protection law applies, who can compel access to a user's information, and how much sovereign control the government keeps over the dependency.

02

Design challenge

Make plain, to both the agency and the user's agent, where the model behind a service runs, where its data is processed, and what its supply chain depends on.

Provide these as machine-readable signals.

Match the level of sovereignty required to the sensitivity of the interaction, and check it before a user's data moves, not after.

Tell the user when these facts change their legal protections, in terms they can act on rather than click past.

Let them switch to another model where one exists.

Keep a path open for the user who can't weigh the legal detail, or for whom no compliant alternative exists, so sovereignty doesn't shut them out of the service.

Patterns in this territory

8 shown
9.1 Frontier

Jurisdiction disclosure when data is processed

Telling the user, at the moment their data is processed, where it goes, whose law can reach it, and whether it stays onshore. A person deciding whether to share something sensitive knows, before sharing, whether a foreign authority could compel it.

9.2 Frontier

Data-sovereignty tiers for sensitive interactions

Matching the sovereignty of the infrastructure to the sensitivity of the interaction: routine tasks proceed with disclosure, sensitive ones require hosting no foreign entity can compel. A person raising a sensitive matter gets the stronger hosting automatically rather than by knowing to ask for it.

9.3 Emerging

AI system transparency registers

A public, machine-readable account of which AI system powers each government service, delivered to the user at the point of use rather than left in a register. A person challenging an outcome can name the specific system that produced it, the fact every accountability process needs first.

9.5 Frontier

Cross-border data transfer as a design obligation

Making the legal basis for a cross-border data transfer checkable before the data moves: an agent queries the status, the user sees a plain assurance. A transfer whose legal basis has lapsed fails before the data moves.

9.6 Frontier

Sector-specific data residency

Encoding a sector's data-residency law as a hard constraint the platform enforces before routing, with a plain assurance to the user that it held. Health and finance data stays where the statute says.

9.7 Frontier

Sovereign AI model selection and disclosure

A provenance label for the AI model behind a government service: who built it, where it was trained, where it runs, whose law governs it. A person can see whether the model handling their case answers to their own country's law.

9.8 Frontier

Concentration-risk and supply-chain disclosure

Making the whole AI supply chain's jurisdictional exposure inspectable, not just the top layer's: a sovereignty bill of materials an agent can query before committing data. A sovereign front end with foreign dependencies underneath is disclosed as exactly that.

9.9 Frontier

Context-triggered disclosure

Firing sovereignty disclosure only at the moments jurisdiction changes the user's protection: silent when infrastructure matches the data's sensitivity, unmistakable when it doesn't. Because the warning fires only when the user's protection changes, users keep reading it.

Case studies that touch this territory