La primera bretxa amb agent d'IA ja està notificada. El més difícil va ser poder explicar-la

El 14 de setembre l'Agència Espanyola de Protecció de Dades va publicar que ha rebut la primera notificació d'una bretxa de dades personals que «habría sido ejecutada mediante un agente de inteligencia artificial». L'atac sencer ocupa una frase. Aquesta frase és el que ens interessa, i no per l'atacant: pel que va caldre per poder-la escriure.

Comencem pel condicional, que en gairebé tota la cobertura d'aquesta setmana ha desaparegut. L'Agència avisa abans d'explicar res: «Con carácter previo a ningún tipo de conclusión, hay que señalar que la información disponible procede de la notificación presentada por la organización afectada y deberá ser objeto del correspondiente análisis». El confirmat, per tant, és la notificació; l'autoria és el que diu l'organització que la va patir. I no hi ha nom d'empresa, ni sector, ni xifres, així que això no és una anàlisi de l'incident: és la lectura de quatre línies administratives com allò que acabaran sent per a algú altre — un formulari. Avancem la conclusió, que és la part que no ven: de les quatre fases, tres es paren amb coses avorrides que no porten IA.

Les quatre fases, en les paraules de l'AEPD

Ho signa Francisco Pérez Bes, adjunt a la Presidència de l'Agència. Del model només diu que era «un conocido modelo de lenguaje», sense anomenar-lo. I convé no estirar la frase més del que dona: d'aquest cas concret l'Agència no afirma res més que aquestes quatre fases, i el «de forma autónoma» va enganxat a una de sola — la cerca de vulnerabilitats dins de l'aplicació. La resta que s'ha llegit aquests dies («va planificar», «es va adaptar») ve d'un altre paràgraf, el que descriu en general de què és capaç un agent: «Un agente puede recibir un objetivo, planificar tareas intermedias, utilizar herramientas, ejecutar código, consultar fuentes, interpretar resultados y modificar su actuación, de forma autónoma, en función de lo que encuentra». Això és un catàleg de capacitats, no l'acta de l'incident.

El que la notificació no diu (i convé no omplir)

No diu quina organització, ni de quin sector, ni quantes persones afectades. No diu quin model. No diu quant va durar, ni si hi va haver alerta, ni qui se'n va adonar. I sobretot: no diu d'on van sortir les credencials d'aquest login correcte. En una entrada de quatre línies, tots aquests buits són legítims — l'Agència no publica un informe forense, avisa d'un vector. El problema és què fa el sector amb els buits.

L'AEPD no ho diu. Ho diem nosaltres, i és una conjectura: les dues primeres frases van juntes. «Archivos genéricos» és el vocabulari d'un escombratge de rutes conegudes — una còpia de seguretat oblidada, un fitxer de configuració servit en clar, un bolcat amb nom de data. Si una d'aquestes rutes retorna alguna cosa amb credencials a dins, el «login correcto» de la frase següent deixa de ser un misteri i passa a ser la conseqüència de l'anterior. És el mateix mecanisme del qual parlàvem aquest mateix matí: la fallada la publica el fabricant, però l'exposició la decideix la teva pròpia configuració.

Un login correcte no dispara res

Entre la fase u i la fase tres hi ha una autenticació que va funcionar. No un salt d'autenticació, ni un token falsificat, ni una escalada: un login. Això trenca l'esquema mental amb què molta gent munta la seva vigilància, perquè els controls que gairebé tothom té mirant la porta compten intents fallits. Davant d'aquesta seqüència no tenien res a comptar. La porta es va obrir a la primera.

És el punt on Zero Trust deixa de ser una paraula de fullet i és una decisió concreta i una mica incòmoda: assumir que una sessió perfectament vàlida pot ser hostil, i per tant que l'autenticació no és el final del control sinó el principi. El que segueix un login correcte — a què arriba aquella sessió, quantes coses diferents toca, a quin ritme — és just el que aquí va importar. I la simetria amb els agents propis és incòmoda a propòsit: quan connectes un agent als teus sistemes amb el token d'una persona, al registre del sistema de destí surt la persona, no l'agent. El mateix punt cec, en els dos sentits.

Ara posa't a l'altre costat del formulari

La mateixa AEPD té publicat, a part d'aquesta notícia, el recordatori de sempre: «El plazo para notificar a la autoridad de control es de 72 horas desde que la organización tiene constancia de la brecha», la notificació es presenta amb el formulari de la Seu Electrònica «para garantizar una correcta ejecución de las obligaciones del artículo 33.3 del RGPD», i el responsable té a més l'obligació de documentar «cualquier violación de la seguridad de los datos personales, incluidos los hechos relacionados con ella, sus efectos y las medidas correctivas adoptadas».

Llegeix una altra vegada l'ordre d'aquestes tres paraules: fets, efectes, mesures. Les quatre fases que obren aquest article són exactament el primer. Algú va poder reconstruir quatre fases, posar-les en ordre i distingir quina venia d'un escombrat extern i quina de dins de l'aplicació. Això no surt de la intuïció de ningú: surt de registres. Així que la pregunta incòmoda no és si la teva aplicació és vulnerable — ho és, i la meva també. És aquesta: amb el que guardes avui, podries escriure aquelles quatre frases sobre tu mateix en tres dies?

Fase per fase, el registre que cal per afirmar-la

El que l'AEPD et demana ara per escrit

