Cuando un agente de IA hackea por su cuenta, la defensa de “nadie quiso hacerlo” ya no sirve

La pregunta ya no es si una herramienta de IA puede provocar un incidente operativo serio. La pregunta es bastante menos cómoda: cuando lo haga, ¿tu entidad sabe en qué cajón regulatorio cae, quién responde y con qué plazos? Ahí es donde se acaba la conversación de laboratorio y empieza la parte que duele: DORA, GDPR, NIS2 y, en algunos casos, el AI Act no se pisan del todo, pero tampoco se reparten el terreno con una elegancia precisamente suiza.

La confusión suele venir de una idea demasiado simple: pensar que la IA es un problema nuevo y, por tanto, requiere una lógica de respuesta totalmente separada. No funciona así. Si un modelo altera una decisión crítica, bloquea una operativa, degrada un control antifraude, dispara una cascada de falsos positivos o abre una vía de acceso a datos personales, la primera pregunta regulatoria no es si el incidente “es de IA”. La primera pregunta es qué impacto operativo, de seguridad, de continuidad, de integridad o de privacidad ha producido. Y a partir de ahí, qué régimen legal se activa.

Eso obliga a leer las normas en cruce. No porque quede bonito en una presentación al consejo, sino porque cada una captura una parte distinta del problema. DORA ordena la resiliencia operativa y la gestión del riesgo TIC para entidades financieras; GDPR activa deberes específicos si hay brecha de datos personales, con notificación a la autoridad de control en 72 horas cuando proceda bajo el artículo 33; NIS2 impone medidas de ciberseguridad y obligaciones de notificación para entidades esenciales e importantes, con el artículo 21 como eje de medidas de gestión de riesgos y el artículo 23 para notificaciones; y el AI Act añade obligaciones sobre sistemas de alto riesgo, gobernanza de datos, supervisión humana, registro y vigilancia poscomercialización. Si alguien esperaba una línea recta, mala suerte.

El error más común: tratar la IA como categoría jurídica autónoma cuando el daño se mide por su efecto

Un fallo de IA puede parecer técnicamente exótico y jurídicamente bastante clásico. Imagina un modelo desplegado en una entidad financiera para priorizar alertas de fraude. Si por deriva del modelo, mala calidad del dato, errores de integración o manipulación adversaria deja de escalar operaciones anómalas y eso afecta a la prestación de servicios, la continuidad o la disponibilidad de sistemas críticos, el incidente entra en el terreno de la resiliencia operativa digital. Si además compromete datos personales o genera accesos no autorizados, el análisis no termina ahí: se abre también el frente de GDPR.

La tentación de etiquetarlo todo como “riesgo algorítmico” tiene un problema práctico. Desvía la atención de lo que exige la norma. DORA no te pregunta si el incidente era novedoso o si el proveedor vendía la solución con más marketing que control interno. Te exige que tengas un marco de gestión del riesgo TIC, gobernanza clara, capacidades de detección, respuesta, recuperación, aprendizaje y, cuando corresponda, clasificación y notificación de incidentes. El punto de partida está en el capítulo II de DORA: el artículo 5 aborda la gobernanza y la organización; el artículo 6 exige un marco interno sólido, exhaustivo y debidamente documentado para la gestión del riesgo relacionado con las TIC; y los artículos posteriores desarrollan, por bloques, protección y prevención, detección, respuesta y recuperación, aprendizaje y comunicación. Dicho de otro modo: el marco no cabe en una sola frase ni en una referencia comprimida. Y conviene no fingir que sí.

Ese matiz importa porque cambia cómo diseñas controles. Si reduces DORA a una obligación genérica de “tener buen gobierno TIC”, te perderás la parte operativa. Si la reduces a incident reporting, llegarás tarde. Si la lees bien, verás que exige una cadena completa: inventario y dependencia, protección, monitorización, respuesta, restauración, revisión postincidente y capacidad de traducir todo eso en decisiones de gestión. Una IA mal gobernada puede fallar en cualquiera de esos eslabones.

DORA no regula la IA como objeto aislado; regula el riesgo operativo que la IA puede amplificar

