Agents IA et RGPD : les questions à régler avant le déploiement

TL;DR (Quick Summary)

Le point décisif se joue sur le cadre de contrôle, pas sur le choix du modèle. Décidez ce que l'agent peut faire et quelles données il atteint. Fixez quand un humain reprend la main et comment le prouver dans la durée.

• Cadrer ce que l'agent a le droit de faire : périmètre, finalité et interdits écrits avant de comparer des outils.
• Cartographier les données vraiment atteignables : l'accès réel compte plus que la liste des systèmes branchés.
• Décider où une revue humaine reste obligatoire : des seuils de reprise et un responsable nommé pour chaque sortie.
• Fixer accès, journalisation et revue périodique : droits détaillés, journaux exploitables, cadence de contrôle définie.
• Tenir un dossier de gouvernance : une trace écrite et signée qui rend le programme défendable en interne.
• Traiter les exceptions avant l'incident : blocage, escalade et revue terrain décidés à l'avance.
• Takeaway: Un agent branché aux systèmes sans règles d'accès, sans journaux exploitables et sans dossier de référence dérive vite. Verrouillez les points de décision avant le branchement, pas après.

La conformité RGPD d'un agent IA tient à ce que vous l'autorisez à faire et à atteindre. Le modèle choisi compte moins. Ce cadrage concerne les équipes opérations, IT et conformité qui préparent un déploiement sur des données clients, RH, finance ou santé.

Les six points suivants décrivent le travail à mener avant la mise en production. Ils vont du périmètre de l'agent à la gestion des exceptions.

Cadrer ce que l'agent IA a le droit de faire avant de parler d'outils

Avant de comparer des modèles ou des interfaces, écrivez ce que l'agent est autorisé à faire. Précisez aussi ce qu'il peut seulement préparer et ce qui lui est interdit. Bornez son périmètre à l'avance : cas d'usage autorisés, actions possibles, résultats exclus.

Classez chaque cas d'usage dans une catégorie :

• Préparer : l'agent synthétise un dossier, propose une réponse ou rédige un brouillon.
• Proposer : l'agent recommande une action à un humain, avec le contexte utile et la source.
• Exécuter : l'agent déclenche une action dans un système, sur des scénarios bornés et contrôlés.

Listez ensuite les interdits en situations concrètes :

• ne jamais modifier des coordonnées bancaires
• n'envoyer aucune communication externe sans validation
• ne pas traiter seul un dossier comportant des données de santé
• ne pas réutiliser pour un autre usage une donnée atteinte via un connecteur support

Rattachez la finalité à l'objectif métier, pas à la connexion technique. Un accès donné pour répondre au support n'autorise pas à réutiliser la donnée ailleurs. Scorer un client, enrichir une base marketing ou préparer une décision RH sont des usages distincts.

Ouvrir un nouveau cas d'usage n'est pas une case à cocher. Passez par une mini-revue : finalité, données nécessaires, type de sortie, destinataire, niveau de risque, validation des responsables.

L'exemple de la santé montre pourquoi l'accès externe mérite une revue renforcée. Dans une organisation de soins, un outil de relation patient réunit des échanges, des documents joints et des informations administratives. Des éléments sensibles se glissent parfois dans des notes libres.

Par exemple, imaginons une note où un conseiller a mentionné l'arrêt de travail d'un patient et sa situation familiale. Ce champ, prévu pour un usage interne, devient lisible par l'agent dès qu'il ouvre la fiche. Un élément clinique ou social se retrouve alors exposé à un traitement externe non prévu.

Les données de santé sont des données sensibles au sens du RGPD. Leur traitement est en principe interdit, sauf exceptions comme le consentement explicite ou la prise en charge médicale. Connecter un agent à un CRM pour la santé, comme celui de Bitrix24, ne prouve pas la conformité pour autant.

Ce qui compte reste ce que l'agent peut lire, dans quels cas et avec quels contrôles. Il faut aussi savoir qui valide l'usage quand un dossier peut contenir des données sensibles.

Liste de contrôle RGPD pour déployer un agent IA

Saisissez votre adresse e-mail pour recevoir un guide complet, étape par étape

Je confirme d'avoir lu et compris la Politique de confidentialité de Bitrix24

Cartographier les données réellement atteignables, pas seulement les systèmes connectés

Ce qu'un agent peut atteindre dépasse la liste des systèmes officiellement branchés. Dire « l'agent est connecté au CRM et au helpdesk » ne suffit pas. Il faut tracer les chemins réels d'accès aux données.

