Introduction to sovereign AI

Why sovereign AI is a systems problem

An AI workload is not sovereign merely because its model runs locally. The organization must also be able to decide and enforce where data moves, which artifacts enter the environment, which model version is used, who can invoke the system, what tools it can call, how it is updated, and what evidence proves those controls operated.

Sovereign AI is therefore a system property. It emerges from architecture, ownership, technical controls, operational practice, and evidence working together.

A useful starting definition: sovereign AI is the organizational capability to make, enforce, verify, and change material decisions about an AI system without unacceptable external dependency or loss of control.

This definition does not require every component to be owned or hosted by the organization. It requires dependencies and decision rights to be understood, accepted, and governed.

The five questions SAI-100 asks

Use these questions before selecting a model, cloud, runtime, or product:

1. What is the AI system intended to do? Define the purpose, users, affected parties, inputs, outputs, and prohibited uses.
2. Where are its boundaries? Identify where data, artifacts, identities, requests, tools, and evidence cross between trust zones.
3. Which decisions must the organization control? Include models, infrastructure, access, egress, updates, operations, and retirement.
4. How are those decisions enforced? Connect each decision to preventative, detective, corrective, or recovery controls.
5. How can control be proven? Define evidence that is attributable, versioned, reviewable, and retained.

What sovereign AI is not

Sovereign AI should not be reduced to one of these incomplete claims:

• “The server is in our country.” Residency is important, but it does not establish control over administrators, dependencies, keys, egress, or updates.
• “The model is open source.” Model access does not automatically establish license clarity, provenance, reproducibility, or operational independence.
• “The system is on-premises.” Physical location does not guarantee controlled artifacts, identity, observability, recovery, or evidence.
• “No data is used for training.” This is one privacy property, not a complete sovereignty architecture.
• “The environment is air-gapped.” Disconnection changes the risk and operating model, but artifacts, updates, identities, and evidence still require control.

A running example

SAI-100 uses a synthetic enterprise knowledge assistant as a running example. Employees ask questions over internal policies. The system retrieves permitted documents, sends grounded context to an approved model, returns citations, and records evidence.

The example is deliberately simple enough to reason about but complete enough to expose real questions:

• Who owns each document and permission?
• Can the model runtime make an outbound connection?
• How are model and container artifacts approved?
• What happens when retrieval finds no authoritative answer?
• Which events must be retained for investigation?
• How is the system updated or disabled?

What you will produce

By the end of SAI-100, you should have five artifacts for the running example or your own approved scenario:

1. A one-page AI system definition.
2. A context and trust-boundary diagram.
3. A prioritized control-objective register.
4. An evidence map.
5. A readiness backlog with owners and next actions.

Continue with Sovereignty control dimensions to examine the different forms of control independently.