Conviene ser precisos. DORA no es una ley sectorial “sobre IA”. Tampoco necesita serlo para ser relevante. Su lógica es tecnológicamente agnóstica: le importa el riesgo derivado de las TIC y la resiliencia de las funciones soportadas por esas TIC. Si un sistema basado en IA forma parte de procesos relevantes para una entidad financiera —atención al cliente, detección de fraude, scoring, autenticación, monitorización de transacciones, continuidad de servicios, ciberdefensa— entra de lleno en el perímetro de gobierno y control cuando su fallo afecta a la operativa o a la seguridad.

Por eso la lectura útil no consiste en buscar una mención expresa a “modelos fundacionales”, “agentes” o “comportamiento autónomo” en DORA, sino en identificar dónde encaja ese riesgo dentro de las obligaciones existentes. El artículo 6 obliga a establecer el marco de gestión del riesgo TIC. El artículo 8 se centra en la identificación y clasificación de funciones, activos de información y dependencias TIC. El artículo 9 trata la protección y prevención. El artículo 10 aborda la detección de actividades anómalas. Los artículos 11 y 12 se ocupan de respuesta, recuperación y restauración. El artículo 13 introduce el aprendizaje y la evolución del marco a partir de la experiencia. Si la IA participa en funciones críticas o importantes, cada una de esas piezas debería reflejarlo de forma expresa. Si no aparece en el inventario, en los escenarios de fallo, en los runbooks o en las pruebas, el problema no es la sofisticación del modelo. El problema es un control incompleto.

Hay otra consecuencia poco glamurosa y muy real: la IA complica la trazabilidad en el momento peor posible, que es cuando algo ya ha salido mal. Una regla estática falla de forma más o menos legible. Un modelo con múltiples entradas, dependencia de datos de terceros y ajuste continuo no siempre ofrece esa cortesía. Pero el regulador no te va a conceder una dispensa por complejidad técnica. Si el sistema soporta un proceso crítico, la exigencia sigue siendo la misma: entender dependencias, delimitar responsabilidades, registrar eventos relevantes y poder reconstruir qué ha pasado. El consejo de administración no podrá refugiarse en que “era una caja negra” sin que esa frase suene, además de débil, peligrosamente cara.

Incidentes: la etiqueta “IA” no sustituye la clasificación jurídica

Cuando un incidente involucra IA, la cuestión operativa inmediata es si encaja en el régimen de gestión, clasificación y notificación de incidentes relacionados con las TIC de DORA. El capítulo III del reglamento cubre esa materia: obliga a establecer un proceso para gestionar incidentes, clasificar los incidentes relacionados con las TIC y, en los casos previstos, notificarlos a las autoridades competentes con arreglo a los criterios y actos de desarrollo aplicables. La lectura prudente aquí es deliberada: la obligación existe, pero la clasificación exacta y los umbrales dependen del marco de DORA y de sus estándares y actos de nivel 2. Presentarlo como una fórmula automática para cualquier incidente generado por un agente de IA sería vender certeza donde lo que hay es análisis caso por caso.

Lo que sí puede decirse con seguridad es esto: si la causa inmediata del incidente es un sistema de IA, la entidad no queda exenta de aplicar el proceso de clasificación bajo DORA. Tendrá que valorar el impacto en servicios, clientes, operaciones, disponibilidad, integridad y, en su caso, la posible afectación transfronteriza. Y si del mismo hecho se deriva una violación de la seguridad de los datos personales, entran en juego los artículos 33 y 34 de GDPR: notificación a la autoridad de control sin dilación indebida y, cuando sea probable un riesgo para los derechos y libertades de las personas físicas, en un plazo no superior a 72 horas desde que se tenga constancia; además, comunicación a los interesados cuando proceda.

Este cruce genera un problema de gobernanza bastante más serio de lo que parece. Muchas organizaciones siguen separando demasiado el equipo de resiliencia operativa, el de ciberseguridad, el DPO y el responsable del sistema de IA o del proveedor. En un incidente convencional eso ya retrasa decisiones. En uno que combine automatización, datos personales, dependencia de tercero y afectación al servicio, puede ser letal desde el punto de vista regulatorio. No por dramatismo. Por reloj.

