Qué ha pasado
La Agencia Española de Protección de Datos ha recibido una notificación de brecha de datos personales que no había recibido nunca. El ataque lo habría ejecutado un agente de inteligencia artificial. Lo contó el 14 de septiembre Francisco Pérez Bes en el blog de la Agencia.
La secuencia que describe la AEPD es corta y conviene leerla entera. El agente atacante inició una búsqueda de vulnerabilidades en archivos genéricos y realizó un inicio de sesión correcto. Ya dentro del sistema, siguió buscando por su cuenta vulnerabilidades en la aplicación. Lo que encontró le permitió modificar datos personales y acceder a facturas.
Un agente de inteligencia artificial es un programa al que le das un objetivo en vez de una lista de órdenes. Él decide los pasos intermedios, usa herramientas, mira el resultado y cambia de plan si lo que intentó no funcionó. Esa es la diferencia con los ataques automatizados de siempre, que ejecutan un guion escrito de antemano y se paran cuando el guion se acaba.
La propia Agencia pone el freno de mano antes de que nadie saque conclusiones. La información sale de la notificación que presentó la organización afectada y está pendiente de análisis. El agente se apoyó en un modelo de lenguaje conocido. La AEPD avisa de que eso no implica que el modelo ni la infraestructura de su proveedor hayan sido comprometidos. Tampoco que la herramienta se diseñara para hacer daño.
El ataque no era nuevo; el reloj sí
Ninguno de los pasos de arriba es una técnica inédita. Buscar fallos conocidos, entrar con credenciales que funcionan y moverse hacia dentro es lo que se lleva haciendo años. La frase con la que la AEPD lo resume es la que hay que retener: «la IA no crea nuevas amenazas. Pero sí aumenta la velocidad, escala y capacidad de adaptación de técnicas maliciosas ya conocidas, reduciendo el tiempo disponible para detectarlas y contenerlas».
Eso es lo que cambia para tu negocio. Un atacante humano se para entre fase y fase. Tiene que mirar qué ha encontrado, probar otra cosa cuando una vía se cierra y decidir hacia dónde tira. Cada una de esas pausas es tiempo, y el tiempo es lo que permite que alguien vea algo raro en los registros del servidor y reaccione.
Un agente no hace esas pausas. Prueba muchas variantes seguidas, interpreta lo que le devuelven y sigue. Parte de lo que protegía a una web pequeña era, sin decirlo, que atacarla a mano costaba horas de alguien. Ese cálculo cambia cuando el que ataca no necesita las horas de nadie.
Entró con un inicio de sesión correcto
El detalle que más cuesta de digerir del caso es que el agente hizo un inicio de sesión correcto. No forzó la cerradura: usó una llave. Cómo consiguió esa llave no se ha publicado.
La AEPD dedica un párrafo entero a eso. Las identidades y las credenciales ganan peso, dice. Un agente que se hace con una cuenta puede recorrer varios servicios a velocidad de máquina antes de que nadie note nada. Vale igual para una credencial de API o para un permiso más amplio de lo que hacía falta.
En una web de una pyme, las llaves suelen estar en tres sitios. Las cuentas de las personas que entran al gestor de contenidos. Las credenciales de las conexiones con otros programas, que ya tratamos aparte en lo que tu web tiene conectado. Y los accesos técnicos creados un día para una migración o para dar de alta un servicio.
De los tres, el primero es el que puedes revisar tú esta semana sin ayuda de nadie. Abre el gestor de tu web y mira la lista de usuarios. Ahí suelen seguir personas que ya no trabajan contigo, la agencia que te hizo una campaña en 2023 o aquel becario que subía fotos al catálogo. Una cuenta que nadie usa es una cuenta que nadie vigila, y abre la misma puerta que el primer día.
Lo que corrige de verdad una actualización
El agente del caso encontró fallos en la aplicación una vez estuvo dentro. Aquí es donde el calendario de actualizaciones deja de ser papeleo.
Tu web está construida sobre un framework y sobre librerías, que son piezas de programación hechas por otros. Sus actualizaciones de seguridad existen porque alguien encontró un fallo y el fabricante lo ha tapado. Mientras tu web siga con la versión anterior, ese fallo sigue ahí y además ya es público. Es la parte del trabajo que un agente hace mejor que un humano: comprobar en cadena una lista larga de fallos conocidos, sin cansarse y sin saltarse ninguno.
En los proyectos que mantenemos nosotros, eso se traduce en una rutina con fecha. Los tres planes de mantenimiento de Galianet incluyen la actualización mensual de frameworks y librerías, y empieza por las de seguridad, que son las que corrigen las vulnerabilidades ya conocidas.
En los planes Profesional y Empresarial hay además una revisión del código con inteligencia artificial. Cuando aparece una nueva generación de modelos, revisamos con ella el código del proyecto. Buscamos errores de programación que puedan afectar a la seguridad y corregimos los que encontramos. No es una revisión periódica ni una auditoría de seguridad con informe: las correcciones que salen aparecen en las fichas de actualización que ya enviamos.
Es la otra cara de lo que contamos cuando un proyecto de código abierto revisó su propio código con tres modelos de IA y encontró, en sus palabras, un número significativo de problemas. La misma capacidad de leer código deprisa buscando fallos sirve para taparlos y para aprovecharlos.
Lo que la Agencia pide ahora
La petición de la AEPD va dirigida a responsables, encargados y delegados de protección de datos. Eso incluye tanto a la empresa que decide para qué se usan los datos como a la que los trata por encargo de otra. Pide incorporar expresamente los ataques asistidos o ejecutados mediante inteligencia artificial a los análisis de riesgos de los tratamientos. No basta con una referencia genérica a los programas maliciosos, al fraude por correo o al acceso no autorizado. Según la Agencia, esta automatización puede modificar sustancialmente la probabilidad, la velocidad y el alcance del incidente.
La Agencia remite también a una guía del Centro Criptológico Nacional sobre inteligencia artificial ofensiva, la BP/36. En palabras de la AEPD, esa guía recomienda cinco cosas. Reforzar los controles esenciales, acelerar la gestión de vulnerabilidades, proteger las identidades, controlar la cadena de suministro y gobernar el uso de agentes.
Lo que ya te obligaba antes de este caso
Si tu empresa no tiene un análisis de riesgos formal, esa petición de meter los ataques con inteligencia artificial en el análisis se traduce en dos preguntas con respuesta escrita. Si mañana alguien modifica datos de tus clientes en tu web, ¿en cuántas horas te enterarías, y a quién llamas?
La respuesta no la inventa este caso. Está en el Reglamento General de Protección de Datos, que se aplica desde el 25 de mayo de 2018. Lo que cambia con un atacante así es el reloj.
El Reglamento pide notificar la brecha a la Agencia sin dilación indebida y, de ser posible, en un máximo de 72 horas desde que tienes constancia de ella. El reloj arranca cuando te enteras. Solo te libras de notificar si es improbable que la brecha suponga un riesgo para los derechos y las libertades de las personas, y eso tienes que poder demostrarlo tú.
Llegar tarde o llegar con la mitad no te deja fuera. Si se te pasan las 72 horas, se notifica igual, indicando por qué se ha tardado. Y si todavía no sabes del todo lo que ha pasado, se notifica con lo que tengas y se completa después.
Cuando sea probable que la brecha suponga un alto riesgo para los derechos y las libertades de las personas afectadas, además hay que decírselo a ellas. El aviso va sin dilación indebida, en un lenguaje claro y sencillo, y con un contenido mínimo que el propio Reglamento detalla. Hay tres casos en los que ese aviso individual no hace falta. En uno de ellos, cuando avisar a cada persona supone un esfuerzo desproporcionado, el aviso no desaparece: se sustituye por una comunicación pública o por otra medida que informe igual de bien. Y en ninguno de los tres decides tú solo: si la Agencia considera probable ese alto riesgo, puede exigirte que avises a las personas. Ninguno de los tres te libra de notificar a la Agencia.
Avisar a la Agencia y avisar a las personas son obligaciones de quien decide para qué se usan los datos y cómo. Puede que esas decisiones no las tomes tú, porque tratas los datos por encargo de otra empresa que es la que puso las reglas. Entonces lo que te toca es avisarle a ella sin dilación indebida, y es ella quien se lo notifica a la Agencia.
Y hay una parte que no depende de que se notifique o no. Quien decide para qué se usan los datos documenta toda brecha: lo que pasó, qué efectos tuvo y qué hizo para corregirla. También cuando decide que no hace falta notificarla. Sirve para que la Agencia pueda comprobar que se ha cumplido el artículo, así que, si decidiste no notificar, es ahí donde tendrás que poder enseñar por qué.
Lo que este caso todavía no dice
Hay tres huecos en la información publicada, y van por delante de cualquier decisión que tomes.
No se sabe cómo obtuvo el agente unas credenciales válidas. Puede haber sido una contraseña filtrada, un correo de engaño o un acceso guardado donde no debía. Cada una de esas tres cosas se previene de una manera distinta.
Tampoco se publica qué organización fue ni de qué modelo de lenguaje se trata. Con lo que hay escrito no se puede saber qué parte del ataque venía de la herramienta y qué parte la puso quien la manejaba.
Y sigue siendo una sola notificación. La AEPD lo escribe con todas las letras: no permite afirmar una tendencia estadística, aunque sí es una señal significativa. Lo que sí permite afirmar es que esto ya ha pasado una vez, con datos personales de por medio.
Por dónde empezar esta semana
Tres cosas, las tres cortas. La primera es la lista de usuarios de tu gestor, para dar de baja a quien ya no tenga que estar. La segunda es preguntarle a quien lleva tu web con qué periodicidad aplica las actualizaciones de seguridad, y dónde queda escrito lo que se aplicó. La tercera es dejar escrito a quién llamas si mañana pasa, y en cuántas horas crees que te enterarías.
Las dos primeras se contestan hoy mismo, y son las que el caso de la AEPD deja encima de la mesa: por dónde entró y qué le dejó seguir avanzando. La tercera es la que no querrás estar improvisando el día que haga falta.
Fuentes
- «Primera notificación de una brecha de datos personales causada por un ataque ejecutado mediante un agente de IA», por Francisco Pérez Bes, blog de la Agencia Española de Protección de Datos, 14 de septiembre de 2026. https://www.aepd.es/prensa-y-comunicacion/blog/primera-notiviacion-brecha-datos-personales-causada-por-ataque-ejecutado-mediante-agente-ia
- «La AEPD notifica el primer ciberataque ejecutado de forma autónoma por un agente de IA en España», por Natalia Polo, WWWhat's new, 17 de septiembre de 2026. https://wwwhatsnew.com/2026/09/17/aepd-primer-ataque-autonomo-agente-ia-espana-datos-personales-facturas-2026/
¿Estás pensando en rehacer tu web o en un software a medida para tu negocio? Cuéntanos qué necesitas y te explicamos cómo lo haríamos y qué mantenimiento pediría después.