L'entrada acaba amb deures. El primer és el que et canvia la documentació: «Incorporar expresamente los ataques asistidos o ejecutados mediante IA a los análisis de riesgos de los tratamientos». La resta és una llista que podries haver llegit fa deu anys: «[c]onocer los tratamientos, minimizar los datos, limitar los accesos, corregir vulnerabilidades, controlar a los proveedores y estar preparados para responder». I demana també revisar els temps de resposta i reforçar el control sobre identitats i credencials.

Fixa't en els sis verbs: cap no és nou. El que és nou és l'adverbi: expresamente, «expressament». Una anàlisi de riscos que no anomena un escenari no el cobreix, i fins ara l'absència no es veia; des del 14 de setembre hi ha un precedent publicat per l'autoritat, i l'absència es llegeix diferent. La mateixa AEPD remet, per al detall tècnic, a la guia CCN-CERT BP/36 del Centre Criptològic Nacional, de juny de 2026, el plantejament central de la qual és que la IA ofensiva permet «automatizar, acelerar y ampliar a gran escala ataques ya conocidos». Convé llegir les tres últimes paraules: ya conocidos.

I no, això no s'arregla comprant alguna cosa amb «IA» al nom

És previsible que aquest titular es converteixi en argument de venda durant la tardor, així que diguem la part que no ven. De les quatre fases, tres es paren amb coses que ja podies haver fet l'any passat: treure de l'arrel del servidor els fitxers que no haurien d'estar publicats, posar un segon factor a l'autenticació, i tenir un lloc on els canvis a les dades quedin escrits i no es puguin esborrar des de l'aplicació. Cap de les tres porta IA. Cap de les tres és cara. Les tres són avorrides, i és exactament per això que continuen pendents en tants llocs.

I ara la part que ens toca dir tot i que no ens convingui. Si ets una empresa de quinze persones amb una aplicació de gestió, no necessites un SIEM. Nosaltres monitoritzem amb Zabbix i SmokePing, a la nostra pròpia plataforma i a la de clients, i la regla amb què els operem és una de sola: alertes que importen, no soroll. Muntar un SIEM per complir una recomanació és la forma més eficaç que coneixem d'acabar amb un panell en vermell permanent que ningú no mira, i això és pitjor que no tenir-lo: l'alerta que s'ignora cada dia ensenya a ignorar la que importa. Comença per retenció i per deixar els canvis escrits; la correlació ve després, i si no hi ha ningú que la vigili a les quatre de la matinada, ve delegada en algú que sí que hi sigui o no ve. Decidir-ho a l'inrevés és com es compren tecnologies que acaben apagades al cap de sis mesos.

La prova de la mitja hora

Cinc preguntes, amb una regla: cada resposta ha de ser un número, un nom de fitxer o un nom de sistema. Un «sí» no compta com a resposta.

Si tres de les cinc respostes són «caldria mirar-ho», la feina que tens pendent no és de seguretat. És de registre. I són dos pressupostos molt diferents.

El llistó que deixa aquesta notificació

El titular diu que la IA ja ataca sola, i és veritat. El que diu la notificació llegida a poc a poc és alguna cosa menys espectacular i bastant més útil: que hi va haver una organització capaç d'explicar amb precisió, per fases i en ordre, el que li havia passat. Aquest és el llistó que deixa el 14 de setembre, i no té res a veure amb comprar. Gairebé totes les converses que tenim comencen a l'inrevés, amb un «ens sembla que van entrar per aquí», i aquesta frase, al formulari de la Seu Electrònica, no es pot escriure.

Sobre la velocitat de l'altre costat ja vam escriure fa unes setmanes, quan el problema va deixar de ser trobar la fallada i va passar a ser el calendari de després. Això és l'altra meitat del mateix: si l'atacant no dorm, el teu avantatge no és córrer més. És poder reconstruir el que va passar sense dependre de la memòria de ningú.

Fonts (verificades el 26-09-2026): la descripció literal de les quatre fases, el condicional «habría sido ejecutada», l'advertiment que la informació «deberá ser objeto del correspondiente análisis», la definició genèrica d'agent, la menció a «un conocido modelo de lenguaje» i les recomanacions citades — entrada del blog de l'AEPD del 14-09-2026, signada per Francisco Pérez Bes; el seu càrrec d'adjunt a la Presidència de l'AEPD (Reial Decret 143/2025, presa de possessió el 03-03-2025) no consta en aquella entrada, sinó a la nota de premsa de la mateixa Agència. El termini de 72 hores des que l'organització en té constància, el formulari de la Seu Electrònica i les obligacions de l'article 33.3 del RGPD, i el deure de documentar «los hechos relacionados con ella, sus efectos y las medidas correctivas adoptadas» — pàgina de bretxes de seguretat de l'AEPD. La frase «automatizar, acelerar y ampliar a gran escala ataques ya conocidos» i el plantejament de la guia — nota del Laboratori de l'AEPD; la data de la guia, a la portada de la mateixa CCN-CERT BP/36 («Guía de seguridad, junio 2026»). El que és nostre i no de les fonts: la conjectura que el «login correcto» pugui venir de l'escombratge d'arxius genèrics (marcada com a conjectura al text), la llista de registres per fase, els senyals per inferir automatisme, l'advertiment sobre el SIEM i les cinc preguntes. La nostra experiència amb Zabbix i SmokePing en producció és el que fem, no un estudi: no la presentem com a estadística. L'AEPD no publica el nom de l'organització, el sector, la durada ni el nombre d'afectats, i aquest article no els supleix. Foto de portada: banc d'imatges de llicència lliure (domini públic).