Construire une IA de support client conforme au RGPD : Suppression des PII ET des identifiants personnalisés avant l'envoi aux fournisseurs d'IA
Votre équipe de support client utilise un assistant IA pour rédiger des réponses, résumer l'historique des tickets et suggérer des solutions. L'IA est bonne. La productivité est en hausse. Puis votre DPO examine la mise en œuvre.
Les messages des clients collés dans l'interface IA contiennent :
- Nom du client : "Bonjour, je suis Sarah Johnson et ma commande..."
- Adresse e-mail : "Veuillez m'envoyer un e-mail à sarah.j@gmail.com"
- Identifiant de commande : "ORD-4521893 n'est pas encore arrivé"
Le nom et l'e-mail sont des données personnelles. L'identifiant de commande est également une donnée personnelle — il est lié à Sarah Johnson dans votre système de gestion des commandes, que le fournisseur d'IA peut croiser s'il traite des données pour plusieurs clients, ou qui crée un risque de ré-identification si les données d'entraînement de l'IA sont jamais exposées.
Vous envoyez des données personnelles à un fournisseur d'IA externe sans base légale valide ou protections appropriées. C'est une violation du RGPD.
Pourquoi les identifiants de commande sont des données personnelles
La définition des données personnelles par le RGPD est délibérément large : "toute information se rapportant à une personne physique identifiée ou identifiable." Une personne est identifiable si elle peut être identifiée "directement ou indirectement, en particulier par référence à un identifiant."
Un identifiant de commande (ORD-4521893) est un identifiant indirect. À lui seul, il n'identifie pas Sarah Johnson. Mais combiné avec votre base de données de gestion des commandes — à laquelle le fournisseur d'IA peut ou non avoir accès — il l'identifie avec certitude.
Le concept de pseudonymisation de l'article 4(5) du RGPD s'applique ici : les identifiants de commande sont des pseudonymes qui nécessitent des informations supplémentaires (la base de données de commande) pour la ré-identification. Lorsque l'organisation contrôlant la clé de pseudonyme (vous, le responsable du traitement) envoie ce pseudonyme à un fournisseur d'IA externe, vous partagez des données pseudonymes qui peuvent être ré-identifiables.
L'analyse juridique : les données pseudonymes envoyées à un tiers qui n'a pas la clé sont protégées contre la ré-identification par ce tiers — mais vous avez tout de même partagé des données personnelles nécessitant une base légale et un accord de DPA.
L'écart d'anonymisation standard
Les équipes de support mettant en œuvre la conformité au RGPD pour leurs outils d'IA déploient souvent une détection PII standard :
Ce qui est supprimé :
- Noms des clients (détection d'entité PERSON) ✓
- Adresses e-mail (détection d'EMAIL_ADDRESS) ✓
- Numéros de téléphone (détection de PHONE_NUMBER) ✓
- Numéros de carte de crédit (détection de CREDIT_CARD) ✓
Ce qui reste :
- Identifiants de commande (format ORD-XXXXXXX — pas dans la bibliothèque d'entités standard) ✗
- Numéros de compte (format ACC-XXXXXXXX-XX) ✗
- Numéros de référence de ticket (format TKT-XXXXX) ✗
- Identifiants d'utilisateur internes (UUID ou format personnalisé) ✗
- Identifiants d'abonnement (format SUB-XXXXXXXX) ✗
Le message anonymisé ressemble à : "Bonjour, je suis [PERSON_1] et ma commande ORD-4521893 n'est pas encore arrivée. Veuillez m'envoyer un e-mail à [EMAIL_1]."
L'identifiant de commande reste. Quiconque sait que c'est ORD-4521893 (ce qui est littéralement tout le monde dans votre organisation ayant accès au CRM) peut immédiatement identifier le client auquel ce message se réfère. L'anonymisation est incomplète.
Extension Chrome : Détection d'identifiant personnalisé en temps réel
Pour les agents de support utilisant des outils d'IA basés sur le web (Claude, ChatGPT, Gemini) directement dans leur navigateur, l'extension Chrome fournit une anonymisation en temps réel au point d'entrée :
- L'agent de support copie le message du client dans le presse-papiers ou le tape dans l'interface IA
- L'extension Chrome détecte que la destination est une plateforme IA
- Les PII standards sont automatiquement détectées et remplacées
- Les modèles d'entités personnalisées (identifiants de commande, numéros de compte dans votre format spécifique) sont détectés à l'aide de la configuration d'équipe sauvegardée
- L'agent voit le message anonymisé dans l'interface IA — jamais les PII d'origine
La configuration d'entité personnalisée (modèle ORD-XXXXXXX) est définie une fois par le DPO ou l'équipe de conformité et appliquée à tous les membres de l'équipe utilisant l'extension. Les agents individuels n'ont pas besoin de connaître les détails techniques de ce qui est anonymisé — ils collent le message, il est propre.
Serveur MCP : Détection au niveau API pour outils intégrés
Pour les plateformes de support client utilisant l'IA via des intégrations API (Intercom avec réponses IA, Zendesk avec rédaction IA), le serveur MCP fournit une anonymisation middleware :
Flux d'intégration :
- Message client reçu dans la plateforme de support
- Avant de passer au modèle IA : message routé via le point de terminaison d'anonymisation MCP
- Anonymisation appliquée (entités standard + personnalisées)
- Message anonymisé envoyé au modèle IA
- Réponse IA générée (pas d'exposition de PII)
- Réponse retournée à la plateforme de support, l'agent examine et édite
Cette intégration est transparente pour les agents de support — le flux de travail reste inchangé. L'anonymisation se produit au niveau de l'API, ne nécessitant aucune action de l'agent.
Configuration du connecteur : Définissez les entités personnalisées une fois dans la configuration MCP. Tous les appels API via le MCP appliquent automatiquement la détection complète des entités, y compris les modèles personnalisés.
Liste de contrôle de mise en œuvre du DPO
Pour le DPO examinant la mise en œuvre de l'assistance client assistée par IA :
1. Inventaire de toutes les données circulant vers l'IA :
- Collage/entrée directe (outils IA basés sur le navigateur)
- Appels API (IA intégrée dans la plateforme de support)
- Pièces jointes (si les agents téléchargent des captures d'écran ou des documents)
2. Identifier tous les types d'identifiants dans les messages des clients : PII standard : noms, e-mails, téléphones (couverts par la détection par défaut) Identifiants personnalisés : identifiants de commande, numéros de compte, numéros de ticket (nécessitent une configuration personnalisée)
3. Configurer des modèles d'entités personnalisées : Pour chaque format d'identifiant personnalisé : définir le modèle, tester contre des messages d'exemple, sauvegarder dans le préréglage d'équipe
4. Mettre en œuvre l'anonymisation aux niveaux appropriés : IA basée sur le navigateur : extension Chrome avec préréglage d'équipe IA intégrée par API : serveur MCP ou prétraitement au niveau API
5. Documenter pour ROPA : Enregistrer que le traitement de l'IA de support client utilise une anonymisation PII automatisée, y compris quels identifiants personnalisés sont détectés. C'est la documentation des mesures de protection techniques.
6. Valider avec des scénarios de test : Envoyer des messages de test contenant tous les types d'identifiants à travers l'anonymisation mise en œuvre. Vérifier que tous les identifiants sont supprimés avant d'atteindre le modèle IA.
Exemple du monde réel : Support client SaaS
L'équipe de support client d'une entreprise SaaS utilise Claude (via leur plateforme IA interne) pour rédiger des réponses de support. Les messages des clients incluent :
- Noms et e-mails des clients
- Identifiants de commande (format ORD-XXXXXXX)
- Identifiants d'abonnement (format SUB-XXXXXXXX)
- Noms de drapeaux de fonctionnalités (contiennent parfois des identifiants clients internes)
Avant l'examen du RGPD : Tout le contenu des messages envoyé directement au modèle IA, y compris les identifiants de commande et d'abonnement.
Après la mise en œuvre de la détection d'entités personnalisées :
- Modèles ORD-XXXXXXX et SUB-XXXXXXXX configurés en tant qu'entités personnalisées
- Extension Chrome déployée à l'équipe de support avec préréglage partagé
- DPO vérifié : les messages de test à travers le système montrent que tous les identifiants ont été supprimés
Changement de flux de travail de support : Zéro. Les agents collent les messages comme avant. L'anonymisation est invisible pour eux. Le DPO a la documentation de la mesure de protection technique.
Conclusion
Une IA de support client conforme au RGPD nécessite plus que la suppression des noms et des e-mails. Les identifiants de commande, les numéros de compte et les références de ticket sont des données personnelles que les outils PII standards négligent. L'écart de conformité entre "nous anonymisons les PII avant l'IA" et "nous anonymisons réellement tous les identifiants" est comblé par la configuration d'entités personnalisées.
La solution n'est pas complexe : définissez les formats d'identifiant de votre organisation, testez contre des messages d'exemple, déployez à l'équipe. Le DPO peut configurer cela en un après-midi. Le bénéfice continu de conformité — toutes les PII clients supprimées avant le traitement externe par l'IA — est permanent.
Sources :