Cartographiez ces chemins réels :

• prompts saisis par les utilisateurs
• pièces jointes déposées dans la conversation
• historique des échanges repris par défaut
• API appelées par l'agent
• recherches transverses dans plusieurs bases
• outils tiers déclenchés par l'agent

Un système « non connecté » reste atteignable si un utilisateur colle son contenu dans le chat. À l'inverse, un système connecté peut être moins risqué si l'agent n'accède qu'à un sous-ensemble filtré. Plus un agent agit seul et garde en mémoire les échanges, plus la donnée circule hors de vue.

Classez chaque source selon quatre angles : sensibilité, volumétrie, fréquence d'accès et risque métier en cas d'erreur. Les données RH, clients, finance, support et santé n'appellent pas les mêmes garde-fous.

Un tableau de décision par source évite les débats flous :

Chaque source devient alors opposable en interne. Vous fixez un accès interdit, partiel, anonymisé ou soumis à validation, avec un responsable identifié. Un CRM qui centralise des données clients demande le même soin.

Les bonnes pratiques RGPD d'un CRM aident à cadrer ce que l'agent peut y lire. Quand un connecteur arrive « pour tester », ce tableau empêche de transformer l'essai en accès permanent par défaut.

Définir les décisions que l'agent peut influencer et où une revue humaine reste obligatoire

Un agent produit un effet réel sans « décider » au sens strict. Une priorisation, un routage, une synthèse orientée ou une recommandation de réponse pèsent déjà sur le résultat.

Inventoriez les sorties de l'agent, pas seulement ses actions techniques :

• priorisation ou qualification de demandes
• rédaction de réponses client
• routage vers une file ou un niveau de support
• génération de contenu interne
• synthèse de dossier
• déclenchement d'actions dans les outils métiers

Certaines sorties relèvent d'une décision individuelle automatisée, encadrée par l'article 22 du RGPD. Cet article vise les décisions prises sur le seul fondement d'un traitement automatisé. Il s'applique quand elles produisent des effets juridiques ou affectent la personne de manière significative.

Dans ces cas, la personne doit être informée et pouvoir obtenir une intervention humaine. Elle doit aussi pouvoir contester la décision, sauf exceptions prévues : consentement explicite, contrat ou disposition légale.

Fixez des seuils de reprise humaine :

• toute recommandation touchant un dossier sensible est revue avant envoi
• tout déclenchement à effet externe passe par une validation humaine
• toute sortie fondée sur des données incomplètes ou anciennes est bloquée ou signalée
• un utilisateur peut contester une proposition qui influence son traitement

La bascule entre machine et humain doit être explicite. Qui reçoit la sortie, dans quel outil, sous quelle forme, avec quelles explications ? Si l'agent recommande une priorisation, l'opérateur voit les données utilisées, ce qui manque et ce qui reste incertain.

La responsabilité redevient nette à un moment précis. Un rôle valide, rejette ou corrige, et la décision finale lui appartient. Sans cette bascule, l'agent oriente l'issue sans que personne n'assume la décision.

"Le CRM Bitrix24 est un outil qui possède de nombreuses possibilités d’automatisation."

Formateur, Lionel Graf

LGXR Consulting

Obtenir Bitrix24 gratuitement

Fixer un modèle d'accès, de journalisation et de revue périodique avant toute mise en production

Un agent branché sans modèle d'accès détaillé devient vite plus permissif que les utilisateurs humains. On ouvre large pour accélérer un pilote, puis le pilote reste en place.

Définissez le modèle d'accès sur quatre axes :

• le rôle : support, finance, RH, opérations, équipe projet
• le jeu de données : sources, champs, niveau de détail
• le type d'action : lecture, synthèse, suggestion, exécution, export
• le contexte d'usage : cas normal, exception approuvée, accès temporaire

« Accès au CRM » ne suffit pas. Précisez le niveau : lecture seule, synthèse, proposition de mise à jour, écriture, ou export hors du système source. Ces niveaux n'ont pas le même risque.

La journalisation utile à l'audit interne doit permettre de reconstruire :

• qui a lancé la demande
• quel agent ou workflow (flux de travail) a été utilisé
• quelles sources ont été appelées
• quelles catégories de données ont été mobilisées
• quelle sortie a été générée
• quelles actions ont été proposées ou exécutées
• quels contrôles, exceptions ou blocages ont eu lieu

