La primera brecha con agente de IA ya está notificada. Lo difícil fue poder contarla

El 14 de septiembre la Agencia Española de Protección de Datos publicó que ha recibido la primera notificación de una brecha de datos personales que «habría sido ejecutada mediante un agente de inteligencia artificial». El ataque entero ocupa una frase. Esa frase es lo que nos interesa, y no por el atacante: por lo que hizo falta para poder escribirla.

Empecemos por el condicional, que en casi toda la cobertura de esta semana ha desaparecido. La Agencia avisa antes de contar nada: «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». Lo confirmado, por tanto, es la notificación; la autoría es lo que dice la organización que la sufrió. Y no hay nombre de empresa, ni sector, ni cifras, así que esto no es un análisis del incidente: es la lectura de cuatro líneas administrativas como lo que acabarán siendo para alguien más — un formulario. Adelantamos la conclusión, que es la parte que no vende: de las cuatro fases, tres se paran con cosas aburridas que no llevan IA.

Las cuatro fases, en las palabras de la AEPD

Lo firma Francisco Pérez Bes, adjunto a la Presidencia de la Agencia. Del modelo dice solo que era «un conocido modelo de lenguaje», sin nombrarlo. Y conviene no estirar la frase más de lo que da: de este caso concreto la Agencia no afirma nada más que esas cuatro fases, y el «de forma autónoma» va pegado a una sola de ellas — la búsqueda de vulnerabilidades dentro de la aplicación. Lo demás que se ha leído estos días («planificó», «se adaptó») viene de otro párrafo, el que describe en general de qué es capaz un agente: «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». Eso es un catálogo de capacidades, no el acta del incidente.

Lo que la notificación no dice (y conviene no rellenar)

No dice qué organización, ni de qué sector, ni cuántas personas afectadas. No dice qué modelo. No dice cuánto duró, ni si hubo alerta, ni quién se dio cuenta. Y sobre todo: no dice de dónde salieron las credenciales de ese login correcto. En una entrada de cuatro líneas, todos esos huecos son legítimos — la Agencia no está publicando un informe forense, está avisando de un vector. El problema es lo que hace el sector con los huecos.

La AEPD no lo dice. Lo decimos nosotros, y es una conjetura: las dos primeras frases van juntas. «Archivos genéricos» es el vocabulario de un barrido de rutas conocidas — una copia de seguridad olvidada, un fichero de configuración servido en claro, un volcado con nombre de fecha. Si una de esas rutas devuelve algo con credenciales dentro, el «login correcto» de la frase siguiente deja de ser un misterio y pasa a ser la consecuencia de la anterior. Es el mismo mecanismo del que hablábamos esta misma mañana: el fallo lo publica el fabricante, pero la exposición la decide tu propia configuración.

Un login correcto no dispara nada

Entre la fase uno y la fase tres hay una autenticación que funcionó. No un salto de autenticación, ni un token falsificado, ni una escalada: un login. Eso rompe el esquema mental con el que mucha gente monta su vigilancia, porque los controles que casi todo el mundo tiene mirando la puerta cuentan intentos fallidos. Ante esta secuencia no tenían nada que contar. La puerta se abrió a la primera.

Es el punto donde Zero Trust deja de ser una palabra de folleto y es una decisión concreta y algo incómoda: asumir que una sesión perfectamente válida puede ser hostil, y por tanto que la autenticación no es el final del control sino el principio. Lo que sigue a un login correcto — a qué llega esa sesión, cuántas cosas distintas toca, a qué ritmo — es justo lo que aquí importó. Y la simetría con los agentes propios es incómoda a propósito: cuando conectas un agente a tus sistemas con el token de una persona, en el registro del sistema de destino sale la persona, no el agente. El mismo punto ciego, en los dos sentidos.

Ahora ponte al otro lado del formulario

La propia AEPD tiene publicado, aparte de esta noticia, el recordatorio de siempre: «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ón se presenta con el formulario de la Sede Electrónica «para garantizar una correcta ejecución de las obligaciones del artículo 33.3 del RGPD», y el responsable tiene además la obligación 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».

Lee otra vez el orden de esas tres palabras: hechos, efectos, medidas. Las cuatro fases que abren este artículo son exactamente lo primero. Alguien pudo reconstruir cuatro fases, ponerlas en orden y distinguir cuál vino de un barrido externo y cuál de dentro de la aplicación. Eso no sale de la intuición de nadie: sale de registros. Así que la pregunta incómoda no es si tu aplicación es vulnerable — lo es, y la mía también. Es esta: con lo que guardas hoy, ¿podrías escribir esas cuatro frases sobre ti mismo en tres días?

Fase por fase, el registro que hace falta para afirmarla

Lo que la AEPD te pide ahora por escrito

La entrada acaba con deberes. El primero es el que cambia papeles: «Incorporar expresamente los ataques asistidos o ejecutados mediante IA a los análisis de riesgos de los tratamientos». El resto es una lista que podrías haber leído hace diez años: «[c]onocer los tratamientos, minimizar los datos, limitar los accesos, corregir vulnerabilidades, controlar a los proveedores y estar preparados para responder». Y pide también revisar los tiempos de respuesta y reforzar el control sobre identidades y credenciales.

