Guide
What is sovereign AI?
Sovereign AI is AI operated under your organisation's control: the models, data, execution, credentials, knowledge and audit evidence remain inside the environment you govern.
- Models on endpoints you operate
- Self-hostedModels on endpoints you operate
- Data, context and outputs
- Customer-controlledData, context and outputs
- No external LLM API required
- Air-gap capableNo external LLM API required
- Approval and audit in every workflow
- GovernedApproval and audit in every workflow
Definition
Sovereign AI, in one sentence
Sovereign AI is an AI operating model in which an organisation controls where models run, where data flows, who can access them, how decisions are governed, and what evidence is retained.
Sovereignty is about control, not only about where a cloud data centre is located. A model hosted in your region but operated, updated and metered by someone else is not under your control. A model running on infrastructure you govern, called by a workflow you can inspect, with credentials from your vault and evidence written to your storage, is.
The test is practical. Who can start, observe, interrupt or change the AI while it is working? If the answer includes an organisation other than yours, part of the system is outside your sovereignty, however the storage is labelled. This guide breaks that test into six dimensions you can check in an architecture review.
Why it matters
Why organisations ask for sovereign AI
Government, defence, finance, healthcare, critical infrastructure and regulated enterprises share a set of pressures. Specific legal obligations vary by sector and jurisdiction; the operational concerns are consistent.
Sensitive data
Case files, patient records, financial positions, classified material and operational telemetry are exactly the content AI is most useful on, and the content least suited to leaving a governed boundary.
Model input and output exposure
A model call carries the prompt, the context retrieved to build it and the response. Retrieved context is usually where regulated content enters, so every inference is a data flow.
External API dependency
If an AI step only works while a public model API is reachable, the process inherits that provider's availability, pricing, model changes and terms of service.
Auditability
Reviewers ask what the AI saw, what it produced, who acted on it and which version of the process ran. That evidence is only reliable if you hold it.
Operational continuity
Defence, infrastructure and public services need processes that keep working during network isolation, supplier disruption or a contract change.
Identity and secrets control
AI that acts on enterprise systems needs credentials. Who stores them, who can read them and whose directory decides access are sovereignty questions.
Running AI inside your boundary does not by itself make a process compliant. It gives you the controls that governance depends on. Our sovereignty page describes how that supports institutional oversight.
Six dimensions
What makes AI sovereign
Each dimension has an operational meaning you can verify. Any one of them can leave your boundary while the others appear to stay in place.
- 01
Model control
Models run on endpoints you register, version and operate. You decide which model handles which task and when it changes. No external LLM API sits in the path.
- 02
Data control
Inputs, intermediate state, prompts, retrieved context and outputs stay on infrastructure you govern. Any outbound flow is a configuration choice you make, not a platform requirement.
- 03
Execution control
The workflow engine that schedules, runs and records AI steps operates inside your environment, so you can inspect, pause or roll back work without asking a vendor.
- 04
Identity and secrets
Access resolves against your directory through SSO, MFA, RBAC and AD/LDAP. Credentials for every connected system are held in a vault you manage.
- 05
Knowledge and retrieval
Knowledge bases, embeddings and retrieval indexes are hosted alongside the models, with scope set by policy. The sensitivity of an AI step follows from what it can retrieve.
- 06
Governance and evidence
Guardrails, human approval and audit records are part of the workflow. The record of what ran, what the model produced and who approved it is written to storage you retain.
Related terms
Sovereign AI vs private AI, on-premises AI, data residency and air-gapped AI
These terms are often used interchangeably, and none has a single universally standardised legal definition. In architecture reviews they describe different things.
| Term | What it describes | What it covers | What it leaves open |
|---|---|---|---|
| Sovereign AI | Control over models, data, execution, identity, secrets and evidence during operation. | The full operating boundary, wherever the infrastructure sits. | Requires the organisation to govern and operate the environment, directly or through a contracted operator. |
| Private AI | AI where data is isolated from other customers and not used for provider training. | Confidentiality of inputs and outputs. | The runtime, model endpoint and credentials may still be operated by the provider. |
| On-premises AI | A deployment location: hardware in your own facilities. | Physical location of compute. | Not automatically sovereign. On-premises software can still depend on external licensing, telemetry or a hosted model. |
| Data residency | Where data is stored at rest, usually by region or jurisdiction. | Geography of storage. | Says nothing about where inference runs, where prompts travel or who controls the runtime and credentials. |
| Air-gapped AI | AI running in an environment with no network route to the outside. | The strongest connectivity boundary. | One way to achieve sovereignty, not the only one. Sovereign AI can also run in controlled connected environments. |
On-premises is a location, and data residency is a storage property. Both can be part of a sovereign design, but neither controls the model runtime or the credentials on its own. Air-gapped deployment is the strictest form; read more in air-gapped deployment.
Workflow
How a sovereign AI workflow looks
AI is one step in a governed process, not a free-standing chat window. A generic document-processing example shows how the pieces fit.
- 01
Trigger
A file lands in a monitored location, or an upstream system sends a webhook. The workflow starts inside your environment.
- 02
Integration
The workflow pulls related records from an enterprise system, using credentials read from your vault at run time.
- 03
Rules + Code
Deterministic rules and code validate the input, normalise fields and reject anything malformed before AI is involved.
- 04
Sovereign AI
A self-hosted model classifies the document and extracts the relevant fields, with retrieval scoped to an approved knowledge base.
- 05
Human Approval
If the outcome is sensitive, the run pauses. A named reviewer with the right role sees the evidence and approves or rejects.
- 06
System Action
Approved results are written back to the systems of record. Rejected items are routed to an exception queue.
- 07
Audit
The run, the model version, the inputs and outputs, the approval and every system action are recorded in storage you retain.
The model never acts on a system of record directly. Code checks what goes in, policy and people decide what comes out, and the record shows both. See how Nexus works for the full execution model.
Architecture
Where sovereign AI actually runs
Not an on-premises connector to a cloud AI service. An AI and automation execution layer that runs inside your environment.
The infrastructure is customer-operated: your data centre, a private cloud, a sovereign cloud under your contract, or an isolated network. Model endpoints are self-hosted. Knowledge bases and embeddings sit next to them, so retrieval never crosses the boundary.
The workflow engine that calls those models also holds the integrations to your systems. It reads credentials from your vault at run time, resolves users against your directory, and writes audit records to storage you retain. Kubernetes-agnostic deployment means it fits the platform your teams already operate.
Options and topologies are covered in deployment.
Your governed environment
- Self-hosted model endpoints
- Knowledge bases and embeddings
- Workflow engine
- Vault-managed secrets
- Identity: SSO, MFA, RBAC, AD/LDAP
- Audit records
Connected systems
ERP, CRM, ITSM, document stores, databases and infrastructure, reached from inside the boundary.
Evaluation checklist
How to evaluate a sovereign AI platform
Put these questions to any vendor, including us. Each has an observable answer.
- 01
Where do model inference and embeddings run?
Name the endpoints and who operates them. Embeddings carry document content too.
- 02
Can operation continue without vendor connectivity?
Block egress in a test environment and run a representative workflow end to end.
- 03
Can you use your own models and endpoints?
You should be able to register, version and swap the models a workflow calls.
- 04
Where do prompts, retrieved context and outputs travel?
Trace one AI step and list every hop. Each hop outside your boundary is exposure.
- 05
Who holds credentials and secrets?
Look for vault-managed secrets inside your environment, with no recovery path for the vendor.
- 06
Can identity map to existing enterprise controls?
SSO, MFA, RBAC and AD/LDAP should govern who builds, runs, approves and reads.
- 07
Can sensitive steps require named human approval?
The workflow should pause and bind the decision to a named identity, not a chat message.
- 08
Is each system action attributable?
Every write to a system of record should trace back to a run, a version and, where needed, an approver.
- 09
Can it run air-gapped?
Even if you do not need it today, it is a clear test that nothing depends on an outside service.
- 10
Can you replace integrations or model components without rebuilding the process?
The workflow should survive a model change or a system migration with a configuration update.
- 11
What evidence remains after a workflow runs?
Ask to see the record of a completed run: inputs, model output, approval, actions and version.
Working through this list now?
We can walk through each question against your environment.
Where it fits
When sovereign AI is most useful
Government and public-sector casework
Classifying and routing case documents and drafting summaries over citizen data that must stay in the institution's environment.
Defence and disconnected operations
AI-assisted processing where networks are isolated by design and nothing may depend on an external service.
Regulated document processing
Extracting fields from contracts, claims or filings, with code validation and human approval before records change.
Internal knowledge assistants
Retrieval over sensitive internal knowledge bases, with scope set by role and every answer traceable to its sources.
AI-assisted security operations
Triaging alerts and enriching findings where telemetry and investigation context should not leave the security boundary.
Infrastructure and IT operations
Model output proposes a remediation; policy checks and a named approver decide whether a production change happens.
For sector-level patterns, see sovereign AI solutions.
Nexus approach
How Nexus approaches sovereign AI
Nexus is a sovereign, self-hostable automation and orchestration platform. It runs self-hosted models in the same workflow as your systems and infrastructure, so AI reasoning sits between deterministic code and governed system actions rather than beside them.
Teams build with low-code steps and real code together, add human approval where a decision matters, and get an audit record for every run. The platform deploys inside your estate and does not require an external LLM API.
Read the detail on Nexus sovereign AI and how Nexus works.
- Self-hosted models, model endpoints, knowledge bases and guardrails
- Low-code steps combined with Rules + Code
- Named human approval on sensitive steps
- Audit records for runs, approvals and system actions
- SSO, MFA, RBAC, AD/LDAP and vault-managed secrets
- On-premises, private cloud, sovereign cloud or air-gapped
FAQ
Sovereign AI questions
What is sovereign AI?
Sovereign AI is an AI operating model in which an organisation controls where models run, where data flows, who can access them, how decisions are governed, and what evidence is retained. It is defined by control during operation, not by the location of a data centre.
Is sovereign AI the same as private AI?
Not necessarily. Private AI usually means data is not shared with other tenants or used for training. Sovereign AI goes further: the organisation also controls the runtime, the model endpoints, the credentials and the audit evidence.
Does sovereign AI have to run on-premises?
No. It can run on-premises, in a private cloud, in a sovereign cloud or in an air-gapped environment. What matters is that the organisation governs the environment and that core operation does not depend on a runtime it cannot inspect, pause or replace.
Can sovereign AI run air-gapped?
Yes, when the models, knowledge bases, workflow engine and audit storage all run inside the disconnected environment. Air-gapped operation is the strictest connectivity boundary, but sovereign AI can also run in controlled connected environments.
Does sovereign AI mean building your own foundation model?
No. Most organisations run existing models they are permitted to self-host on infrastructure they operate. Sovereignty concerns who controls the model endpoint and the data passed to it, not who trained the model.
How is sovereign AI different from data residency?
Data residency describes where data is stored at rest. Sovereign AI also covers where inference runs, where prompts and retrieved context travel, who holds the credentials and who keeps the record of what the AI did.
Can sovereign AI use human approval?
Yes. A sovereign AI workflow can pause before a sensitive action, require a named person with the right role to approve or reject it, and record that decision against the run it authorised.
How should a regulated organisation evaluate sovereign AI?
Ask where inference and embeddings run, whether operation continues without vendor connectivity, who holds credentials, how identity maps to existing controls, whether sensitive steps can require named approval, and what evidence remains after each run.
Architecture session
Discuss your sovereign AI architecture.
If you are evaluating how to run AI over sensitive data without moving models, credentials or workflow execution outside your control, we can map the deployment boundary with you.