El ataque en sí suena casi convencional. Un sistema escaneó archivos genéricos en busca de debilidades, encontró un punto de acceso e inició sesión con éxito. A partir de ahí continuó: buscó nuevas vulnerabilidades en la aplicación, las explotó, modificó datos personales y accedió a facturas. Lo que hizo diferente a esta notificación fue quién, o qué, llevó a cabo la búsqueda. Según la organización afectada, se trató de un agente de IA que utilizaba un conocido modelo lingüístico.

La AEPD se apresuró a añadir matices tras publicar el caso. La información procede de la propia notificación enviada por la organización y aún debe ser analizada. El uso de un modelo determinado no implica que dicho modelo, o la infraestructura de su proveedor, hayan sido comprometidos. Asimismo, una sola notificación no constituye una tendencia estadística. En opinión de la Agencia, se trata de una señal de que los ataques asistidos por IA están empezando a materializarse en incidentes que involucran datos personales reales.

Qué hizo diferente a este ataque

La IA lleva tiempo formando parte de los ciberataques: en correos de phishing, en mensajes de estafa traducidos o en el análisis de código. Sin embargo, un agente añade un elemento distinto: es capaz de asumir un objetivo, desglosarlo en pasos, utilizar herramientas, analizar los resultados y ajustar sus acciones posteriores con escasa o nula intervención humana entre cada paso.

En este caso, eso significó que un único sistema encadenó toda la secuencia, desde la detección de la vulnerabilidad hasta la modificación de los datos personales. La AEPD señala un riesgo específico derivado de esto: un agente que obtiene una cuenta, una clave API o un token con permisos más amplios de los necesarios puede desplazarse entre servicios antes de que alguien detecte una actividad inusual. El detalle más relevante del caso español es lo poco extraordinario que fue el acceso inicial: el agente simplemente inició sesión.

Esto desplaza el foco de atención de la defensa perimetral hacia una cuestión menos vistosa: qué cuentas, claves y tokens existen en su organización, a qué tiene acceso cada uno de ellos y con qué rapidez se pueden revocar.

El reloj del RGPD no cambia; el tiempo para comprender el incidente, sí.

El RGPD es tecnológicamente neutro y el caso de la AEPD no altera ni una sola obligación. El artículo 32 sigue exigiendo una seguridad adecuada al riesgo. El artículo 33 sigue obligando a los responsables del tratamiento a notificar la brecha de seguridad a la autoridad de control sin dilación indebida y, a ser posible, a más tardar 72 horas después de haber tenido constancia de ella, a menos que sea improbable que constituya un riesgo para las personas físicas.

La diferencia radica en el margen existente entre tener constancia del incidente y comprender su alcance. Un equipo puede saber que un atacante accedió a una aplicación mientras aún intenta averiguar qué registros se vieron afectados, si se copiaron datos y, como en este caso, si fueron modificados. La modificación de datos transforma una cuestión de confidencialidad en una de integridad, lo que complica la investigación. Si el agente utilizó credenciales válidas, también puede resultar difícil distinguir sus acciones de la actividad legítima.

De esto se derivan dos consecuencias para quienes gestionan los incidentes. En primer lugar, la evaluación jurídica debe comenzar mientras la investigación técnica aún está en curso, no después de recibir el informe forense. El propio RGPD ya prevé esta situación: cuando no se disponga de toda la información al mismo tiempo, el artículo 33 permite facilitarla de manera gradual, sin otra dilación indebida. Un plan que trate la notificación como un documento único y definitivo tendrá dificultades para responder ante un ataque que se desarrolla a la velocidad de las máquinas.

En función de la organización, el mismo incidente también podría activar la obligación de notificar bajo las directivas NIS2, DORA o la Ley de Ciberresiliencia (Cyber Resilience Act), cada una con sus propios umbrales, plazos y autoridades competentes. La primera hora es crucial para tomar esas decisiones.

Qué tiene que ver la Ley de IA en todo esto

Es tentadora la idea de interpretar este caso como una historia sobre la Ley de IA. Sin embargo, para la organización atacada, en su mayor parte no lo es. La Ley de IA de la UE regula cómo se construyen, se comercializan y se utilizan los sistemas de IA. No gobierna al atacante, y nada en el caso de la AEPD sugiere que la víctima estuviera ejecutando la IA implicada.

La Ley de IA puede adquirir relevancia en el otro lado: cuando es su propia organización la que despliega sus propios agentes de IA. Los agentes que leen registros de clientes, actualizan un CRM, envían correos electrónicos o gestionan pagos ostentan precisamente el tipo de acceso sobre el que advierte la AEPD. Si uno de ellos —o sus credenciales— se viera comprometido, la misma cadena de eventos podría recorrer sus sistemas, iniciada desde el interior.

Es ahí donde se cruzan la privacidad y la gobernanza de la IA:

• Bajo el RGPD, lo que sus propios agentes hagan con los datos personales requiere una base jurídica, a menudo una evaluación de impacto relativa a la protección de datos (EIPD) y salvaguardias cuando se automaticen las decisiones.

• Bajo la Ley de IA, los sistemas de IA de alto riesgo deben alcanzar niveles adecuados de precisión, solidez y ciberseguridad de conformidad con el artículo 15. Tras el Digital Omnibus de IA, estas obligaciones son aplicables desde el 2 de diciembre de 2027 para los sistemas independientes y desde el 2 de agosto de 2028 para la IA integrada en productos regulados. Los proveedores de los modelos de IA de fin general más avanzados ya tienen obligaciones vigentes en materia de ciberseguridad e incidentes graves.

En ambos casos, las preguntas prácticas son las mismas: ¿qué agentes tiene en funcionamiento?, ¿quién es el responsable de cada uno?, ¿a qué datos y sistemas pueden acceder? y ¿quién autorizó dicho acceso?

Nuestra visión: Las organizaciones que aborden el RGPD y la Ley de IA como proyectos independientes responderán a estas preguntas dos veces, en lugares distintos y, probablemente, de forma diferente. Se trata de un único conjunto de preguntas.

Cómo respalda Formalize este proceso

Una plataforma de GRC no detecta ni bloquea a un agente de IA. Ese es el cometido de las herramientas de seguridad, desde la gestión de identidades hasta la monitorización. Lo que hace una plataforma de GRC es garantizar que la estructura organizativa responda adecuadamente cuando se produce un incidente, y que usted pueda demostrar que así fue.

En Formalize, esto se traduce en:

• Evaluaciones de riesgos con responsables asignados, actualizadas a medida que amenazas como los ataques asistidos por IA alteran el escenario.

• Controles entendidos como un trabajo recurrente y documentado con evidencias —como revisiones de acceso para cuentas de servicio y claves API—, en lugar de meras intenciones plasmadas en una política.

• Flujos de trabajo de incidentes que registran quién evaluó qué, cuándo y por qué, desde la primera alerta hasta la decisión de notificación.

• Gestión del RGPD y de la Ley de IA en un mismo sistema, con plantillas (blueprints) para ambos marcos, de modo que sus registros de actividades de tratamiento y sus sistemas de IA se gobiernen de forma paralela.

Cuando un regulador le pregunte más adelante qué sabía, cuándo lo supo y qué medidas adoptó, la respuesta ya debería estar registrada. Descubra cómo aborda Formalize el cumplimiento del RGPD y la Ley de IA.