NIS2
Las ESAs respaldan la alerta del ESRB sobre la IA de frontera: el riesgo sistémico ya no es una hipótesis académica
Por Redacción CyberComplianceAI21 min lectura
Ultima revision
8 de julio de 2026
Fuente
EIOPA News
Ultima revision
8 de julio de 2026
Fuente
EIOPA NewsLa pregunta útil para banca, seguros y mercados no es si la inteligencia artificial merece atención regulatoria propia dentro de la gestión del riesgo tecnológico. La pregunta útil es bastante menos abstracta y bastante más incómoda: dónde está ya metida la IA en procesos críticos, qué dependencias añade y qué exige eso bajo normas que ya están vigentes o a punto de aplicarse.
Ahí es donde conviene apartar el humo. No hace falta exagerar para concluir que el asunto es serio. Basta leer las obligaciones que ya existen sobre gestión del riesgo TIC, terceros, seguridad de las redes y de la información, protección de datos y gobernanza de sistemas de IA. DORA obliga a las entidades financieras a mantener un marco interno de gestión del riesgo TIC sólido, documentado y gobernado por el órgano de dirección; NIS2 impone medidas de gestión del riesgo y notificación de incidentes a entidades esenciales e importantes; el GDPR activa obligaciones inmediatas si hay violaciones de seguridad que afecten a datos personales; y el AI Act añade exigencias específicas para ciertos sistemas de alto riesgo, además de reglas de gobernanza y transparencia para distintos usos.
La tentación de tratar la IA como una capa separada del resto del stack es comprensible. También es un error. Si una funcionalidad basada en modelos afecta a autenticación, atención al cliente, prevención del fraude, filtrado de alertas, análisis documental, soporte a decisiones o interacción con terceros, el debate deja de ser filosófico y pasa a ser operativo. Qué activo es. Quién responde por él. De qué proveedor depende. Qué datos toca. Qué pasa si falla, deriva, alucina o queda indisponible. Y si tu entidad aún no tiene esto aterrizado con nombre y apellidos, no está sola, pero tampoco tiene demasiado margen.
DORA no menciona la IA como categoría mágica que todo lo cambia. Y precisamente por eso importa. Su lógica es tecnológicamente neutral: si una tecnología forma parte de funciones soportadas por TIC, entra en el perímetro del riesgo operativo digital. El núcleo está en los artículos 5 a 16 sobre el marco de gestión del riesgo TIC, con especial peso del artículo 6, que exige un marco interno de gobernanza y control para un riesgo TIC que sea sólido, completo y bien documentado, y del artículo 8, que obliga a identificar y clasificar adecuadamente todas las funciones soportadas por TIC, los activos de información y los activos TIC, así como sus funciones y dependencias. Esa es la referencia correcta. No una versión creativa del artículo.
El matiz importa porque cambia la conversación. Si una entidad usa herramientas con capacidades de IA dentro de procesos relevantes, la exigencia jurídica no es redactar un manifiesto sobre innovación responsable. La exigencia es saber si esas herramientas forman parte de funciones soportadas por TIC, cómo se clasifican, de qué dependen y qué impacto tendría su degradación o indisponibilidad. DORA también pide mecanismos de detección de actividades anómalas, de respuesta y recuperación, pruebas proporcionales y gestión del riesgo de terceros TIC. Ninguna de esas piezas desaparece porque el software venga con etiqueta de “copilot”, “assistant” o “AI-powered”, ese perfume comercial que a veces intenta sustituir a la arquitectura.
En terceros TIC, el punto de apoyo es muy claro. DORA art. 28 exige gestionar el riesgo derivado de terceros proveedores de servicios TIC como parte integrante del marco de gestión del riesgo TIC. El artículo 30 concreta elementos contractuales mínimos. Y el artículo 31 obliga a mantener un registro de información sobre todos los acuerdos contractuales relativos al uso de servicios TIC prestados por terceros. Si una funcionalidad de IA llega a la entidad vía SaaS, API, integraciones cloud o software empresarial con capacidades embebidas, no hay escapatoria conceptual: eso entra en la disciplina de terceros. La pregunta no es si el proveedor se presenta como “vendor de IA” o como otra cosa. La pregunta es qué servicio TIC presta, para qué proceso, con qué subcontratación y con qué capacidad de sustitución.
NIS2 sigue otra lógica sectorial, pero el mensaje de fondo coincide. El artículo 21 exige a las entidades esenciales e importantes medidas técnicas, operativas y organizativas apropiadas y proporcionadas para gestionar los riesgos que amenacen la seguridad de las redes y sistemas de información. La lista incluye gestión de incidentes, continuidad de negocio, seguridad en la cadena de suministro, seguridad en la adquisición, desarrollo y mantenimiento de redes y sistemas, políticas para evaluar la eficacia de las medidas, higiene básica y formación, criptografía cuando proceda, recursos humanos y control de acceso. De nuevo, no hace falta una cláusula especial sobre IA para ver la consecuencia práctica: si la IA forma parte del sistema o de la cadena de suministro que soporta el servicio, entra en ese perímetro.
Con datos personales, el GDPR elimina cualquier posibilidad de romanticismo tecnológico. El artículo 32 exige medidas técnicas y organizativas apropiadas para garantizar un nivel de seguridad adecuado al riesgo. El artículo 33 obliga a notificar a la autoridad de control una violación de la seguridad de los datos personales sin dilación indebida y, de ser posible, a más tardar 72 horas después de haber tenido constancia de ella. El artículo 35 exige una evaluación de impacto cuando un tipo de tratamiento pueda entrañar un alto riesgo para los derechos y libertades de las personas físicas, algo muy relevante si el uso de IA implica evaluación sistemática, tratamiento a gran escala o decisiones con efectos significativos. Si el sistema falla y expone datos, el problema ya no es “de IA”: es un incidente de seguridad y, en su caso, una violación de datos personales con obligaciones concretas y plazos concretos.
El AI Act añade otra capa, pero conviene no confundir capas con sustitución. La norma no reemplaza a DORA, NIS2 ni GDPR. Se les suma. Para sistemas de IA de alto riesgo, el reglamento establece requisitos de gestión de riesgos, gobernanza de datos, documentación técnica, mantenimiento de registros, transparencia e información a los desplegadores, supervisión humana, robustez, precisión y ciberseguridad. Si una entidad financiera actúa como desplegadora de un sistema de alto riesgo, no puede comportarse como simple espectadora. Y si modifica sustancialmente un sistema o lo pone en servicio bajo determinadas condiciones, puede asumir obligaciones adicionales. El detalle fino dependerá del caso de uso, del rol de la entidad en la cadena y de la clasificación aplicable. Justo por eso no sirve la respuesta estándar.
Muchas discusiones sobre IA y resiliencia se desvían hacia lo visible: el chatbot, el asistente interno, la herramienta que resume documentos o el motor que ordena alertas. El riesgo regulatorio serio suele esconderse en algo menos fotogénico: la dependencia técnica y contractual que ese componente introduce dentro de un proceso que ya estaba sometido a obligaciones estrictas.
DORA art. 8 obliga a identificar y clasificar funciones, activos y dependencias. La palabra decisiva aquí es “dependencias”. Una entidad puede tener perfectamente inventariada una aplicación de front, un proveedor cloud y un proceso de negocio, y seguir sin haber aterrizado un mapa suficiente de las dependencias que añade una capacidad basada en modelos. Por ejemplo: de qué servicio externo depende la inferencia; qué telemetría sale de la organización; qué datos se usan para ajuste, validación o monitorización; qué controles existen sobre cambios de modelo, versiones o proveedores subyacentes; y qué pasa cuando una funcionalidad “embebida” en software corporativo activa servicios de terceros fuera del circuito de revisión contractual que el área de compras cree tener bajo control.
Aquí aparece una ironía regulatoria bastante instructiva. Cuanto más “invisible” se presenta una capacidad de IA dentro de una herramienta empresarial, más fácil es que alguien asuma que no hay nada nuevo que evaluar. Y cuanto más integrada está en procesos ordinarios, más probable es que sí lo haya. El punto ciego no es necesariamente un modelo exótico entrenado en casa. Puede ser una función estándar activada por defecto en una suite ofimática, una plataforma CRM o un sistema de ticketing. Si altera flujos de datos, introduce una nueva subcontratación o afecta a la integridad, disponibilidad o confidencialidad de la información, ya no estamos ante marketing del proveedor. Estamos ante riesgo TIC, cadena de suministro y, en algunos casos, tratamiento de datos personales.
La consecuencia práctica es menos glamourosa de lo que querrían algunos departamentos de innovación, pero bastante más útil: revisar el inventario de servicios TIC y el registro de terceros con una lógica funcional, no comercial. No preguntes solo “dónde usamos IA”. Pregunta “qué funciones soportadas por TIC dependen de capacidades de IA, aunque el contrato no las llame así”. Esa reformulación suele descubrir más de lo que a algunos les gustaría admitir en comité.
Si uno junta DORA art. 28 sobre terceros TIC, DORA art. 30 sobre contenido contractual y NIS2 art. 21 sobre seguridad de la cadena de suministro, aparece un patrón muy nítido: el regulador europeo desconfía, con razón, de las dependencias opacas. No hace falta demostrar ninguna teoría grandilocuente sobre el mercado de la IA para ver el problema operativo. Basta con constatar que muchas soluciones se prestan a través de varias capas técnicas y contractuales: proveedor principal, infraestructura cloud, APIs de terceros, herramientas de observabilidad, servicios de soporte, subencargados de tratamiento y, en ocasiones, componentes reutilizados o integrados de manera poco visible para el cliente final.
Ese apilamiento no es nuevo. Lo que cambia con ciertas funcionalidades basadas en IA es el nivel de opacidad que puede introducir si la entidad no exige visibilidad suficiente. DORA no obliga a una transparencia perfecta del universo. Obliga a gestionar el riesgo de terceros TIC de manera proporcionada, a considerar la criticidad de las funciones soportadas y a reflejar contractualmente cuestiones como descripciones completas del servicio, lugares de tratamiento o almacenamiento, disponibilidad, integridad, confidencialidad, acceso, recuperación, asistencia en incidentes, terminación y derechos de acceso, inspección y auditoría, según proceda. La lectura práctica es casi brutal en su simplicidad: si no sabes exactamente qué te presta tu proveedor, con qué subcontratación y para qué parte del proceso, te faltan piezas para cumplir.
NIS2 empuja en la misma dirección al exigir que las medidas de gestión del riesgo tengan en cuenta las vulnerabilidades específicas de cada entidad y, cuando proceda, de sus proveedores directos y prestadores de servicios. Eso no resuelve por sí solo los problemas de visibilidad, pero sí convierte la excusa de “es que el proveedor no da más detalle” en algo regulatoriamente pobre. Puede ser una limitación real de negociación, desde luego. Lo que no es, o no debería ser, es un argumento suficiente para asumir que no hay riesgo que documentar, escalar o mitigar.
La pregunta incómoda para los equipos jurídicos y de procurement es bastante concreta: ¿tu due diligence de terceros distingue entre software convencional y capacidades de IA embebidas cuando estas alteran el tratamiento de datos, la lógica funcional o la cadena de subprocesadores? Si la respuesta es no, el problema no es semántico. Es de control interno.
Una de las contribuciones más útiles de DORA es que liquida la fantasía de que el riesgo TIC es un asunto que se puede delegar por completo a tecnología o seguridad. El artículo 5 atribuye al órgano de dirección la responsabilidad última de definir, aprobar, supervisar y responder por la aplicación del marco de gestión del riesgo TIC. No es un detalle ornamental. Significa que el consejo o equivalente debe entender lo suficiente como para tomar decisiones informadas sobre apetito de riesgo, dependencias críticas, tolerancias, supervisión de terceros y respuesta a incidentes.
Trasladado a la IA, el mensaje es directo: si una entidad adopta herramientas o servicios con impacto operativo relevante, la gobernanza no puede quedarse en una combinación de entusiasmo comercial y fe en el proveedor. Debe existir una asignación clara de responsabilidades entre negocio, tecnología, seguridad, riesgo, cumplimiento, privacidad y, cuando proceda, validación de modelos o funciones equivalentes. No porque “la IA sea especial” en abstracto, sino porque cruza varias obligaciones que ya existían y añade exigencias documentales y de supervisión especialmente sensibles.
El AI Act refuerza este punto al imponer, para determinados sistemas, obligaciones de documentación, instrucciones de uso, supervisión humana y monitorización posterior a la comercialización. Una entidad que despliega sistemas de alto riesgo necesita gobernanza real sobre su uso, no solo una política bonita. Y una entidad que no despliega sistemas clasificados como alto riesgo tampoco queda libre de gobierno robusto si el uso afecta a seguridad, continuidad, terceros o datos personales. Los marcos se solapan. La gestión debe hacerlo también.
Hay una escena que se repite demasiado: el negocio activa una función “inteligente” porque venía incluida, seguridad se entera después, privacidad entra cuando ya hay datos circulando, y cumplimiento recibe la pregunta cuando alguien sospecha que quizá convendría revisar el contrato. Ese orden de factores no altera solo el producto; altera la capacidad de defensa regulatoria cuando llegue una inspección o un incidente. Y llegará una de las dos cosas, probablemente ambas.
El puente entre “fallo técnico” y “problema regulatorio” es mucho más corto de lo que suele parecer en presentaciones internas. DORA exige procesos de detección, gestión y notificación de incidentes relacionados con las TIC; NIS2 contiene reglas de notificación escalonada para incidentes significativos; GDPR art. 33 y 34 activan obligaciones de notificación a la autoridad y, en ciertos casos, a los interesados cuando hay violación de datos personales. Si una funcionalidad basada en IA participa en un proceso esencial o importante, el incidente no se evaluará por su novedad tecnológica, sino por sus efectos.
Eso cambia la manera de preparar la respuesta. Una entidad no debería limitarse a preguntar si “se ha caído la IA”. Debería poder responder, con rapidez, al menos a cinco cuestiones: qué función soportada por TIC se ha visto afectada; qué datos estaban implicados; si existe impacto en confidencialidad, integridad, disponibilidad o autenticidad; qué terceros participan en la prestación o recuperación del servicio; y si el evento cruza umbrales internos o regulatorios de escalado y notificación. Sin esa traducción inmediata del evento técnico a lenguaje regulatorio, el reloj corre y la organización improvisa. Nada inspira menos confianza a un supervisor que una entidad improvisando bajo plazo legal.
El GDPR aquí actúa como prueba de realidad. No importa si la incidencia nace en una automatización documental, una interfaz conversacional o un motor de clasificación. Si ha habido destrucción, pérdida, alteración, divulgación no autorizada de datos personales o acceso no autorizado, la definición de violación de seguridad del artículo 4.12 entra en juego. El análisis debe hacerse sobre hechos y riesgos para los derechos y libertades de las personas. No sobre lo futurista que suene la tecnología afectada.
Conviene añadir una cautela. No todo error de un sistema con capacidades de IA será un incidente notificable. Sería un disparate decir lo contrario. Pero tampoco todo “fallo funcional” puede tratarse como simple bug de producto si afecta a controles, disponibilidad de servicios críticos, integridad de procesos o exposición de datos. Esa frontera hay que diseñarla antes, no durante la llamada de crisis de las 6:40 de la mañana.
La conversación sobre IA suele llenarse de grandes conceptos y olvidar algo muy pedestre: datos personales, base jurídica, minimización, limitación de finalidad, encargados y transferencias. El GDPR no pierde vigencia porque una herramienta prometa eficiencia. Si acaso, gana protagonismo porque ciertas implementaciones multiplican puntos de fricción que antes estaban más claros.
Piensa en flujos de prompts, adjuntos, historiales de interacción, registros de auditoría, telemetría, datasets de validación, feedback de usuarios o revisión humana de resultados. Cada uno de esos elementos puede implicar tratamiento de datos personales. Cada uno exige saber quién actúa como responsable, quién como encargado, qué instrucciones operan, qué medidas de seguridad se aplican y si hay transferencias internacionales. Si además la herramienta se apoya en varios proveedores o subencargados, la necesidad de trazabilidad deja de ser una preferencia de compliance y pasa a ser una condición básica de control.
El artículo 32 del GDPR obliga a adecuar las medidas al riesgo; el 35, a evaluar el impacto cuando el tratamiento pueda entrañar alto riesgo; el 28, a regular la relación con encargados; y el 44 y siguientes, a encuadrar las transferencias internacionales. Nada de eso es nuevo. Lo nuevo, si acaso, es la facilidad con la que algunas organizaciones introducen nuevas rutas de datos sin darse cuenta de que lo han hecho. Una opción activada en un panel de administración puede alterar conservación, acceso, reutilización para mejora del servicio o localización del tratamiento. Y luego todos ponen cara de sorpresa en el comité, como si los términos de servicio se hubieran escrito solos.
Desde el punto de vista de resiliencia, privacidad y seguridad no compiten: se necesitan. Una entidad que no sabe qué datos salen, adónde van y con qué controles contractuales y técnicos, tampoco podrá responder bien ante un incidente, evaluar dependencia de terceros o justificar su marco de riesgo TIC. El silo entre DPO, CISO y función de riesgo tecnológico quizá siga siendo muy popular. También es una fábrica de agujeros.
Conviene distinguir entre dos planos que a menudo se mezclan. El primero es normativo: las reglas existentes ya permiten, y en varios casos exigen, tratar determinados usos de IA como parte del perímetro de riesgo TIC, seguridad, privacidad y gobernanza. Eso está respaldado por los textos. El segundo es empírico: cuánto usan las entidades estas herramientas, con qué intensidad, qué riesgos materializados se están viendo o qué estructura exacta tiene el mercado subyacente. Ahí la prudencia no es cobardía; es rigor.
Sin datos específicos y verificables, no conviene pontificar sobre cuántas entidades financieras usan IA en cada función, si la adopción es masiva o desigual, o si existe una configuración concreta de mercado con determinados niveles de concentración. Puede ser una intuición razonable en muchos casos. No basta para escribirlo como hecho cerrado. Lo sólido, y jurídicamente más relevante, es otra cosa: que cualquier entidad que utilice servicios TIC de terceros con componentes de IA en funciones relevantes debe evaluarlos dentro de su marco de riesgo, su gobierno de terceros y, cuando proceda, su esquema de privacidad y seguridad. Eso sí se sostiene.
Lo mismo ocurre con las afirmaciones amplias sobre capacidades ofensivas. No hace falta convertir el artículo en una lista de amenazas supuestamente aceleradas por la IA para justificar medidas. Las obligaciones regulatorias de seguridad no dependen de demostrar una teoría universal sobre atacantes. Dependen de que la entidad gestione riesgos previsibles, proteja sus sistemas, asegure su cadena de suministro, detecte incidentes y responda de forma adecuada. Si determinados supervisores, ENISA o autoridades sectoriales publican orientaciones o análisis específicos sobre riesgos emergentes, serán un apoyo adicional. Pero la base de cumplimiento no necesita hipérboles para mantenerse en pie.
Uno de los errores más comunes es intentar resolver el tema de la IA con una política única y transversal que trata igual un uso accesorio y una dependencia incrustada en una función crítica. DORA no funciona así. Su arquitectura gira alrededor de la identificación, clasificación y proporcionalidad. El artículo 8 exige clasificar funciones soportadas por TIC, activos y dependencias; el artículo 11 se refiere a la respuesta y recuperación; el 12 a las copias de seguridad y restauración; el 13 a aprendizaje y evolución; y los artículos sobre pruebas e incidentes exigen calibrar según tamaño, perfil de riesgo y criticidad.
La implicación práctica es bastante concreta. No todos los usos de IA requieren el mismo nivel de revisión contractual, pruebas, contingencia o supervisión. Pero algunos sí exigirán controles reforzados porque están más cerca de funciones esenciales o importantes, porque procesan datos sensibles, porque afectan a decisiones con impacto relevante o porque su indisponibilidad degrada controles clave. La clasificación no es burocracia: es el mecanismo que permite priorizar recursos y defender por qué se adoptaron unas medidas y no otras.
Quien intente resolver esto con una etiqueta binaria —“tenemos IA” frente a “no tenemos IA”— se perderá justo lo que el regulador quiere ver. No una declaración existencial, sino un mapa de uso, dependencia, criticidad y control. Lo demás sirve para la keynote anual. No necesariamente para una inspección.
La buena noticia es que no hace falta inventar un programa paralelo. La mala es que sí hace falta trabajar. El enfoque sensato consiste en reutilizar marcos ya exigidos y ampliarlos donde haya lagunas. En términos operativos, eso implica al menos cinco movimientos.
Fíjate en lo que no aparece en esa lista: una guerra teológica sobre si la IA es revolucionaria. Para cumplir, esa discusión vale poco. Lo que vale es saber qué dependencias crea, qué datos toca, qué controles requiere y quién responde.
Es una objeción parcialmente cierta y bastante abusada. Sí, quedan zonas donde habrá interpretación, desarrollo supervisor y ajuste de mercado. Sí, el AI Act exigirá aterrizaje fino por casos de uso, roles y actos de ejecución o normas técnicas cuando correspondan. Sí, la transposición y aplicación de NIS2 puede generar diferencias prácticas entre jurisdicciones y autoridades competentes. Todo eso es real.
Lo que no se sostiene es convertir esa falta de claridad absoluta en permiso para no hacer nada. DORA ya está ahí con obligaciones bastante concretas sobre gobernanza, identificación, protección, detección, respuesta, recuperación, pruebas y terceros TIC. GDPR lleva años exigiendo seguridad, responsabilidad proactiva y evaluación de impacto en escenarios de alto riesgo. NIS2 ya fija una dirección inequívoca sobre gestión del riesgo y cadena de suministro. La falta de perfección interpretativa no elimina la obligación de mapear dependencias, reforzar contratos o preparar notificaciones.
Dicho sin rodeos: esperar a que cada supervisor te explique con ejemplos exactamente cómo tratar cada funcionalidad de IA es una estrategia muy cómoda hasta que deja de serlo. Suele dejar de serlo el día del incidente, o el día de la inspección. A veces ambos se dan la mano con una puntualidad admirable.
La conversación útil sobre IA y resiliencia en servicios financieros no necesita grandilocuencia. Necesita trazabilidad. Qué función soporta la tecnología. Qué activo interviene. Qué tercero la presta. Qué datos procesa. Qué obligaciones activa. Qué pasa si falla. DORA, NIS2, GDPR y el AI Act no componen un mosaico perfectamente simple, desde luego. Pero sí ofrecen algo suficiente para actuar ya: una estructura de deberes que obliga a integrar la IA en gobierno, inventario, cadena de suministro, seguridad, privacidad y respuesta a incidentes.
Quien siga tratando estas capacidades como una capa exótica gestionada al margen del marco TIC está comprando complejidad con descuento y riesgo a precio completo. Y eso, en regulación financiera y ciberseguridad, suele acabar saliendo bastante caro aunque aún no sepas en qué casilla del formulario lo vas a reportar.
Si tu entidad quiere una pregunta final para comprobar si va tarde, aquí la tienes: ¿puedes identificar hoy, sin improvisar, qué servicios o funciones relevantes dependen de capacidades de IA, qué terceros intervienen, qué datos personales están en juego y qué playbook regulatorio se activa si algo sale mal? Si la respuesta es dubitativa, ya sabes dónde empieza el trabajo de verdad.
Resumen semanal gratis
Suscríbete al resumen semanal y te avisamos de cada cambio en NIS2: entidades esenciales/importantes, notificación de incidentes y medidas mínimas.
¿Necesitas priorizar acciones ya? Empieza un GAP Assessment NIS2.
NIS2 (Directiva UE 2022/2555) distingue entre entidades "esenciales" e "importantes" en sectores como energía, transporte, banca, salud, infraestructura digital y administración pública, generalmente medianas y grandes empresas.
Se exige una alerta temprana en un máximo de 24 horas, una notificación de incidente en 72 horas y un informe final en el plazo de un mes (art. 23).
NIS2 es una directiva, por lo que cada Estado miembro la transpone a su legislación nacional. Las obligaciones concretas y la autoridad competente dependen de la transposición de cada país.