Donneespersonnelles.fr

Plateforme de veille en conformite numerique

Lundi 10 aout 2026
AI Act

IA agentique et RGPD : le cadre applicable en 2026

La CNIL et le CIANum ont publié le 20 juillet 2026 une note sur l'IA agentique. Ce qu'elle change concrètement pour vos déploiements d'agents IA.

Une employée d’une grande entreprise du numérique a raconté récemment comment son agent IA avait supprimé une partie de sa messagerie professionnelle — et à quel point il avait été difficile d’interrompre le processus à distance. L’anecdote figure noir sur blanc dans la note publiée le 20 juillet 2026 par la CNIL et le Conseil de l’IA et du numérique (CIANum). Ce n’est pas un fait divers : c’est l’illustration d’un problème de conformité que la plupart des organisations qui déploient des agents IA n’ont pas encore posé.

Voici ce que dit cette note, ce que le droit impose déjà, et les mesures concrètes à mettre en place avant que vos agents ne commencent à agir seuls sur vos données.

Ce qu’est une IA agentique, techniquement

La note CNIL/CIANum définit l’IA agentique comme « un ensemble de programmes informatiques reposant sur des modèles d’IA générative et capables de prendre des décisions de manière autonome, d’orchestrer des actions complexes et d’interagir avec des services tiers, avec ou sans validation humaine ». La différence avec un simple chatbot n’est pas de degré, elle est de nature : l’agent n’écrit pas une réponse, il exécute une action.

L’architecture type repose sur trois briques :

  • un agent orchestrateur, animé par un modèle génératif, qui sert d’interface en langage naturel ;
  • des agents spécialisés, coordonnés par l’orchestrateur, chargés de tâches précises (génération de code, traitement documentaire, paiement en ligne) ;
  • des services externes — messagerie, agenda, bases de données, moteurs de recherche, API métier — mobilisés via des protocoles d’échange standardisés comme MCP ou ACP.

Deux mécanismes de gestion des données méritent une attention particulière, parce qu’ils déterminent tout le raisonnement juridique qui suit :

Mécanisme Contenu Durée de vie
Contexte Historique des échanges, instructions reçues, interactions avec les autres agents et services Supprimé à la fin du processus
Mémoire Informations réutilisables d’un processus à l’autre, notamment le profil de l’utilisateur Persistante, indépendante des processus

Chaque agent — orchestrateur comme spécialisé — dispose de son propre contexte et de sa propre mémoire. Dans certaines architectures, une mémoire partagée s’y ajoute. Vous avez donc, dans un déploiement multi-agents ordinaire, plusieurs espaces de stockage de données personnelles dont personne ne tient l’inventaire.

C’est là que le registre des systèmes d’IA cesse d’être un exercice formel : sans cartographie de ces mémoires, aucune durée de conservation n’est démontrable.

Pourquoi le RGPD est mis en tension

La note est claire sur un point que je trouve utile de rappeler, parce qu’il circule beaucoup de commentaires inverses : les IA agentiques demeurent pleinement soumises au RGPD. Le règlement n’est pas dépassé, il est difficile à appliquer. La nuance est fondamentale — elle signifie que l’absence de texte spécifique n’est pas un vide juridique, mais un problème de mise en œuvre dont vous restez comptable.

Principe par principe :

Principe RGPD Point de friction avec l’IA agentique
Finalité — Art. 5(1)(b) L’agent est conçu pour réaliser un grand nombre de tâches dans des domaines variés : le périmètre exact des traitements devient difficile à délimiter, et le risque de réutilisation incompatible est structurel
Licéité — Art. 6 L’autonomie de l’agent distend le lien entre les nouvelles opérations qu’il déclenche et la base légale initialement retenue
Minimisation — Art. 5(1)© L’agent mobilise e-mails, historiques, fichiers, les partage entre agents et les conserve pour anticiper les besoins : la nécessité de chaque donnée est rarement démontrable
Exactitude — Art. 5(1)(d) La nature probabiliste des modèles génère des erreurs qui se propagent d’agent en agent, sans mécanisme d’alerte pour l’utilisateur
Transparence — Art. 5(1)(a) Les sorties du modèle sont difficiles à expliquer, et les appels à des services tiers sont souvent initiés par l’agent lui-même, sans figurer dans la requête initiale
Limitation de la conservation — Art. 5(1)(e) Les mémoires diffuses et multiples rendent le contrôle des durées matériellement complexe

