# Jurisdiction and Control Planes A way of thinking about AI sovereignty that asks who can control a system and under which law, rather than which country a model came from. ## Control plane vs data plane The terms come from networking. - **Data plane:** the part that does the work. For AI, the GPUs running inference and the data flowing through them. - **Control plane:** the part that decides and configures. Who can deploy or update the model, who holds the encryption keys, where logs go, who sets access policy, who can switch it off. Two deployments of the same [[Open Weights]] can have completely different sovereignty profiles depending on who holds the control plane. ## Jurisdiction The legal authority a system is subject to: where the operator is incorporated, where the servers sit, whose courts can compel access or shutdown. A model trained in one country but run entirely on infrastructure governed by another is, in practical terms, under the second jurisdiction. ## Why origin-based sovereignty is weak Once weights are downloaded, their origin gives the originating country no ongoing control. What matters is: 1. Where it runs and under which law (jurisdiction). 2. Who operates, updates and can revoke it (control plane). 3. Which hard dependencies it still has: chips, power, cloud contracts, APIs ([[Chokepoints in the AI Stack]]). > [!important] The defensible version of sovereignty > Control the keys, the operator and the jurisdiction, and know your chokepoints. Country of origin of the weights is a weaker test than it looks. Related: [[Sovereign AI Positioning]], [[Navon Sovereign Vaults]], [[The Resolver as Sovereignty Chokepoint]], [[Hardware Security Modules (HSM) MOC]]