L'attaque elle-même semble presque ordinaire. Quelque chose a analysé des fichiers génériques à la recherche de faiblesses, a trouvé un moyen d'entrer et s'est connecté avec succès. Ensuite, il a continué : il a recherché d'autres vulnérabilités dans l'application, les a exploitées, a modifié des données personnelles et a ouvert des factures. Ce qui a distingué cette notification, c'est qui, ou quoi, a effectué la recherche. Selon l'organisation touchée, il s'agissait d'un agent IA utilisant un modèle de langage bien connu.

L'AEPD s'est empressée d'ajouter des mises en garde lors de la publication du cas. Les informations proviennent de la propre notification de l'organisation et doivent encore être analysées. L'utilisation d'un modèle particulier ne signifie pas que le modèle, ou l'infrastructure de son fournisseur, a été compromis. Et une notification ne constitue pas une tendance statistique. Il s'agit, selon l'Agence, d'un signal indiquant que les attaques assistées par IA commencent à apparaître dans des incidents impliquant de réelles données personnelles.

Ce qui a rendu cette attaque différente

L'IA fait partie des cyberattaques depuis un certain temps: dans les e-mails de phishing, les messages d'escroquerie traduits, l'analyse de code. Un agent apporte autre chose. Il peut prendre un objectif, le décomposer en étapes, utiliser des outils, analyser les résultats et ajuster ce qu'il fait ensuite, avec peu ou pas d'intervention humaine entre ces étapes.

Dans ce cas, cela signifie qu'un seul système a enchaîné toute la séquence, depuis la découverte d'une faiblesse jusqu'à la modification de données personnelles. L'AEPD souligne un risque spécifique derrière cela: un agent qui s'empare d'un compte, d'une clé d'API ou d'un jeton disposant d'autorisations plus larges que nécessaire peut se déplacer entre les services avant que quiconque ne remarque une activité inhabituelle. Le détail notable dans le cas espagnol est le caractère banal de l'entrée: l'agent s'est simplement connecté.

Cela déplace l'attention de la défense périphérique vers une question moins spectaculaire: quels comptes, clés et jetons existent dans votre organisation, à quoi chacun d'eux peut-il accéder, et à quelle vitesse pouvez-vous en révoquer un?

L'horloge du RGPD ne change pas. Le temps nécessaire pour comprendre, oui.

Le RGPD est neutre sur le plan technologique, et le cas de l'AEPD ne modifie pas une seule obligation. L'article 32 exige toujours une sécurité appropriée au risque. L'article 33 exige toujours que les responsables du traitement notifient l'autorité de contrôle sans retard injustifié et, si possible, dans les 72 heures après en avoir pris connaissance, à moins que la violation ne soit peu susceptible d'engendrer un risque pour les personnes.

La différence réside dans l'écart entre le fait de prendre connaissance et le fait de comprendre. Une équipe peut savoir qu'un attaquant a accédé à une application tout en cherchant encore à déterminer quels enregistrements ont été touchés, si des données ont été copiées et, comme dans ce cas, si elles ont été modifiées. Des données modifiées transforment une question de confidentialité en une question d'intégrité également, ce qui rend l'enquête plus difficile. Si l'agent a utilisé des identifiants valides, il peut aussi être difficile de séparer ses actions de l'activité légitime.

Deux conséquences en découlent pour les personnes qui gèrent les incidents. L'évaluation juridique doit commencer pendant que l'enquête technique est encore en cours, et non après l'arrivée du rapport d'analyse d'investigation numérique. Et le RGPD l'anticipe déjà: lorsque toutes les informations ne sont pas disponibles en même temps, l'article 33 permet de les fournir par étapes, sans retard injustifié supplémentaire. Un plan qui traite la notification comme un document unique et final aura du mal à faire face à une attaque qui se développe à la vitesse de la machine.

Selon l'organisation, le même incident peut également déclencher un signalement au titre de NIS2, de DORA ou du Cyber Resilience Act, chacun ayant ses propres seuils, délais et autorités. C'est au cours de la première heure que ces décisions se prennent.

Ce que l'IA Act a à voir avec tout cela

Il est tentant de lire ce cas sous l'angle de l'IA Act. Pour l'organisation attaquée, ce n'est principalement pas le cas. L'IA Act de l'UE réglemente la manière dont les systèmes d'IA sont conçus, mis sur le marché et utilisés. Il ne régit pas l'attaquant, et rien dans le cas de l'AEPD ne suggère que la victime utilisait l'IA en question.

L'IA Act peut devenir pertinent de l'autre côté: lorsque votre organisation déploie ses propres agents IA. Les agents qui lisent des dossiers clients, mettent à jour un CRM, envoient des e-mails ou déclenchent des paiements détiennent exactement le type d'accès contre lequel l'AEPD met en garde. Si l'un d'eux, ou ses identifiants, était compromis, la même chaîne d'événements pourrait se dérouler dans vos systèmes, en déclenchement interne.

C'est là que la protection de la vie privée et la gouvernance de l'IA se rencontrent:

• Sous le RGPD, ce que vos propres agents font avec des données personnelles nécessite une base légale, souvent une analyse d'impact relative à la protection des données (AIPD), et des garanties lorsque les décisions sont automatisées.

• Sous l'IA Act, les systèmes d'IA à haut risque doivent atteindre des niveaux appropriés d'exactitude, de robustesse et de cybersécurité en vertu de l'article 15. Suite à l'Omnibus Numérique sur l'IA, ces obligations s'appliquent à partir du 2 décembre 2027 pour les systèmes autonomes et à partir du 2 août 2028 pour l'IA intégrée dans des produits réglementés. Les fournisseurs des modèles d'IA à usage général les plus performants ont déjà des obligations en matière de cybersécurité et d'incidents graves aujourd'hui.

• Dans les deux cas, les questions pratiques sont les mêmes: quels agents utilisez-vous, qui est responsable de chacun d'eux, quelles données et quels systèmes peuvent-ils atteindre, et qui a approuvé cet accès?

Notre point de vue: les organisations qui traitent le RGPD et l'IA Act comme des projets distincts répondront deux fois à ces questions, à des endroits différents, et probablement de manière différente. Il s'agit d'un seul et même ensemble de questions.

Comment Formalize vous accompagne

Une plateforme GRC ne détecte ni ne bloque un agent IA. C'est le rôle des outils de sécurité, de la gestion des identités à la surveillance. Ce qu'une plateforme GRC apporte, c'est la garantie que le volet organisationnel tienne la route lorsqu'un incident survient, et que vous puissiez le prouver.

Dans Formalize, cela se traduit par:

• Des évaluations de risques avec des responsables désignés, mises à jour à mesure que des menaces telles que les attaques assistées par IA font évoluer la situation.

• Des contrôles conçus comme des tâches récurrentes et documentées par des preuves, telles que les revues d'accès pour les comptes de service et les clés d'API, plutôt que de simples bonnes intentions dans un document de politique.

• Des flux de travail d'incident qui enregistrent qui a évalué quoi, quand et pourquoi, de la première alerte jusqu'à la décision de notification.

• Le travail relatif au RGPD et à l'IA Act réuni dans le même système, avec des modèles dédiés aux deux, afin que vos registres de traitement et vos systèmes d'IA soient gouvernés côte à côte.

Lorsqu'un régulateur vous demandera ultérieurement ce que vous saviez, quand vous l'avez appris et ce que vous avez fait, la réponse devrait déjà exister. Découvrez comment Formalize aborde la conformité au RGPD et à l'IA Act.