What is sovereign AI?

Sovereign AI is AI whose data, model and compute stay under your control and your law, including the power to switch it off. It is a property of the whole chain, not of one part.

That is what separates it from its neighbors. Data residency answers one question: where records are stored. A private cloud answers part of another: who runs the servers. An open model answers a third, but only if you run it yourself. Sovereignty needs all of the answers at once, and the weakest one sets its level.

The term started with governments. In NVIDIA’s account of national AI strategy, updated in July 2026, a country builds AI on its own infrastructure, data and talent. Its models are trained on local data and “hosted and run on local infrastructure, subject only to local laws.” The compute sits in AI clouds owned, operated and governed in the country.

The enterprise meaning is the same idea one level down. A manufacturer does not need a foundation model of its own. It needs to know that its part records, maintenance logs and supplier notices go only where it sends them. When a regulator, a works council or a customer asks where the data went, the company can answer without asking a vendor first.

• Where the data lives. The systems of record, the copies an AI system makes of them for search, its logs and its backups. Residency covers this layer alone.
• Where the model runs. An assistant puts records into the prompt it sends the model. Wherever the model runs, the records go too, one prompt at a time.
• Who operates the compute. Whoever holds administrator access to the servers can read what runs on them, in any region.
• Which law applies. The law of the place the data sits, and the law the operator answers to. They are not always the same country.
• Who can switch it off. A license check, a revoked API key, a retired model version or a suspended account. Each is a switch someone else may hold.

Two rules make the layers concrete for a company in Europe, and a third shows what sovereignty does not change.

The GDPR restricts transfers of personal data out of the EU. Article 44 allows a transfer to a third country only under the conditions of its Chapter V. The aim, in the article’s words, is that “the level of protection of natural persons guaranteed by this Regulation is not undermined.” The chapter then lists the routes: adequacy decisions, appropriate safeguards and binding corporate rules. A prompt that carries a customer’s name to a model hosted outside the EU can be such a transfer.

Location alone does not settle who can be ordered to hand data over. Under 18 U.S.C. § 2713, a provider of communication or remote computing services must preserve or disclose data in its possession, custody or control. The statute applies “regardless of whether such communication, record, or other information is located within or outside of the United States.” An EU region answers the first layer, not the fourth.

The EU AI Act works the other way. Article 2 covers providers who place AI on the EU market, wherever they are established, and deployers located in the EU. Running a model in your own building does not take you out of its scope. Sovereignty decides who controls the system, not whether the rules apply.

Most failures claim one layer for the whole:

• An EU region at a provider that answers to another country’s law.
• Records on premises, while every prompt that quotes them goes to a hosted model.
• A deployment on your servers that still sends usage reports, error reports or license checks over the internet.
• Open weights, served by someone else’s inference service.
• A system you cannot leave, because the data model, the access rules and the tools live in the vendor’s format.

None of these is wrong in itself. Many companies send some work to a hosted model on purpose. The failure is not knowing which layer you gave up, and for which records.

Ask five questions, one per layer, and ask for the answers in writing:

1. Where is each copy of our data, including indexes, logs and backups?
2. Where does the model run, and which records does a prompt carry to it?
3. Who has administrator access to the machines, and under which law do they work?
4. What leaves the deployment on its own: usage reports, error reports, license checks, updates?
5. If the network cable is cut, what still works, and who could stop it from outside?

Then test two of them on a trial system. Cut the line and see what still answers. Change the model in configuration and see what breaks. A system that passes both is sovereign in practice, whatever its brochure says.

Curiosity Studio runs on premises or in your private cloud. A cloud deployment we host runs in European data centers, on Hetzner. Connectors copy what they map into one graph on that deployment. Access is synced from your source systems and checked per record at query time.

The model is a setting. 19 providers are built in, hosted ones among them, and open weights run on your own servers through Ollama or any OpenAI compatible endpoint. Spark serves open models on your own hardware, so prompts and answers stay in your network. The models page shows where each model runs.

Air gapped deployments are supported, with an offline license, local models and usage reporting switched off. A connected install reports out by default. Studio sends a daily usage report, a status ping and error reports to Curiosity until MSK_DISABLE_TELEMETRY and MSK_DISABLE_CLOUD_ERROR_REPORT switch them off. Its front end reports product usage to Mixpanel, by user name and email, and has no setting to stop that. The subprocessors page lists both.

A sovereign system still changes, and someone has to answer for each change. That is the next question: why should a person approve what an AI changes?