Conformité au RGPD pour l'IA conversationnelle

En France, la CNIL a reçu 20 150 plaintes en 2025, soit 10 % de plus qu'en 2024, après 17 772 plaintes cette année-là. Elle a aussi traité 5 629 notifications de violation de données personnelles en 2024. Ces chiffres ne décrivent pas un risque juridique abstrait. Ils montrent que la conformité au RGPD exige désormais une organisation capable de filtrer, sécuriser, purger, documenter et défendre chaque traitement, y compris ceux opérés par un LLM ou un agent conversationnel. Le rapport annuel de la CNIL fournit le cadre factuel de cette pression croissante.

Pour un DPO, une DSI ou une direction relation client, la question n'est donc plus seulement de savoir si un chatbot affiche une politique de confidentialité. Il faut pouvoir démontrer quelles données entrent dans le système, où elles circulent, combien de temps elles restent accessibles, quel modèle les traite, quels sous-traitants interviennent et comment une personne peut exercer ses droits. Avec un LLM, un RAG et une mémoire conversationnelle, la conformité devient une propriété de l'architecture, pas un document ajouté après le déploiement.

Pourquoi la conformité au RGPD est devenue un risque opérationnel majeur

La CNIL a prononcé 83 sanctions en 2025, pour un montant cumulé de 486 839 500 €, dont 78 amendes et 27 assorties d'injonctions sous astreinte. Le bilan des sanctions et mesures correctrices de la CNIL en 2025 montre pourquoi le risque dépasse le montant de l'amende. Une injonction sous astreinte impose une remédiation technique vérifiable, parfois dans un délai contraint, sur les cookies, la surveillance des salariés ou la sécurité des données.

La mécanique de contrôle est elle-même structurée. En 2025, la CNIL a mené 323 contrôles et rendu 259 décisions, dont 143 mises en demeure et 83 sanctions, selon son rapport annuel 2025. Pour un projet d'agent IA, cela signifie qu'une conformité seulement déclarative est fragile. Le registre, la minimisation, la gestion des accès et les journaux doivent pouvoir être produits et expliqués sans reconstituer l'historique dans l'urgence.

Règle opérationnelle : une mesure de conformité qui n'a ni propriétaire, ni journal, ni preuve exportable n'est pas encore un contrôle.

Les risques que les projets IA sous-estiment

Un agent conversationnel collecte du langage libre. Une personne peut saisir une information de santé, un numéro de contrat, une plainte nominative ou une donnée concernant un tiers, alors que le parcours métier n'avait prévu aucun champ correspondant. Le modèle peut ensuite transmettre cette information vers un orchestrateur, une base vectorielle, un fournisseur LLM ou un outil CRM.

Trois défauts reviennent souvent dans les revues de conception :

• Registre incomplet. L'organisation décrit le chatbot, mais pas les sous-traitements liés au RAG, aux logs, aux embeddings, à la supervision humaine ou à l'amélioration du modèle.
• Minimisation insuffisante. Le système envoie tout l'historique au LLM alors qu'une intention, un identifiant technique ou un extrait documentaire suffirait.
• Sous-traitance mal maîtrisée. Les clauses contractuelles couvrent le fournisseur principal, mais pas toujours les sous-traitants ultérieurs, les lieux d'hébergement, la conservation des prompts ou la réutilisation éventuelle des données.

Une plateforme d'agents IA peut accélérer le service client, mais elle ne réduit pas automatiquement ces risques. Elle les rend parfois plus rapides et plus difficiles à observer. La solution d'agents IA de Webotit.ai illustre le type d'architecture qu'il faut examiner avec cette grille, en distinguant les parcours, les intégrations, les contrôles et les preuves.

Une lecture prudente des sanctions

Les données publiques disponibles ne permettent pas d'isoler un nombre fiable de décisions CNIL consacrées spécifiquement aux traitements IA et conversationnels, ni de calculer une amende moyenne par motif. Il serait donc trompeur de remplir un tableau avec des chiffres inventés. La bonne pratique consiste à utiliser les décisions publiées comme signaux de contrôle, puis à rapprocher chaque motif de l'architecture réellement déployée.