Bitrix24, par exemple, permet de gérer droits et accès à l'échelle de l'entreprise. Définissez alors comment les permissions de l'agent héritent, ou non, des droits existants. Précisez aussi comment l'activité est tracée et à quelle cadence les accès sont revus.

Adopter un tel outil ne prouve pas à lui seul la conformité. Tout dépend de la configuration, de l'exploitation des journaux et du contrôle dans la durée.

Fixez cette cadence de revue et nommez qui la déclenche. Voici un repère indicatif, à adapter à votre exposition.

Prévoyez une revue mensuelle pour les sources sensibles (RH, santé, finance), et trimestrielle pour le reste. Ajoutez une revue à chaque changement de connecteur.

Le propriétaire de la donnée et le responsable IT la déclenchent conjointement, pas la seule équipe projet. Elle repère les dérives classiques : connecteur resté ouvert après un test, compte de service trop large, droit devenu inutile.

Mettre en place le dossier de gouvernance qui rend le programme défendable en interne

Sans dossier de référence, chaque cas d'usage repart de zéro. Les décisions se perdent dans les mails, et personne ne sait sur quelle base un accès a été autorisé. Réunissez un dossier simple, maintenu et utilisable.

Le minimum à réunir avant déploiement tient en quelques points :

• finalité du cas d'usage
• base de discussion avec le DPO et le juridique
• données concernées et sources connectées
• risques identifiés
• responsables métier et IT
• contrôles prévus
• politique de conservation des journaux
• procédure d'escalade en cas d'écart ou d'incident

Ce dossier vit dans un référentiel unique et partagé, un espace documentaire versionné, pas dans une suite de mails. Il est signé par le sponsor métier, après consultation du DPO et du juridique. Le propriétaire de la donnée et le responsable IT le co-portent.

Cette signature rend la décision opposable en interne : on sait qui a autorisé quoi, et sur quelle base. Le traitement peut être susceptible d'engendrer un risque élevé pour les droits des personnes. Dans ce cas, une analyse d'impact (AIPD, article 35 du RGPD) devient nécessaire et rejoint le dossier.

Rattachez-le aussi au registre des traitements, pour que l'usage de l'agent n'existe pas en dehors de la documentation RGPD. Une fiche standard par agent ou par cas d'usage évite les validations ad hoc et pose les mêmes questions pour tous. Elle reprend les points de la liste ci-dessus, plus les critères d'arrêt et la date de prochaine revue.

Les critères d'arrêt manquent presque toujours, alors qu'ils servent beaucoup. Prévoyez des cas de suspension : journaux devenus insuffisants, connecteur changé sans revue, afflux inattendu de données sensibles.

Ce dossier vit après le lancement. Intégrez-y les changements de connecteurs, les élargissements de périmètre, les incidents et les résultats des revues d'accès. Sinon, il ne reste qu'une photo propre du jour de lancement.

Traiter les exceptions avant qu'elles ne deviennent des incidents de conformité ou d'exploitation

Les incidents sérieux viennent rarement du scénario nominal. Ils viennent des bords : données sensibles envoyées par erreur, réponse fausse prise pour vraie. D'autres viennent d'un connecteur qui contourne une restriction ou d'une action sur une information périmée.

Couvrez quelques cas avant la production :

• des données sensibles non prévues dans un prompt ou une pièce jointe
• une synthèse fausse ou trompeuse
• un connecteur donnant un accès indirect à une information interdite
• une action fondée sur une version ancienne d'un dossier
• une tentative de contournement par reformulation ou collage de contenu

Décidez les mesures de repli à l'avance : blocage automatique, redirection vers un traitement humain, suppression ou masquage. Ajoutez la suspension du connecteur et la notification des responsables. L'essentiel est que la chaîne de réaction soit connue avant l'incident.

En production, gardez des contrôles réguliers : revue d'échantillons de conversations, tests de permissions, vérification des journaux. Réunissez un comité pour arbitrer les nouveaux usages. Sans rythme, les exceptions s'accumulent jusqu'au jour où un incident force une réaction dans l'urgence.

Le signal d'alerte n'est pas que l'incident avéré. Une hausse des demandes de dérogation, des journaux trop pauvres ou des justifications floues révèlent déjà un dispositif mal cadré. Des utilisateurs qui contournent l'outil pour « aller plus vite » sont un autre signe.

FAQ