PII Protection : anonymiser les données sensibles avant l'envoi au LLM

Vos utilisateurs écrivent des prompts qui contiennent des noms, des emails, des IBAN, des numéros de sécurité sociale, des références internes. Chaque requête envoyée à OpenAI, Mistral ou Gemini devient une fuite potentielle. Voici pourquoi automatiser l'anonymisation change radicalement votre exposition juridique — et comment l'activer en une ligne sans toucher à votre code applicatif.

Le vrai problème : ce que voient les providers

OpenAI, Anthropic, Google et les autres affirment ne pas utiliser les données API pour entraîner leurs modèles. C'est exact, dans la plupart des cas. Mais ce n'est pas ce qui pose problème :

• Les prompts sont conservés 30 jours côté provider pour la modération et le debug
• Ils sont accessibles à leurs équipes Trust & Safety en cas d'incident
• Ils transitent par des serveurs hors-UE (US, Singapour, Inde)
• Ils sont sous juridiction CLOUD Act américaine pour les providers US

Pour une app B2C grand public, c'est gérable. Pour les métiers qui traitent des données clients sensibles — juridique, médical, RH, finance, conseil — c'est un problème de conformité, de responsabilité, et de confiance avec vos clients.

L'idée : ce que le LLM voit n'a pas besoin d'être nominatif

Quand vous demandez à un LLM "résume ce contrat de Jean Dupont", il a besoin de savoir qu'il y a un nom de personne, mais pas qui c'est. La structure du raisonnement reste identique si on remplace "Jean Dupont" par "[PERSON_1]". Et après la réponse, on remet "Jean Dupont" à la place du placeholder pour l'utilisateur final.

# Prompt original (côté utilisateur)
"Analyse le contrat de Jean Dupont, IBAN FR76 3000 4001 2345..."

# Ce que voit le LLM (anonymisé en transit)
"Analyse le contrat de [PERSON_1], IBAN [IBAN_1]..."

# Réponse du LLM
"Le contrat de [PERSON_1] stipule que..."

# Réponse rendue à l'utilisateur (placeholders restaurés)
"Le contrat de Jean Dupont stipule que..."

Le résultat : le provider LLM ne voit jamais les données réelles. Vos logs côté provider ne contiennent que des placeholders sans valeur. L'expérience utilisateur reste rigoureusement identique.

Ce qui est anonymisé par défaut

Routtx détecte automatiquement les catégories de données sensibles les plus courantes en France et en Europe :

Cette couverture par défaut est suffisante pour 80% des cas. Pour les 20% restants — données métier, identifiants internes, références clients — Routtx vous laisse définir vos propres règles.

Vos propres règles : la vraie différence

Chaque secteur a ses identifiants spécifiques. Un avocat manipule des numéros de dossier (CASE-847291), un médecin des numéros de patient (PT-2024-58432), une banque des références opérations (OP-FR-...), une RH des matricules salariés (EMP-4821). Ces formats ne sont jamais inclus par défaut dans aucune solution générique — c'est trop spécifique à votre métier.

Sur Routtx, vous définissez vos règles depuis l'interface dashboard, sans écrire la moindre ligne de code :

1. Collez un texte d'exemple contenant le format à anonymiser
2. Surlignez le mot ou identifiant à cacher
3. Choisissez le mode :
   • "Mot exact" : cache uniquement cette valeur précise (ex : un nom de personne spécifique)
   • "Patterns similaires" : cache toutes les valeurs ayant la même structure (ex : CASE-###### attrape tous les numéros de dossier qui suivent ce format)
4. Donnez un nom et une catégorie à la règle (ex : "Numéro de dossier" / CASE_NUMBER)
5. Activez — la règle s'applique immédiatement à toutes vos requêtes

Aperçu en temps réel sur votre échantillon avant de sauvegarder : vous voyez exactement ce qui sera masqué et ce qui ne le sera pas. Pas de surprise en production.

Activation en une ligne

Aucun changement structurel à faire dans votre code. Vous ajoutez un header HTTP à vos appels et c'est terminé :

headers = {
    "Authorization": "Bearer sk-gw-...",
    "X-LLM-Gateway-Redact": "true",  # <-- c'est tout
}

Ou bien activez l'option par défaut sur tout votre compte depuis votre page Compte — toutes vos requêtes sont anonymisées sans avoir à modifier les appels existants. Vous gardez la possibilité d'override par requête (X-LLM-Gateway-Redact: false) pour les cas où vous avez besoin de l'identité réelle.

En réponse, le gateway vous indique combien de champs ont été masqués et leurs catégories — utile pour vos audits et votre tableau de bord conformité :

X-LLM-Gateway-Redacted: 7
X-LLM-Gateway-Redacted-Fields: [
    {"category": "PERSON", "placeholder": "[PERSON_1]", "masked": "Jea***"},
    {"category": "IBAN", "placeholder": "[IBAN_1]", "masked": "FR7***"},
    ...
]

La valeur business : 4 bénéfices mesurables

1. Conformité RGPD démontrable

L'article 5.1.c du RGPD exige la minimisation des données traitées. Anonymiser avant transmission à un sous-traitant LLM est exactement ce que recommandent la CNIL et l'EDPB. En cas de contrôle, vous pouvez prouver que les données sensibles ne quittent jamais l'UE en clair.

2. Secret professionnel respecté

Pour les avocats (article 66-5 loi 71-1130), médecins (L.1110-4 CSP), notaires, experts-comptables, journalistes : le secret est absolu et son violation est pénalement sanctionnée (article 226-13 Code pénal — 1 an d'emprisonnement, 15 000 €). Anonymiser permet d'utiliser un LLM tout en respectant l'obligation déontologique.

3. Réduction du risque en cas de fuite provider

Si OpenAI subit une fuite (déjà arrivé en mars 2023, accessibilité accidentelle des historiques de chat), vos logs ne contiennent que des placeholders. La gravité passe de "violation RGPD majeure avec notification CNIL sous 72h" à "incident sans portée pour vos clients".

4. Confiance client

Pouvoir afficher dans vos CGV et votre politique de confidentialité que "les données personnelles ne sont jamais transmises en clair à nos partenaires d'IA" est un argument commercial fort, en particulier pour vendre à des clients européens, des services publics, ou des entreprises sous compliance ISO 27001 / SOC 2.

Limites à connaître

• Le LLM ne peut pas raisonner sur l'identité. Si vous demandez "Jean Dupont est-il cité 3 fois dans ce document ?", le LLM voit "[PERSON_1]" partout — il sait qu'il s'agit du même placeholder, mais il ne peut pas associer "Jean" à "Jean Dupont" si vous lui posez ensuite la question avec le prénom seul. Pour ces cas spécifiques, vous désactivez l'anonymisation par requête.
• Pas de protection contre le vol côté client. Si l'utilisateur final voit la donnée en clair (puisqu'elle est restaurée pour lui), un employé malveillant peut toujours faire un screenshot. PII Protection sécurise le pipeline LLM, pas le poste utilisateur.
• Les noms très courts ou rares peuvent demander un ajustement via une règle custom — c'est précisément à quoi sert le système de patterns personnalisés.

En résumé

PII Protection sur Routtx, ce n'est pas juste de l'anonymisation — c'est une posture juridique qui transforme votre intégration LLM d'un risque RGPD à un atout commercial. Activation en 5 minutes, règles personnalisables sans code, audit traçable des champs masqués sur chaque requête.

← Retour au blog