L’exemple que donne la note est parlant : vous ouvrez à un agent l’accès à votre environnement de travail — messagerie, agenda, espaces documentaires. Pour répondre à une requête donnée, il consulte l’ensemble des informations disponibles. Une partie de ces données n’était pas strictement nécessaire à la tâche. Elles sont pourtant intégrées à différents espaces de mémoire, voire transmises à des services externes.

Sur le plan de l’analyse d’impact appliquée à l’IA, cela déplace le curseur : ce n’est plus le modèle qu’il faut évaluer, mais l’étendue des accès consentis et la persistance des mémoires.

Le point dur : l’exercice des droits

La CNIL avait déjà relevé, dans sa publication du 7 février 2025 sur les droits des personnes, que l’identification et la suppression de données personnelles au sein des données d’entraînement d’un modèle génératif est complexe. L’agentique aggrave la difficulté d’un cran.

Concrètement, une personne qui exerce son droit d’accès ou son droit à l’effacement face à un système agentique se heurte à quatre questions sans réponse évidente : quel agent a collecté l’information ? Où a-t-elle été conservée ? A-t-elle été transmise à un autre composant du système ? Auprès de quel responsable exercer le droit ?

Si vous ne savez pas répondre à ces quatre questions pour vos propres déploiements, vous avez identifié votre chantier prioritaire. Une demande d’effacement à laquelle vous ne pouvez répondre de manière complète et traçable est un manquement, pas une difficulté technique.

Quand l’agent décide à votre place : l’article 22

C’est le point juridiquement le plus tranchant de la note. L’autonomie de ces systèmes peut conduire à des décisions relevant du régime des décisions individuelles automatisées de l’Art. 22 RGPD : toute personne a le droit de ne pas faire l’objet d’une décision fondée exclusivement sur un traitement automatisé, y compris le profilage, produisant des effets juridiques la concernant ou l’affectant de manière significative de façon similaire. Une telle décision n’est licite que sous l’une des trois exceptions de l’Art. 22(2) : exécution d’un contrat, autorisation par le droit de l’Union ou d’un État membre, consentement explicite.

L’erreur que je vois se répandre consiste à croire qu’un écran de validation suffit à sortir du régime. Il ne suffit pas. C’est la lecture que retient la note en s’appuyant sur l’arrêt SCHUFA de la CJUE (C-634/21, 7 décembre 2023), dans lequel la Cour a jugé qu’un score de probabilité constitue une décision au sens de l’Art. 22(1) dès lors qu’il joue un rôle déterminant dans la décision prise par le tiers. Traduit en termes opérationnels : l’intervention humaine doit être réelle, effective et exercer une influence sur la décision finale. Une validation purement formelle ou automatique est insuffisante.

Or, dans une chaîne agentique, l’appréciation du degré réel de supervision devient un exercice délicat. Un opérateur qui valide en série des propositions produites par un orchestrateur, sans disposer des éléments pour les contester, ne constitue pas une intervention humaine effective au sens de la jurisprudence. Le risque est particulièrement net dans les secteurs régulés — scoring financier, RH, assurance — où l’effet significatif est acquis.

En pratique : documentez, pour chaque décision automatisable, ce dont dispose l’humain qui valide, le temps dont il dispose, et son pouvoir réel de s’écarter de la proposition. C’est ce faisceau qui sera examiné, pas la présence d’un bouton. Le sujet est développé en détail dans notre analyse des décisions automatisées et du profilage et dans le commentaire de l’article 22 du RGPD.

Qui est responsable quand l’agent se trompe ?

Le déploiement d’un système agentique ne remet pas en cause le principe : un responsable du traitement doit pouvoir être identifié et rester en mesure d’assurer le respect des obligations. Mais la multiplication des agents, des services tiers et des décisions autonomes complique la répartition des rôles entre responsable du traitement et sous-traitant, et rend la démonstration de l’accountability autrement plus exigeante.

