En Espagne, une violation de données a été notifiée pour la première fois, dans laquelle une attaque aurait été menée à l'aide d'un agent d'IA. Cet article explique comment classer l'obligation de notification d'une violation de données impliquant un agent d'IA, quand les 72 heures commencent à courir et quels préparatifs doivent déjà être en place pour ne pas improviser dans l'urgence.
Le 14 septembre 2026, il est devenu public en Espagne qu'une attaque menée avec un agent d'IA avait été notifiée pour la première fois à une autorité de protection des données. Cela soulève une question pratique : qui doit faire quoi lorsqu'un agent d'IA est en jeu, que ce soit comme outil d'attaque de tiers malveillants ou comme outil propre à l'entreprise ? Il s'agit de l'obligation de notification, des délais, des journaux et des procédures pour le cas d'urgence.
Le cas de l'AEPD en bref
En Espagne, une violation de données à caractère personnel a été notifiée pour la première fois, dans laquelle une attaque aurait été exécutée avec un agent d'IA reposant sur un modèle de langage connu. Selon les informations disponibles, l'attaquant a d'abord cherché des vulnérabilités dans des fichiers accessibles publiquement, puis s'est connecté au système cible. L'agent a trouvé d'autres vulnérabilités dans l'application, a modifié des données personnelles et a accédé à des factures.
La répartition des rôles est importante. L'entreprise qui a notifié était la victime, l'agent était l'outil des attaquants. Il ne s'agit donc pas de la défaillance d'un agent exploité par l'organisation elle-même. Ni l'organisation ni le modèle ne sont nommés. L'utilisation d'un modèle connu n'implique pas que son fournisseur ou son infrastructure ait été compromis, et il n'est pas dit que l'outil ait été conçu à des fins nuisibles. Un cas isolé ne permet en outre aucune conclusion sur une tendance.
L'IA ne crée pas de menaces fondamentalement nouvelles, mais elle peut augmenter la vitesse, l'ampleur et la capacité d'adaptation des attaques. Il en découle des conséquences pratiques : les attaques recourant à l'IA doivent entrer dans l'analyse de risques, les temps de réaction conçus pour des attaques manuelles doivent être réexaminés, les identifiants aux droits trop étendus doivent être mieux protégés, et la supervision humaine a besoin du soutien d'une détection et d'un confinement rapides.
Quand un agent d'IA déclenche une violation de données à notifier
L'obligation de notification des violations de données causées par des agents d'IA ne dépend pas de la technique, mais du résultat. Selon l'art. 4, point 12, du RGPD, il y a violation de données à caractère personnel lorsqu'une violation de la sécurité entraîne la destruction, la perte, l'altération, la divulgation non autorisée de données ou l'accès non autorisé à celles-ci, de manière accidentelle ou illicite. Qu'un humain, un script ou un agent soit à l'origine de la violation est indifférent pour cette définition. Deux scénarios peuvent néanmoins être clairement distingués.
Dans le scénario A, un agent externe attaque, comme dans le cas espagnol. L'accès non autorisé et la modification des données constituent la violation, et l'obligation de notification naît avec elle. Ce qui est nouveau ici, c'est surtout la vitesse, pas la qualification juridique. Dans le scénario B, c'est l'agent de l'entreprise elle-même qui cause la violation. Il peut s'agir d'un agent de service client qui envoie des données à la mauvaise personne, d'un agent de programmation aux droits trop étendus ou d'un agent de messagerie qui transfère des contenus après une instruction injectée.
Dans le scénario B, la qualification n'est pas toujours évidente. Si l'agent a fait exactement ce pour quoi il avait été configuré et qu'aucune personne non autorisée n'a eu accès aux données, il n'y a souvent pas de violation de la sécurité. En revanche, si des données parviennent à des destinataires qui n'auraient pas dû les recevoir, ou si l'agent accède à des fonds de données qui auraient dû lui être fermés, il y a de fortes chances qu'il s'agisse d'une violation. Il n'existe guère encore de lignes directrices propres aux agents. L'appréciation reste donc une question de cas par cas et suit les critères généraux des autorités.
| Scénario | Violation ? | Objectif de protection concerné |
|---|---|---|
| Un agent externe se connecte sans autorisation | Oui | Confidentialité |
| Un agent externe modifie des enregistrements dans l'application | Oui | Intégrité |
| Un agent interne envoie des factures aux mauvais destinataires | Oui | Confidentialité |
| Un agent interne transmet à l'extérieur des contenus de messagerie après une injection de prompt | Oui | Confidentialité |
| Un agent interne supprime des enregistrements sans sauvegarde | Oui | Disponibilité |
| Un agent interne répond de manière erronée sans fuite de données | Le plus souvent non | Aucun, plutôt un problème de qualité |
La question centrale peut ainsi être résumée brièvement.
Une violation de données impliquant un agent d'IA doit-elle être notifiée au titre de l'art. 33 du RGPD ?
Seuil de risque et exception à la notification
Toute violation ne doit pas être notifiée. L'art. 33 du RGPD prévoit une exception lorsque la violation n'est pas susceptible d'engendrer un risque pour les droits et libertés des personnes physiques. Le seuil est donc bas. En règle générale, on notifie dès lors qu'un risque ne peut être exclu. Celui qui renonce à la notification doit pouvoir justifier solidement pourquoi il n'y avait aucun risque.
Dans le cas d'attaques et d'incidents impliquant des agents, beaucoup d'éléments plaident contre cette exception. Les agents accèdent souvent à de nombreux enregistrements à la fois, ils travaillent vite et ont accès à des domaines tels que les factures, les comptes clients ou les messageries. Lorsqu'un attaquant modifie des données, un problème supplémentaire s'ajoute à la perte de confidentialité : personne ne sait d'abord quels enregistrements sont encore exacts. Cela accroît le risque pour les personnes concernées.
Les autorités européennes de protection des données ont publié des lignes directrices pour cette évaluation. Les lignes directrices du CEPD sur la notification des violations de données citent notamment comme critères la nature de la violation, la sensibilité et le volume des données, la facilité d'identification des personnes concernées, la gravité des conséquences possibles et le nombre de personnes concernées. En cas de risque élevé s'ajoute la communication aux personnes concernées prévue à l'art. 34 du RGPD. Cette étape est distincte de la notification à l'autorité et obéit à ses propres exigences.
La responsabilité reste à l'exploitant
Un agent est un outil et non un sujet de droit. Reste responsable celui qui décide des finalités et des moyens du traitement, c'est-à-dire l'entreprise qui déploie l'agent. Il ne suffit pas de renvoyer au modèle, à la plateforme ou au service métier. Même lorsqu'un agent agit de manière autonome, le traitement reste imputé à l'exploitant.
L'agent est un outil, la responsabilité reste à l'exploitant.
Lorsqu'une plateforme ou un fournisseur de modèle exploite l'agent pour le compte de l'entreprise, il agit en principe en tant que sous-traitant. L'art. 33, paragraphe 2, du RGPD s'applique alors : le sous-traitant doit notifier une violation au responsable du traitement dans les meilleurs délais après en avoir pris connaissance. Le délai du responsable du traitement ne commence toutefois qu'avec sa propre connaissance. Les contrats devraient donc fixer dans quel délai et par quel canal les incidents sont signalés. Une alerte qui n'arrive qu'après plusieurs jours dans une boîte de réception générale n'aide personne.
| Intervenant | Rôle lors d'un incident impliquant un agent |
|---|---|
| Exploitant de l'agent | Responsable du traitement, notifie l'autorité de contrôle et documente |
| Plateforme d'agents | Souvent sous-traitant, informe l'exploitant dans les meilleurs délais |
| Fournisseur du modèle | Selon l'architecture, sous-traitant ou sous-traitant ultérieur, également tenu d'informer en cas de compromission propre |
| Service métier | Détecte et signale en interne, sans décider lui-même |
| Autres prestataires | Fournissent journaux et informations pour l'évaluation |
Si un attaquant passe par un prestataire, les mêmes principes s'appliquent que pour tout incident dans la chaîne d'approvisionnement.
Bien compter les 72 heures
Selon l'art. 33, paragraphe 1, du RGPD, le délai court à partir du moment où le responsable du traitement a connaissance de la violation. La notification doit intervenir dans les meilleurs délais et, si possible, dans les 72 heures. Selon les lignes directrices du CEPD, il y a connaissance lorsque le responsable du traitement a un degré de certitude raisonnable qu'un incident de sécurité a conduit à une violation de données à caractère personnel. Un bref délai d'examen pour clarifier un soupçon est admis. L'inaction ne l'est pas.
Avec les agents, le goulot d'étranglement se déplace. Un agent peut consulter ou modifier des milliers d'enregistrements en quelques minutes. Que l'incident soit détecté le jour même ou seulement après une semaine dépend alors de la surveillance et de l'alerte. Les agents qui tournent la nuit ou le week-end aggravent la situation. Celui qui ne remarque les anomalies qu'au prochain coup d'œil sur un tableau de bord perd un temps que le délai ne prévoit pas. Ce qui compte ici, ce sont surtout le temps de détection et la question de savoir qui peut réagir en dehors des heures de bureau.
Avec les agents, les 72 heures sont avant tout une question de temps de détection.
La loi permet de notifier par phases. Si toutes les informations ne sont pas encore disponibles, elles sont fournies ultérieurement, sans retard indu, conformément à l'art. 33, paragraphe 4, du RGPD. Si le délai est dépassé, le retard doit être motivé. Le déroulement suivant peut servir de repère.
Les durées indiquées sont des valeurs indicatives. L'essentiel est que chaque étape ait quelqu'un pour la déclencher et que la décision de notifier ne dépende pas de la disponibilité d'une seule personne.
Journaliser les actions des agents
Sans journaux, l'ampleur d'une violation est difficile à chiffrer. Avec les agents, c'est particulièrement délicat, car ils exécutent de nombreuses actions individuelles qui paraissent anodines prises isolément. Un journal utile répond à quatre questions : qui a agi, qu'a-t-on fait, à quelles données a-t-on accédé et où sont-elles allées ? S'y ajoute l'obligation de documentation prévue à l'art. 33, paragraphe 5, du RGPD, qui concerne toute violation, y compris celles qui ne sont pas notifiées.
| Champ du journal | Utilité pour la notification | Remarque sur la minimisation des données |
|---|---|---|
| Identité et version de l'agent | Rattache l'incident à un système et à une configuration | Un identifiant technique suffit |
| Mission et déclencheur | Précise si un humain, un calendrier ou une entrée externe a déclenché l'action | Brève description plutôt que le texte intégral |
| Accès aux outils et aux données | Montre la nature et l'étendue des données concernées | Catégories et volumes plutôt que contenus |
| Horodatages | Base pour la connaissance et le calcul du délai | Sans difficulté |
| Systèmes cibles et destinataires | Montre où les données sont parvenues | Adresses uniquement si nécessaire |
| Erreurs et interruptions | Indices de tentatives d'attaque et de dysfonctionnements | Sans difficulté |
| Validations par des humains | Prouve la supervision et les circuits de décision | Seulement l'identifiant du service validant |
Pour la journalisation des agents, il faut retenir ceci : les journaux contiennent eux-mêmes des données personnelles et doivent être protégés. L'accès doit être limité à peu de personnes, et les entrées devraient être conservées de manière infalsifiable, par exemple sur un système séparé. La durée de conservation relève d'une pesée des intérêts : assez longue pour pouvoir reconstituer un incident, assez courte pour ne pas créer une collecte de données. Ces mesures relèvent de la sécurité du traitement au titre de l'art. 32 du RGPD. Les mêmes journaux aident aussi pour les demandes d'accès. La manière d'organiser utilement la surveillance des agents d'IA sans que les agents ne contournent eux-mêmes leur contrôle est un sujet à part.
Limiter les droits d'accès et les identifiants
Le cas espagnol montre comment procède un attaquant disposant d'un agent : il cherche des fichiers connus, des accès par défaut et des vulnérabilités ordinaires. C'est précisément ce qu'un agent sait faire à la vitesse de la machine et sans fatigue. Celui qui comble de telles failles enlève à l'attaque une bonne partie de sa vitesse. L'autorité cite expressément comme point faible les comptes, clés d'API et jetons aux autorisations trop étendues.
Quelques principes ont fait leurs preuves dans la pratique :
- Chaque agent reçoit son propre compte avec les droits minimaux nécessaires.
- Les clés et jetons sont de courte durée et peuvent être révoqués individuellement.
- Les accès à de nombreux enregistrements en peu de temps sont limités et signalés.
- Un interrupteur d'arrêt d'urgence arrête les agents et bloque leurs accès sans demander d'abord l'avis de quiconque.
- Les fichiers publiés, comptes de test et mots de passe par défaut sont recherchés et supprimés régulièrement.
Ces mesures protègent contre les agents externes comme contre les erreurs des agents internes. L'ampleur des dégâts dépend fortement des droits accordés à un agent. Pour la surface d'attaque d'une application web, des contrôles automatisés qui détectent les vulnérabilités visibles avant que d'autres ne le fassent peuvent aider.
Vérifier la surface d'attaque
Les fichiers exposés, les protections manquantes et les fuites de données sur votre propre site web peuvent être détectés automatiquement.
Plan de réaction aux attaques automatisées
De nombreux plans d'urgence partent du principe d'un attaquant qui a besoin d'heures ou de jours. L'autorité recommande de réexaminer les temps de réaction conçus pour des attaques manuelles. La supervision humaine reste importante, mais elle a besoin du soutien de mécanismes capables de détecter, de contenir et de réagir assez vite. Une attaque automatisée ne tient pas compte de l'heure de fermeture.
Un plan solide fixe quelques points. Il existe des alertes pour les schémas d'accès inhabituels, par exemple de nombreuses consultations depuis le même compte ou des connexions à des heures atypiques. Les comptes peuvent être bloqués automatiquement lorsque des seuils sont dépassés. Quelqu'un est joignable en dehors des heures de bureau. On sait qui décide de la notification et qui l'envoie. Le formulaire de notification de l'autorité de contrôle est préparé et les coordonnées du délégué à la protection des données sont à portée de main. Pour les premières heures d'un incident, le plan d'action pour les 60 premières minutes mérite un coup d'œil : il a été conçu pour les rançongiciels, mais se transpose à d'autres attaques.
Il est bon que le plan ait été exercé. Un exercice avec un incident d'agent fictif, au cours duquel un compte consulte des données en grande quantité, montre vite où cela coince : astreinte manquante, responsabilités floues, journaux inexploitables. De telles lacunes se comblent en période calme, pas en situation d'urgence.
Préparer la notification à l'autorité de contrôle
L'art. 33, paragraphe 3, du RGPD fixe le contenu minimal. Il faut décrire la nature de la violation, avec le nombre approximatif de personnes et d'enregistrements concernés, le nom et les coordonnées du délégué à la protection des données ou d'un autre point de contact, les conséquences probables ainsi que les mesures prises ou proposées. L'autorité compétente est en principe l'autorité de contrôle de l'État dans lequel l'entreprise a son siège. La plupart des autorités proposent un formulaire en ligne, et la Conférence allemande de protection des données en fournit un aperçu.
Avec les agents, il existe des lacunes typiques. Sans journaux, l'étendue de l'accès ne peut pas être chiffrée, et en cas de modification de données, on ne sait pas quels enregistrements ont réellement été touchés. Il est utile de clarifier à l'avance comment dériver un chiffre fiable à partir des journaux, des sauvegardes de base de données et des versions antérieures. Celui qui ne peut qu'estimer indique la fourchette et la qualifie de provisoire. La notification complémentaire comblera les lacunes plus tard.
Une courte liste de contrôle pour la notification :
- Moment de la prise de connaissance et période de l'incident
- Nature de la violation : accès non autorisé, modification, divulgation, perte
- Catégories de données concernées et nombre approximatif de personnes et d'enregistrements
- Rôle de l'agent : outil d'attaque externe ou agent interne
- Comptes, clés et systèmes confinés
- Conséquences probables pour les personnes concernées
- Décision sur l'information des personnes concernées
- Coordonnées du délégué à la protection des données
La question de savoir si d'autres régimes imposent en outre des obligations de notification, par exemple pour les exploitants d'infrastructures critiques ou au titre du règlement sur l'IA, dépend du cas d'espèce et devrait figurer dans le plan d'urgence, afin que la compétence ne doive pas être clarifiée pendant l'incident.
Conclusion
Le premier cas notifié en Espagne ne montre pas une nouvelle notion juridique, mais un nouveau rythme. Qu'un agent externe attaque ou que l'agent interne commette une erreur : ce qui compte, c'est de savoir s'il y a une violation de données à caractère personnel et s'il existe un risque pour les personnes concernées. Dans ce cas, il faut agir sans délai et notifier si possible dans les 72 heures.
Courte liste de contrôle :
- Les agents externes comme attaquants et les agents internes comme cause sont des scénarios différents avec la même évaluation.
- La responsabilité reste à l'exploitant, même lorsque des plateformes et des fournisseurs de modèles sont impliqués.
- Le temps de détection décide si le délai peut être respecté.
- De bons journaux transforment un soupçon en une notification solide.
- Des droits minimaux, des clés de courte durée et un interrupteur d'arrêt d'urgence retirent à l'attaque sa vitesse et ses dégâts.
My name is Klaus Meffert. I have a doctorate in computer science and have been working professionally and practically with information technology for over 30 years. I also work as an expert in IT & data protection. I achieve my results by looking at technology and law. This seems absolutely essential to me when it comes to digital data protection. My company, IT Logic GmbH, also offers consulting and development of optimized and secure AI solutions.
