Protection des PII dans LLM selon 152-FZ sans perte d'UX

Protection des données personnelles dans les LLM pour la conformité 152-FZ : substitution de jetons avec NestJS

Le développement d’un assistant IA pour le traitement des leads dans une entreprise de construction a révélé un risque critique : chaque message utilisateur contenant des données personnelles (PII) était envoyé directement à l’API Google Gemini. Noms, numéros de téléphone, adresses e-mail et informations sur les entreprises clientes étaient transférés vers des serveurs étrangers — en violation de la loi russe 152-FZ. Ce transfert transfrontalier nécessite une notification à Roskomnadzor ainsi qu’un consentement explicite du sujet concerné, avec des amendes pouvant atteindre 3 millions de roubles.

Solution : remplacer les PII par des jetons avant d’envoyer les données au modèle. Le LLM traite un texte anonymisé mais génère des réponses personnalisées. Les données réelles ne sont restaurées qu’à la dernière étape de sortie.

Principe de substitution de jetons

Le processus comporte quatre étapes :

• Intercepter les messages utilisateurs avant leur arrivée sur l’API.
• Remplacer les PII par des espaces réservés : [USER_NAME], [USER_EMAIL], [USER_COMPANY], [PHONE].
• Envoyer le texte masqué au LLM et recevoir une réponse contenant des jetons.
• Restaurer les données réelles avant d’afficher le résultat à l’utilisateur.

Le modèle voit : « Super, [USER_NAME] ! Je prépare un devis pour [USER_COMPANY] à [USER_EMAIL]. » L’utilisateur reçoit un texte naturel avec ses informations réelles. Le modèle n’interagit jamais avec des données brutes.

Mise en production : NestJS et WebSocket

Le schéma de base est simple, mais le streaming des réponses LLM complique l’exécution. Les jetons arrivent par morceaux via WebSocket, provoquant des artefacts visuels comme des clignotements de [USER_NAME] à l’écran.

Problèmes clés et solutions :

• Découpage des jetons entre morceaux. Si [USER_ se trouve dans un morceau et NAME] dans un autre, la substitution échoue. Résolu par tamponnage : la classe StreamingPiiRestorer (instance par flux) accumule les fragments en cours, vérifie la présence de ], puis émet le jeton complet.
• Bypass du pipeline. Le module de génération d’estimations lisait auparavant les PII directement depuis PostgreSQL. Maintenant, toutes les requêtes LLM passent par un seul point d’entrée.
• Faux positifs avec regex. Des montants et des codes SKU dans les estimations étaient incorrectement identifiés comme INN ou OGRN. Séparation des motifs : INN d’entités légales (10 chiffres), INN individuels (12 chiffres), OGRN (commence par 1 ou 5), chacun validé selon les règles de checksum du FNS.

Architecture de sécurité en cinq couches

Le système utilise des couches complémentaires pour une protection robuste :

Couche 1 : substitution déterministe des PII connues. À partir des profils de dialogue : nom, e-mail, téléphone, entreprise. Précision : 99 %.

Couche 2 : scanner regex pour PII ponctuelles. Détecte e-mails, numéros de téléphone, INN, OGRN, passeports, IP, cartes bancaires. Validation de format appliquée.

Couche 3 : chiffrement dans PostgreSQL. Champs PII chiffrés avec AES-256-GCM. Clé stockée dans les variables d’environnement ; les sauvegardes de base de données restent illisibles.

Couche 4 : journal d’audit HMAC. Logs du texte net + HMAC-SHA256 des données originales (avec clé secrète). Prouve l’absence de fuite sans exposer d’infos sensibles.

Couche 5 : suppression automatique selon politique de conservation. Tâche cron anonymise les PII dans les dialogues datant de plus de 90 jours (par lots de 500, sans verrouillage).

Avantages métier et conformité

Les données restent dans l’infrastructure de l’entreprise. Le LLM conserve le contexte conversationnel sans accès aux PII. En cas d’audit par Roskomnadzor, des preuves cryptographiques sont fournies.

Limites : les noms tiers sans info de contact (ex. « appelle Ivan ») ne sont pas masqués — le NER russe atteint 65–75 % de précision, avec quelques faux positifs. Ces éléments ne constituent pas des PII exploitables selon la 152-FZ.

Les mesures techniques sont renforcées par des actions administratives : consentement utilisateur, notification à Roskomnadzor, et accord de traitement des données (DPA) avec les prestataires.

Points clés

• La substitution de jetons garantit une fuite zéro de PII vers les LLM sans nuire à l’expérience utilisateur.
• Le tamponnage du streaming résout la fragmentation des jetons dans les flux WebSocket.
• Un point d’entrée unique empêche les bypass du pipeline.
• Les journaux HMAC offrent une preuve vérifiable de conformité.
• La politique de conservation automatisée supprime les données conformément aux exigences de la 152-FZ.

— Editorial Team