Public previewRAGSuite is open-source, self-hosted and EU-ready — and we build it in the open.See it live

Platform Platform overviewSee it in actionAI SearchAI AssistantAI Connectors & MCPIntegrationsQuality LoopAdministration & SecurityMobile app
Solutions IT & Platform teamsCompliance & Data ProtectionDevelopersAgencies & Partners
Sovereignty
References
Pricing
Resources Trust CenterEU AI ActSecurity & disclosureFree toolsOpen source & open coreDocumentation ↗API reference ↗GitHub ↗ReferencesBlogChangelog
Company AboutPartnersContact
Search See it live Book a demo
Sovereignty

Sovereign AI in plain English — what it actually means for your business

Sovereign AI comes down to three questions about your own system: where the data physically sits, who could compel someone to hand it over, and whether you can prove both. A jargon-free guide for the person who signs.

SOVEREIGNTY jargon · plain language ragsuite.de
Jürgen Pietschmann
Jürgen Pietschmann AI Consultant
Published4 August 2026 Read6 min Sovereignty

Sovereign AI means you can answer three questions about your own system: where the data physically sits, who could compel someone to hand it over, and whether you can prove both rather than being told them. Everything else in this article is detail.

A partner told us recently that our materials were too technical for their clients. They were right, and it is a fair criticism of most writing in this field. So this article has no acronyms you have to look up, and where a technical term is genuinely necessary it is explained on first use. If you want the precise version afterwards, what is sovereign enterprise AI is written for an evaluator; this one is written for the person who signs.

The three questions

1. Where does the data physically sit?

When an employee asks an artificial-intelligence tool a question about a contract, two things travel: the question, and enough of the contract for the tool to answer. Both end up on a computer somewhere.

Most organisations can answer this one, at least approximately. “It’s in the European region of our provider” is an answer. It is worth noticing how little it actually settles.

2. Who could compel someone to hand it over?

This is the question that separates people who have thought about it from people who have not.

The company operating the software is subject to the law of the country it belongs to. If that law allows authorities to compel disclosure of data the company holds or controls, then the location of the building is not the decisive fact — the company’s home jurisdiction is. The United States CLOUD Act works this way, and it is not unique in doing so. We wrote about the specifics in the US CLOUD Act and your AI vendor.

The practical version of this question is short: which legal entity operates the service, under whose law, and is there a parent company anywhere that changes the answer?

3. Can you prove both — or were you told them?

Here is where nearly everything fails, and it is worth being precise about why.

It is usually not dishonesty. It is that the architecture leaves the customer nothing to check. If the software runs on someone else’s computers, your assurance is a contract and a compliance certificate. Both have value. Neither is the same as being able to watch what your own system does.

The market has noticed. In the Bitkom Cloud Report 2026 — a survey of 603 German companies with twenty or more employees — 87% said the “sovereign” offerings of international providers do not give them enough transparency about how data is processed and who can access it. In the same survey, 91% said they would prefer a German provider and 53% actually had one.

That is not a complaint about vendors being foreign. It is a complaint about not being able to see.

What “self-hosted” means, without the jargon

Self-hosted means the software runs on computers your organisation controls. Your own servers, or machines you rent and administer. Nobody else logs in. That is the entire idea, and it is less exotic than it sounds — most companies already self-host their file storage, their accounting system, or their email at some point in their history.

What changes when the software runs on your own machines:

  • Jurisdiction. There is no third-party operator holding your documents, so there is nobody for a foreign authority to serve an order on in respect of them.
  • Access. Nobody outside your organisation has a technical route to your data, because nobody outside your organisation has an account on the system.
  • Verification. You can watch what the software does at the network level. If it claims not to send anything out, that is a claim you can test rather than trust. The method is in no phone-home: how to verify it.
  • Exit. The data is already on your infrastructure, which changes the character of leaving from a migration project into a configuration change.

What it costs — the part vendors skip

Someone has to run it.

That means a named person or team who owns updates, backups, monitoring, and who has access. It means security patches get applied on a schedule rather than silently by a provider. It means the first serious incident is yours to handle.

For an organisation that already runs internal systems, this is incremental — the same people, one more thing. For one that has moved everything to services and kept nobody who runs anything, it is a genuine new commitment, and the honest advice is to decide whether you want that commitment before the pilot, not three months after it.

Five questions to put to any vendor

Including us. A vendor who can answer all five in a technical review is describing something real; one who deflects on more than one is describing a brochure.

Take these into the evaluation

  • Which legal entity operates the service, and under which country's law? Follow the corporate ownership up to the top before accepting the answer.
  • What outbound network connections does the software make? Ask to see it in a network capture, not described in a datasheet.
  • Who at your company can technically access our data, and what stops them? “Policy” is a weaker answer than “nothing is technically possible.”
  • What is the export format, and has anyone ever run a full export? Ask them to run one during the evaluation.
  • Could we run this ourselves if we decided to? The answer tells you what your leverage looks like in three years.

The short version

Sovereign artificial intelligence is not a product category and not a certification. It is a property of an arrangement you can describe in three sentences: your data sits here, this entity under this law controls it, and here is how you would check both if you wanted to.

If a vendor’s answer to any of the three is “trust us,” that is not a moral failing. It is simply a different architecture, with different consequences, and you should price those consequences into the decision rather than discovering them at renewal.

If you want the technical depth behind any of this, why self-host your RAG platform covers the reasoning and self-hosting: architecture and operations covers what running it actually involves.

Frequently asked questions

Is sovereign AI just a marketing word?

It is becoming one, which is exactly the problem. The Bitkom Cloud Report 2026 found that 87% of German companies say the “sovereign” offerings of international providers do not give them enough transparency about how data is processed and who can access it. The word has outrun the evidence. The fix is not to abandon the term but to insist it comes attached to something you can inspect — a network capture, a licence file, a jurisdiction, an export.

Isn't it enough that the data centre is in Germany?

Not by itself. Where data sits is residency. Who controls it, and who can be legally compelled to hand it over, is sovereignty. A provider subject to another country's law can be obliged to disclose data it holds or controls regardless of which data centre it sits in. Residency is necessary and not sufficient.

Do we need to run our own language model?

Not necessarily, and treating it as all-or-nothing is the most common mistake. The realistic pattern is to decide per project based on what is in the documents: a hosted model where the content is public or low-sensitivity, a local model where the content is confidential. One document-classification decision up front saves a great many arguments later.

What does self-hosting actually cost us in effort?

Someone has to run it. In practice that means a person or team who owns updates, backups, monitoring and access control — the same responsibilities any internal system carries. For an organisation that already runs its own infrastructure this is incremental. For one that runs nothing in-house it is a real new commitment, and it is better to say so before a pilot than after.

How do I check a vendor's sovereignty claim without a technical team?

Ask for artefacts rather than assurances, and let your technical people evaluate what comes back. Which legal entity operates the service and under which law; what outbound network connections the software makes, demonstrated in a capture rather than described in a datasheet; who at the vendor can technically access your data; what the export format is and whether anyone has actually run a full export. A vendor who cannot produce those in a technical review is selling you the word.

Sources & further reading

  1. Bitkom — Cloud Report 2026 (press release, 17 June 2026) — 603 German companies with 20+ employees; 85% dependence figure, 87% transparency gap
  2. US CLOUD Act (2018) — extraterritorial disclosure obligations — why provider jurisdiction, not data location, decides the compulsion question

← All posts