Cyber Resilience Act
La ciberresiliencia mejora, pero la IA amplía el reto para los CISO
20 min lectura
Imagen generada por IALa ciberresiliencia empresarial parece mejorar. El problema es que el terreno de juego también se ha vuelto más difícil de defender.
El informe Voice of the CISO 2026, publicado por Proofpoint, detecta indicios de una mayor confianza de los responsables de seguridad en la capacidad de sus organizaciones para resistir y recuperarse de un ataque. Pero el mismo diagnóstico introduce la variable que está complicando todos los cuadros de mando: la inteligencia artificial.
La paradoja merece atención. Las empresas han reforzado controles, procedimientos de respuesta y capacidades de detección; al mismo tiempo, la IA está acelerando el fraude, ampliando la superficie de ataque y haciendo más difícil saber qué sistemas, modelos y proveedores intervienen en una decisión crítica. El resultado no es que el CISO tenga menos problemas. Es que algunos problemas antiguos ahora llegan más deprisa y con menos señales visibles.
La mejora de la resiliencia tampoco equivale a seguridad. Una organización puede restaurar sus sistemas en pocas horas y seguir expuesta a una extracción de datos que no puede deshacer. Puede tener un plan de continuidad probado y, sin embargo, no saber qué modelo de IA ha utilizado información confidencial de clientes. Puede cumplir con un control de acceso y permitir que un agente autónomo ejecute una transferencia o modifique un registro sin una revisión humana eficaz.
Aquí está el quid del informe: el avance operativo no elimina el riesgo. Cambia su forma.
La señal del informe: más capacidad de recuperación, no una victoria sobre el atacante
La noticia de Proofpoint no presenta una cifra aislada como solución mágica. Su conclusión es más matizada: el porcentaje global de CISOs que percibe un riesgo para su organización y la evaluación general de la resiliencia apuntan a una evolución favorable, mientras la complejidad del riesgo empresarial aumenta. El extracto publicado no ofrece el desglose completo de respuestas por país, sector o tamaño de empresa, de modo que sería imprudente convertir esa señal en una afirmación sobre toda la economía europea.
Lo que sí puede extraerse es una lectura operativa. La resiliencia se ha convertido en una capacidad medible y defendible ante el consejo de administración. Ya no basta con afirmar que existe un centro de operaciones de seguridad, una herramienta de detección o un contrato de recuperación ante desastres. Hay que demostrar cuánto tarda la entidad en identificar un incidente, contenerlo, recuperar los servicios prioritarios y determinar si los datos fueron alterados o exfiltrados.
La diferencia entre seguridad y resiliencia importa especialmente en finanzas. Una defensa preventiva puede fallar. La obligación de una entidad regulada consiste también en limitar el impacto cuando falla. Por eso el Reglamento DORA exige a las entidades financieras un marco de gestión del riesgo de las tecnologías de la información y la comunicación, pruebas de resiliencia operativa digital y gestión de terceros ICT. DORA es aplicable desde el 17 de enero de 2025; en 2026 ya no sirve presentarlo como una obligación futura o como un proyecto de transformación que puede esperar a la siguiente reunión del comité.
El artículo 5 de DORA sitúa la responsabilidad última en el órgano de dirección. El artículo 6 exige un marco de gestión del riesgo ICT documentado y revisado. Los artículos 11 y 12 conectan la respuesta a incidentes con la recuperación y los planes de continuidad. La consecuencia práctica es incómoda: el CISO no puede ser propietario único de la resiliencia, pero sí suele acabar siendo quien explica por qué una capacidad crítica no estaba probada.
La IA no solo crea nuevos ataques: cambia la escala del riesgo
El debate sobre IA en ciberseguridad suele reducirse a dos imágenes demasiado cómodas. En la primera, los atacantes utilizan modelos generativos para escribir correos de phishing sin errores gramaticales. En la segunda, el defensor despliega otra herramienta de IA y el problema queda equilibrado. La realidad es menos simétrica.
La IA reduce el coste de producir contenido convincente, personalizar campañas y probar variantes de un ataque. Un fraude dirigido ya no necesita una larga preparación manual para cada víctima. El atacante puede combinar información pública, datos obtenidos en filtraciones y lenguaje generado automáticamente para fabricar una comunicación que imite el estilo de un proveedor, un director financiero o una entidad bancaria.
El riesgo no se limita al correo electrónico. Los atacantes pueden emplear modelos para acelerar el reconocimiento de activos expuestos, clasificar información robada, identificar credenciales útiles o adaptar cargas maliciosas a las respuestas de una víctima. No hace falta atribuir a la IA capacidades autónomas extraordinarias para observar el cambio: basta con que reduzca el tiempo y el trabajo necesarios para ejecutar fases conocidas de una intrusión.
En el lado defensivo, la IA puede ayudar a correlacionar señales, priorizar alertas, resumir investigaciones y generar consultas para equipos que no disponen de especialistas suficientes. Pero esa utilidad introduce dependencias nuevas. Un analista puede aceptar una recomendación incorrecta porque el sistema la presenta con seguridad. Un copiloto puede incorporar datos sensibles a un servicio externo. Un agente con permisos excesivos puede realizar cambios sobre identidades, reglas de red o repositorios sin que exista una trazabilidad comprensible para auditoría.
La organización no solo tiene que preguntar si la herramienta es precisa. Debe saber qué datos recibe, dónde se procesan, qué proveedor interviene, qué permisos utiliza, cuánto tiempo se conservan los registros y cómo se revoca el acceso cuando cambia el modelo o termina el contrato.
El riesgo invisible: la IA que no aparece en el inventario
El inventario de activos tradicional se construyó alrededor de servidores, aplicaciones, bases de datos, endpoints y conexiones. La IA añade otra capa: modelos, interfaces de programación, conjuntos de datos, prompts, agentes, plugins, conectores y servicios integrados en productos que el departamento de seguridad quizá no compró.
Un empleado puede utilizar una herramienta generativa para resumir una presentación comercial. Un proveedor puede incorporar un modelo en su plataforma de atención al cliente. Un desarrollador puede conectar una API a un repositorio interno. Ninguno de esos usos tiene por qué aparecer en el registro corporativo de aplicaciones. La organización puede descubrirlos solo cuando investiga una fuga de información o cuando un auditor pregunta quién ha accedido a los datos.
La primera obligación operativa no es comprar un nuevo producto de gobernanza de IA. Es saber qué existe. El inventario debe identificar, como mínimo, el caso de uso, el propietario de negocio, el proveedor, el modelo utilizado, los datos procesados, las conexiones con sistemas internos, los permisos, la localización del tratamiento y el mecanismo de supervisión humana.
El nivel de detalle dependerá del riesgo. No requiere el mismo control un asistente que redacta borradores sin acceso a información confidencial que un agente conectado al sistema de pagos o a una plataforma de negociación. Mezclar ambos casos bajo la etiqueta de IA genera una falsa sensación de control.
En las entidades financieras, el punto de conexión con DORA es directo. El artículo 28 exige que la entidad gestione el riesgo de terceros ICT y mantenga una estrategia de riesgo de concentración. El artículo 30 establece elementos contractuales que deben cubrir los servicios ICT, incluidos derechos de acceso, auditoría, cooperación y salida. Un proveedor de IA integrado en un proceso crítico no deja de ser un tercero relevante porque la contratación se haya canalizado a través de una plataforma de productividad o de un proveedor tecnológico más amplio.
La pregunta que debería responder cada comité de riesgos es sencilla: si mañana se desactiva el modelo, se interrumpe su API o el proveedor cambia sus condiciones de tratamiento, ¿qué proceso deja de funcionar y cuánto tarda la entidad en recuperar una alternativa? Si nadie puede responder, no existe resiliencia; existe dependencia con buena presentación.
De la alerta al incidente: el CISO necesita una cadena de decisión
La velocidad de la IA agrava un problema que ya era conocido: muchas organizaciones detectan señales, pero tardan demasiado en decidir qué significan y quién debe actuar.
Un correo generado automáticamente, una anomalía en una cuenta privilegiada o una consulta inesperada a una base de datos no constituyen necesariamente un incidente notificable. Pero tampoco pueden quedar atrapados durante días en una cola de alertas porque nadie ha definido el umbral de escalado. La resiliencia depende de una cadena de decisión previamente acordada.
Esa cadena debe asignar al menos cinco responsabilidades: quién valida la alerta, quién puede aislar un sistema, quién evalúa el impacto sobre clientes o servicios esenciales, quién decide la comunicación externa y quién conserva la evidencia. El CISO coordina buena parte del proceso, pero legal, privacidad, continuidad, fraude, operaciones y comunicación tienen que estar dentro del circuito. Un incidente de IA puede ser simultáneamente un evento de seguridad, una violación de datos personales, una interrupción operativa y un incumplimiento contractual.
Los plazos regulatorios hacen visible el coste de la indecisión. El artículo 33 del GDPR obliga a notificar una violación de datos personales a la autoridad de control, cuando proceda, sin dilación indebida y, como máximo, dentro de las 72 horas desde que se tiene constancia. La notificación no exige conocer todos los detalles, pero sí exige explicar la naturaleza de la violación y actualizar la información cuando avance la investigación.
Para las entidades sujetas a DORA, los artículos 17, 18 y 19 establecen el marco de gestión, clasificación y notificación de incidentes ICT graves. La clasificación no puede depender solo de la intuición del equipo técnico: debe considerar factores como los servicios afectados, la duración, el impacto geográfico, las pérdidas económicas y el número de clientes o contrapartes afectados, de acuerdo con los criterios regulatorios aplicables.
NIS2 utiliza otra arquitectura temporal para incidentes significativos: alerta temprana en 24 horas desde que se tiene conocimiento, notificación del incidente en 72 horas y un informe final, como regla general, en el plazo de un mes. El artículo 21 exige medidas de gestión del riesgo, incluida la gestión de incidentes, la continuidad de negocio, la seguridad de la cadena de suministro y el uso de criptografía cuando proceda. Para un grupo que opera en varios sectores, mantener tres relojes regulatorios separados es una receta para el error.
La solución no consiste en crear tres procesos paralelos. Consiste en un expediente único de incidente que capture los hechos desde el primer minuto y permita generar las comunicaciones exigidas por cada régimen. La información puede después adaptarse a DORA, NIS2, GDPR, contratos y autoridades nacionales. Lo que no funciona es redactar una notificación desde cero cuando ya han transcurrido 60 de las 72 horas disponibles.
La regulación de IA añade gobernanza, pero no sustituye la seguridad
El Reglamento de IA de la Unión Europea introduce obligaciones por niveles de riesgo y por tipo de sistema. En 2026, la mayoría de sus reglas generales ya resultan relevantes: las prohibiciones y las obligaciones de alfabetización en IA comenzaron a aplicarse el 2 de febrero de 2025; las obligaciones para modelos de propósito general entraron en aplicación el 2 de agosto de 2025; y el grueso de las obligaciones del Reglamento es aplicable desde el 2 de agosto de 2026, con excepciones y calendarios específicos para determinadas categorías.
Para un CISO, el Reglamento no es un sustituto de DORA, NIS2 o GDPR. Es otra capa de obligaciones que debe conectarse con los controles existentes. El artículo 9 del Reglamento de IA exige un sistema de gestión de riesgos para sistemas de alto riesgo. El artículo 10 aborda la gobernanza y gestión de datos. El artículo 12 exige conservación de registros para determinados sistemas, y el artículo 14 regula la supervisión humana. El artículo 15 se ocupa de precisión, robustez y ciberseguridad.
Esta última conexión es especialmente relevante. Un sistema puede ser correcto desde el punto de vista de la ciberseguridad y fallar en precisión; también puede ofrecer resultados razonables y ser vulnerable a manipulación de entradas, extracción de datos o ataques de envenenamiento. La gobernanza de IA no debe dividirse entre un equipo de ética que documenta usos y un equipo de seguridad que protege servidores. El riesgo se produce en la intersección.
El artículo 50, relativo a determinadas obligaciones de transparencia, también puede tener impacto operativo cuando el sistema interactúa directamente con personas o genera contenido sintético. La organización necesita saber dónde debe informar de que una persona está interactuando con una máquina o de que un contenido ha sido generado o manipulado. No es solo una cuestión de interfaz: afecta a fraude, confianza del cliente y conservación de evidencias.
El CISO debe evitar dos errores opuestos. El primero consiste en tratar toda IA como un sistema de alto riesgo y paralizar usos de bajo impacto con burocracia innecesaria. El segundo consiste en dejar fuera del perímetro los modelos internos porque no se venden al público. El criterio práctico es mapear el uso, el impacto y la capacidad de influir sobre personas, operaciones o derechos, y después asignar controles proporcionales.
El proveedor vuelve a ser el eslabón incómodo
La IA intensifica un problema que los reguladores llevan años señalando: una entidad puede controlar sus propios sistemas y seguir dependiendo de una cadena tecnológica que no ve.
El proveedor del modelo puede apoyarse en un proveedor de nube. La nube puede utilizar servicios de monitorización de un tercero. La aplicación final puede enviar prompts, metadatos o registros a otra región. El contrato principal puede describir el servicio como una función estándar y no explicar qué ocurre cuando el modelo se reentrena, cambia de versión o retiene datos para mejorar el producto.
Para gestionar este riesgo, el contrato debe ir más allá de las cláusulas genéricas de seguridad. Debe identificar los subcontratistas relevantes, regular los cambios de modelo, exigir notificación de incidentes, describir los controles de acceso, establecer límites de uso de datos y permitir pruebas o auditorías proporcionales. También debe fijar la portabilidad de configuraciones, registros y datos, así como un procedimiento de salida que pueda ejecutarse bajo presión.
En DORA, el artículo 30 no convierte el derecho de auditoría en una formalidad decorativa. La entidad debe poder obtener información suficiente para evaluar el servicio, controlar el riesgo y cumplir sus obligaciones. El artículo 28, además, obliga a mirar la concentración: muchas entidades pueden depender de los mismos grandes proveedores de nube, identidad, correo o modelos. Una interrupción en uno de ellos puede afectar a competidores que, sobre el papel, tienen planes de continuidad independientes.
En septiembre de 2026 entra además en una fase especialmente relevante el Cyber Resilience Act. Sus obligaciones de notificación de vulnerabilidades explotadas activamente y de incidentes graves empiezan a aplicarse el 11 de septiembre de 2026, mientras la aplicación general del Reglamento está prevista para el 11 de diciembre de 2027. La fecha no convierte todos los productos conectados en un problema financiero, pero sí refuerza una expectativa que los CISO ya deberían tener incorporada: los fabricantes deben ofrecer información y procesos de gestión de vulnerabilidades más estructurados.
Esto cambia la conversación con proveedores. Ya no basta con pedir una certificación anual o un informe SOC 2 que nadie lee completo. Hay que preguntar cómo se recibe una alerta de vulnerabilidad, quién decide si afecta al servicio contratado, qué plazo existe para aplicar un parche y qué evidencia se entrega al cliente. La resiliencia depende tanto de la calidad del control como de la velocidad con la que la información llega a quien debe usarla.
Qué debería medir un CISO en 2026
El informe de Proofpoint apunta a una mejora de la confianza, pero la confianza necesita indicadores que resistan una crisis y una auditoría. Las métricas más útiles no son necesariamente las más vistosas.
El tiempo medio de detección sigue siendo relevante, pero debe acompañarse del tiempo hasta la decisión. Una alerta puede detectarse en dos minutos y permanecer 40 minutos sin propietario. Conviene medir por separado el tiempo hasta validar, contener, recuperar y determinar el alcance de los datos afectados.
También hay que medir la cobertura real de los activos críticos. No el porcentaje de dispositivos conectados a una herramienta, sino el porcentaje de servicios prioritarios con registros suficientes, cuentas privilegiadas revisadas, dependencias documentadas y una recuperación probada. Un sistema invisible no puede ser resiliente por decreto.
En IA, los indicadores deben capturar usos no autorizados, modelos sin propietario, datos sensibles enviados a servicios externos, cambios de versión sin evaluación, permisos de agentes y porcentaje de casos de uso con revisión humana. Una métrica como el número de modelos inventariados puede premiar el papeleo y ocultar que nadie conoce las conexiones de esos modelos con los sistemas de producción.
La continuidad también requiere pruebas adversariales. Un ejercicio de mesa que pregunta qué haría la organización ante una interrupción del proveedor aporta poco si todos responden según el manual. Es más útil simular que el modelo devuelve resultados manipulados, que el proveedor no puede explicar una anomalía, que los registros están incompletos o que el canal principal de comunicación ha sido comprometido.
NIST CSF 2.0, publicado en febrero de 2024, ofrece una estructura útil para ordenar esta conversación mediante las funciones Govern, Identify, Protect, Detect, Respond y Recover. Su valor no está en convertirlo en otra lista de comprobación, sino en conectar gobierno y recuperación con los controles técnicos. Para IA, la función Govern obliga a discutir quién acepta el riesgo; Identify, a localizar activos, proveedores y dependencias; Detect y Respond, a definir cómo se investigan las salidas anómalas; Recover, a demostrar que la operación puede continuar sin el modelo original.
La evidencia será el campo de batalla
Las organizaciones suelen mejorar sus políticas antes que sus evidencias. En una auditoría, sin embargo, una afirmación de control vale poco si no puede probarse.
Un CISO debería poder presentar la relación entre cada servicio crítico y sus dependencias tecnológicas, el último resultado de una prueba de recuperación, los registros de cambios de modelos, la aprobación del caso de uso, las evaluaciones de permisos y los informes de incidentes. También debería demostrar qué ocurrió cuando una prueba falló. Un control que nunca genera excepciones puede ser un control perfecto o un control que nadie pone a prueba.
La evidencia debe conservar el contexto suficiente para reconstruir decisiones. Si un agente de IA bloquea una cuenta, el registro no debería limitarse a indicar que la acción fue ejecutada. Debe permitir saber qué entrada recibió, qué regla o modelo influyó, qué identidad autorizó la acción, qué datos consultó y cómo se revisó el resultado. Sin esa trazabilidad, la organización tendrá dificultades para investigar un incidente y para explicar su conducta al regulador o al cliente.
El artículo 12 del Reglamento de IA, cuando resulta aplicable al sistema correspondiente, refuerza la exigencia de registros. El GDPR exige además aplicar medidas técnicas y organizativas adecuadas al riesgo, conforme al artículo 32, y mantener una respuesta capaz de cumplir el artículo 33 cuando se produce una violación de datos personales. DORA exige conservar documentación del marco de riesgo ICT, de las pruebas y de los incidentes. No son obligaciones intercambiables, pero pueden apoyarse en una arquitectura común de evidencias.
El beneficio de esa arquitectura es tangible. El mismo registro de una interrupción puede alimentar el análisis de continuidad, la evaluación de impacto sobre clientes, la clasificación DORA, la notificación GDPR y la revisión contractual del proveedor. El riesgo aparece cuando cada departamento mantiene su propia versión de los hechos en una hoja de cálculo distinta.
La objeción: más controles pueden frenar la innovación
La crítica habitual es razonable: si cada uso de IA exige un comité, una evaluación jurídica y una batería de pruebas, los equipos buscarán herramientas fuera del perímetro corporativo. La innovación no desaparece; se vuelve clandestina.
La respuesta no es imponer el mismo nivel de control a todo. Es clasificar. Un asistente que trabaja con información pública y no puede ejecutar acciones debería tener un tratamiento distinto de un agente que modifica órdenes, decide límites de crédito o accede a datos de salud. La proporcionalidad permite acelerar los usos de bajo riesgo y reservar la revisión profunda para los casos que pueden causar daño financiero, regulatorio u operativo.
Pero proporcionalidad no significa informalidad. Incluso el caso de bajo riesgo necesita un propietario, una política de datos y una vía para reportar problemas. Un experimento puede ser pequeño; una fuga de información nunca lo es para la persona cuyos datos han salido de la organización.
La alfabetización también importa. El artículo 4 del Reglamento de IA obliga a proveedores y responsables del despliegue a adoptar medidas para garantizar un nivel suficiente de alfabetización en IA de su personal y de las personas que utilizan estos sistemas en su nombre. No exige que cada empleado se convierta en ingeniero de modelos. Sí impide que la organización trate una herramienta generativa como una aplicación inocua cuyo funcionamiento nadie necesita comprender.
El papel del consejo: aceptar riesgo con información, no con optimismo
El aumento de la resiliencia solo será sostenible si el consejo de administración recibe información que permita decidir. Un cuadro con el número de alertas bloqueadas no cumple esa función. El consejo necesita conocer qué servicios no pueden detenerse, qué proveedores concentran dependencia, qué escenarios siguen sin probarse y qué consecuencias tendría una pérdida de confidencialidad frente a una interrupción.
DORA coloca la responsabilidad última en el órgano de dirección y exige formación adecuada. Eso no significa que el consejo deba aprobar cada regla de firewall. Significa que debe poder cuestionar supuestos: ¿por qué se considera recuperable un servicio cuya dependencia de identidad está concentrada en un único proveedor? ¿Qué ocurre si el sistema de IA sigue disponible, pero sus datos de entrenamiento o sus registros han sido manipulados? ¿Qué clientes o mercados quedarían afectados si la respuesta tarda 72 horas?
El CISO tampoco debería aceptar el papel de propietario universal del riesgo tecnológico. Su responsabilidad es aportar criterio técnico, visibilidad y capacidad de respuesta. La decisión de mantener un riesgo residual pertenece a la dirección que controla presupuesto, producto, operaciones y proveedores. Cuando todo se entrega al CISO, la organización consigue un responsable conveniente, no necesariamente una defensa mejor.
La conclusión que deja 2026
La lectura más útil del Voice of the CISO 2026 no es que la ciberseguridad esté resuelta. Es que las organizaciones parecen estar construyendo mejores músculos de recuperación mientras la IA les obliga a correr una carrera distinta.
La prioridad para los próximos meses no debería ser perseguir cada novedad del mercado de herramientas. Debería consistir en cerrar tres huecos concretos: inventar los usos reales de IA, conectar los procesos de incidentes con los plazos regulatorios y probar las dependencias externas como si fueran parte del propio sistema.
Un programa sólido debe saber qué modelo interviene en un proceso crítico, qué datos recibe, qué puede hacer, quién puede detenerlo y cómo se continúa la operación si deja de estar disponible. Debe poder transformar una alerta técnica en una decisión de negocio y una decisión de negocio en evidencia verificable. Y debe hacer todo eso antes de que un proveedor, un atacante o un empleado descubra por la vía más cara que el inventario estaba incompleto.
La ciberresiliencia mejora cuando la organización aprende a recuperarse. Pero en 2026 la pregunta decisiva es otra: ¿puede recuperarse sin perder el control sobre la inteligencia que ha incorporado a sus procesos? Si la respuesta sigue siendo vaga, la resiliencia aún es una promesa, no una capacidad.