When a company evaluates an AI solution, the question of confidentiality comes up quickly. And the answer is almost always the same: a contractual non-training commitment, combined with European hosting and encryption. This is useful. But it does not answer the real question a CISO is asking: does my data leave my perimeter, yes or no?
GDPR-compliant does not mean “the data stays put”
This is the most widespread confusion. A solution can be perfectly GDPR-compliant and send your real data to a third-party AI provider. Compliance governs how the data is processed (legal basis, retention, the rights of individuals). It does not guarantee that the data stays with you.
A non-training commitment follows the same logic: it is a promise about the use the provider makes of your data once it has received it. The important word is “received”. The data has left your server. You can neither verify it nor undo it.
The right question is not "does the provider commit to behaving well?" but "did the real data leave my server?". The first depends on trust. The second can be proven.
The local anonymization approach
There is another way: making AI work without ever sending it the real data. Concretely, before any call to a model (cloud or local), sensitive identifiers - names, addresses, IBANs, social security numbers, customer identifiers - are detected and replaced locally with codes. The model receives a text where “Sophie Martin” has become a code, “FR76 1234…” another. It reasons on the codes. The answer comes back, and it is reconstructed locally with the real values.
The model never saw who was concerned. And above all: every transmission is logged. You produce the report of what left yourself, to show to your DPO - without having to take anyone’s word for it.
This mechanism has its limits, and we must be honest: no automatic detection is 100% perfect. That is why a sound implementation combines several layers (known formats such as the IBAN or the social security number, entity recognition, company-specific lists) and adopts a fail-closed principle: when in doubt, nothing is allowed out, it is kept locally or referred to a human. Security holds through deterministic code and a human safety net, not through the goodwill of the model.
Contract or proof: a table to decide
- Contractual commitment: the data leaves, a document governs its use, you trust, you cannot verify.
- Technical proof: the real data does not leave, the model only sees codes, every transmission is traced, you produce the report yourself.
The two are not mutually exclusive - you can perfectly well have a solid contract and local anonymization. But if you had to keep only one, which one truly reassures a regulator or a client that forbids you from exposing its data? The one that can be proven.
Going further
This is precisely the philosophy of CLEVYA. You can see the detail of the security layers on the Security page, how the component that sits in front of your AI calls works on the API Key Audit page, and the compliance reading on the GDPR & sovereignty page.