“Sovereign” describes an architecture, not a model
That is the first misunderstanding to clear. No model is sovereign in itself. What is or is not sovereign is the path your data takes: what leaves your infrastructure, towards where, in what form, and who can see it.
Hence a more useful question than the usual one. Not “which model is sovereign”, but “what exactly leaves”.
Four levels, and the right one is the lightest that suffices
They stack in cost and in constraint. Moving up a level with no need is spending with nothing in return.
Level 1. Remote model, personal data obfuscated before the call. Identities, contact details and identifiers are replaced before the request leaves your infrastructure. The model works on an anonymised form, and the answer is re-associated locally. That is an architectural choice, not a cosmetic precaution: what never left is not a transfer.
Level 2. Remote model hosted in Europe. Useful when the constraint is contractual or geographic rather than technical. It changes nothing about the data leaving; it changes who hosts it and under which law.
Level 3. Self-hosted model on your infrastructure. Nothing leaves. The cost becomes a fixed cost, server, accelerator and operations, justified by volume or by regulation, rarely by convenience.
Level 4. Air-gapped network. No outbound connection at all. This is the level of defence environments, closed healthcare settings and some industrial sites. Everything that assumes a remote update then has to be rethought, including continuous evaluation.
The self-hosted LLM, without advocacy
Two truths that sit badly together in the usual discussions.
The first: on a general task, an open model running at your site stays below the best remote model. The gap has narrowed, it has not disappeared.
The second: on a narrow task, that gap often stops being decisive. Classifying a document, extracting fields, answering over a bounded document base: what decides quality is retrieval and tool descriptions, not model size. We observe this project after project, and it makes self-hosting realistic far more often than people assume.
What caps the discussion is the fixed cost. A server with an accelerator and its operations are only justified past a certain volume, or when the constraint is regulatory. Below that, level 1 does the job for far less.
Open models are what makes any of this possible
A model whose weights are published can be run on your infrastructure, including on an air-gapped network. That is the material condition of sovereignty: without open models, levels 3 and 4 do not exist.
There is a useful side effect, rarely stated: their existence caps the price of closed models. A provider who knows their client can switch to an open model running in-house does not have the same pricing power. That argument works for you too, in a negotiation.
What GDPR actually changes
The regulation does not forbid calling a model hosted outside Europe. It frames what leaves, on what legal basis, and what data subjects know about it. Three concrete architectural consequences.
Obfuscation happens before the call, not after. Personal data sent and then deleted has been transferred. The only solid treatment is the one that prevents the departure.
Minimisation is a design parameter. A system that sends a whole document where three fields would do creates needless exposure that no contract clause repairs.
Traceability is a feature, not a report. Every call logged with its parameters, every decision with its reason. That is what lets you answer an access request or an audit without reconstructing six months of history by hand.
This is not legal advice. Your data protection officer remains the arbiter, and our job is to give them a defensible architecture rather than a promise.
Healthcare: what HDS-certifiable means, and what it does not
For a healthcare institution, hosting is not a contract clause, it is an elimination criterion. We deploy on HDS-certifiable infrastructure in France, or at the client’s site.
The word certifiable is chosen. Certification applies to the host and to a defined perimeter, not to software in general. Blurring the two costs you the tender, and a buyer in that sector spots the confusion immediately.
One measured example: on MonEcho, five classifiers, one per exam type, 0.974 accuracy in the first quarter, deployed on HDS-certifiable infrastructure in France.
Sovereignty and the AI Act are not the same subject
They get conflated, which leads to handling one while believing you handled the other.
Sovereignty answers “where does the data run, and what leaves”. That is a hosting and architecture question.
The AI Act answers “which obligations apply to this system given its field of application”. That is a question of classification, documentation and human oversight. The detail is on AI Act.
A system can be perfectly sovereign and non-compliant, or compliant and hosted outside Europe. Both are addressable, but separately.
What we do by default
Our systems run on your infrastructure: a containerised image deployed on OVH, AWS, GCP or on premises, including air-gapped networks, with local models where sovereignty or latency requires it. Metering is per tenant, which lets vendors bill usage back to their customers.
And one engineering rule worth more than any declaration: the code never calls a model provider directly, always an abstraction layer. That is what makes moving from remote to self-hosted a one-day change instead of a project.