La CNIL rappelle que les sanctions peuvent atteindre 20 millions d'euros ou 4 % du chiffre d'affaires annuel mondial. Le point décisif, pour un agent IA, reste la capacité à suspendre un flux, isoler une donnée, appliquer une purge et démontrer l'action effectuée.

Ce que le RGPD change vraiment pour les agents IA conversationnels

Un chatbot rule-based classique suit un chemin relativement borné. Il collecte des champs structurés, applique une règle, puis transmet une information définie au CRM. Un agent IA basé sur un LLM reçoit au contraire une entrée libre, construit un contexte, interroge parfois une base documentaire et produit une réponse probabiliste.

Cette différence change le périmètre du traitement. Le RGPD ne s'applique pas seulement à la fenêtre visible du chat. Il concerne aussi les prompts, les réponses, les traces d'orchestration, les documents récupérés, les embeddings, la mémoire longue durée, les outils appelés et les éventuelles données utilisées pour l'évaluation ou le fine-tuning.

Cinq propriétés techniques à traiter dès la conception

La mémorisation involontaire apparaît lorsqu'un agent conserve une conversation au-delà du parcours initial. Une mémoire longue durée peut enregistrer une préférence, un incident client ou une information familiale sans qu'aucune règle métier ne l'ait explicitement demandé. Il faut donc distinguer le contexte temporaire, la mémoire utile au service et les logs nécessaires à la sécurité.

L'inférence pose un autre problème. Un prompt apparemment banal peut permettre au modèle de déduire une situation de santé, une opinion ou une vulnérabilité. L'organisation doit analyser ce que le système produit et infère, pas seulement les champs qu'elle a prévu de collecter.

La base vectorielle n'est pas un espace anonyme par nature. Avec un RAG utilisant Pinecone, par exemple, les chunks et leurs métadonnées peuvent permettre de retrouver un dossier ou de relier plusieurs conversations à une personne. Les embeddings doivent être indexés, protégés et supprimables comme les autres éléments du traitement.

Le fournisseur LLM ajoute une question de maîtrise. Un agent qui envoie les prompts vers une API tierce hébergée hors UE nécessite une analyse des rôles, des garanties contractuelles, des transferts et de la conservation effective. La promesse commerciale de ne pas entraîner un modèle avec les données ne remplace pas la documentation du flux.

Le fine-tuning complique enfin l'effacement. Si des données clients ont influencé un modèle, supprimer la ligne source ne suffit pas nécessairement à démontrer que l'influence a disparu. Une architecture conforme évite d'abord de mélanger les données personnelles avec l'entraînement lorsque le cas d'usage ne le justifie pas.

Un agent IA conforme n'est pas celui qui prétend ne jamais traiter de données personnelles. C'est celui qui sait les détecter, les limiter, les isoler et prouver ce qu'il en fait.

La CNIL souligne en 2025-2026 que l'applicabilité du RGPD aux modèles d'IA dépend notamment des capacités du modèle et de la documentation de l'analyse. Elle recommande aussi d'examiner la mémorisation éventuelle de données personnelles et de placer des filtres fiables dans le système qui encapsule le modèle, comme l'expose sa recommandation sur le développement des systèmes d'intelligence artificielle.

Choisir la bonne base juridique pour un chatbot ou un agent IA

La base juridique se détermine avant le choix du modèle. Elle dépend de la finalité précise, de la relation avec l'utilisateur et des données réellement nécessaires au fonctionnement de l'agent. Un même système peut poursuivre plusieurs finalités. Chacune doit alors être décrite, justifiée et reliée à ses propres flux, règles de conservation et preuves techniques.

Pour un support contractuel, l'exécution du contrat peut couvrir les données indispensables à la réponse. Elle ne couvre pas automatiquement l'analyse de sentiment, la personnalisation commerciale ou la réutilisation des conversations pour entraîner un modèle. Ces usages doivent faire l'objet d'un examen distinct, avec une configuration séparée dans l'orchestrateur et une durée de conservation documentée.

Un arbre de décision utilisable en atelier

Commencez par formuler la finalité en une phrase testable. « Répondre à une question sur un contrat en cours » est exploitable. « Améliorer l'expérience grâce à l'IA » reste trop vague pour guider un registre, une analyse d'impact ou un contrôle de configuration.

