A growing number of technical leadership teams are making a sensible choice: selecting a European language model provider rather than an actor subject to extraterritorial legislation. This direction is legitimate and represents tangible progress in matters of governance. It reduces legal exposure, simplifies the relationship with the regulator, and brings data processing closer to the European framework. This article does not seek to call that choice into question, but to clarify its exact scope, so that a CIO, a DPO, or a CISO can assess it accurately.
Two questions often conflated
The term “sovereignty” in practice covers two distinct questions that it is useful to separate.
The first concerns the model: who trained it, where it is hosted, which legislation its publisher is subject to. A European model provides a clear and favourable answer here. This is the most visible dimension, and the one that most evaluation frameworks consider.
The second concerns the data: the real content you submit to the model for it to work on. Internal documents, client exchanges, identifiers, business data. Does this data leave your perimeter, and if so, in what form? This is a different question, and a sovereign model does not answer it on its own.
”Hosted in Europe” does not mean “the data does not travel”
For a language model to process a request, it must receive the text of that request. This is the very principle of how it works: the content is transmitted to the model, which reads it, processes it, and returns a response. Whether that model is European or not, hosted in Paris or elsewhere, changes nothing in this mechanism. The real data is indeed sent to the model.
European hosting and GDPR compliance frame this processing: they determine the legal basis, the retention period, the rights of the data subjects, the location of the servers. These are serious guarantees. But they bear on the way the data is processed once received, not on the fact that it stays with you. Compliance organises the data’s departure; it does not prevent it.
This distinction is not a lawyer’s nicety. For certain categories of data, the issue is not only “is the processing compliant?” but “does this data have the right to leave my perimeter, in any form whatsoever?”. Health data falling under Article 9 of the GDPR, industrial secrets, files subject to a contractual confidentiality clause: for these cases, the decisive criterion is the transit itself, regardless of the quality of the recipient.
A sovereign LLM answers the question "to whom is my data entrusted?". It does not answer the question "does my real data leave my server?". Both are legitimate, but they are not substitutes for one another.
A complementary layer, not a competing product
It follows from the above that data sovereignty is addressed at a different point than the choice of model: upstream of the call, on your own infrastructure. The objective is to have the model work on the meaning of a document without transmitting to it the elements that identify the persons or organisations concerned.
In concrete terms, before any call, sensitive identifiers - names, addresses, IBANs, social security numbers, client identifiers - are detected and replaced locally with typed codes that remain consistent from one document to another. The model receives a text in which the real values have been substituted. It reasons on the codes, and the response is reconstituted locally with the true values. The model has never seen who was concerned.
This approach is deliberately model-agnostic. It sits above the provider you have chosen, whether it is a European model, another actor on the market, or a model run entirely locally. A sovereign LLM and a local anonymisation layer are therefore not in competition: they answer two different questions and work together. Selecting a European model remains a good choice; adding a local anonymisation layer extends the guarantee of model sovereignty to data sovereignty.
What is measured, and what is not promised
For the sake of honesty, one clarification is required: no automatic identifier detection is perfect. The seriousness of such a layer is judged on two things, the measurement and the behaviour in case of doubt.
On measurement, our evaluations place recall at 94.2% on an internal corpus of 206 synthetic multi-sector French documents (written for testing), and at around 75% on a public French benchmark (within the scope of the data types we claim to cover, and that the evaluation explicitly targets). These two figures are deliberately given together: the second, more demanding because independent, indicates where the real margin for improvement lies. We do not claim, and will not claim, perfect 100% detection.
On behaviour, this is the decisive point. Because no detection is infallible, the layer rests on a fail-closed principle: in case of doubt, the data is not sent, it is kept locally or submitted to human validation. Several mechanisms are layered together - known formats recognised by deterministic rules (IBAN, social security number), entity recognition, lists specific to the company. The guarantee holds through verifiable code and a human safety net, not through the goodwill of the model. Finally, every transmission is logged, which allows the company to produce, itself, the report of what has left.
On the regulatory front, this subject is gaining in importance with the EU AI Act, whose application is staggered and whose major milestone falls on 2 August 2026. The ability to document precisely which data is submitted to an AI system, and in what form, will become an expected element of governance. Having a log of what leaves, rather than a contractual commitment about what happens once the data is gone, constitutes from this standpoint a more defensible position.
In summary for an evaluation committee
- Sovereign model: addresses the risk linked to the provider (jurisdiction, hosting, usage). A recommended and useful choice.
- Sovereign data: addresses the risk linked to the transit of the real content. Not covered by the choice of model alone.
- The two together: a European model complemented by local, logged anonymisation extends model sovereignty to the data itself.
The question is therefore not “is this model more sovereign than another?”, but “does my processing chain guarantee, and prove, that the real does not leave improperly?”. Choosing a sovereign LLM is a good first step. Data sovereignty, for its part, is decided at the step before.
Going further
This is precisely the role CLEVYA sets for itself: a local, model-agnostic anonymisation layer that sits above the provider you have chosen - a European model included. To understand the overall positioning, see the Why CLEVYA page. On the difference between a contractual commitment and a technical proof, see the article AI sovereignty: contract vs technical proof. And for regulatory preparation, the article EU AI Act 2026: what to prepare.