Au-delà du RGPD, la note pointe un flou réel. Trois éléments à connaître :

  1. Il n’existe pas de régime européen spécifique de responsabilité du fait de l’IA. Le projet de directive sur la responsabilité en matière d’intelligence artificielle a été abandonné en 2025, faute d’accord.
  2. L’AI Act n’instaure pas de régime de responsabilité exprès. Il impose des obligations de conformité selon une approche par les risques et selon la position dans la chaîne de valeur, ce qui permet d’identifier les rôles — pas d’imputer un dommage.
  3. Le droit commun français reprend donc la main : responsabilité délictuelle pour faute (art. 1240 du code civil), responsabilité du fait des choses (art. 1242), responsabilité contractuelle, et le cas échéant le régime de la directive (UE) 2024/2853 du 23 octobre 2024 sur les produits défectueux, qui a été révisée précisément pour couvrir les technologies émergentes dont l’IA.

Un système d’IA n’a pas la personnalité juridique et ne peut voir sa responsabilité engagée. Mais, comme le souligne la note, il ne saurait pour autant être assimilé à un simple outil passif. Entre ces deux constats, il reste un espace contractuel à occuper : c’est là que se joue la négociation avec vos fournisseurs. Nos clauses RGPD pour la sous-traitance IA et l’article 28 du RGPD donnent le cadre de départ.

Ce que dit — et ne dit pas — l’AI Act

Point important, souvent mal restitué : le règlement (UE) 2024/1689 ne consacre pas l’IA agentique comme catégorie spécifique. Il ne la définit pas et ne lui applique pas de régime dédié. Ses règles lui sont néanmoins pleinement applicables.

Trois conséquences concrètes, à la date du 8 août 2026 :

  • Les obligations de transparence de l’article 50 s’appliquent depuis le 2 août 2026. Un agent destiné à interagir avec des personnes physiques ou à générer du contenu y est soumis. C’est la principale obligation AI Act nouvellement opposable à la plupart des déploiements agentiques — aux côtés des interdictions de l’article 5, applicables depuis le 2 février 2025, et de l’obligation de maîtrise de l’IA de l’article 4. Voir notre guide de la transparence au titre de l’article 50.
  • L’autonomie et l’usage d’outils entrent dans la qualification du risque systémique des modèles à usage général qui sous-tendent les agents. Les fournisseurs de modèles GPAI à risque systémique doivent intégrer les capacités autonomes et l’usage agentique dans leur gestion des risques, conformément au code de bonnes pratiques.
  • Les exigences substantielles applicables aux systèmes à haut risque de l’annexe III sont reportées au 2 décembre 2027 par le règlement (UE) 2026/1744, dit omnibus numérique IA. Si votre agent opère dans un domaine de l’annexe III — RH, crédit, éducation, santé —, vous disposez de seize mois de plus, mais la date est fixe et inconditionnelle : voir notre analyse du nouveau calendrier de l’AI Act.

Le Bureau de l’IA de la Commission indique lui-même que ses considérations sur les agents restent préliminaires et qu’il surveille les développements. Autrement dit : ne comptez pas sur un texte spécifique à court terme. Le RGPD est, aujourd’hui, votre principal instrument de maîtrise.

À noter également : le CEPD et la Commission européenne rédigent actuellement des lignes directrices sur l’articulation entre RGPD et AI Act, attendues d’ici fin 2026. Le CEPD a par ailleurs adopté le 7 juillet 2026 ses Guidelines 03/2026 sur le moissonnage en ligne dans le contexte de l’IA générative, en consultation publique jusqu’au 30 octobre 2026 — un texte qui intéresse directement les agents autorisés à naviguer sur le web.

Les sept mesures à mettre en place

La note identifie des voies de conciliation entre déploiement agentique et protection des données. Je les reprends ici sous forme opérationnelle, en distinguant ce qui relève de la conception (privacy by design, Art. 25) et ce qui relève de la gouvernance.

1. Cloisonner la mémoire de chaque agent