• Exécution contractuelle. Cette base convient lorsque le traitement est nécessaire pour fournir le service demandé ou exécuter un contrat. Un agent d'onboarding peut guider un client, si les données envoyées correspondent réellement au parcours prévu.
• Obligation légale. Elle s'applique lorsqu'un texte impose la conservation, la vérification ou la transmission d'informations. Le registre doit citer l'obligation concernée et identifier le flux ou la règle qui y répond, plutôt que d'indiquer seulement « conformité ».
• Intérêts vitaux. Cette base reste exceptionnelle. Elle ne justifie pas un agent généraliste qui traiterait largement des informations sensibles sans nécessité démontrée.
• Mission d'intérêt public. Elle peut concerner une organisation investie d'une mission définie par le droit. Les instructions données à l'agent, ses sources RAG et ses actions doivent rester dans ce périmètre.
• Consentement. Il doit être libre, spécifique, éclairé et retirable. Une case globale couvrant l'assistance, la personnalisation et l'entraînement ne fournit pas une granularité suffisante. Le retrait doit aussi être propagé aux mémoires, historiques et files de réutilisation concernés.
• Intérêt légitime. Il impose une analyse documentée des intérêts poursuivis, de la nécessité du traitement et de la mise en balance avec les droits des personnes. Une analyse de sentiment sur des conversations doit démontrer son utilité, limiter les données traitées et prévoir une opposition effectivement prise en compte.

La CNIL détaille les droits des personnes sur leurs données. Ces droits influencent le choix de la base et l'architecture de l'agent. Une base qui rend l'opposition ou le retrait impraticable crée un risque opérationnel, même si elle paraît commode dans la documentation juridique. Les équipes doivent pouvoir retrouver la décision, les prompts concernés, les sorties produites et les données conservées.

Le cas des données sensibles

Un agent peut recevoir ou inférer des données de santé, d'origine ethnique ou d'opinion politique à partir d'un échange libre. L'article 9 ajoute alors des conditions spécifiques, qui ne se résument pas à sélectionner une base de l'article 6. Le filtrage doit intervenir avant l'envoi au modèle lorsque la donnée n'est pas indispensable. L'équipe doit aussi décider si le parcours peut continuer sans cette information et conserver la justification de ce choix.

La transparence doit correspondre au moment réel de collecte. Les personnes doivent savoir si leurs données peuvent servir à entraîner un modèle ou être mémorisées par lui. Les écrans d'information, les paramètres de mémoire et les journaux d'exécution doivent rester cohérents. Une information affichée uniquement dans la politique générale ne suffit pas si l'agent modifie ensuite le traitement.

Minimisation des données et droits des personnes dans les parcours IA

La minimisation ne consiste pas à demander moins de champs dans l'interface. Elle consiste à empêcher une donnée non nécessaire de traverser les couches de l'agent. Dans une architecture RAG, le risque se situe souvent dans le contexte préparé automatiquement, quand l'orchestrateur injecte trop de documents, trop de métadonnées ou un historique complet dans le prompt.

Réduire la donnée avant qu'elle atteigne le LLM

Un pipeline utile sépare la détection, la transformation et l'autorisation d'envoi. Un filtre de reconnaissance d'entités nommées peut repérer un nom, une adresse, un identifiant de contrat ou une information de santé. Le système remplace ensuite l'entité par un jeton lorsque le modèle n'a pas besoin de sa valeur réelle.

La technique doit rester réversible uniquement là où le métier le justifie. Une réponse de classification peut fonctionner avec un identifiant pseudonymisé. Une action de remboursement, elle, devra retrouver le dossier exact dans un système métier sécurisé, sans transmettre l'ensemble de la fiche client au LLM.

Pour le RAG, chaque chunk devrait porter des métadonnées permettant de filtrer le périmètre avant la recherche. Un agent destiné à un client ne doit pas interroger une base entière puis compter sur le modèle pour ignorer les documents interdits. Le contrôle d'accès doit précéder la génération.

