Le problème de la cartographie des jetons
Les organisations utilisant l'IA pour des flux de travail en contact avec les clients font face à un défi technique spécifique avec l'anonymisation : le flux de travail complet nécessite que les entrées anonymisées produisent des réponses pouvant être désanonymisées pour l'agent humain.
Le flux de travail sans cartographie des jetons : la plainte du client contenant "Maria Schmidt" est anonymisée en "[CUSTOMER_1]" avant le traitement par l'IA. Claude traite la plainte anonymisée et rédige une réponse : "Cher [CUSTOMER_1], nous nous excusons pour le retard de votre commande." Le gestionnaire de réclamations doit remplacer manuellement "[CUSTOMER_1]" par "Maria Schmidt" avant d'envoyer. Avec 200 interactions clients par jour, le remplacement manuel des jetons consomme un temps considérable pour l'agent — suffisamment pour annuler le bénéfice de productivité de l'assistance IA.
Le flux de travail avec cartographie des jetons persistants de session : la même anonymisation produit un tableau de correspondance conservé dans la session en cours. "[CUSTOMER_1]" → "Maria Schmidt." Lorsque la réponse préliminaire de Claude est affichée au gestionnaire de réclamations, la couche d'auto-décryptage applique la cartographie de session et l'agent voit "Cher Maria Schmidt" — le vrai nom, déjà restauré. L'agent examine et envoie. Pas de remplacement manuel des jetons. La protection GDPR a fonctionné silencieusement et complètement.
Cohérence de session
La cartographie des jetons doit être cohérente au sein d'une session. Si le nom du même client est anonymisé dans deux parties différentes de la même conversation — une fois dans la plainte initiale et une fois dans un suivi — il doit correspondre au même jeton. "[CUSTOMER_1]" doit toujours faire référence à la même personne au sein d'une session ; le raisonnement de Claude sur la conversation dépend d'un suivi d'identité cohérent.
Sans cohérence au niveau de la session, les réponses de Claude peuvent confondre plusieurs clients (si "[CUSTOMER_1]" dans le premier message et "[CUSTOMER_1]" dans le troisième message font référence à des personnes différentes), produisant des réponses incohérentes que l'agent ne peut pas utiliser.
L'article 4(5) du GDPR reconnaît la pseudonymisation comme une technique de traitement qui réduit le risque de conformité. Les lignes directrices de l'EDPB de 2022 sur la pseudonymisation exigent que la clé de pseudonymisation (dans ce cas, le tableau de cartographie des jetons) soit conservée séparément des données pseudonymisées. La cartographie des jetons au niveau de la session satisfait à cette exigence : le tableau de correspondance est maintenu dans la session du navigateur, et non transmis avec les données anonymisées aux serveurs de Claude.
Le cas d'utilisation des réclamations d'assurance
Le système de traitement des réclamations d'une compagnie d'assurance allemande alimenté par l'IA traite les e-mails de plaintes des clients. Les noms des clients, les numéros de police et les montants des réclamations sont anonymisés avant que Claude ne traite les e-mails. Claude rédige des réponses en utilisant les jetons anonymisés. La couche d'auto-décryptage dans l'extension Chrome restaure les informations client originales dans le brouillon de Claude avant qu'il ne soit affiché au gestionnaire de réclamations. Le gestionnaire examine le brouillon, effectue les ajustements nécessaires et envoie la réponse finale avec les vrais noms des clients.
Le calcul de conformité au GDPR : les données transmises aux serveurs de Claude aux États-Unis contiennent "[CUSTOMER_1]", "[POLICY_2024-08847]", et "[AMOUNT_1]" — pas de données personnelles telles que définies par le GDPR. Le vrai nom et le numéro de police du client restent en Allemagne sur le navigateur du gestionnaire de réclamations. La question du transfert de données de l'article 46 du GDPR — quelles protections s'appliquent aux transferts de données personnelles vers les États-Unis ? — ne se pose pas car les données personnelles n'ont pas été transférées.
Sources :