Fíjate en los seis verbos: ninguno es nuevo. Lo nuevo es el adverbio. Expresamente. Un análisis de riesgos que no nombra un escenario no lo cubre, y hasta ahora la ausencia no se veía; desde el 14 de septiembre hay un precedente publicado por la autoridad, y la ausencia se lee distinto. La propia AEPD remite, para el detalle técnico, a la guía CCN-CERT BP/36 del Centro Criptológico Nacional, de junio de 2026, cuyo planteamiento central es que la IA ofensiva permite «automatizar, acelerar y ampliar a gran escala ataques ya conocidos». Conviene leer las tres últimas palabras: ya conocidos.

Y no, esto no se arregla comprando algo con «IA» en el nombre

Lo previsible es que este titular se convierta en argumento de venta durante el otoño, así que digamos la parte que no vende. De las cuatro fases, tres se paran con cosas que ya podías haber hecho el año pasado: quitar de la raíz del servidor los ficheros que no deberían estar publicados, poner un segundo factor en la autenticación, y tener un sitio donde los cambios a los datos queden escritos y no se puedan borrar desde la aplicación. Ninguna de las tres lleva IA. Ninguna de las tres es cara. Las tres son aburridas, y es exactamente por eso por lo que siguen pendientes en tantos sitios.

Y ahora la parte que nos toca decir aunque no nos convenga. Si eres una empresa de quince personas con una aplicación de gestión, no necesitas un SIEM. Nosotros monitorizamos con Zabbix y SmokePing, en nuestra propia plataforma y en la de clientes, y la regla con la que los operamos es una sola: alertas que importan, no ruido. Montar un SIEM para cumplir una recomendación es la forma más eficaz que conocemos de acabar con un panel en rojo permanente que nadie mira, y eso es peor que no tenerlo: la alerta que se ignora todos los días enseña a ignorar la que importa. Empieza por retención y por dejar los cambios escritos; la correlación viene después, y si no hay nadie que la vigile a las cuatro de la mañana, viene delegada en alguien que sí esté o no viene. Decidirlo al revés es cómo se compran tecnologías que acaban apagadas a los seis meses.

La prueba de la media hora

Cinco preguntas, con una regla: cada respuesta tiene que ser un número, un nombre de fichero o un nombre de sistema. Un «sí» no cuenta como respuesta.

Si tres de las cinco respuestas son «habría que mirarlo», el trabajo que tienes pendiente no es de seguridad. Es de registro. Y son dos presupuestos muy distintos.

El listón que deja esta notificación

El titular dice que la IA ya ataca sola, y es verdad. Lo que dice la notificación leída despacio es algo menos espectacular y bastante más útil: que hubo una organización capaz de contar con precisión, por fases y en orden, lo que le había pasado. Ese es el listón que deja el 14 de septiembre, y no tiene nada que ver con comprar. Casi todas las conversaciones que tenemos empiezan al revés, con un «creemos que entraron por ahí», y esa frase, en el formulario de la Sede Electrónica, no se puede escribir.

Sobre la velocidad del otro lado ya escribimos hace unas semanas, cuando el problema dejó de ser encontrar el fallo y pasó a ser el calendario de después. Esto es la otra mitad de lo mismo: si el atacante no duerme, tu ventaja no está en correr más. Está en poder reconstruir lo que pasó sin depender de la memoria de nadie.

Fuentes (verificadas el 26-09-2026): la descripción literal de las cuatro fases, el condicional «habría sido ejecutada», la advertencia de que la información «deberá ser objeto del correspondiente análisis», la definición genérica de agente, la mención a «un conocido modelo de lenguaje» y las recomendaciones citadas — entrada del blog de la AEPD del 14-09-2026, firmada por Francisco Pérez Bes; su cargo de adjunto a la Presidencia de la AEPD (Real Decreto 143/2025, toma de posesión el 03-03-2025) no consta en esa entrada, sino en la nota de prensa de la propia Agencia. El plazo de 72 horas desde que la organización tiene constancia, el formulario de la Sede Electrónica y las obligaciones del artículo 33.3 del RGPD, y el deber de documentar «los hechos relacionados con ella, sus efectos y las medidas correctivas adoptadas» — página de brechas de seguridad de la AEPD. La frase «automatizar, acelerar y ampliar a gran escala ataques ya conocidos» y el planteamiento de la guía — nota del Laboratorio de la AEPD; la fecha de la guía, en la portada de la propia CCN-CERT BP/36 («Guía de seguridad, junio 2026»). Lo que es nuestro y no de las fuentes: la conjetura de que el «login correcto» pueda venir del barrido de archivos genéricos (marcada como conjetura en el texto), la lista de registros por fase, las señales para inferir automatismo, la advertencia sobre el SIEM y las cinco preguntas. Nuestra experiencia con Zabbix y SmokePing en producción está en lo que hacemos, no en un estudio: no la presentamos como estadística. La AEPD no publica el nombre de la organización, el sector, la duración ni el número de afectados, y este artículo no los suple. Foto de portada: «Archivmagazin Schweizerisches Wirtschaftsarchiv 01», Wikimedia Commons (CC0).