Comment l'anonymisation des données personnelles affecte les agents LLM : l'expérience Hivetrace Dataclean

Nettoyer les données personnelles avant de les transmettre à un agent LLM paraît être une mesure de sécurité évidente, mais son coût n'est pas toujours clair. Dans un article publié sur Habr AI, les auteurs ont mesuré l'effet sur un agent bancaire lorsque celui-ci reçoit des masques ou des pseudonymes à la place des noms réels et d'autres identifiants.

Où naît le conflit

Les agents LLM traitent de plus en plus de scénarios utilisateurs où les données personnelles sont incontournables : requêtes bancaires, support, assurance, documents, historique des opérations. À ce stade, l'équipe doit toujours arbitrer entre deux risques. Le premier : transmettre les données sensibles telles quelles au modèle et s'exposer à des questions de confidentialité, de conformité et de sécurité interne. Le second : nettoyer l'entrée, au prix d'une partie du contexte dont l'agent a besoin pour construire sa réponse, relier les entités entre elles et agir avec précision.

«

Dans quelle mesure l'agent se dégrade-t-il s'il voit "PERSON_1" ou "XXXXXXXX" au lieu de "Ivanov Ivan" ? »

En pratique, il ne s'agit pas d'un débat académique mais d'un problème d'ingénierie. Si le système ne comprend plus qu'un même client apparaît à plusieurs endroits de la requête, ce n'est pas seulement la qualité du texte qui en pâtit, mais aussi la logique métier : routage du dossier, rapprochement des coordonnées bancaires, interprétation des statuts, vérification de l'enchaînement des étapes. L'enjeu n'est donc pas une thèse générale du type « l'anonymisation est utile » ou « l'anonymisation est gênante », mais une réponse mesurable pour une classe d'agents donnée et une méthode de nettoyage précise.

Comment l'hypothèse a été testée

Les auteurs ont déployé un agent bancaire minimaliste auquel ils ont connecté Hivetrace Dataclean. Ils lui ont ensuite soumis 102 requêtes synthétiques dans trois variantes d'entrée : sans modification, avec masquage et avec pseudonymes.

Ce protocole a l'avantage d'éliminer le bruit des véritables historiques utilisateurs et d'offrir une comparaison contrôlée. Dans chaque cas, l'agent résout la même tâche, mais voit les identifiants, les noms et les autres attributs personnels sous une forme différente.

La méthode d'évaluation compte aussi. Les auteurs ont utilisé DeepEval en mode LLM-as-a-judge : plutôt que de comparer des impressions subjectives sur quelques réponses, ils ont tenté de formaliser la qualité via un circuit de vérification unique. Pour une étude appliquée rapide, c'est un choix raisonnable : il ne transforme pas les conclusions en « vérité absolue », mais permet de repérer où la dégradation saute aux yeux et où l'agent reste utile même après le nettoyage des champs sensibles.

Trois modes de données

L'expérience ne vise pas simplement à vérifier si l'agent « fonctionne ou non » après anonymisation, mais à comparer différents niveaux de perte de contexte. C'est particulièrement important pour les systèmes LLM, qui s'appuient non seulement sur le sens des mots, mais aussi sur des liens stables entre entités au sein d'un même dialogue ou document. Masquage complet et pseudonymisation ne se ressemblent pour le modèle qu'en apparence : dans une tâche réelle, ce sont deux signaux distincts.

• Données brutes : le scénario de référence, sans altération.
• Masque du type XXXXXXXX : confidentialité maximale, sémantique minimale.
• Pseudonymes du type PERSON_1 : ils cachent l'identité mais préservent les liens.
• 102 requêtes synthétiques par mode : de quoi garantir une comparaison honnête.

Ce type de test débouche rarement sur une interdiction ou une autorisation universelle, mais plutôt sur une cartographie des compromis. Si l'agent n'a besoin que de l'intention générale de l'utilisateur, un masquage strict peut s'avérer acceptable. Si sa logique dépend en revanche de la répétition d'un même objet dans plusieurs fragments, les pseudonymes constituent souvent l'option la plus pragmatique. C'est pourquoi ces vérifications sont particulièrement utiles avant de déployer des agents dans la banque, la fintech, la santé ou tout processus où une erreur sur des données personnelles coûte vite cher.

Ce que cela signifie

Principal enseignement de l'article : la question de l'anonymisation pour les agents LLM ne peut pas se trancher à l'intuition. Avant la mise en production, il faut mesurer spécifiquement l'effet d'une méthode de nettoyage donnée sur un scénario donné : compréhension de la requête, préservation des liens entre entités et qualité finale de la réponse. Pour les équipes qui construisent des agents d'IA dans des domaines sensibles, ce n'est plus une option, mais un élément de base de l'architecture et du dispositif de test.