Chaque agent devrait disposer d’une mémoire dédiée et isolée, sans accès automatique aux données des autres agents. Ajoutez un cloisonnement par traitement — des sessions dédiées séparant les usages — pour éviter l’accumulation d’un profil unique alimenté par toutes les finalités.

2. Limiter et purger les mémoires

Mesures concrètes : taille de mémoire plafonnée, expiration automatique des informations au bout d’un délai déterminé, remplacement régulier par des données plus récentes. Cette dernière mesure a un double effet — elle sert la limitation de conservation (Art. 5(1)(e)) et l’exactitude (Art. 5(1)(d)). Un mécanisme de comparaison des mémoires entre agents permet en outre de détecter les divergences.

3. Cloisonner l’environnement d’exécution (sandboxing)

Un environnement dédié réduit au strict nécessaire les accès aux services et données, limite le périmètre de risque et facilite la surveillance. En cas d’exfiltration, le préjudice se limite au périmètre effectivement accessible à l’agent. C’est une mesure technique au sens de l’article 32 du RGPD, documentable comme telle.

4. Classer les actions par niveau de risque

C’est, à mon sens, la mesure la plus rentable et la plus négligée. Établissez une grille des actions possibles sur chaque service connecté :

Niveau Type d’action Validation humaine
1 Lecture de données non sensibles Non
2 Lecture de données sensibles (Art. 9) ou confidentielles Journalisation renforcée
3 Modification de données Recommandée
4 Suppression de données Requise
5 Envoi de données hors du système (e-mail, API tierce) Requise
6 Transaction financière, décision produisant des effets juridiques Requise et effective (Art. 22)

L’utilisateur devrait pouvoir choisir lui-même quelles actions requièrent sa validation préalable. C’est le principe du human in the loop appliqué au bon endroit : non pas partout, ce qui rend le système inutilisable et la validation formelle, mais sur les actions irréversibles.

5. Prévoir un bouton d’arrêt d’urgence

Un kill switch permettant d’interrompre à tout moment l’exécution d’un processus agentique en cas de comportement inattendu. L’exemple des e-mails supprimés cité en ouverture illustre exactement ce qui manque quand cette fonction n’existe pas : la capacité à identifier rapidement l’origine d’une action, la corriger et limiter ses effets.

6. Filtrer et détecter les usages détournés

Combinaison de deux leviers : des modèles entraînés et instruits pour limiter les usages illicites, et un filtrage des requêtes. Trois mesures techniques citées : reconnaître et bloquer les requêtes suspectes, surveiller en temps réel les actions des agents avec alerte sur comportement inhabituel, tester la robustesse avant et pendant le déploiement.

Point technique important souvent manqué : le filtrage doit s’appliquer à chaque sollicitation du modèle par un agent — orchestrateur ou spécialisé — et pas seulement à la requête initiale de l’utilisateur. Un agent spécialisé qui reçoit une instruction d’un autre agent constitue un point d’entrée à part entière.

7. Tracer le processus décisionnel

Pour chaque tâche exécutée, l’utilisateur devrait pouvoir identifier les données personnelles mobilisées, les agents intervenus, les services tiers sollicités, les échanges réalisés et leur chronologie. Cette traçabilité sert deux fins distinctes : la transparence à l’égard de la personne concernée, et l’établissement d’une chaîne de responsabilité en cas de dysfonctionnement. Elle est la condition pratique de l’explicabilité dans un système distribué.

Ces sept mesures ont vocation à être formalisées dans votre gouvernance : une charte d’usage de l’IA et un dispositif de gouvernance IA en entreprise restent le véhicule le plus efficace pour les rendre opposables en interne.

