AI Sovereignty: The Eight Control Planes Behind a Model Request

An authenticated analyst sends a classified prompt to an LLM endpoint in an approved European region. The route looks sovereign on the architecture diagram. Yet the provider's control plane may sit under another jurisdiction, an overseas subcontractor may support the service, and the customer may lack a workable exit path. Region selection answers one sovereignty question.

The European Commission's Cloud Sovereignty Framework defines eight objectives. I use those objectives as control planes because they force a useful review: follow one model request, identify which layer owns each decision, and ask for evidence from that owner.

TL;DR

• AI sovereignty spans eight objectives in the European Commission framework, including jurisdiction, data and AI, operations, supply chain, technology and security.
• Region pinning proves only where a request was sent. It leaves provider control, subcontractors, operational independence and infrastructure dependencies for separate evidence.
• An HTTP enforcement point can govern the authenticated caller, prompt classification, the approved provider and model, plus the region for routed traffic.
• Ownership, chip origin, training-data provenance, foreign-law exposure and independent operation sit outside that request boundary.

Eight sovereignty objectives, one request

The Commission framework names strategic; legal and jurisdictional; data and AI; operational; supply-chain; technology; security and compliance; and environmental sustainability objectives. Its scope is deliberately wider than a data-location control.

That breadth changes the review. Start with a request ID on a whiteboard. The caller's identity belongs to the application and IAM layer. Prompt classification belongs to the data-control layer. Destination approval belongs to policy. Provider ownership and subcontractor exposure belong to procurement and legal review. Continuity and exit capability belong to operations. Hardware and energy dependencies require infrastructure evidence.

I think any vendor questionnaire that reduces sovereignty to a region dropdown is procurement theater. A green tick beside "EU" supports a location claim and nothing more. The framework gives security and risk teams a better structure: one question and one accountable owner per objective, with evidence that matches the claim.

Strategic and jurisdictional control

Strategic sovereignty asks who retains meaningful control over the technology and its direction. Legal and jurisdictional sovereignty asks which laws, authorities, contractual terms, and ownership structures can reach the service or its data. A model request carries little direct evidence for either question.

The request record can identify the selected provider and endpoint. Procurement records must establish the contracting chain. Legal review must address governing law and provider control. It must also address relevant jurisdictional exposure. Those artifacts need a shared provider identifier so the route in production connects to the entity that was approved.

Architecture and governance often drift apart here. A committee approves one provider, then an application team changes an endpoint during a Friday deployment. The production record now shows a destination that the legal memo never covered. A policy rule at the request boundary can reject the unapproved route. Corporate ownership and foreign-law analysis come from records outside the HTTP exchange.

Data and AI control

The Commission's data and AI objective covers data protection and processing location. It also covers customer autonomy over AI capabilities. This is the layer closest to an individual model request. The application can supply the caller's identity and role. A classification service can label the prompt. Policy can then evaluate the proposed provider and model for the selected region before forwarding the HTTP call.

A claims analyst opens an internal assistant, attaches a document marked confidential, and presses Send. At that moment, the enforcement point has a caller, a data class, and a destination to evaluate. An allowed request should leave a record of the policy version and chosen endpoint. A denied request should leave the same decision context without forwarding the prompt to the model.

This layer overlaps with AI data residency controls, but sovereignty continues after regional routing. A destination record says nothing by itself about provider control, operational independence, the hardware below the service, or the customer's ability to leave.

Operational sovereignty and exit

The Commission defines operational sovereignty around the ability to run and support technology while evolving it independently of foreign control. That objective needs plans and tested capabilities outside the request path. Teams need to know who can administer the service, how support access works, what happens during provider disruption, and how workloads move when the approved route disappears.

Request-time policy still has a role. If the primary model endpoint becomes unavailable, a gateway should avoid silently sending classified traffic to an unapproved fallback. The failover destination needs the same provider, model, jurisdiction, and data-class approval as the primary route. Multi-region AI gateway failover addresses that routing problem.

The broader exit question remains an operational test. Can the organization move prompts, configurations, logs and dependent workflows to another service under its own procedures? A successful HTTP failover proves route continuity for that event. Independent operation and model evolution require a separate exercise.

Supply-chain and technology infrastructure

Supply-chain sovereignty reaches through subcontractors and suppliers rather than stopping at the logo on the contract. Technology sovereignty examines dependency and control across the stack. Environmental sustainability adds physical infrastructure and energy considerations. These layers may be several steps below the API hostname an application calls.

The Commission's implementation guidance says assessment must cross sovereignty dimensions, technical layers, subcontractors, and suppliers. It also records that the framework was first presented in October 2025 for the Cloud III DPS procurement.

Supplier declarations, architecture records, procurement evidence and service documentation must support the layers beneath the runtime destination record. Chip origin, energy source, subcontractor control and training-data provenance are invisible in the HTTP payload. Attaching those claims to a gateway record would create false precision.

Security and compliance, including audit custody

Security and compliance sovereignty asks who controls protective measures and who holds the evidence. For routed AI traffic, the critical evidence is a per-decision record made outside the calling application's write path. It should bind the supplied identity, prompt classification, approved destination, policy version, decision and timestamp.

That record answers a narrow but valuable set of questions. Which authenticated caller initiated the request? Which model and region did policy permit? Did the enforcement point deny the call, or allow it with or without redaction? Which rule was active? AI gateway data residency covers the destination evidence in greater depth.

Audit custody also needs an owner, retention policy, access controls, and an integrity mechanism. The proxy can create evidence for traffic it receives. Direct calls that bypass the route, local inference, provider-internal processing and interactions inside hosted products remain outside the enforcement point.

A sovereignty evidence review

The Commission's eight objectives work best as an evidence map rather than a product checklist. For each objective, name the claim, owner, source record, review date, and failure action. Then connect the identifiers that cross layers: provider, service, model, region, policy and request.

Run the review on a real event. Pick one authenticated request and place its destination record beside the approved-provider entry, subcontractor assessment, operational fallback and relevant infrastructure declarations. A printed request trace with a highlighted endpoint is more useful than a slide full of green shields. Missing links reveal exactly where the sovereignty claim depends on an assumption.

The same exercise prevents duplication with residency architecture. Regional controls decide where inference and evidence may occur. Sovereignty review asks who controls the service and which dependencies sit underneath it. It also asks how operations continue and which evidence supports every claim. Each owner should answer only for the layer they can observe.

DeepInspect

DeepInspect covers the request-visible slice of AI sovereignty. It sits as a stateless proxy between authenticated users or agents and HTTP-based LLM endpoints. For traffic deliberately routed through it, policy can evaluate the supplied identity and prompt classification, then the approved provider and model for the selected region before the request reaches the LLM. Each decision produces a record of the destination and policy outcome.

Provider ownership, subcontractor control, chip origin, training-data provenance, foreign-law exposure, environmental dependencies and independent model operation remain with legal, procurement, platform, and infrastructure owners. Local inference and HTTP calls that bypass the proxy also sit outside DeepInspect's enforcement path.

Book a technical deep dive at deepinspect.ai.