Primera brecha atribuida a un agente de IA notificada a la AEPD: qué cambia en el análisis de riesgos

El 14 de septiembre, la Agencia Española de Protección de Datos informó en su blog de que había recibido la primera notificación de una brecha de datos personales causada por un ataque ejecutado mediante un agente de IA, apoyado en un conocido modelo de lenguaje. No ha trascendido qué organización la sufrió, a qué sector pertenece ni cuántas personas se han visto afectadas.

Según la Agencia, el agente empezó buscando vulnerabilidades en archivos genéricos y consiguió iniciar sesión. Una vez dentro, buscó por su cuenta fallos en la aplicación y, al encontrarlos, pudo modificar datos personales y acceder a facturas.

Esa información procede de la notificación de la organización afectada y, según la AEPD, deberá analizarse. La Agencia advierte también de que usar un modelo determinado no implica que el modelo o la infraestructura de su proveedor hayan sido comprometidos, ni que la herramienta se diseñara con fines maliciosos. Lo relevante, añade, es que un tercero habría utilizado el agente como instrumento para encadenar las fases del ataque.

Tal como se ha descrito, la secuencia sigue el guion de muchas intrusiones web de los últimos veinte años. Lo nuevo es la herramienta que la ejecuta y la lectura que hace el supervisor para la gestión de riesgos: los análisis de los tratamientos deben contemplar de forma expresa los ataques asistidos o ejecutados por IA. Responsables y encargados del tratamiento, con sus delegados de protección de datos, tendrán que revisar con ese criterio los análisis vigentes.

¿Qué se sabe de la primera brecha atribuida a un agente de IA?

Entre la entrada de la Agencia, la bitácora de INCIBE-CERT del 24 de septiembre y la información de Infobae basada en EFE, lo publicado se resume en seis puntos:

1. Ejecución: un agente de IA basado en un modelo de lenguaje cuyo nombre no se ha hecho público.
2. Reconocimiento: búsqueda de vulnerabilidades en archivos genéricos.
3. Acceso: un inicio de sesión correcto, sin que se haya explicado cómo lo consiguió.
4. Explotación: localización y aprovechamiento autónomos de fallos dentro de la aplicación.
5. Impacto: modificación de datos personales y acceso a facturas, que Infobae describe como facturas de terceros.
6. Estado: la AEPD sigue analizando la información y no ha publicado conclusiones.

Quedan fuera del relato público la identidad de la organización, el número de afectados, el volumen de datos, si el acceso se contuvo y si los datos modificados se restauraron. INCIBE-CERT señala esos mismos puntos como no divulgados y añade que tampoco se ha confirmado que el modelo o la infraestructura de su proveedor se vieran comprometidos.

El caso no debe leerse como el primer ataque de este tipo en España. Es el primero notificado a la AEPD como tal, y para eso la organización tuvo que detectarlo e identificar que detrás había un agente. Puede haber otros que nadie haya atribuido a una IA.

¿A qué tipo de fallo apunta la secuencia?

La Agencia no detalla la vulnerabilidad, así que lo que sigue es una lectura técnica y no un hecho confirmado. Los «archivos genéricos» apuntan a rutas que existen en muchas aplicaciones: ficheros de configuración, copias de seguridad, registros o documentación olvidada en el servidor. Si el acceso se hizo con credenciales, estas pudieron salir de ahí, aunque nadie lo ha afirmado. Caben otras vías, como contraseñas filtradas en otro servicio o robadas por un infostealer, o un fallo en el mecanismo de inicio de sesión.

La fase posterior sería compatible con una pérdida de control de acceso, el primer riesgo del OWASP Top 10 2025. Si fue así, la aplicación comprobaba quién había iniciado sesión, pero no si el registro consultado o modificado pertenecía a ese usuario. Recorrer miles de identificadores de factura ya se automatizaba con un script; lo que añade el agente es leer cada respuesta y ajustar la siguiente petición sin que nadie lo guíe. Explicamos por qué este tipo de fallo sigue encabezando la lista en el OWASP Top 10 2025 visto desde el pentest.

La AEPD lo resume así: «la IA no crea nuevas amenazas. Pero sí aumenta la velocidad, escala y capacidad de adaptación de técnicas maliciosas ya conocidas». Es la misma pauta que vimos en el agente con DeepSeek que atacó unos 460 objetivos.

¿Qué pide la AEPD a responsables y encargados?

La entrada del blog, firmada por Francisco Pérez Bes, adjunto de la AEPD, extrae cuatro consecuencias para la gestión de riesgos. No es una guía ni una resolución, pero indica cómo lee el caso el supervisor:

1. Análisis de riesgos: nombrar específicamente los ataques en los que interviene la IA, porque una mención genérica a malware o acceso no autorizado se queda corta cuando la automatización «puede modificar sustancialmente la probabilidad, velocidad y alcance del incidente».
2. Tiempos de respuesta: revisar procedimientos pensados para ataques manuales, que pueden fallar ante un agente que analiza a la vez varios activos y prueba distintas vías de acceso.
3. Identidades: si un agente obtiene una cuenta, un token o credenciales de API con permisos excesivos, puede operar a velocidad de máquina y acceder a distintos servicios antes de que la organización detecte un comportamiento anómalo.
4. Detección: la supervisión humana sigue siendo imprescindible, pero necesita apoyarse en mecanismos de detección, contención y respuesta que actúen con suficiente rapidez.

La Agencia remite además a la guía CCN-CERT BP/36, «Buenas prácticas frente al modelo de IA ofensiva», publicada por el Centro Criptológico Nacional el 23 de junio. Entre las prioridades de su decálogo figuran reforzar los controles esenciales, acelerar la gestión de vulnerabilidades, asegurar identidades y accesos, gobernar el uso de la IA, proteger la cadena de suministro y mantener la supervisión humana sobre la automatización.