Une solution d'agents IA dédiée à la relation client avec Webotit.ai peut être évaluée selon ces mêmes critères, notamment la séparation des parcours, la supervision et les intégrations. Le choix de l'outil compte moins que la capacité à configurer et vérifier ces garde-fous.

Purger, rectifier et effacer sans angle mort

La CNIL rappelle qu'une durée de conservation doit être déterminée selon la finalité. Elle donne l'exemple d'un service client qui doit supprimer ou anonymiser les tickets anciens, plutôt que conserver tout l'historique sans limite, sauf obligation légale d'archivage. Le guide CNIL sur les durées de conservation précise qu'un non-respect peut relever de l'article 83(5), avec une amende pouvant atteindre 20 000 000 € ou 4 % du chiffre d'affaires annuel mondial.

Dans un agent IA, la purge doit couvrir plusieurs emplacements :

• Conversation active. Définir ce qui reste dans la fenêtre de contexte et supprimer le reste à la fin du parcours.
• Cache et mémoire. Identifier les clés de rattachement et supprimer les souvenirs associés à la personne.
• Vector store. Conserver l'identifiant du document source, les métadonnées personnelles et la date d'expiration pour permettre une suppression ciblée.
• Logs. Séparer les traces de sécurité des logs opérationnels, puis anonymiser ou purger les prompts selon leur finalité.
• Entraînement. Éviter l'usage de données personnelles lorsque la finalité ne l'exige pas. Le machine unlearning peut être étudié, mais il ne doit pas servir d'excuse à une collecte excessive.

Une demande d'accès doit produire un export lisible des conversations et des données associées. Une demande de rectification doit indiquer quels systèmes ont été corrigés. Une demande d'effacement doit générer une preuve de propagation vers le cache, la base vectorielle, les sauvegardes pertinentes et les jeux d'évaluation concernés.

Preuve attendue : un ticket de droit doit montrer la demande, la vérification d'identité, les systèmes interrogés, les actions réalisées, les exceptions retenues et la clôture contrôlée.

Sécuriser les flux et tracer les traitements des agents IA

Un déploiement LLM ajoute plusieurs points de passage. Le prompt quitte l'interface, traverse l'orchestrateur, appelle éventuellement un moteur de recherche, récupère des documents, sollicite une API de modèle puis revient vers le canal client. Chaque étape peut exposer une donnée, modifier un contexte ou produire un log.

L'article 32 impose une sécurité adaptée au risque. Pour un agent, cela se traduit par un chiffrement en transit et au repos, une gestion stricte des secrets, une isolation réseau du vector store et une protection contre les injections de prompt. Une injection réussie peut pousser l'agent à révéler un document récupéré, un message système ou une information appartenant à un autre utilisateur.

Les contrôles à intégrer dans le pipeline

Les clés d'API ne doivent pas apparaître dans le code, les prompts ou les journaux. Un coffre de secrets, une rotation organisée et des droits limités par environnement réduisent le risque de réutilisation abusive. Le modèle ne devrait pas pouvoir appeler directement toutes les fonctions métier. Un orchestrateur doit appliquer une liste d'outils autorisés, des paramètres contrôlés et une validation humaine pour les actions à conséquence.

La journalisation doit servir de preuve sans devenir une nouvelle source de fuite. Un log d'audit horodaté peut conserver l'identifiant de requête, la version du modèle, la politique appliquée, l'outil appelé et le résultat du contrôle. Le contenu intégral du prompt n'est pas toujours nécessaire. Lorsqu'il l'est, son accès doit être séparé de celui des logs de performance.

SaaS, on-premise et sous-traitance

Le SaaS simplifie l'exploitation, mais rend la chaîne de sous-traitance plus importante. Il faut identifier le fournisseur LLM, l'hébergeur, le fournisseur de vector store, les outils de supervision et les sous-traitants ultérieurs. Les clauses RGPD doivent préciser les instructions, la confidentialité, la sécurité, l'assistance pour les droits, la notification des violations, la suppression en fin de service et les audits.

L'on-premise réduit certains flux externes, mais ne supprime pas les obligations. Les équipes doivent toujours sécuriser les modèles, les sauvegardes, les accès administrateurs et les mises à jour. Une architecture locale mal journalisée peut fournir moins de preuves qu'un SaaS correctement gouverné.

