En España se ha notificado por primera vez una brecha de datos personales en la que, según se indica, se ejecutó un ataque con un agente de IA. Este artículo explica cómo encuadrar la obligación de notificación de una brecha de datos con agente de IA, cuándo empiezan a correr las 72 horas y qué preparativos conviene tener hechos para no improvisar bajo presión.
El 14 de septiembre de 2026 se hizo público en España que, por primera vez, se había notificado a una autoridad de protección de datos un ataque ejecutado con un agente de IA. Esto plantea una pregunta práctica: ¿quién debe hacer qué cuando interviene un agente de IA, ya sea como herramienta de ataque de terceros o como herramienta propia de la empresa? Se trata de la obligación de notificación, los plazos, los registros y los procedimientos para el caso de emergencia.
El caso de la AEPD en resumen
En España, se ha notificado por primera vez una brecha de datos personales en la que, según se indica, se ejecutó un ataque con un agente de IA basado en un modelo de lenguaje conocido. Según el relato, el atacante buscó primero vulnerabilidades en archivos de acceso público y después inició sesión en el sistema objetivo. El agente encontró otras vulnerabilidades en la aplicación, modificó datos personales y accedió a facturas.
El reparto de papeles es importante. La empresa que notificó fue la víctima, y el agente fue la herramienta de los atacantes. No se trata, por tanto, del fallo de un agente que la propia organización hubiera operado. No se nombra ni a la organización ni al modelo. Del uso de un modelo conocido no se deduce que su proveedor o su infraestructura hayan sido comprometidos, y tampoco se dice que la herramienta se hubiera creado con fines dañinos. Además, un caso aislado no permite afirmar nada sobre una tendencia.
La IA no crea amenazas fundamentalmente nuevas, pero puede aumentar la velocidad, el alcance y la capacidad de adaptación de los ataques. De ahí se derivan consecuencias prácticas: los ataques con IA deben entrar en el análisis de riesgos, hay que revisar los tiempos de reacción pensados para ataques manuales, las credenciales con permisos excesivos requieren mejor protección y la supervisión humana necesita el apoyo de una detección y contención rápidas.
Cuándo un agente de IA provoca una brecha notificable
La obligación de notificar las brechas de datos causadas por agentes de IA no depende de la tecnología, sino del resultado. Según el art. 4, punto 12, del RGPD, existe una violación de la seguridad de los datos personales cuando una brecha de seguridad provoca la destrucción, pérdida o alteración, la comunicación o el acceso no autorizados, ya sea de forma accidental o ilícita. Que detrás haya una persona, un script o un agente no influye en esta definición. Aun así, pueden distinguirse con claridad dos supuestos.
En el supuesto A, un agente ajeno ataca, como en el caso español. El acceso no autorizado y la modificación de datos constituyen la brecha, y con ella nace la obligación de notificar. Lo nuevo aquí es sobre todo la velocidad, no el encuadre jurídico. En el supuesto B, el agente propio causa la brecha. Puede ser un agente de atención al cliente que envía datos a la persona equivocada, un agente de programación con permisos demasiado amplios o un agente de correo que reenvía contenidos tras una instrucción inyectada.
En el supuesto B, el encuadre no siempre es evidente. Si el agente ha hecho exactamente aquello para lo que se configuró y ninguna persona no autorizada ha obtenido acceso, a menudo falta una brecha de seguridad. En cambio, si los datos llegan a destinatarios que no debían recibirlos, o si el agente accede a fondos de datos que deberían estar vedados para él, hay muchos indicios de una brecha. Hasta ahora apenas existen directrices específicas para agentes. La valoración sigue siendo, por tanto, una cuestión de cada caso y se rige por los criterios generales de las autoridades.
| Escenario | ¿Brecha? | Objetivo de protección afectado |
|---|---|---|
| Un agente ajeno inicia sesión sin autorización | Sí | Confidencialidad |
| Un agente ajeno modifica registros en la aplicación | Sí | Integridad |
| El agente propio envía facturas a destinatarios equivocados | Sí | Confidencialidad |
| El agente propio reenvía al exterior el contenido de un buzón tras una inyección de prompt | Sí | Confidencialidad |
| El agente propio borra registros sin copia de seguridad | Sí | Disponibilidad |
| El agente propio responde de forma incorrecta sin que salgan datos | Normalmente no | Ninguno, más bien un problema de calidad |
La cuestión central puede responderse así de forma breve.
¿Hay que notificar una brecha de datos con un agente de IA conforme al art. 33 del RGPD?
Umbral de riesgo y excepción a la notificación
No toda violación debe notificarse. El art. 33 del RGPD prevé una excepción cuando sea improbable que la violación entrañe un riesgo para los derechos y libertades de las personas físicas. El listón es, por tanto, bajo. Por regla general se notifica ya cuando no puede descartarse un riesgo. Quien omita la notificación debe poder justificar bien por qué no había riesgo.
En ataques e incidentes con agentes, hay muchos argumentos contra esta excepción. Los agentes suelen acceder a muchos registros a la vez, trabajan con rapidez y tienen acceso a áreas como facturas, cuentas de clientes o buzones de correo. Si un atacante modifica datos, además de la pérdida de confidencialidad surge un problema añadido: al principio nadie sabe qué registros siguen siendo correctos. Eso aumenta el riesgo para los afectados.
Para la valoración, las autoridades europeas de protección de datos han publicado directrices. Las directrices del CEPD sobre la notificación de violaciones de la seguridad de los datos personales citan como criterios, entre otros, el tipo de violación, la sensibilidad y el volumen de los datos, la facilidad para identificar a los afectados, la gravedad de las posibles consecuencias y el número de afectados. Si el riesgo es alto, se añade la comunicación a los afectados conforme al art. 34 del RGPD. Este paso es independiente de la notificación a la autoridad y tiene sus propios requisitos.
La responsabilidad recae en el operador
Un agente es una herramienta, no un sujeto de derecho. Sigue siendo responsable quien decide sobre los fines y los medios del tratamiento, es decir, la empresa que emplea el agente. No basta con remitirse al modelo, a la plataforma o al departamento especializado. Aunque un agente actúe de forma autónoma, el tratamiento se atribuye al operador.
El agente es una herramienta, la responsabilidad sigue siendo del operador.
Si una plataforma o un proveedor de modelos opera el agente por encargo, suele actuar como encargado del tratamiento. Entonces se aplica el art. 33, apartado 2, del RGPD: el encargado debe notificar al responsable una violación sin dilación indebida en cuanto tenga conocimiento de ella. El plazo del responsable, sin embargo, solo empieza con su propio conocimiento. Por eso, los contratos deberían regular en qué plazo y por qué canal se comunican los incidentes. Un aviso que acaba tras varios días en un buzón genérico no ayuda a nadie.
| Parte implicada | Papel en un incidente con agentes |
|---|---|
| Operador del agente | Responsable del tratamiento, notifica a la autoridad de control y documenta |
| Plataforma de agentes | Con frecuencia encargado del tratamiento, informa al operador sin dilación indebida |
| Proveedor del modelo | Según la arquitectura, encargado o subencargado del tratamiento; también debe informar si resulta comprometido |
| Departamento especializado | Detecta y comunica internamente, sin decidir por sí mismo |
| Otros proveedores de servicios | Aportan registros e indicios para la valoración |
Si un atacante entra a través de un proveedor de servicios, rigen los mismos principios que en cualquier incidente de la cadena de suministro.
Contar bien las 72 horas
Conforme al art. 33, apartado 1, del RGPD, el plazo corre desde el momento en que el responsable tiene constancia de la violación. La notificación debe hacerse sin dilación indebida y, de ser posible, en un plazo de 72 horas. Según las directrices del CEPD, hay conocimiento cuando el responsable tiene un grado razonable de certeza de que un incidente de seguridad ha dado lugar a una violación de la seguridad de los datos personales. Se admite un breve período de comprobación para aclarar una sospecha. La inactividad, no.
Con los agentes, el cuello de botella se desplaza. Un agente puede consultar o modificar miles de registros en minutos. Que el incidente se detecte el mismo día o solo después de una semana depende entonces de la supervisión y de las alertas. Los agentes que funcionan de noche o en fin de semana agravan el problema. Quien solo advierte las anomalías al volver a mirar un panel pierde un tiempo que el plazo no contempla. Aquí pesan especialmente el tiempo de detección y la cuestión de quién puede reaccionar fuera del horario de oficina.
Con los agentes, las 72 horas son sobre todo una cuestión de tiempo de detección.
La ley permite notificar por fases. Si aún no se dispone de toda la información, esta se facilita después, sin más dilación indebida, conforme al art. 33, apartado 4, del RGPD. Si se supera el plazo, debe justificarse el retraso. Como orientación puede servir la siguiente secuencia.
Los plazos son valores orientativos. Lo decisivo es que cada fase tenga a alguien que la ponga en marcha y que la decisión sobre la notificación no dependa de la disponibilidad de una sola persona.
Registrar las acciones de los agentes
Sin registros apenas puede cuantificarse el alcance de una violación. Con los agentes esto es especialmente delicado, porque ejecutan muchas acciones individuales que por sí solas parecen inofensivas. Un buen registro responde a cuatro preguntas: ¿quién actuó, qué se hizo, a qué datos se accedió y adónde fueron? A ello se suma la obligación de documentación del art. 33, apartado 5, del RGPD, que afecta a toda violación, también a la que no se notifica.
| Campo del registro | Utilidad para la notificación | Nota sobre minimización de datos |
|---|---|---|
| Identidad y versión del agente | Asigna el incidente a un sistema y una configuración | Basta un identificador técnico |
| Encargo y desencadenante | Aclara si la acción la inició una persona, una programación o una entrada externa | Descripción breve en lugar del texto íntegro |
| Accesos a herramientas y datos | Muestra el tipo y el alcance de los datos afectados | Categorías y volúmenes en lugar de contenidos |
| Marcas de tiempo | Base para el conocimiento y el cálculo del plazo | Sin problemas |
| Sistemas de destino y destinatarios | Muestra adónde han llegado los datos | Direcciones solo si es necesario |
| Errores e interrupciones | Indicios de intentos de ataque y de fallos de funcionamiento | Sin problemas |
| Autorizaciones de personas | Acredita la supervisión y las vías de decisión | Solo el identificador de la instancia que autoriza |
Para el registro de agentes se aplica lo siguiente: los propios registros contienen datos personales y deben protegerse. El acceso debe limitarse a pocas personas y las entradas deberían guardarse a prueba de manipulaciones, por ejemplo en un sistema aparte. El plazo de conservación es una cuestión de ponderación: lo bastante largo para poder reconstruir un incidente, lo bastante corto para no crear una colección de datos. Estas medidas forman parte de la seguridad del tratamiento conforme al art. 32 del RGPD. Los mismos registros ayudan además en las solicitudes de acceso. Cómo diseñar de forma razonable la supervisión de agentes de IA sin que los agentes eludan su propio control es un tema aparte.
Limitar permisos y credenciales
El caso español muestra cómo actúa un atacante con un agente: busca archivos conocidos, accesos por defecto y vulnerabilidades cotidianas. Eso es exactamente lo que un agente puede hacer a velocidad de máquina y sin cansancio. Quien cierra esas brechas le quita al ataque buena parte de su ritmo. La autoridad cita expresamente como punto débil las cuentas, claves de API y tokens con permisos excesivos.
En la práctica se han acreditado unos pocos principios:
- Cada agente recibe su propia cuenta con los mínimos permisos necesarios.
- Las claves y los tokens son de corta duración y pueden revocarse de forma individual.
- Los accesos a muchos registros en poco tiempo se limitan y se notifican.
- Un interruptor de emergencia detiene a los agentes y bloquea sus accesos sin exigir consulta previa.
- Los archivos publicados, los accesos de prueba y las contraseñas por defecto se buscan y se eliminan con regularidad.
Estas medidas protegen frente a agentes ajenos y frente a errores de los propios. La magnitud del daño depende en gran medida de los permisos que se hayan concedido a un agente. Para la superficie de ataque de una aplicación web ayudan las comprobaciones automatizadas que detectan vulnerabilidades visibles antes de que lo hagan otros.
Revise su superficie de ataque
Los archivos expuestos, las protecciones ausentes y las fugas de datos en su propio sitio web pueden detectarse de forma automatizada.
Verificación RGPD del sitio web Verificación de seguridad web
Plan de respuesta ante ataques automatizados
Muchos planes de emergencia parten de un atacante que necesita horas o días. La autoridad propone revisar los tiempos de reacción diseñados para ataques manuales. La supervisión humana sigue siendo importante, pero necesita el apoyo de mecanismos que detecten, contengan y reaccionen con la suficiente rapidez. Un ataque automatizado no respeta la hora de salida.
Un plan sólido fija pocas cosas. Hay alertas para patrones de acceso inusuales, como muchas consultas desde la misma cuenta o inicios de sesión en horarios atípicos. Las cuentas pueden bloquearse automáticamente al superarse ciertos umbrales. Hay alguien localizable fuera del horario de oficina. Está claro quién decide sobre la notificación y quién la envía. El formulario de notificación de la autoridad de control está preparado y los datos de contacto del delegado de protección de datos están a mano. Para las primeras horas de un incidente merece la pena consultar el plan de actuación para los primeros 60 minutos, surgido para el ransomware pero aplicable a otros ataques.
Es bueno que el plan se haya practicado. Un ejercicio con un incidente de agente inventado, en el que una cuenta consulta datos en gran cantidad, muestra enseguida dónde falla algo: falta de guardias, responsabilidades poco claras, registros que no pueden analizarse. Esas lagunas pueden cerrarse en tiempos de calma, no en plena emergencia.
Preparar la notificación a la autoridad de control
El art. 33, apartado 3, del RGPD fija el contenido mínimo. Se describe la naturaleza de la violación, con el número aproximado de personas y de registros afectados, el nombre y los datos de contacto del delegado de protección de datos o de otro punto de contacto, las posibles consecuencias y las medidas adoptadas o propuestas. Por lo general es competente la autoridad de control del Estado donde la empresa tiene su sede. La mayoría de las autoridades ofrece un formulario en línea, y la Conferencia de Protección de Datos ofrece una visión de conjunto.
Con los agentes hay lagunas típicas. Sin registros no puede cuantificarse el alcance del acceso, y cuando se han modificado datos no está claro qué registros se han visto realmente afectados. Conviene aclarar de antemano cómo obtener una cifra fiable a partir de registros, copias de seguridad de bases de datos y versiones. Quien solo pueda estimar indica el intervalo y lo marca como provisional. La notificación posterior rellena después las lagunas.
Una breve lista de comprobación para la notificación:
- Momento del conocimiento y período del incidente
- Tipo de violación: acceso no autorizado, modificación, comunicación, pérdida
- Categorías de datos afectadas y número aproximado de personas y registros
- Papel del agente: herramienta de ataque ajena o agente propio
- Cuentas, claves y sistemas contenidos
- Posibles consecuencias para los afectados
- Decisión sobre la comunicación a los afectados
- Contacto del delegado de protección de datos
Si además se aplican obligaciones de notificación de otros regímenes, por ejemplo para operadores de infraestructuras críticas o derivadas del Reglamento de IA, depende de cada caso y debería constar en el plan de emergencia, para que la competencia no tenga que aclararse durante el incidente.
Conclusión
El primer caso notificado en España no muestra un concepto jurídico nuevo, sino un ritmo nuevo. Tanto si ataca un agente ajeno como si el propio agente comete un error, lo decisivo es si existe una violación de la seguridad de los datos personales y si hay un riesgo para los afectados. Entonces hay que actuar sin dilación indebida y, de ser posible, notificar en un plazo de 72 horas.
Breve lista de comprobación:
- Los agentes ajenos como atacantes y los agentes propios como causa son supuestos distintos con la misma valoración.
- La responsabilidad recae en el operador, incluso cuando participan plataformas y proveedores de modelos.
- El tiempo de detección decide si puede cumplirse el plazo.
- Unos buenos registros convierten una sospecha en una notificación sólida.
- Permisos mínimos, claves de corta duración y un interruptor de emergencia quitan ritmo y daño al ataque.
Me llamo Klaus Meffert. Soy doctor en informática y llevo más de 30 años dedicándome profesional y prácticamente a las tecnologías de la información. También trabajo como experto en informática y protección de datos. Obtengo mis resultados analizando la tecnología y el Derecho. Esto me parece absolutamente esencial cuando se trata de protección de datos digitales.