¿Cómo se incorpora un ataque ejecutado por IA al análisis de riesgos del RGPD?

Un ataque ejecutado por IA se incorpora al análisis de riesgos revisando cuatro parámetros de cada tratamiento expuesto a internet: probabilidad, ventana de reacción, alcance de las credenciales e integridad. Añadir al registro de amenazas una fila titulada «ataque con IA» sirve de poco.

La probabilidad sube para los fallos que antes exigían paciencia, como enumerar identificadores o manipular parámetros uno a uno. Si probar apenas cuesta, la hipótesis de que «nadie se va a tomar la molestia» deja de sostenerse.

La ventana de reacción se estrecha. Un control que depende de revisar registros cada semana presupone un atacante lento; los plazos de revisión y respuesta deben medirse en horas.

El alcance de cada credencial pasa a primer plano. Para cada cuenta de servicio, token o clave API hay que saber qué datos puede leer y cuáles puede cambiar, porque es lo que un agente puede averiguar con rapidez.

La integridad entra en el cálculo. En este caso hubo modificación de datos, y el artículo 4.12 del RGPD incluye la alteración ilícita en la definición de violación de la seguridad, junto al acceso no autorizado. El artículo 32 obliga a aplicar medidas adecuadas al riesgo, teniendo en cuenta el estado de la técnica. Su apartado 2 menciona la alteración entre los riesgos que deben valorarse, y el 32.1.d incluye, cuando proceda, la verificación regular de la eficacia de esas medidas. Si el tratamiento tiene una evaluación de impacto, el artículo 35.11 pide revisarla cuando cambia el riesgo.

¿Con qué controles se frena un ataque de este tipo?

Cinco controles cubren las fases descritas: exposición del servidor, credenciales, autorización, detección y recuperación.

El primer frente es lo que el servidor deja ver. Un inventario periódico de rutas y ficheros accesibles desde fuera, con retirada de copias, configuraciones y registros olvidados, quita al agente su punto de partida. Es el trabajo habitual de una revisión de superficie de ataque.

Las credenciales van después: doble factor en las cuentas de usuario con acceso a datos personales, secretos guardados en un gestor y fuera de los ficheros accesibles del servidor, y tokens de vida corta con el mínimo privilegio para las cuentas de servicio. Nuestra guía sobre identidades no humanas detalla cómo tratar claves API y cuentas de servicio, y el glosario explica qué hacer con credenciales comprometidas.

La autorización debe comprobarse objeto a objeto. Una auditoría de aplicaciones web o de API que pruebe, con dos usuarios distintos, si uno puede leer o cambiar los registros del otro puede detectar el tipo de fallo que, según nuestra hipótesis, aprovechó este agente.

La detección tiene que reconocer la actividad automatizada, venga de un agente o de un escáner convencional: ráfagas de peticiones desde una misma sesión, identificadores recorridos en orden, muchos errores 403 o 404 seguidos y modificaciones en serie. Que las peticiones cambien en función de las respuestas anteriores apunta más a un agente. Un SOC con analítica de comportamiento puede revocar la sesión automáticamente y dejar la revisión para el analista.

Por último, la recuperación. Registrar cada cambio en datos personales con su valor anterior permite saber qué se alteró y restaurarlo, y el plan de respuesta a incidentes debe prever brechas de integridad, no solo robos de información.

¿Cambia la notificación si el atacante es un agente?

No. Las obligaciones de notificación del RGPD son las mismas. El artículo 33 exige notificar a la autoridad de control sin dilación indebida y, de ser posible, en 72 horas desde que se tiene constancia de la brecha, salvo que sea improbable que constituya un riesgo para los derechos y libertades de las personas. Si el tratamiento lo lleva un encargado, este debe avisar al responsable sin dilación indebida. Cuando el riesgo es alto, el artículo 34 añade, por regla general, la comunicación a los afectados.

El registro de la brecha que exige el artículo 33.5 debería recoger, además, los indicios de automatización, el modelo si se ha podido identificar, los datos modificados y cómo se han restaurado. Con esa información, la autoridad entiende mejor el caso y la organización puede demostrar su diligencia. Las directrices 9/2022 del CEPD sobre notificación de brechas distinguen entre violaciones de confidencialidad, integridad y disponibilidad, y, según lo notificado, este caso reúne al menos las dos primeras.

Si los registros permiten identificar al proveedor del modelo, avisarle por su canal de abusos puede ayudar a bloquear la cuenta utilizada, compartiendo solo los datos personales imprescindibles. En nuestro análisis de los avisos de brecha vimos que en Estados Unidos cada vez menos explican cómo entró el atacante; en un caso así, esa explicación es lo más útil del expediente.

Las seis pautas básicas que recuerda la AEPD

La AEPD cierra su entrada con una lista que sirve de índice para una revisión de este tipo: «conocer los tratamientos, minimizar los datos, limitar los accesos, corregir vulnerabilidades, controlar a los proveedores y estar preparados para responder». El primer paso es abrir el análisis de riesgos de cada tratamiento expuesto a internet y comprobar si alguna de sus valoraciones da por hecho un atacante humano y paciente.

Este análisis se basa en la información publicada hasta el 27 de septiembre de 2026 por la AEPD, INCIBE-CERT y los medios citados. La organización afectada, el modelo utilizado y el tipo exacto de vulnerabilidad no se han hecho públicos, y la lectura técnica del fallo es una hipótesis del autor. El texto no constituye asesoramiento jurídico ni atribuye el incidente a fallos de productos o proveedores determinados.