Un agente de Inteligencia Artificial (en adelante, IA) comenzó examinando posibles fallos en archivos genéricos y, rastreando defectos en estos archivos fue capaz de acceder a la aplicación. Es decir, analizando los archivos consiguió, a través de un log correcto, acceder a la aplicación y, una vez dentro, pudo modificar datos personales y acceder a facturas de manera autónoma, es decir, por su propia cuenta.
Así lo ha dado a conocer la Agencia Española de Protección de Datos (en adelante, AEPD o la Agencia) el pasado 14 de septiembre al informar de que había recibido la primera notificación de una brecha de datos personales en la que el ataque habría sido ejecutado por un agente de IA apoyado en un modelo de lenguaje conocido.
En este comunicado, la Agencia parte de una posición prudente indicando que la información que ostentan proviene directamente de la entidad afectada y que todavía debe analizarse en detalle. Desde esta prudencia, la AEPD indica que, pendiente de analizar en detalle tal información facilitada por la organización afectada; que se utilizara un modelo concreto no implica que ese modelo o la infraestructura de su proveedor hayan sido comprometidos, ni que la herramienta se diseñara con fines maliciosos.
Aun con todo y desde un enfoque en protección de datos, en la línea de lo señalado por la AEPD, los ataques derivados del uso de IA o riesgos consecuentes de su uso ya no son solo un posible teórico, sino que son riesgos que pueden materializarse y afectan a tratamientos de datos reales.
Como señala la AEPD lo relevante no es únicamente el hecho de que se realicen ciberataques mediante el uso de IA, en otros escenarios hemos podido observar como modelos generativos suplantan identidades, analizan códigos, intervienen en campañas fraudulentas… todo ello bajo la directriz o gestión por parte de una persona física.
En este caso, la novedad está en que la actuación no tiene la base en una persona física, sino en un agente de IA, es decir, un agente de IA recibió un objetivo, planificó tareas, uso herramientas, interpretó los resultados que obtuvo y fue capaz de cambiar dichas directrices para acabar accediendo a la aplicación. Es decir, no se limitó a realizar el análisis de los archivos genéricos. Y, este punto, es jutos lo que describe la notificación y en donde la AEPD pone el foco: la IA no inventa amenazas ya existentes, pero multiplica la velocidad, la escala y la capacidad de adaptación de las que ya conocíamos, y, sobre todo, reduce el tiempo que tenemos para detectarlas y contenerlas.
Esta misma idea la comparte el Centro Criptológico Nacional en su Guía CCN-CERT BP/36: Buenas prácticas frente al modelo de IA ofensiva, publicada en junio de 2026. El documento advierte de que la IA ofensiva ya no es una amenaza emergente, sino una capacidad operativa integrada en campañas reales, tanto criminales como estatales, y propone responder con cuatro fundamentos: reforzar los controles básicos (identidades, segmentación, monitorización continua, control de accesos), rediseñar los procesos para que la seguridad nazca con ellos, construir sistemas resilientes y seguros por defecto, y usar la IA como herramienta defensiva gobernada, con supervisión humana y trazabilidad.
Cabe mencionar esta Guía porque el Centro Criptológico Nacional resume en ella un conjunto de prioridades que cualquier responsable del tratamiento debe conocer: controles esenciales, gestión de vulnerabilidades más rápida, identidades protegidas, cadena de suministro bajo control y gobierno del uso de agentes.
Por ello, de la lectura de esta Guía del Centro Criptológico Nacional junto con la información publicada por la AEPD tras esta primera notificación brecha de datos personales en la que el ataque habría sido ejecutado por un agente de IA, lo importante, más que la tecnología, es el escenario de gestión de riesgos que dibuja la AEPD que a continuación detallamos, junto con la importancia de una buena actuación del responsable del tratamiento.
- La posibilidad de ataques realizados mediante IA debe incluirse expresamente en el análisis de riesgos que realice el responsable del tratamiento con cada tratamiento de datos en el que se detecte dicha posibilidad, en la línea de lo exigido en el Reglamento General de Protección de Datos en sus artículos 24, 32 y 35.
En este sentido, una mención genérica a malware, phishing o acceso no autorizado no refleja que la automatización puede cambiar la probabilidad, la velocidad y el alcance del incidente.
- Entre las diferentes medidas que debe adoptar el responsable del tratamiento, es conveniente, con cierta periodicidad o frecuencia, revisar los tiempos de respuesta ante incidentes o brechas de seguridad.
Aunque el plazo legal para notificar es de 72 horas, en ocasiones, es límite legal de plazo puede pasar a un segundo plazo si la organización es capaz de detectar, contener y responder en el tiempo adecuado y de la manera más garantista posible para reducir el impacto de dicho incidente.
Para ello, será necesario revisar los procedimiento y tener en cuenta los riesgos derivados del uso de agentes de IA, así como las medidas necesarias para actuar ante los posibles incidentes causados por estos agentes, teniendo en cuenta la inmediatez y rapidez con la que actúan para, en respuesta, poder actuar a la misma velocidad.
- Las cuentas y formas de acceso a las plataformas y/o aplicaciones deben configurarse cada vez con un mayor rigor. Si un agente consigue una cuenta o una clave API, puede acceder rápidamente a distintos servicios sin levantar sospechas. Esto fue lo que sucedió en el caso analizado, el ataque comenzó con un acceso legítimo al sistema. cada vez más importancia.
Para reducir estos riesgos, el Centro Criptológico Nacional recomienda utilizar sistemas de autenticación más seguros, emplear credenciales temporales en lugar de claves permanentes y mantener un registro actualizado de todas las identidades con acceso, incluidas las de los propios agentes.
En definitiva, la seguridad de los tratamientos no puede depender solo de la intervención manual. Y,aunque, la supervisión humana sigue siendo imprescindible, necesita apoyarse en mecanismos de detección, contención y respuesta capaces de moverse a la misma velocidad que el ataque. Por ello, gobernar estos agentes de IA es parte de la protección de datos. La tecnología que ejecutó el ataque analizado es la misma que muchas organizaciones están incorporando a sus procesos, con cuentas, claves y permisos para actuar por su cuenta, es decir, en sus tratamientos de datos de carácter personal. Y, ante esto, será determinante que una entidad, ante el uso de dichos agentes de IA, hay adecuado correctamente que dichos agentes de IA o sistemas de IA cumplan, no solo las exigencias del Reglamento de Inteligencia Artificial, sino que estén también bajo el paraguas de las obligaciones en materia de protección de datos.
Esta misma idea la recoge el Centro Criptográfico Nacional cuando señala las pautas específicas que debe adoptar toda organización para garantizar un uso seguro: mínimo privilegio, autonomía limitada, identidad única por agente, control humano en las decisiones críticas y registro completo de lo que hacen. A lo que podemos añadir lo indicado por la AEPD, los sistemas de automatización deben desplegarse como usuarios no confiables, con puntos de control humano, interruptores para detenerlos y capacidad de operar en modo degradado con procedimientos manuales.
En definitiva, este comunicado de la AEPD pone de manifiesto que la llegada de los agentes de IA no cambia en sí los principios básicos de la protección de datos, sino que aumenta la necesidad de aplicarlos de una manera más eficaz, recalcando nuevamente el principio de responsabilidad proactiva que debe regir en todo responsable del tratamiento.
Las organizaciones deben anticiparse a estos nuevos riesgos, reforzar sus controles y adaptar sus medidas de seguridad a un entorno en el que los ataques pueden ejecutarse de forma cada vez más rápida y autónoma. De nuevo, la clave no está solo en reaccionar cuando se produce un incidente, sino en estar preparados para prevenirlo, detectarlo y contenerlo a tiempo.
