Sovereign AI Capabilities

1. Your data never leaves your tenancy

This is the foundation. Every other capability on this page assumes it.

When you upload a document to a Sovereign AI assistant, it goes into a workspace inside your organisation's cloud. The model that reads it is also inside your cloud. The answer comes back across the same private network. No part of that exchange touches a third party's servers.

Compare that to a public AI tool like ChatGPT, Gemini or Claude, where the document leaves your organisation, lands on the vendor's servers in the United States, is processed there, and a copy stays in their logs.

The enterprise tiers of public AI tools come with a contract that says your data will not be used to train the model. A Sovereign AI build is the architecture where the vendor cannot reach it. A promise versus a proof.

2. Your rules, enforced consistently

Public tools come with someone else's rules baked in. A Sovereign AI build comes with yours.

When your organisation writes a rule into the assistant's system prompt, that rule applies to every user, every prompt, every time. The rule isn't a vendor's content policy. It's yours, enforced consistently.

A real example: a manager asks the assistant to identify the oldest members of a redundancy pool, to protect the pension scheme. ChatGPT will produce the list with a caveat. The Sovereign AI assistant refuses, citing the Equality Act 2010 and your organisation's HR policy on age discrimination.

Another, with hiring: your organisation's policy says you don't rank candidates by gender. ChatGPT will do it anyway. The Sovereign AI assistant refuses, because your rule is in the system prompt.

The same pattern works in a staff handbook assistant. The boundaries on what it will and won't discuss are decided by your organisation, not a vendor.

3. You decide who can do what

Public AI tools give you a blunt switch. Either someone has access to the tool or they don't. Inside it, every user sees the same features, has the same capabilities, can touch the same data.

A Sovereign AI build can give you central control over which assistants each role can see and use, whether they can build their own, whether they can share their builds with a named group or right across the organisation, and which capabilities (web search, code execution, file search, memories, the marketplace, and so on) appear in their interface. A Sovereign AI build can also apply different base configurations to different roles, so contractors land on a stripped down endpoint where file uploads are turned off, while partners get the full toolkit.

New starters have the right access from day one. HR can use the HR assistant; Legal can use the contracts assistant. No one has to remember what they're allowed to use because the platform enforces it.

ChatGPT, Copilot, Gemini and Claude all have admin controls in their enterprise tiers. The difference is who owns them. On a Sovereign AI build, the access controls are yours, codified by your team, changed when you decide they need to change, not when a vendor ships a feature.

4. Grounded in your knowledge, refuses to guess

Public AI tools draw on whatever's in their training data. That's why they sometimes make things up. They're guessing from patterns rather than reading your documents.

A Sovereign AI assistant works differently. It answers from documents you control: your staff handbook, your contracts, your tender library. Every answer cites where it came from, so you can check. When the answer isn't in the corpus, the assistant says so rather than inventing one.

This is the practical answer to the hallucination problem. Not a guarantee, because no AI is hallucination-proof. But a system engineered to refuse rather than guess.

Couldn't you just upload your handbook to ChatGPT and get the same answer? You can upload it. But ChatGPT will still answer from its training data when the document doesn't have what was asked, and you cannot tell which sentences came from where. A Sovereign AI assistant is configured to answer only from the documents you load, to refuse when the answer isn't in them, and to cite the source paragraph behind every claim.

You might say: I'd upload the handbook. The next clip shows what happens when you do.

This kind of cited, grounded work scales to bigger document sets. Here are two clips of a Sovereign AI assistant working across a tender, each answer cited back to the document it came from.

5. Connects to the systems you already use, on your terms

A Sovereign AI build doesn't have to live in isolation. It can connect to the systems your organisation already runs: Google Drive, internal databases, your CMS, document stores in your cloud, sector specific systems like case management or compliance archives.

Because the assistant is inside your cloud, those connections are configured by your IT team, with credentials your IT team controls. The data being read never routes through a third party vendor on its way to the model.

6. Automates work, not just answers questions

Most of what people picture when they hear "AI assistant" is a chat window. A person types, the model answers. A Sovereign AI build can do that, and it can also do work without a person at the keyboard.

Watch a shared folder and summarise new documents into a daily digest. Triage incoming emails and route them. Run a nightly check across a contract library and flag changes. Receive a webhook from another system, classify what came in, file it, reply.

This is the part that's hardest to do safely with a public AI tool. A chat session sends one document at a time and there's a human there to spot when something goes wrong. An automation sends documents constantly, all day, and there's no human in the loop. The data flow is bigger and much less supervised. On a Sovereign AI build, the data flow stays inside your cloud regardless of how many documents the automation reads or how often it runs.

7. Defensible if someone asks what your AI has been doing

Every prompt sent to a Sovereign AI assistant, every document it retrieved, every answer it gave, every user who asked, can be logged inside your own system, on a retention schedule you control.

If a regulator asks how the assistant has been used in your organisation, you can answer with specifics. If a tribunal needs to show how a hiring decision involving the AI was made, you can produce the prompts and the answers. If a client raises a subject access request, you can show what was processed and when. If something goes wrong, you can trace exactly what was asked and exactly what came back.

Public AI tools log this too. The difference is who holds the logs. On ChatGPT, Gemini or Claude, they sit with the vendor; you can request your own usage data but you cannot produce a full prompt and response history on demand. On a Sovereign AI build, the logs are yours, queryable by your team, retained on your timeline.

8. Swappable model, no vendor lock-in

A Sovereign AI build uses open weights models that run inside your cloud. The model is configurable, not a fixed commitment to one vendor's product roadmap.

If a better open weights model is released next month, you can swap it in. If your current model is deprecated, your workspace, your system prompt and your rules carry over to whichever replacement you choose. You're not locked into a vendor's pricing or product decisions.

The same control lets you route simple tasks to a lean model and complex work to a heavier one, so monthly spend tracks the work rather than the vendor's pricing.

How the capabilities fit together

Eight capabilities is a long list. In a real organisation, they rarely fire on their own. Here is one story that pulls four of them at once.

An employee tries to use the Sovereign AI assistant to draft a memo that softens a health and safety failure. The assistant refuses on policy grounds (capability 2). The refusal is logged and the compliance lead is notified by a background agent (capability 6). The compliance lead pulls the full transcript of the attempt for the disciplinary file (capability 7). None of it ever left your UK tenancy (capability 1).