El tercer riesgo no es accesorio: si la IA viene de fuera, DORA mira de frente al proveedor

Otra simplificación habitual consiste en reducir la gestión del riesgo de terceros TIC a un par de artículos y pasar página. DORA es más exigente. La materia se desarrolla en el capítulo V, dedicado a la gestión del riesgo de terceros prestadores de servicios de TIC. Ahí están las obligaciones de estrategia, registro de información, evaluación previa, contenido contractual, vigilancia, derechos de acceso, inspección y auditoría, así como el marco de supervisión para proveedores terceros críticos a escala de la Unión. Quedarse en una referencia estrecha no describe bien ni el alcance ni la carga operativa.

Esto es decisivo para la IA porque una parte relevante del stack no la controla la entidad de principio a fin. Puede haber modelos de terceros, infraestructura cloud, APIs, herramientas de monitorización, capas de seguridad, anotación de datos, fine-tuning externo o integraciones con proveedores especializados. Cada una de esas dependencias añade una pregunta incómoda: cuando falle algo, ¿qué sabe realmente la entidad, qué puede exigir contractualmente y hasta dónde llega su capacidad de auditoría?

DORA no prohíbe apoyarse en terceros. Lo que prohíbe, en la práctica, es fingir que la externalización desplaza el riesgo. El artículo 28 fija principios clave sobre la gestión del riesgo asociado a terceros prestadores de servicios TIC. Los artículos siguientes desarrollan, entre otras cuestiones, la evaluación previa de acuerdos contractuales, los elementos contractuales mínimos para funciones que apoyen funciones críticas o importantes y la supervisión continuada. Más adelante, el reglamento crea un marco específico de oversight para proveedores terceros críticos. El mensaje regulatorio es bastante menos ambiguo de lo que algunos contratos comerciales sugieren: puedes subcontratar tecnología; no puedes subcontratar la responsabilidad de gobernarla.

En IA ese punto se vuelve más afilado. Si el proveedor no ofrece trazabilidad suficiente, si limita de forma desproporcionada los derechos de auditoría, si no aclara cadena de subprocesadores o subcontratistas técnicos, si las métricas de rendimiento no incluyen escenarios de fallo relevantes para tu actividad o si la documentación es básicamente una mezcla de brochure y fe, el problema no es solo técnico. Es de cumplimiento, de resiliencia y, potencialmente, de capacidad de defensa ante el supervisor.

GDPR sigue siendo el regulador más rápido cuando el incidente toca datos personales

La fascinación por la IA a veces tiene un efecto curioso: hace que algunas compañías redescubran, con bastante retraso, que el GDPR ya llevaba años exigiendo disciplina documental y de respuesta. Si un sistema de IA provoca una destrucción, pérdida, alteración, divulgación no autorizada o acceso no autorizado a datos personales, la definición operativa relevante está en la violación de seguridad de los datos personales del artículo 4.12 de GDPR. Desde ahí, los artículos 33 y 34 marcan el camino.

Eso importa incluso cuando el incidente principal parezca “operacional” y no “de privacidad”. Un modelo mal configurado que expone historiales de clientes en un interfaz interno, una canalización de entrenamiento que mezcla datos de entornos sin controles adecuados, un asistente conversacional que revela información personal en respuestas no previstas o una herramienta de IA generativa conectada a repositorios corporativos sin segmentación suficiente: todo eso puede empezar como fallo de diseño o de gobernanza TIC, pero termina muy deprisa en una obligación de analizar riesgo para los derechos y libertades de las personas.

Y aquí aparece una asimetría incómoda. Los equipos de negocio tienden a preguntar si ha habido “hackeo”. La autoridad de protección de datos preguntará algo más simple y mucho más útil: ¿ha habido violación de seguridad en el sentido del reglamento y cómo lo habéis evaluado? Si la organización necesita varios días para aclarar qué datos tocó el modelo, qué repositorios consultó, si hubo logging suficiente o quién autorizó la integración, ya llega tarde a la única parte del debate donde el reloj está escrito en el propio texto legal.

