Intelligence sovereignty: keeping what your organisation knows, remembers and learns

What is intelligence sovereignty?

The Sovereign Intelligence Platform recognises seven kinds of sovereignty. Intelligence sovereignty is the one most often missing from sovereign AI conversations, which tend to focus on where servers sit and which model is used. It covers three things: proprietary knowledge, memory and derived insight.

In the brief's words, what your organisation knows, remembers and learns stays an asset you own and can move. This is why the category is called sovereign *intelligence* rather than sovereign AI: the durable value is not in the model call, it is in the context around it. The distinction is developed in sovereign AI versus sovereign intelligence.

Why is accumulated context the strategic asset?

Models are increasingly interchangeable inputs. An organisation can move from one model to another in a planned migration, as long as the evaluation set and integrations are in order. What it cannot do quickly is recreate years of cleaned documents, resolved entities, corrected answers, approved procedures and recorded decisions.

Think of it as the difference between renting a brain and building a memory. If the memory lives in a form only one vendor can read, the vendor owns your switching cost. If it lives in open formats under your control, any model can be pointed at it, and the organisation gets smarter through AI with every loop around the closed intelligence loop: outcomes and their evidence flow back into data and context.

What actually counts as your organisation's intelligence?

Teams usually inventory data and models and forget the layer in between. Use this table as a checklist of assets, with the portability question to ask for each.

How does permission-aware retrieval protect what the organisation knows?

Owning knowledge is not enough. The knowledge also has to be reachable only by the right people and agents. A common failure in enterprise AI is an assistant that answers from a document the asker is not allowed to open, because the index flattened the permissions of the source system.

• Carry permissions into the index. Store the source's access rules, or a reference to them, with each chunk, and check them at query time, not at ingestion time.
• Retrieve as the user, or as a scoped agent identity. Never as an all-powerful service account. This ties retrieval to identity and access.
• Test with two accounts. One that may see a document and one that may not. Ask about the document from each. If the second gets an answer, stop and fix retrieval before adding more sources.
• Respect classification and residency. Data classes decide which models may read retrieved context. See data sovereignty.
• Log what was retrieved. The audit trail should show which sources contributed to an answer.

The data layer is covered in Data and Context, and the technical detail in the RAG architecture guide.

Who controls agent memory?

Memory is new. A chatbot forgets at the end of a session. An agent that remembers carries personal data, preferences, mistakes and business context from one task to the next. That makes memory both an asset and a liability.

• Scope it. Per user, per team, per agent or organisation-wide, chosen deliberately.
• Make it inspectable. A person should be able to see what an agent remembers and why.
• Make it correctable and deletable. Retention rules and data-subject requests apply to memory the same way they apply to any other store.
• Keep it out of the model weights. Memory held in a store can be governed. Memory baked into weights cannot be selectively removed.
• Version it. When memory changes agent behaviour, you need to know which memory state produced which decision.

Each agent's memory scope and retention belong in its Trust Profile, alongside permitted systems and approval rules.

Derived insight: who else may learn from what you generate?

Derived insight is everything your organisation produces by running AI over its knowledge: summaries, classifications, forecasts, extracted entities, patterns across thousands of interactions. It is often more valuable than the source material, because it is already shaped to your decisions.

Three questions decide whether you control it. First, who owns outputs under the contract? Second, may the provider use your prompts, files or outputs to improve its own models, and is that off by default, on by default or negotiable? Third, if aggregate or de-identified signals are used for any purpose, what exactly is included, and can you opt out?

Swfte's current statements on data handling, including what is true today and what is still in progress, are on the trust centre. The trust page also holds the policy statement on model training: `<policy statement on use of customer content for model training - founder to fill>`. Whatever any vendor tells you, get the answer in the contract, not on a web page.

What leaves with a vendor, and what stays?

Vendor lock-in in AI rarely looks like a locked door. It looks like a system that works well and cannot be exported. Check each item below before you sign, and again at renewal.

• Source content. You still hold the originals. This is the easy part.
• Processed content. Cleaned, chunked, enriched and de-duplicated content, often the result of long effort, may be exportable only as raw text.
• Indexes. Embeddings are tied to the model that produced them. Plan on re-embedding. The question is whether you can, and at what cost.
• Configuration. Workflows, agent definitions, tool connections, permissions. Are they declarative files you can read, or UI state?
• History. Conversations, feedback, corrections, approvals and the audit record.

In Europe, the EU Data Act gives customers of data processing services rights around switching and, from 12 January 2027, bans switching charges for providers within scope, according to this summary of Chapter VI (opens in a new tab). It also requires providers to let customers retrieve digital assets, including data and configurations, in a structured, machine-readable format. Check what applies to your contracts with legal counsel. Regulation is a floor. A portability test you run yourself is better evidence.

Which export formats and checks keep intelligence portable?

Prefer formats that any tool can read: plain text and Markdown for documents and prompts, JSON or JSON Lines for records, CSV or Parquet for tabular data, standard graph exchange formats for knowledge graphs, and open model formats for adapters. Where a store only exports proprietary dumps, treat that as a risk and document the workaround.

1. Inventory every intelligence asset in the table above and name an owner for each.
2. For each, run the portability test once a year: export, load into an alternative, check the result.
3. Keep evaluation sets, prompts and agent definitions in your own version control.
4. Store permissions with content and test retrieval with two accounts after every new source.
5. Define memory scopes and retention for every agent in its Trust Profile.
6. Put output ownership, training-use limits and export rights in the contract.
7. Re-embed a sample with a second embedding model to prove the index can move.

Swfte's Cortex answers from your files and meetings and runs on the laptop by default, so sensitive work does not have to leave it. At the platform level, intelligence sits across Data and Context and Intelligence and Models. Where a portability or export option is architectural intent rather than shipped, treat it as a question for your evaluation, and ask for it in writing. The guide walks through the build order.