On this page
What is the difference in short?
Both terms point at the same worry: an organisation does not want its AI to be something it cannot control. They differ in scope. Sovereign AI, as the phrase is used in most market material, is about locality and jurisdiction: which country the compute is in, which legal regime the provider answers to, sometimes which model is used. Sovereign Intelligence takes the same concern and applies it to everything AI touches inside the organisation.
That wider scope is not branding for its own sake. It follows from where control actually gets lost. Control over a model's hosting location does little for you if an agent can write to a production system with no approval, or if the context your AI learned from lives in a format only one vendor can read. Those are failures of operation and ownership, not of geography. The definition used across this site is covered in what is Sovereign Intelligence.
How do they compare side by side?
| Dimension | Sovereign AI (typical usage) | Sovereign Intelligence |
|---|---|---|
| Core question | Where does the AI run, and under which law? | Can we retain meaningful control over our whole AI estate? |
| Main unit of control | Hosting location, provider jurisdiction, sometimes the model | Seven sovereignties: data, infrastructure, model, intelligence, operational, governance, supply-chain |
| Data | Residency and transfer | Residency plus access, processing, retention, classification and context ownership. See data sovereignty |
| Models | A national or regional model, or a locally hosted one | Selection, deployment, customisation and lifecycle under your approval. See model sovereignty |
| Agents and workflows | Often out of scope | In scope: identity, permissions, approval and limits. See operational sovereignty |
| Governance | Policies on paper, provider attestations | Policy enforced at runtime, with evidence you hold. See runtime governance |
| Evidence | Provider reports | Traceable chain from data to outcome that the organisation can read |
| Outcome focus | Safe hosting | Measurable business outcomes, with evidence fed back into context |
Is Sovereign AI the wrong term?
No, and it would be unfair to treat it that way. Sovereign AI names a real and urgent requirement. Public bodies and regulated firms are right to ask where inference runs, which legal system can compel the provider and whether a domestic or regional alternative exists. Those questions drive procurement, and the European Commission has formalised part of them in its Cloud Sovereignty Framework (opens in a new tab), which scores cloud services against eight sovereignty objectives.
The term is also useful shorthand. If a board member asks whether the organisation has a sovereign AI strategy, the answer begins with locality and jurisdiction. The risk is that the answer ends there. A strategy that settles geography and stops has dealt with one of seven concerns. The rest of this page treats sovereign AI as the foundation and asks what is missing from it.
Where does a locality-only approach fall short?
There are five recurring gaps. Each is a place where an organisation can hold the sovereign AI label and still lack control.
- Agents act with unreviewed authority. The model runs in-region, but the agent built on it holds a broad service credential. Nothing stops it reading data it was never meant to see. See governed agents.
- Context is locked in. Embeddings, memory and knowledge graphs sit in a vendor's format. You control the server and not the knowledge. See intelligence sovereignty.
- Governance is a document. Policies exist, but nothing enforces them inside the AI at runtime, so behaviour drifts from the policy. See governance versus guardrails.
- The supply chain is invisible. A regional model may itself depend on a foreign component, library or hosted service that nobody has mapped. See supply-chain sovereignty.
- Outcomes are unmeasured. The system is safe and unused, or used and unexamined. Nothing returns evidence to improve it. See the closed intelligence loop.
Where can the wider view go wrong?
A wider scope has its own failure mode: it can become a reason to do nothing. If an organisation waits until all seven sovereignties are settled before it ships anything, it will ship nothing. The platform view is meant as a map, not a gate.
The second risk is vagueness. Control claims that cannot be tested are marketing. Every sovereignty should reduce to questions a buyer can put to a vendor and check, such as those in the vendor-evaluation checklists on the role pages. The third risk is overclaiming. No product delivers all seven in full on day one, and a trustworthy vendor says which parts are available, which are designed for and which are in progress. Swfte's own position is on the trust centre.
Which one does your organisation need first?
Use these four questions in order. They are a framework for prioritising, not a score.
- Is there a legal or contractual locality requirement? If yes, settle location, jurisdiction and provider exposure first. This is the sovereign AI core.
- Will AI take actions, not only answer questions? If yes, operational and governance sovereignty are urgent regardless of location, because action is where harm happens.
- Will AI learn from proprietary knowledge? If yes, decide who owns the context and how it can be exported, before volume makes it expensive to change.
- Do you depend on one model or one vendor for something critical? If yes, treat supply-chain and model sovereignty as the priority, and plan an exit before you need one.
Most organisations answer yes to more than one. The readiness self-assessment turns these considerations into a starting point on the entry ladder, and runs entirely in your browser.
How do you move from sovereign AI to Sovereign Intelligence?
Treat the sovereign AI work you have already done as layer 01 and part of layer 03. Then extend upward, one layer at a time, in an order driven by risk rather than by product catalogue.
| Step | What you add | What it gives you |
|---|---|---|
| 1 | An inventory of models, agents and data flows | Visibility. You cannot govern what you have not listed. See the estate inventory post. |
| 2 | Identity and permissions for agents | Bounded authority per tool and data source |
| 3 | A Trust Profile per AI system | Owner, risk level, approved models, allowed and restricted actions. See Trust Profile |
| 4 | Runtime policy with approval points | Behaviour that changes when policy changes |
| 5 | Owned context and export paths | Knowledge you can move |
| 6 | Evidence and outcome measurement | A loop that gets smarter and can be audited |
The ordered version of this journey, with decisions and pitfalls at each step, is the build guide. A narrative version is in building a sovereign AI stack layer by layer.
What should you ask a vendor who says sovereign AI?
- Which of the seven sovereignties does your claim cover, and which does it not?
- Who can compel you to disclose my data, and how do your contracts and architecture limit that exposure?
- Can I export my context, prompts, memory and logs in a format I can read?
- What can your agents do without human approval, and who sets that limit?
- Which parts of what you describe are available today, and which are designed for?
A vendor that answers these specifically is worth talking to, whichever label they use. If you are weighing a conversation, the contact page is the route to the Swfte team.
Frequently asked questions
Is Sovereign Intelligence just a rebrand of sovereign AI?
No. Sovereign AI usually concerns where AI runs and under which jurisdiction. Sovereign Intelligence keeps that concern and extends it to data context, models, agents, workflows, governance, supply chain and outcomes, so control is retained over the whole AI estate rather than the hosting location alone.
Can a sovereign AI deployment also be Sovereign Intelligence?
Yes, if the other layers are also under the organisation's control. Locality is the foundation. It becomes Sovereign Intelligence when agents, context, policy and evidence are also owned, governed and portable.
Which term should I use in a procurement document?
Use whichever your stakeholders recognise, but define it. State which of the seven sovereignties are in scope, what evidence you expect and how each will be tested. Undefined terms of either kind are easy for a vendor to meet on paper.
Does hosting a model in my own region make AI sovereign?
It addresses one concern: location. Sovereignty is the organisation's ability to retain meaningful control over its AI estate, and it is about control, not just where a server sits. Agents, context, governance and supply chain still need to be controlled.
Where should a small team start?
Start with the question that fits your risk: locality, agent authority, context ownership or vendor dependency. Then use the readiness assessment and the build guide to pick one entry point and expand.