La relación con DORA no es de sustitución, sino de acumulación. Que un hecho deba analizarse como incidente TIC en una entidad financiera no elimina la posible notificación bajo GDPR. Que exista una afectación a datos personales no convierte automáticamente todo incidente en una brecha notificable, pero sí exige una evaluación documentada y seria. Esa palabra —documentada— merece subrayado. Si no está registrada, para el regulador probablemente no existe.

NIS2 complica el mapa para grupos con actividades mixtas y dependencias compartidas

NIS2 tampoco está diseñada “sobre IA”, pero sí captura riesgos de ciberseguridad y continuidad que pueden materializarse a través de sistemas basados en IA o de sus cadenas de suministro. El artículo 21 exige medidas técnicas, operativas y organizativas apropiadas y proporcionadas para gestionar los riesgos de la seguridad de las redes y sistemas de información. Entre esas medidas aparecen, entre otras, la gestión de incidentes, la continuidad de actividad, la seguridad en la cadena de suministro, políticas y procedimientos para evaluar la eficacia de las medidas y prácticas básicas de ciberhigiene. El artículo 23 regula las notificaciones de incidentes significativos.

Para grupos financieros esto puede generar una doble capa de complejidad. Algunas entidades estarán primariamente concentradas en DORA; otras sociedades del grupo, o ciertos servicios comunes, pueden caer además en perímetros de NIS2 según su actividad y transposición nacional. El resultado no es elegante: distintos canales de reporte, distintas autoridades competentes, conceptos que se parecen pero no son idénticos y equipos internos que, si no se coordinan, acabarán haciendo lo de siempre: duplicar trabajo en las partes fáciles y dejar agujeros en las difíciles.

La cadena de suministro vuelve a ser la bisagra. Si el servicio de IA depende de un proveedor cloud, de un integrador, de un modelo externo y de fuentes de datos de terceros, NIS2 refuerza la idea de que la seguridad no se agota en el perímetro propio. Esto no es nuevo, pero sí más exigible. Y cuando convergen DORA y NIS2, la organización necesita una taxonomía interna común de activos, servicios, incidentes y dependencias. Sin eso, cada función hablará su dialecto y el comité de crisis descubrirá, en tiempo real, que nadie estaba discutiendo exactamente del mismo incidente.

El AI Act añade obligaciones útiles, pero no resuelve por sí solo el problema de responsabilidad operativa

La entrada del AI Act ha alimentado una expectativa algo ingenua: que por fin habrá una norma “específica” capaz de ordenar todo el caos. Ojalá. El reglamento sí aporta una arquitectura propia para sistemas de IA, especialmente los de alto riesgo: gestión de riesgos, gobernanza de datos, documentación técnica, registro de eventos, transparencia, supervisión humana, precisión, solidez y ciberseguridad. También establece obligaciones para proveedores, desplegadores e importadores, y prevé vigilancia poscomercialización e información sobre incidentes graves en su propio marco.

Lo que no hace es sustituir las obligaciones sectoriales ya existentes cuando el sistema se usa dentro de una actividad regulada. Si una entidad financiera emplea un sistema de IA en una función relevante, seguirán aplicando las obligaciones de DORA sobre gobernanza, riesgo TIC, incidentes, pruebas y terceros. Si el sistema trata datos personales, GDPR seguirá ahí, con su lógica de licitud, minimización, limitación de finalidad, seguridad y responsabilidad proactiva. Si la entidad o parte del grupo está bajo NIS2, esa capa tampoco desaparece.

Aquí hay una lección que a menudo se pierde entre tanto documento de estrategia: el AI Act puede mejorar disciplina de diseño y operación del sistema, pero no concede una especie de salvoconducto sectorial. Tener documentación técnica, medidas de supervisión humana o logs no evita por sí mismo que una entidad deba clasificar un incidente TIC bajo DORA o analizar una violación de seguridad de datos bajo GDPR. Ayuda, sí. Sustituye, no.

También conviene evitar una conclusión excesiva en sentido contrario. No toda anomalía en un sistema de IA generará automáticamente un problema regulatorio múltiple. Habrá fallos irrelevantes, desviaciones sin impacto material y errores corregidos antes de afectar a operaciones o derechos. La clave está en el impacto y en la función afectada, no en la mera presencia de IA en el sistema.