Ce qu’il faut retenir

  • Les IA agentiques sont pleinement soumises au RGPD. La note CNIL/CIANum du 20 juillet 2026 ne crée pas de régime dérogatoire : elle constate une difficulté d’application, dont le responsable du traitement reste comptable.
  • La mémoire persistante est le principal point de rupture. Multipliée par agent, elle rend les durées de conservation (Art. 5(1)(e)) et les droits d’accès et d’effacement (Art. 15 et 17) matériellement difficiles à honorer si rien n’est cloisonné dès la conception.
  • L’article 22 s’applique dès que l’agent produit des effets juridiques ou significatifs. Un écran de validation ne suffit pas : depuis l’arrêt SCHUFA (C-634/21), l’intervention humaine doit être réelle, effective et influente sur la décision finale.
  • L’AI Act ne connaît pas la catégorie « agent IA ». Seul l’article 50 (transparence) est directement applicable depuis le 2 août 2026 ; le haut risque de l’annexe III est reporté au 2 décembre 2027 par le règlement (UE) 2026/1744.
  • Sept mesures techniques et de gouvernance sont documentables dès aujourd’hui : cloisonnement des mémoires, purge automatique, sandboxing, grille de risque des actions, kill switch, filtrage à chaque appel de modèle, traçabilité du processus décisionnel.
  • Des lignes directrices CEPD/Commission sur l’articulation RGPD–AI Act sont attendues d’ici fin 2026. Elles ne dispenseront pas des chantiers ci-dessus, qui relèvent du droit positif.

FAQ

L’IA agentique est-elle réglementée par un texte spécifique ?

Non. Ni le RGPD ni le règlement (UE) 2024/1689 sur l’IA ne consacrent l’IA agentique comme catégorie juridique autonome. Les deux textes lui sont pleinement applicables, mais aucun ne prévoit de règles taillées pour l’autonomie décisionnelle, la mémoire persistante ou les architectures multi-agents. La note CNIL/CIANum du 20 juillet 2026 est aujourd’hui la référence française la plus précise sur le sujet.

Faut-il réaliser une AIPD avant de déployer un agent IA ?

Il est fortement recommandé de le faire dès lors que l’agent dispose d’accès étendus à des données personnelles, conserve une mémoire persistante ou peut déclencher des actions produisant des effets sur les personnes. La combinaison de ces caractéristiques croise plusieurs critères de l’AIPD, notamment le traitement à grande échelle, le croisement de données et la prise de décision automatisée. Voir notre guide de l’analyse d’impact appliquée aux systèmes d’IA.

Un agent IA qui envoie un e-mail à ma place relève-t-il de l’article 22 ?

Pas nécessairement. L’article 22 vise les décisions produisant des effets juridiques ou affectant la personne de manière significative de façon similaire. L’envoi d’un e-mail ordinaire n’atteint pas ce seuil ; en revanche, une notification de refus de crédit, une décision de rejet de candidature ou la résiliation d’un contrat exécutés par un agent y entrent sans difficulté. Le critère est l’effet produit sur la personne, pas la nature technique de l’action.

Qui est responsable si un agent IA supprime ou divulgue des données par erreur ?

Sur le terrain du RGPD, le responsable du traitement le demeure : ni l’autonomie de l’agent ni la pluralité des fournisseurs ne déplacent cette qualification, et l’incident peut constituer une violation de données à notifier dans les 72 heures. Sur le terrain de la responsabilité civile, en l’absence de régime européen spécifique — le projet de directive sur la responsabilité en matière d’IA ayant été abandonné en 2025 —, ce sont les articles 1240 et 1242 du code civil, la responsabilité contractuelle et la directive (UE) 2024/2853 sur les produits défectueux qui s’appliquent.

La CNIL peut-elle sanctionner un déploiement d’IA agentique ?

Oui, dans les mêmes conditions que tout autre traitement. Les manquements aux principes de l’article 5 et aux droits des personnes relèvent du plafond de l’Art. 83(5) — 20 millions d’euros ou 4 % du chiffre d’affaires mondial. Aucune tolérance particulière n’est prévue au motif que la technologie est récente : la note rappelle au contraire que les principes du RGPD « restent absolument essentiels » dans ce contexte.

Thiébaut Devergranne
Docteur en droit des nouvelles technologies (Paris II)

Docteur en droit, Thiébaut Devergranne travaille en droit des nouvelles technologies et en protection des données personnelles depuis plus de 20 ans. Il a accompagné des centaines d'organisations dans leur mise en conformité RGPD et est le fondateur de Legiscope, logiciel de conformité RGPD.

En savoir plus sur l'auteur →