La solution d'agents IA pour le back-office de Webotit.ai peut être examinée dans ce cadre, en demandant la cartographie des flux, les mécanismes de traçabilité, les rôles contractuels et les modalités de déploiement. Le fournisseur ne peut pas décider seul de la finalité métier. Le client ne peut pas non plus déléguer entièrement la preuve de conformité à son éditeur.

Répartir les responsabilités entre DPO éditeur et métiers

Le DPO ne peut pas valider un agent à partir d'une simple fiche fonctionnelle. L'éditeur ne peut pas déterminer seul la base juridique, la durée de conservation ou la finalité d'une analyse de sentiment. La direction métier, enfin, connaît le parcours et les utilisateurs, mais ne voit pas toujours les traitements secondaires créés par la mémoire, les logs ou les intégrations.

La qualification entre responsable de traitement, sous-traitant et responsable conjoint doit suivre la réalité des décisions. Celui qui détermine pourquoi les données sont traitées et quelles opérations sont nécessaires porte une responsabilité centrale. Le contrat doit ensuite refléter cette répartition, sans se limiter à une formule générale.

Une matrice RACI qui fonctionne

Cette matrice doit vivre dans le projet, pas dans une annexe oubliée. Le socle de connaissance IA pour le service client doit notamment avoir un propriétaire métier, une règle de validation documentaire et une procédure de retrait lorsqu'un contenu devient obsolète ou inapproprié.

Checklist pratique pour un déploiement IA conforme au RGPD

Une conformité démontrable repose sur trois étapes. Pour chaque contrôle, conservez un livrable, un responsable et une date de réexamen. L'objectif est de pouvoir reconstituer les décisions techniques et organisationnelles présentées lors d'un contrôle CNIL.

Avant le déploiement

• Cartographier les flux. Le registre précise le canal, le LLM, le RAG, la mémoire, les prompts, les logs, les intégrations et chaque sous-traitant.
• Valider la finalité et la base juridique. Séparez le support, la personnalisation, la mesure et l'entraînement. Cette distinction doit apparaître dans la documentation et la configuration.
• Évaluer le risque. Le DPO et les métiers déterminent si une AIPD est requise, puis associent chaque risque à une mesure et à une preuve de test.
• Contractualiser. Vérifiez les DPA, les transferts, les sous-traitants ultérieurs, les conditions d'accès aux données et les engagements de suppression.
• Préparer les droits. Décrivez comment retrouver, corriger et supprimer une donnée présente dans une conversation, un index RAG, une mémoire ou un export.

À la mise en production

• Activer les filtres PII. Testez les prompts libres, les documents RAG et les appels vers les outils. Conservez les résultats, les exceptions et les règles de blocage.
• Configurer la conservation. Automatisez et testez la purge des conversations, caches, embeddings et logs. Chaque durée doit correspondre à une finalité documentée.
• Contrôler les traceurs. Distinguez le cookie strictement nécessaire des finalités de mesure, personnalisation ou reprise de conversation, conformément aux conseils de la CNIL sur les chatbots.
• Tracer l'inférence. Conservez une preuve proportionnée de la requête, de la version du modèle, du prompt système, de la politique appliquée et de l'action effectuée.

En suivi continu

• Auditer les accès. Revoyez les droits sur le vector store, les consoles et les exports.
• Tester les dérives. Tout changement de modèle, de prompt système ou de source documentaire déclenche une validation.
• Exécuter les droits. Testez les demandes d'accès, de rectification et de suppression de bout en bout.
• Répéter l'exercice de crise. Identifiez les données exposées, les personnes concernées, les actions prises et les notifications nécessaires.

Pour passer de la documentation à l'exploitation, Webotit.ai propose des agents conversationnels, callbots, mailbots et agents IA en SaaS ou on-premise. Les fonctions de traçabilité, supervision humaine, contrôles métiers et intégrations sécurisées peuvent être examinées sur les solutions de chatbot pour la relation client. Visitez Webotit.ai pour demander un diagnostic de 45 minutes et prioriser une architecture RGPD vérifiable.