La primera brecha ejecutada por un agente de IA
El pasado 14 de septiembre la AEPD publicó en su blog una entrada firmada por su adjunto a la presidencia, Francisco Pérez Bes, dando cuenta de la primera notificación de una brecha de datos personales en la que el ataque habría sido ejecutado mediante un agente de inteligencia artificial apoyado en un modelo de lenguaje de uso general. No es una noticia tecnológica. Es un hecho con consecuencias jurídicas directas para cualquier organización que trate datos personales, y quiero explicar cuáles.
Los hechos y sus límites
Según la notificación de la organización afectada, el agente comenzó buscando vulnerabilidades en archivos genéricos, consiguió un inicio de sesión válido y, ya dentro del sistema, continuó explorando fallos de la aplicación de forma autónoma hasta modificar datos personales y acceder a facturas.
La Agencia advierte de que esta información procede del propio responsable y está pendiente de análisis, y aclara que el uso de un modelo concreto no implica compromiso alguno del proveedor ni diseño malicioso de la herramienta. No conocemos el sector, la escala ni el número de afectados. Cualquier afirmación que vaya más allá es conjetura.
Por qué esto es distinto
La IA lleva tiempo asistiendo a atacantes en tareas concretas: redactar phishing verosímil, analizar código, localizar vulnerabilidades. Lo nuevo es la autonomía. Un agente recibe un objetivo, planifica, utiliza herramientas, ejecuta código, interpreta resultados y corrige su rumbo sin intervención humana. En este caso, un tercero habría delegado en él todas las fases del ataque, y el agente las habría encadenado con éxito.
La AEPD tiene razón al no hablar todavía de tendencia, y la tiene también al calificarlo como señal significativa. Es la misma lectura que hace el CCN-CERT en su guía sobre IA ofensiva: la IA no inventa amenazas nuevas, pero multiplica la velocidad, la escala y la capacidad de adaptación de las que ya conocíamos, y reduce el tiempo disponible para detectarlas y contenerlas.
Consecuencias jurídicas: qué cambia y qué no
Aquí es donde conviene ser precisos. El RGPD no contiene una categoría de “brecha causada por IA”. Las obligaciones son exactamente las mismas que ayer. Lo que cambia es el contenido concreto que esas obligaciones exigen a partir de ahora.
Cuatro apuntes.
- Primero, el art. 32 RGPD obliga a adoptar medidas apropiadas al riesgo teniendo en cuenta el estado de la técnica. Desde el momento en que la autoridad de control publica que este tipo de ataque se ha materializado y el CCN lo documenta, pasa a formar parte de ese estado de la técnica. Un responsable que sufra un incidente análogo dentro de seis meses difícilmente podrá sostener que era imprevisible. Y el art. 83.2.d) permite valorar el grado de responsabilidad atendiendo a las medidas técnicas y organizativas aplicadas. Ese es el terreno en el que se decidirá la sanción.
- Segundo, el art. 35 y el principio de responsabilidad proactiva del art. 5.2. Los análisis de riesgos y las evaluaciones de impacto que hoy mencionan de forma genérica el malware, el phishing o el acceso no autorizado se han quedado cortos. La automatización altera la probabilidad, la velocidad y el alcance del daño, que son precisamente las variables que determinan el nivel de riesgo. Habrá que revisarlas y documentar esa revisión.
- Tercero, los arts. 33 y 34. El plazo de 72 horas no se mueve, pero la ventana real de detección se estrecha. Las Directrices 9/2022 del CEPD ya exigen que el responsable tenga capacidad de detectar y valorar con rapidez. Un procedimiento de gestión de brechas diseñado para un atacante humano y secuencial no cumple ese estándar frente a un agente que analiza varios activos a la vez y prueba distintas vías de acceso simultáneamente.
- Cuarto, el art. 28 y la cadena de encargados. Si el vector de entrada es una credencial, una clave API o un token con permisos excesivos, la exposición se traslada a cada proveedor con acceso a los sistemas. Los contratos de encargo, las auditorías a proveedores y la revisión periódica de accesos dejan de ser trámites documentales.
El dato que más debería preocupar
El agente hizo un inicio de sesión válido. Es decir, no rompió nada: entró con credenciales que funcionaban. Eso convierte la gestión de identidades en el núcleo del art. 32: mínimo privilegio, autenticación reforzada, caducidad y rotación de credenciales, y supervisión de comportamiento anómalo capaz de reaccionar a velocidad de máquina. La supervisión humana sigue siendo imprescindible, pero ya no puede ser la única línea de defensa.
Lo que queda abierto
Tres cuestiones. La primera, los agentes propios: si un agente ajeno puede hacer esto, un agente desplegado por la propia organización con permisos amplios plantea un riesgo interno de idéntica naturaleza, y las orientaciones de la AEPD sobre IA agéntica de febrero de 2026 deberían aplicarse con el mismo rigor.
La segunda, sectorial: en sanidad, un ataque que modifica datos y no solo los lee compromete la integridad clínica, con implicaciones que exceden el RGPD y alcanzan a la responsabilidad asistencial. La tercera, procesal: cómo valorará la AEPD la diligencia de una organización cuya detección llegó cuando el agente ya había alterado datos. Ese expediente sentará criterio.
Conclusión
La pregunta que hoy debería hacerse cualquier responsable no es si tiene antivirus. Es si podría demostrar ante la AEPD, con documentos y fechas, que su análisis de riesgos, su control de credenciales y su procedimiento de respuesta estaban preparados para un atacante que no se cansa, no repite errores y no espera a ser detectado. Quien no pueda responder con seguridad ya sabe por dónde empezar.
