España registra la primera brecha de datos notificada en la que un agente de IA habría ejecutado varias fases del ataque
España acaba de registrar una señal que puede marcar un antes y un después en la relación entre inteligencia artificial y ciberseguridad. La Agencia Española de Protección de Datos (AEPD) ha recibido la primera notificación de una brecha de datos personales en la que el incidente habría sido ejecutado mediante un agente de inteligencia artificial que utilizó un conocido modelo de lenguaje. No estamos hablando simplemente de un atacante humano que utilizó ChatGPT o cualquier otro modelo para pedir consejo sobre cómo vulnerar un sistema. Según la información comunicada a la Agencia por la organización afectada, el agente habría sido capaz de intervenir directamente en diferentes etapas del ataque: localizar vulnerabilidades, acceder al sistema, continuar buscando debilidades una vez dentro, modificar datos personales y consultar información de facturación, todo ello con una intervención humana limitada.
La AEPD ha sido especialmente prudente al presentar el caso. La información continúa bajo revisión, no se ha identificado públicamente ni a la organización afectada ni al modelo de lenguaje utilizado y el hecho de que un determinado modelo aparezca vinculado al incidente no significa que el propio modelo ni la infraestructura de su proveedor hayan sido comprometidos, ni que esa tecnología haya sido desarrollada para realizar actividades maliciosas. Lo relevante es otra cosa: un tercero habría utilizado un agente construido sobre un modelo de IA como mecanismo operativo para ejecutar automáticamente diferentes fases de un ataque real contra un sistema que contenía datos personales.
Del copiloto del atacante al agente que ejecuta el ataque
Hasta hace relativamente poco, el debate sobre inteligencia artificial y ciberseguridad se centraba principalmente en cómo los delincuentes podían utilizar modelos generativos para redactar correos de phishing, producir malware, encontrar vulnerabilidades o mejorar código malicioso. En ese escenario, la inteligencia artificial actuaba fundamentalmente como copiloto del atacante: proporcionaba información, código o recomendaciones, pero era la persona quien ejecutaba las operaciones. La aparición de agentes cambia esa arquitectura. Un agente puede recibir un objetivo, utilizar herramientas, navegar por sistemas, interpretar resultados, modificar su estrategia y continuar ejecutando acciones hasta conseguir el objetivo establecido.
El incidente notificado a la AEPD resulta especialmente interesante precisamente por esa autonomía. Según la información disponible, el agente consiguió autenticarse en el sistema y, una vez dentro, continuó explorando de forma autónoma la aplicación para localizar nuevas vulnerabilidades. Después de encontrar una debilidad, habría conseguido alterar información personal y acceder a registros de facturación.
La diferencia con un ciberataque tradicional asistido por IA es enorme. Un atacante humano puede pedir a un modelo: “analiza esta vulnerabilidad” o “escribe un script para realizar esta acción”. Un agente puede, potencialmente, encadenar el proceso completo: reconocimiento → identificación de vulnerabilidad → explotación → acceso → movimiento dentro del sistema → identificación de información relevante → modificación o extracción de datos. Cada resultado obtenido puede convertirse automáticamente en el contexto para decidir la siguiente acción.
Eso introduce un concepto que será cada vez más importante para las empresas: Agentic Cybersecurity. La misma arquitectura que permite utilizar agentes para automatizar procesos empresariales puede utilizarse también para automatizar procesos ofensivos.
La IA no crea necesariamente ataques nuevos: comprime radicalmente el tiempo del ataque
La propia AEPD introduce aquí una idea especialmente relevante. La inteligencia artificial no necesita inventar nuevas categorías de ciberataque para cambiar radicalmente la amenaza. Puede conseguirlo simplemente aumentando la velocidad, escala y adaptabilidad de técnicas que ya existen.
Esto modifica una de las variables fundamentales de la ciberseguridad: el tiempo.
Tradicionalmente, una organización podía disponer de minutos, horas o incluso días entre diferentes fases de una intrusión. El atacante tenía que reconocer el sistema, analizar lo encontrado, desarrollar o adaptar herramientas y decidir manualmente el siguiente paso. Un agente puede comprimir muchos de esos ciclos. Puede probar una acción, analizar inmediatamente el resultado, cambiar de estrategia y continuar sin descanso.
Esto significa que el concepto de Mean Time to Detect (MTTD) —tiempo medio necesario para detectar una amenaza— adquiere una importancia todavía mayor. Si los sistemas defensivos necesitan horas para identificar un comportamiento anómalo mientras un agente ofensivo puede ejecutar cientos de operaciones en minutos, la ventaja temporal pasa al atacante.
La AEPD advierte precisamente de que responsables del tratamiento, encargados, delegados de protección de datos y profesionales de ciberseguridad deben prepararse para un escenario en el que los ataques puedan producirse cada vez a mayor velocidad.
Los agentes cambian también el concepto de superficie de ataque
La mayoría de las estrategias tradicionales de ciberseguridad están diseñadas pensando fundamentalmente en dos tipos de actores: personas y software malicioso. Los agentes introducen un tercero que combina características de ambos. Son software, pero pueden interpretar contexto, tomar decisiones, utilizar herramientas y adaptar dinámicamente su comportamiento.
Eso significa que la superficie de ataque de una empresa no debería analizarse únicamente preguntando qué puede hacer un usuario malicioso o qué puede ejecutar un malware convencional. Hay que empezar a preguntar qué podría hacer un agente autónomo si obtuviera determinadas credenciales, una API key o acceso inicial a uno de nuestros sistemas.
Un agente podría, por ejemplo, descubrir documentación interna, identificar APIs, probar combinaciones de llamadas, analizar errores devueltos por el sistema, encontrar permisos excesivos, recorrer repositorios, localizar claves expuestas y utilizar automáticamente cada nuevo descubrimiento para ampliar el ataque. No necesita que cada paso haya sido programado previamente. Esa capacidad para razonar sobre el entorno y adaptar la siguiente acción es precisamente lo que convierte a los agentes en una nueva categoría operativa.
Para una empresa, esto hace todavía más importantes principios clásicos como Zero Trust, Least Privilege, Identity and Access Management, Network Segmentation y Secrets Management. Pero ahora hay que aplicarlos pensando también en identidades no humanas.
Las identidades de máquina se convierten en un problema estratégico
Una de las consecuencias menos visibles del desarrollo de agentes es la multiplicación de identidades digitales no humanas. APIs, bots, workloads, servicios automatizados y agentes necesitan credenciales para actuar. En muchas organizaciones existen ya miles o millones de identidades de máquina que pueden superar ampliamente al número de empleados.
La llegada de agentes autónomos aumenta el riesgo porque una credencial deja de dar acceso simplemente a un script preprogramado. Puede dar acceso a un sistema capaz de decidir dinámicamente qué hacer con esos permisos.
Esto obliga a desarrollar una auténtica Agent Identity Governance. Cada agente debería disponer de identidad propia, permisos mínimos, ámbito de actuación definido, duración limitada de credenciales, registro completo de actividades y mecanismos de revocación inmediata.
El principio debería ser sencillo: ningún agente debería tener más permisos de los estrictamente necesarios para ejecutar su tarea.
Un agente encargado de consultar stock no debería poder modificar precios. Uno destinado a preparar facturas no debería poder realizar transferencias. Uno que accede al CRM no debería disponer automáticamente de permisos sobre sistemas de recursos humanos. Y cualquier elevación de privilegios debería activar controles adicionales.
El nuevo SOC tendrá que detectar comportamiento agéntico
Los Centros de Operaciones de Seguridad —SOC— también tendrán que evolucionar. Los sistemas actuales buscan indicadores como IP sospechosas, malware conocido, accesos anómalos o comportamientos incompatibles con el histórico de un usuario. Los agentes pueden generar patrones diferentes: una secuencia extremadamente rápida de peticiones, exploración sistemática de endpoints, cambios frecuentes de estrategia, llamadas encadenadas a múltiples herramientas o utilización intensiva de APIs.
La pregunta ya no será únicamente “¿esta persona está haciendo algo extraño?”, sino también “¿este patrón de comportamiento parece estar siendo ejecutado por un agente?”.
Aquí la inteligencia artificial defensiva tendrá que enfrentarse progresivamente a inteligencia artificial ofensiva. Los SOC necesitarán sistemas capaces de analizar eventos en tiempo real, correlacionar actividades entre aplicaciones, identificar secuencias de comportamiento y detener automáticamente determinados procesos antes de que el agente consiga avanzar.
En otras palabras, entramos en una etapa de machine-speed attack versus machine-speed defence.
El problema no es solo externo: también hay que gobernar los agentes propios
El caso de la AEPD tiene además otra lectura para las empresas. Las mismas medidas que sirven para limitar a un agente atacante sirven para evitar incidentes producidos por los propios agentes corporativos.
Imaginemos un agente con acceso a correo electrónico, CRM, ERP, sistema financiero y bases de datos. Aunque haya sido creado para ayudar a la compañía, una instrucción incorrecta, un error del modelo o un prompt injection encontrado dentro de un email, una web o un documento puede hacer que intente realizar acciones no previstas.
Por eso las empresas deberían empezar a diseñar una arquitectura de Agent Governance antes de desplegar agentes con permisos amplios.
Esta arquitectura debería incluir Tool Allowlisting, definiendo exactamente qué herramientas puede utilizar cada agente; Scoped Permissions, limitando recursos y operaciones; Human-in-the-Loop, exigiendo aprobación humana para determinadas acciones sensibles; Transaction Limits, estableciendo cantidades máximas o frecuencia de operaciones; Sandboxing, aislando la ejecución cuando sea posible; Agent Logging, registrando cada acción realizada; y Kill Switches, permitiendo detener inmediatamente el agente si muestra un comportamiento inesperado.
También debería existir trazabilidad suficiente para responder después a una pregunta fundamental: ¿por qué realizó el agente esta acción?
La brecha activa también obligaciones bajo el RGPD
El hecho de que el ataque haya utilizado inteligencia artificial no altera las obligaciones fundamentales de una organización respecto a una brecha de datos personales. El artículo 33 del RGPD obliga al responsable del tratamiento a notificar una violación de seguridad a la autoridad de control cuando sea probable que suponga un riesgo para los derechos y libertades de las personas. La AEPD recuerda que una brecha puede consistir en destrucción, pérdida, alteración, divulgación no autorizada o acceso indebido a datos personales.
Cuando el riesgo para las personas sea elevado, además, puede existir la obligación de comunicar la brecha directamente a los afectados conforme al artículo 34 del RGPD. Por eso, ante un ataque protagonizado por agentes, el análisis posterior no debería limitarse a contener técnicamente la amenaza. Hay que determinar qué información fue consultada, modificada o exfiltrada; cuántas personas se vieron afectadas; qué consecuencias pueden producirse; qué medidas se han adoptado y qué evidencias existen.
La velocidad del agente no elimina las obligaciones regulatorias de la compañía. Al contrario: reduce el tiempo disponible para entender lo ocurrido.
AI Act, RGPD, NIS2 y Cyber Resilience Act empiezan a converger
Este tipo de incidentes muestra además que la gobernanza de la inteligencia artificial no puede gestionarse de forma aislada. Para muchas organizaciones europeas, IA y ciberseguridad estarán cada vez más conectadas con distintos marcos regulatorios: AI Act, RGPD, NIS2, DORA en determinados sectores financieros y Cyber Resilience Act para productos con elementos digitales.
El AI Act incorpora requisitos de robustez y ciberseguridad para determinadas categorías de sistemas y obligaciones adicionales para modelos GPAI con riesgo sistémico. El RGPD protege los datos personales afectados. NIS2 obliga a determinadas organizaciones a disponer de medidas de gestión del riesgo de ciberseguridad y procedimientos de notificación. El Cyber Resilience Act introduce obligaciones de seguridad durante el ciclo de vida de productos digitales.
Desde la perspectiva de un consejo de administración, esto significa que AI Governance y Cybersecurity Governance deberían empezar a converger.
Mantener equipos completamente separados puede generar zonas ciegas precisamente donde aparecerán muchos de los nuevos riesgos: agentes con acceso a herramientas, modelos conectados a datos corporativos, sistemas autónomos con permisos transaccionales y modelos externos utilizados dentro de procesos críticos.
Qué debería hacer ahora una empresa
La primera medida es conocer exactamente qué agentes existen dentro de la organización. Muchas compañías ya utilizan capacidades agénticas sin disponer de un inventario formal. Debería existir un Agent Registry que identifique cada agente, su propietario interno, modelo utilizado, herramientas disponibles, datos a los que puede acceder, permisos concedidos y procesos en los que interviene.
Después hay que realizar una Agent Permission Review. El objetivo es comprobar si cada agente dispone únicamente de los permisos indispensables. Cualquier credencial compartida, token permanente o acceso administrativo debería considerarse una prioridad de revisión.
La tercera capa es el Agent Activity Logging. Una empresa debería poder reconstruir cronológicamente qué hizo un agente, qué herramienta utilizó, qué información recibió, qué respuesta obtuvo y qué acción ejecutó después. Sin esos registros será extraordinariamente difícil investigar un incidente.
También conviene crear un Agent Incident Response Plan específico. Los playbooks tradicionales deberían incorporar escenarios como comportamiento autónomo inesperado, acceso a información fuera de alcance, prompt injection, utilización indebida de APIs, elevación de privilegios o ejecución de transacciones no autorizadas.
Y finalmente habrá que medir el Agent Blast Radius: qué podría ocurrir si ese agente fuese comprometido o actuara incorrectamente. Si la respuesta es “podría acceder prácticamente a toda la compañía”, el problema no está únicamente en el agente. Está en la arquitectura de permisos de la organización.
De la seguridad de la IA a la seguridad frente a la IA que actúa
Esta primera notificación recibida por la AEPD probablemente será recordada menos por el incidente concreto que por lo que anticipa. Durante años hemos hablado de los riesgos de que una inteligencia artificial genere información incorrecta, sesgada o dañina. Ahora empieza otra etapa: los riesgos derivados de sistemas capaces de actuar.
Un modelo puede equivocarse en una respuesta. Un agente puede convertir esa equivocación en una acción. Y un agente utilizado de forma maliciosa puede ejecutar cientos de acciones antes de que una persona tenga tiempo de reaccionar.
Eso cambia profundamente el problema de la seguridad.
La pregunta ya no es únicamente:
¿qué puede decir la inteligencia artificial?
Empieza a ser:
¿qué puede hacer, a qué sistemas puede acceder, con qué permisos y quién puede detenerla?
Para empresas y directivos, esa puede convertirse en una de las cuestiones más importantes de la próxima generación de inteligencia artificial.
La primera brecha vinculada a un agente notificada a la AEPD es todavía un caso aislado y se encuentra bajo revisión. Pero la advertencia que deja es mucho más amplia: los agentes de IA ya no deben considerarse simplemente herramientas de productividad. Son nuevas identidades digitales capaces de actuar sobre sistemas reales y, como tales, necesitan permisos, límites, trazabilidad, monitorización y gobierno.
Fuente principal: AEPD — Primera notificación de una brecha de datos personales causada por un ataque ejecutado mediante un agente de IA
Descubre más desde THE INTELLIGENCE
Suscríbete y recibe las últimas entradas en tu correo electrónico.
