What is the difference between private AI and sovereign AI?

“Private” answers a confidentiality question. It says that your prompts, your documents and your outputs are not visible to other tenants, are not used to train a shared model, and are held under a processing agreement that says so. It is a real property, and for many use cases it is enough.

“Sovereign” answers a control question, and it has three parts that are often conflated. Jurisdiction: which legal system can compel access to the data, which is not always the country the servers sit in. Operational control: who can change the model, the filters or the terms, and on what notice. Substitutability: whether a component can be replaced without rebuilding the system, which is what makes the first two enforceable rather than contractual.

The distinction matters commercially. A supplier can be entirely truthful about privacy and still leave you with no answer when the model behind their endpoint is deprecated, re-tuned, or repriced — and in a regulated environment, a change in model behaviour is a change in your system's behaviour that you have to be able to detect and explain.

This is the taxonomy used across this site. It exists because “sovereign” on its own has become a marketing word, and a specification has to be more precise than a word.

Fully local AI

Indexing, retrieval, identity, audit and generation all run on infrastructure the organisation controls. Nothing about an answer leaves the perimeter. The cost is hardware and model choice: you get the models you can host, at the throughput your GPUs allow.

Sovereign hybrid AI

Data, retrieval, reconciliation, identity and audit stay local; only the final generation step calls an external inference endpoint, under policy, with the retrieved context passed to it and the record of the call kept locally. The component is replaceable: switching provider changes one integration, not the architecture. This is the model in production at Federfarma Lombarda.

EU private inference

Inference on private or EU-resident infrastructure with explicitly defined residency, retention and access terms. Appropriate where the binding constraint is jurisdiction and processing terms rather than physical custody of the hardware.

Two things follow from stating it this way. First, the honest description of a hybrid system is not “fully on-premise” and not “data never leaves the perimeter” — the retrieved context does, and saying otherwise is the kind of claim that collapses in an audit. Second, the interesting engineering is in the boundary: what is sent, what is stripped before sending, and what is recorded about the exchange.

Five criteria decide it, in roughly this order:

• —Data class. Special-category personal data under the GDPR, or data whose disclosure is itself the incident, pushes towards fully local — or towards an architecture where that class of data never reaches the generation step.
• —Threat model. Who are you actually defending against: another tenant, an opportunistic attacker, a supplier's own staff, or a foreign legal process? The last one is a jurisdiction question and no amount of encryption at rest answers it.
• —Regulatory exposure. What you will have to demonstrate, to whom, and how long after the fact. This determines the audit surface, which is usually a stronger constraint than the inference topology.
• —Capability requirement. If the task genuinely needs a frontier model, a fully local deployment is a decision to accept less capability. Sometimes that is correct; it should be a decision, not a discovery.
• —Total cost and operational reality. GPUs, power, redundancy and the people to run them. An architecture nobody can operate at 3 a.m. is not sovereign, it is unavailable.

“Sovereign cloud.” Ask which of the three parts is being claimed. Datacentre location alone is the weakest of them, and it is the one most often meant.

“Your data never leaves.” Ask what counts as data. Prompts, retrieved context, telemetry, error payloads and support snapshots all leave systems that were described this way.

“GDPR compliant by design.” Compliance is a property of a processing operation in its organisational context, not a product attribute a vendor can confer. What an architecture can do is carry the controls — minimisation at ingestion, retention limits, access separation, an audit record — and let the controller demonstrate the rest. That distinction is the whole of the work in governance and compliance advisory.