Gobernanza: donde muchas entidades todavía están organizadas para perder tiempo

El mayor riesgo de cumplimiento no siempre está en el modelo. A menudo está en el organigrama. Muchas entidades han distribuido las responsabilidades sobre IA de una forma casi garantizada para producir fricción: tecnología controla despliegue, negocio controla uso, compras controla contrato, legal revisa cláusulas al final, privacidad aparece cuando ya hay tratamiento en marcha, seguridad revisa la integración, continuidad de negocio mantiene sus propios mapas y compliance espera una versión consolidada que nadie sabe quién debe redactar.

Bajo DORA, esa fragmentación choca con la exigencia de gobernanza clara. El artículo 5 sitúa la responsabilidad de dirección y control en el órgano de dirección, que debe definir, aprobar, supervisar y responder por la implementación del marco de gestión del riesgo TIC. No significa que el consejo tenga que entender la arquitectura del modelo mejor que el equipo técnico. Significa algo más prosaico y mucho más serio: no puede aceptar un sistema relevante sin saber qué dependencia crea, qué controles lo rodean, cómo se monitoriza su rendimiento, qué escenarios de fallo se contemplan y cómo se escala un incidente.

En la práctica, la prueba de fuego es documental. ¿Existe inventario de los casos de uso de IA relevantes para funciones críticas o importantes? ¿Están vinculados a activos, procesos y proveedores concretos? ¿Hay criterios de aceptación, umbrales de degradación, triggers de escalado y responsables nominales? ¿Se reflejan en los planes de respuesta y recuperación? Si la respuesta es “más o menos” o “depende del área”, el supervisor probablemente lo traducirá a un idioma mucho más franco: todavía no lo tenéis gobernado.

Y sí, la ironía es evidente. Las empresas que más invierten en automatización son a veces las que menos automatizadas tienen las rutas internas de decisión para incidentes. Mucha IA, poca claridad sobre quién levanta el teléfono. El regulador no va a considerar eso una innovación.

Qué debe hacer una entidad ahora, sin esperar a que el problema se explique solo

La reacción útil no es redactar una política de IA más larga. Es integrar la IA en artefactos regulatorios y operativos que ya existen y que sí se examinan de verdad. Hay al menos cinco frentes donde eso se nota.

• Inventario y clasificación: incorpora los sistemas de IA al inventario de activos y dependencias TIC exigido por el marco de DORA, vinculándolos a funciones críticas o importantes cuando corresponda. Si un caso de uso es material, debe aparecer con propietario, proveedor, fuentes de datos, entorno, interfaz y escenarios de fallo.
• Contratación y terceros: revisa los acuerdos con proveedores TIC a la luz del capítulo V de DORA. Derechos de acceso, auditoría, logging, subcontratación ulterior, soporte en incidentes, niveles de servicio y obligaciones de cooperación no son anexos decorativos. Son la diferencia entre investigar un incidente o recibir una respuesta de soporte comercial en 72 horas, justo cuando menos te sirve.
• Clasificación de incidentes: adapta los playbooks para que un incidente con componente de IA entre, desde el minuto uno, en el proceso general de gestión de incidentes TIC y, cuando proceda, en el circuito de evaluación de brechas de datos personales bajo GDPR. La etiqueta interna “fallo de modelo” no basta.
• Pruebas y escenarios: los ejercicios de resiliencia, continuidad y respuesta deben incluir hipótesis específicas de degradación, deriva, poisoning, outputs erróneos a escala, fallo del proveedor o pérdida de trazabilidad. Si nunca se ensaya, el día real parecerá ciencia ficción. Y no lo será.
• Gobernanza ejecutiva: asigna responsables claros entre negocio, tecnología, seguridad, privacidad, compras y compliance. Bajo DORA, el órgano de dirección tiene responsabilidad sobre el marco; eso exige información útil, no una colección de dashboards inconexos.

Nada de esto requiere inventar una categoría regulatoria nueva. Requiere hacer algo bastante menos vistoso y mucho más eficaz: tratar la IA como parte del paisaje de riesgo real de la entidad, no como un proyecto piloto eterno.

