Local anonymization: how it works before an LLM call

Using a language model on corporate documents raises a question that appears simple: what does the provider actually see? As soon as a text contains names, addresses, customer identifiers, or banking details, sending it as-is to a third-party service amounts to exposing personal data. Local anonymization addresses this problem by transforming the text before any call to the model, so that the model reasons only on data stripped of identifying elements. This article describes how this mechanism works without concealing its limits.

Step 1: detecting sensitive entities, in layers

The first step is to identify, within a text, what identifies a person or an organization. No single method is sufficient. A serious implementation combines several complementary layers, each covering a blind spot of the others:

• Deterministic formats (regular expressions): the IBAN, the social security number, the SIREN, an email address, or a phone number follow known structures. They are detected by rule, without ambiguity, and form the most reliable foundation of detection.
• Named entity recognition (NER): local language-processing models identify the names of people, places, or organizations, including those that no list could have anticipated. These models run on the company’s server, with no external call.
• Company-specific lists: a blocklist (terms that must never be allowed to leave, for example an internal project name) and an allowlist (terms that must never be blocked). This is the most powerful adaptation lever: an element that automatic detection missed once is added to the list and systematically blocked for subsequent transmissions, without retraining.

This point deserves emphasis: detection does not rely on training a proprietary model on the client’s data. It enriches code layers (rules, lists, lexicons) that are calibrated per client almost immediately.

Step 2: replacing with consistent typed tokens

Once an entity is detected, it is replaced by a token, that is, a neutral marker. Two properties of this token are decisive for the quality of the result.

The token is, first, typed: “Sophie Martin” does not become an opaque code but a marker that preserves the nature of the information, for example a token of type “person”, another of type “IBAN”. The model thus knows that it is handling a person or a bank account, which allows it to reason correctly without knowing the real value.

The token is, second, consistent: if “Sophie Martin” appears in several places in the document, or across several documents of the same case, she always receives the same token. This stability preserves the logic of the text. The model understands that it is the same person, and cross-references between documents remain possible on the server side without ever exposing the identity.

Step 3: the mapping table never leaves the server

With each replacement, a table associates the token with the real value. This mapping table is the sensitive point of the whole mechanism: it is what makes it possible to reconstruct meaning. It therefore remains strictly on the company’s server, encrypted. The model, for its part, receives only the transformed text. It has no way to find out who or what lies behind a token, because the reading key is never transmitted to it.

Step 4: local reversibility of the response

The model processes the transformed text and returns a response that naturally contains the same tokens. The final step restores meaning: drawing on the mapping table that remained local, each token is replaced by its real value. The user reads a legible response, with tokens restored to their original values, while the model provider has never seen the identity of the persons or organizations concerned. Reversibility is entirely local; it depends on no external service.

Step 5: the egress log, proof of what was sent out

An anonymization that cannot be verified remains an assertion. This is why every transmission to a model is logged. The log never contains the real text: for each send, it records which sources went out, how many identifiers were replaced with tokens, what was blocked (health, cloud-forbidden data), the timestamp and a request identifier. This egress log allows a security department or a data protection officer to establish, on their own, what left the server, without having to rely on a provider’s word. Transparency becomes a consultable artifact, not a commitment.

The limits: zero risk does not exist

Honesty requires clearly stating the limits of the method, because no automatic detection is perfect. On our internal corpus (206 synthetic French documents written for testing, across multiple business domains), detection reaches a measured recall of 94.2%. On a public French benchmark, within our scope of entity types, this recall stands at around 75%. These figures are never presented as 100%: a residual share of entities may escape detection, and claiming otherwise would be misleading.

Two design principles frame this residual risk. First, fail-closed: in case of doubt, what is not certified safe is not sent, but kept locally or submitted to human review. Security rests on deterministic code and a human safety net, not on the goodwill of the model. Second, certain categories do not fall under anonymization: health data, which constitutes sensitive data within the meaning of Article 9 of the GDPR, is blocked rather than anonymized. Pseudonymization does not make lawful a processing operation that would not otherwise be; for such data, the prudent course is not to send it out at all.

A point of rigor, finally, on vocabulary: in the strict sense of the GDPR, a reversible transformation, such as tokenization that can be re-associated with the original value, constitutes pseudonymization, and not anonymization in the legal sense, which presupposes an irreversibility preventing any re-identification. We use the term “anonymization” in its common, product sense, to designate the fact that the real values do not leave the server; legally, pseudonymized data remains personal data.

Going further

This mechanism constitutes CLEVYA’s sovereignty layer, of which local anonymization is the part measured and proven today. The component that sits in front of your AI calls is described on the API Key Audit page, and the full set of security layers on the Security page. On the distinction between a contractual promise and a technical proof, see AI Sovereignty: contract vs proof; and on what an agent must guarantee beyond confidentiality, what an AI agent needs to be reliable.