La objeción habitual: “la norma no menciona este caso concreto”

Es una objeción frecuente y, en parte, comprensible. La tecnología evoluciona más rápido que la prosa legislativa, y nadie encontrará en DORA una descripción milimétrica de todos los fallos posibles de agentes autónomos, modelos generativos, sistemas multimodales o arquitecturas compuestas. Pero usar esa ausencia como escudo suele ser un mal negocio.

La regulación europea reciente funciona cada vez más por principios operativos apoyados en obligaciones concretas de gobernanza, documentación, control y supervisión. DORA no necesita listar cada tecnología para exigir que una entidad gestione el riesgo TIC de forma adecuada. GDPR no necesita prever cada patrón de fuga para activar sus obligaciones ante una violación de seguridad de datos personales. NIS2 no necesita nombrar cada vector emergente para exigir medidas apropiadas y notificación de incidentes significativos. El AI Act, cuando aplica, tampoco agota el análisis de responsabilidad sectorial.

La buena noticia —si quieres llamarla así— es que esa lógica deja poco espacio para la coartada de la novedad tecnológica. La mala es que obliga a hacer trabajo fino: mapear, clasificar, documentar, probar, contratar mejor y coordinar equipos que históricamente han trabajado como feudos con logos compartidos.

Lo que no conviene afirmar con exceso de seguridad

También hace falta un poco de disciplina intelectual. Hay frases que suenan convincentes en conferencias y mucho peor cuando las mira un verificador de hechos. Una de ellas es sugerir que conceptos técnicos como el “comportamiento emergente” resuelven por sí mismos el debate jurídico sobre imputación o exoneración. No lo resuelven. Pueden describir una característica técnica del sistema y complicar la reconstrucción causal, pero el alcance jurídico de esa explicación dependerá del marco aplicable, de los hechos concretos, del diseño de controles, de la relación contractual con proveedores y de la evaluación que hagan autoridades o tribunales en cada caso.

Lo mismo ocurre con la idea de esperar una gran doctrina unificadora para saber cómo actuar. Eso pertenece más al terreno del comentario editorial que al de un hecho verificable. Para una entidad regulada, la pregunta útil no es cuándo llegará el caso emblemático que ordene la conversación académica. La pregunta útil es si hoy puede demostrar que ha incorporado estos riesgos a su gobierno, a su gestión de terceros, a su respuesta a incidentes y a su análisis de privacidad y ciberseguridad. Esa demostración sí es exigible. Y bastante antes de que exista cualquier hito jurisprudencial con aspiraciones históricas.

La conclusión incómoda: el problema no es identificar la norma “correcta”, sino sobrevivir al cruce entre varias

Quien busque una única respuesta normativa para incidentes de IA en sectores regulados se va a llevar una decepción. No porque falten reglas, sino porque sobran puntos de contacto. DORA ordena la resiliencia operativa y el riesgo TIC en finanzas. GDPR captura la dimensión de datos personales con plazos y deberes que no admiten distracciones. NIS2 refuerza la gestión de riesgos de ciberseguridad y la cadena de suministro en su perímetro. El AI Act añade una capa específica sobre diseño, despliegue y supervisión de sistemas de IA. La complejidad no está en escoger una; está en saber cuándo se acumulan.

La consecuencia práctica es simple, aunque no fácil. Si tu entidad usa IA en procesos relevantes y todavía la gobierna como una iniciativa separada del marco general de resiliencia, seguridad, terceros e incidentes, va tarde. No porque lo diga una moda regulatoria. Porque las obligaciones sustantivas ya existen y el incidente no va a esperar a que el organigrama se ponga de acuerdo consigo mismo.

Aquí está el quid. La IA no introduce una excepción al cumplimiento. Introduce una prueba de estrés. Y esa prueba no examina solo al modelo. Examina si la entidad sabe qué depende de qué, quién decide qué, qué se notifica, con qué base legal y en qué plazo. Todo lo demás —el discurso sobre innovación responsable, la épica del despliegue, la promesa de eficiencia— suena muy bien hasta que hay que redactar la cronología del incidente para el supervisor.