La IA dispara las brechas críticas, pero el dato incómodo es otro: casi ninguna exige correr a ciegas

La cifra que se ha llevado el titular es fácil de vender: las brechas críticas se han más que duplicado en el último año. La cifra que de verdad debería incomodar a los equipos de seguridad es bastante menos vistosa: menos de una de cada doce requiere una acción inmediata. Traducido al castellano llano: el problema no es solo que haya más exposición. El problema es que demasiadas empresas siguen respondiendo al ruido como si todo ardiera al mismo tiempo.

Ese es el ángulo realmente útil del informe Under Pressure: 2026 Exposure Gap Report de Check Point. No basta con decir que la IA agrava la superficie de ataque, multiplica configuraciones erróneas y acelera la aparición de fallos explotables. Todo eso ya lo sospechábamos. Lo interesante es la combinación tóxica entre dos fenómenos: más hallazgos catalogados como críticos y menos capacidad real de distinguir qué merece una intervención hoy y qué puede entrar en una cola gestionable sin provocar un colapso operativo.

Y sí, aquí aparece la ironía habitual del sector: llevamos años comprando herramientas para ver más, detectar antes y clasificar mejor, y en 2026 una parte nada menor de las organizaciones sigue atrapada en una economía de alertas donde ver más no equivale a entender mejor.

El titular de las “brechas críticas” necesita traducción simultánea

Cuando un informe afirma que las brechas críticas se han duplicado, conviene hacer la pregunta menos glamourosa y más útil: ¿qué está llamando exactamente “crítico”? En la práctica, muchas plataformas mezclan vulnerabilidades explotables, errores de configuración, identidades sobreprivilegiadas, activos expuestos a internet, secretos embebidos en código, buckets mal configurados o rutas de movimiento lateral demasiado obvias. Todo eso importa, pero no todo eso exige parar la máquina.

La distinción no es semántica. Es presupuestaria, operativa y, en sectores regulados, también legal. Si menos de una de cada doce exposiciones críticas requiere respuesta inmediata, la consecuencia es brutal para cualquier CISO: alrededor del 90% del volumen etiquetado como crítico puede estar compitiendo por atención con incidentes reales, con deuda técnica heredada y con proyectos regulatorios que tienen fecha de entrega sí o sí.

Ahí está la grieta. No entre “tener o no tener ciberseguridad”, ese debate de PowerPoint ya aburre, sino entre capacidad de detección y capacidad de decisión. La IA generativa, los asistentes de desarrollo, la automatización de infraestructura y el aprovisionamiento cada vez más veloz han reducido el tiempo necesario para crear nuevo software, nuevas integraciones y nuevos errores. La defensa, en cambio, sigue dependiendo en demasiados casos de comités, tickets, validaciones cruzadas y ventanas de cambio que se miden en semanas. El atacante automatiza. El defensor convoca una reunión.

Eso explica por qué el riesgo de “colapso digital” no debe leerse solo como una imagen dramática. Hay un colapso más silencioso y bastante más frecuente: la saturación del sistema interno de remediación. Cuando el inventario de exposición crece más rápido que la capacidad de corregir, la organización empieza a tomar atajos. Se aplazan parches, se rebajan excepciones, se toleran privilegios excesivos y se confía en controles compensatorios que nadie valida con rigor. El resultado no siempre es un gran incidente mañana. A veces es algo peor: una erosión progresiva del control hasta que el incidente llega y nadie puede decir que no había señales.

La IA no “crea” el desastre: acelera tres fallos que ya estaban ahí

Conviene bajar el volumen de la retórica. La IA no ha inventado la mala gestión de activos, ni las credenciales expuestas, ni las cadenas de suministro de software opacas. Lo que ha hecho es aumentar la velocidad y la escala de tres problemas antiguos.

1. Desarrollo más rápido, validación más débil

El uso masivo de asistentes de código y automatización de pipelines está acortando ciclos de entrega. Eso tiene valor de negocio. También introduce una tentación muy humana: asumir que si el código compila y pasa pruebas funcionales, ya habrá tiempo para limpiar después. No siempre lo hay. Dependencias no revisadas, secretos insertados en repositorios, configuraciones inseguras heredadas y patrones de autenticación pobres entran en producción con demasiada facilidad.

La propia CISA lleva tiempo advirtiendo que la seguridad debe incorporarse antes en el ciclo. Su catálogo Known Exploited Vulnerabilities sigue recordando algo muy poco futurista: muchos ataques exitosos explotan fallos viejos, públicos y parcheables. No hace falta ciencia ficción. Basta con una ventana abierta y un equipo agotado.

2. Superficies cloud y SaaS más extensas, y peor inventariadas

En 2026, pocas empresas saben con precisión cuántos servicios SaaS usan realmente sus empleados, cuántas identidades de servicio tienen privilegios permanentes o cuántos activos expuestos mantienen un dueño técnico claro. La IA añade otra capa: modelos, conectores, APIs, repositorios de prompts, bases vectoriales y servicios de terceros que a menudo nacen fuera del radar del equipo de seguridad.

Esto no es una cuestión filosófica. Si no conoces el activo, no lo monitorizas. Si no sabes qué identidad lo administra, no puedes aplicar mínimo privilegio. Si no identificas qué datos alimentan al sistema, no puedes evaluar impacto en privacidad ni riesgo contractual. El inventario, esa tarea tan poco sexy que nadie quiere vender en una keynote, sigue siendo una de las defensas más rentables.

3. Priorización defectuosa: CVSS alto, riesgo real incierto

El sector arrastra una adicción a las puntuaciones simples. CVSS sigue siendo útil, pero no basta. Una vulnerabilidad con alta severidad en un sistema aislado y sin ruta de explotación plausible puede ser menos urgente que una mala configuración “moderada” en una identidad con acceso a producción. De hecho, ese es el mensaje de fondo que sugiere el informe de Check Point: no toda criticidad formal equivale a urgencia operativa.

EPSS, inteligencia de explotación activa, contexto del activo, exposición a internet, privilegios asociados y presencia de datos sensibles pesan más en la decisión diaria que una nota numérica sola. Quien siga parcheando por color de semáforo y no por explotabilidad contextualizada está administrando ansiedad, no riesgo.

La brecha de exposición ya no es un problema técnico: es de gobierno

Las empresas maduras en 2026 ya no discuten si deben tener un programa de gestión de vulnerabilidades. Eso se da por hecho. La pregunta incómoda es otra: ¿quién decide qué riesgo se acepta, durante cuánto tiempo y con qué evidencia? Ahí es donde el asunto deja de ser puramente técnico y entra en territorio de gobierno corporativo, auditoría interna y regulación.

NIS2 lo deja poco margen a la improvisación. El artículo 21 exige medidas de gestión de riesgos de ciberseguridad “adecuadas y proporcionadas”, incluyendo gestión de incidentes, continuidad de negocio, seguridad en la cadena de suministro, prácticas de higiene cibernética y uso de criptografía cuando proceda. El artículo 20, además, subraya la responsabilidad de los órganos de dirección en la aprobación y supervisión de esas medidas. Dicho sin jerga: el consejo no puede fingir que esto es solo cosa del SOC.

Para entidades financieras europeas, DORA aprieta todavía más el tornillo. El Reglamento (UE) 2022/2554 obliga a disponer de un marco sólido de gestión del riesgo TIC. El artículo 6 fija los principios generales; el artículo 8 entra en identificación; el artículo 10 se centra en protección y prevención; el artículo 11 en detección; el artículo 12 en respuesta y recuperación; y el artículo 13 en aprendizaje y evolución. No se trata únicamente de tener herramientas. Se trata de demostrar un proceso coherente, repetible y trazable.

Aquí surge una contradicción que muchas organizaciones van a sufrir este año. Por un lado, el negocio exige desplegar casos de uso de IA a gran velocidad. Por otro, DORA y NIS2 premian lo contrario: conocer dependencias, documentar controles, probar resiliencia, registrar incidentes, revisar terceros y asignar responsabilidades. La velocidad no está prohibida. La improvisación, en la práctica, sí.

Y luego está GDPR, que sigue apareciendo donde algunos no quieren mirarlo. Si un despliegue de IA implica tratamiento de datos personales, no basta con hablar de seguridad abstracta. El artículo 25 exige protección de datos desde el diseño y por defecto; el artículo 32 impone medidas técnicas y organizativas apropiadas; el artículo 33 obliga a notificar violaciones de seguridad a la autoridad de control en un máximo de 72 horas cuando proceda. Si una exposición crítica termina en una filtración, el debate sobre “priorización” deja de ser metodológico y se convierte en un expediente.

Lo más peligroso no es tener muchas vulnerabilidades. Es no saber cuáles pueden tumbarte esta semana

Hay un error de gestión que se repite con una constancia casi entrañable: medir madurez por número de hallazgos cerrados. Esa métrica sirve para el tablero. Sirve mucho menos para reducir riesgo material. Si una empresa cierra 5.000 tickets de baja relevancia y mantiene abiertas 20 rutas claras hacia activos críticos, el indicador mejora y la seguridad empeora. Maravillas de la burocracia digital.

La priorización útil en 2026 tiene que responder cinco preguntas concretas antes de mover recursos:

1. ¿Existe explotación activa? Si la vulnerabilidad figura en catálogos de explotación conocida o hay evidencia creíble de abuso en campañas recientes, el tiempo de reacción cambia por completo.

2. ¿El activo está expuesto a internet o accesible desde un segmento comprometible? La mera presencia en producción no basta. La ruta de acceso importa.

3. ¿Qué privilegios o datos están en juego? Un fallo en una cuenta de servicio con permisos amplios puede ser más grave que uno en un servidor periférico con controles de contención sólidos.

4. ¿Hay controles compensatorios reales y probados? “Tenemos WAF” no es una respuesta automática. Hay que validar si mitiga esa ruta concreta y con qué eficacia.

5. ¿Cuál es la dependencia operativa? Si la corrección rompe producción, la decisión requiere coordinación estrecha con negocio, pero no puede convertirse en una excusa infinita.

Esta forma de decidir es más lenta que mirar un ranking por severidad. También es bastante más honesta. Y reduce el riesgo de otra enfermedad corporativa muy extendida: el parcheo ceremonial. Mucha actividad visible, poco impacto real.

La fatiga del equipo de seguridad ya es un riesgo sistémico

Cuando un informe habla de “presión”, no se refiere solo a la presión del atacante. Habla de la presión interna sobre equipos que acumulan backlogs, heredan arquitecturas híbridas imposibles, negocian con proveedores opacos y, además, tienen que demostrar cumplimiento ante auditoría, reguladores y consejo. Ese desgaste ya no puede tratarse como un problema de recursos humanos. Es una variable de control.

Un equipo agotado comete tres errores previsibles. Primero, normaliza el desorden y acepta excepciones que hace un año habría cuestionado. Segundo, responde a la métrica que más se mira, no a la que más reduce riesgo. Tercero, pierde capacidad de anticipación y se vuelve reactivo. El resultado es justo el que describe la idea de “exposure gap”: la distancia entre lo que la organización ve y lo que realmente puede corregir a tiempo.

Esto enlaza con NIST CSF 2.0, que sigue siendo una referencia muy útil aunque no sea una norma obligatoria en Europa. La versión 2.0, publicada por NIST en febrero de 2024, reforzó la función Govern para dejar claro que la gestión del riesgo de ciberseguridad no puede limitarse a controles técnicos. Roles, tolerancia al riesgo, supervisión, política y prioridades del negocio pasan al centro del marco. Esa evolución encaja perfectamente con el problema actual: la exposición crítica crece más rápido que la capacidad de actuar, así que el gobierno de esa capacidad se vuelve decisivo.

Si tu organización sigue tratando el cansancio del equipo como un tema blando, mal asunto. La sobrecarga sostenida termina afectando a tiempos de respuesta, calidad de la remediación, documentación de evidencias y coordinación en crisis. En sectores esenciales o financieros, eso acaba chocando con obligaciones de continuidad y resiliencia. No es solo bienestar laboral. Es control interno.

Qué deberían hacer ahora los CISO y responsables de compliance, sin teatro

La noticia no justifica una estampida hacia nuevas plataformas milagrosas. De hecho, muchas empresas ya tienen demasiadas. Lo que exige es una revisión quirúrgica de cómo priorizan, cómo escalan y cómo documentan decisiones de riesgo. Hay cuatro frentes donde merece la pena intervenir de inmediato.

Revisar la definición interna de “crítico” y “urgente”

Si todo lo crítico entra en el mismo carril de remediación, el sistema está roto. La clasificación debe separar severidad intrínseca de urgencia operativa. Un hallazgo puede ser crítico por impacto potencial y no requerir corrección inmediata si no existe ruta creíble de explotación. A la inversa, una debilidad aparentemente menor puede exigir actuación urgente si afecta a identidades privilegiadas o a activos externos.

La clave es documentarlo. No como teoría, sino en política operativa: qué factores elevan una exposición, quién puede aceptar excepciones, qué evidencias se guardan y cada cuánto se reevalúan. Esa trazabilidad importa para auditoría, para consejo y para la mañana después del incidente.

Medir rutas de ataque, no solo hallazgos aislados

La unidad de riesgo útil ya no es la vulnerabilidad suelta. Es la ruta de ataque completa: activo expuesto, credencial reutilizable, privilegio excesivo, segmentación débil y acceso a dato crítico. La mayoría de las intrusiones serias no dependen de un único fallo heroico, sino de varias debilidades corrientes encadenadas con paciencia y automatización.

Esto exige cruzar fuentes: escáneres de vulnerabilidades, gestión de identidades, posture management cloud, repositorios de código, CMDB y telemetría de red. Suena obvio. En la práctica, sigue siendo una rareza operativa.

Poner a los equipos de plataforma y desarrollo dentro de la ecuación

Un problema de exposición creado por pipelines, IaC o integraciones SaaS no se resuelve solo desde seguridad. Hace falta disciplina de ingeniería: validaciones en CI/CD, escaneo de secretos, políticas de infraestructura como código, revisiones de dependencias y controles de privilegios en cuentas de servicio. La seguridad que llega al final para poner una pegatina roja llega tarde.

Si la IA se usa para acelerar desarrollo, también debe usarse para acelerar revisión y remediación. Pero con una advertencia: automatizar la corrección sin gobernanza puede multiplicar errores a velocidad industrial. Ya sería mala suerte arreglar cinco mil hallazgos rompiendo producción en cadena.

Conectar el backlog técnico con el lenguaje del negocio

El consejo no necesita una lección sobre CVEs. Necesita saber qué procesos de negocio podrían interrumpirse, qué terceros concentran dependencia, qué escenarios afectarían a clientes y cuánto tiempo puede sostenerse la operación degradada. DORA obliga precisamente a pensar así: funciones críticas, dependencias TIC, respuesta, recuperación y pruebas de resiliencia.

Cuando el backlog de exposición se traduce a impacto operativo, las prioridades cambian. También cambia la calidad de la conversación presupuestaria. Dejar de pedir “más herramientas” y empezar a pedir capacidad demostrable de reducción de riesgo suele funcionar mejor. Sorprendente, lo sé.

La IA complica también la cadena de suministro, y ahí DORA y NIS2 no permiten hacerse el distraído

Una parte del problema está fuera del perímetro clásico. Muchos despliegues de IA dependen de terceros: proveedores de modelos, plataformas cloud, APIs externas, librerías open source, servicios de orquestación, almacenamiento vectorial, plugins y conectores. Cada uno añade superficie de exposición, términos contractuales y posibles puntos de fallo.

En el mundo financiero europeo, DORA dedica un bloque entero al riesgo de terceros TIC. El artículo 28 exige gestionar ese riesgo como parte integrante del marco de riesgo TIC; el artículo 30 detalla elementos contractuales clave; y el artículo 31 aborda el registro de información sobre acuerdos contractuales. Si una entidad está incorporando IA mediante servicios de terceros sin revisar derechos de auditoría, localización de datos, subcontratación encadenada, soporte en incidentes y estrategias de salida, está sembrando problemas regulatorios además de técnicos.

NIS2, por su parte, incluye la seguridad de la cadena de suministro dentro de las medidas del artículo 21. No es un adorno. Es una señal clara de que el regulador ya no compra la defensa de “el proveedor falló”. Si el proveedor es crítico para tu servicio, su riesgo acaba siendo tu problema.

Lo delicado en 2026 es que la IA ha normalizado una cadena de suministro menos visible que la del software tradicional. No siempre sabes qué modelo subyacente usa tu proveedor, qué datasets han intervenido, qué subprocesadores participan o cómo gestiona vulnerabilidades en componentes de terceros. Esa opacidad no invalida el uso de IA, pero sí exige diligencia reforzada. Si no puedes entender dependencias básicas, no puedes valorar ni resiliencia ni cumplimiento.

Riesgo de colapso digital: menos apocalipsis, más dependencia acumulada

La expresión “colapso digital” puede sonar grandilocuente. Y a veces se usa así. Pero hay una lectura sobria que merece atención. El colapso no tiene por qué ser una caída absoluta y cinematográfica. Puede ser una degradación simultánea de varias capacidades esenciales: autenticación inestable, herramientas internas lentas, saturación de tickets, retrasos de despliegue, incremento de falsas urgencias, restauraciones fallidas y dependencia excesiva de personal clave. Todo eso junto reduce la resiliencia real de una organización sin necesidad de un único golpe espectacular.

Las normativas europeas más serias llevan años orientándose a ese concepto de resiliencia operativa. DORA, de hecho, no se limita a la confidencialidad del dato ni a la prevención clásica. Su ambición es que las entidades resistan, respondan y se recuperen. Esa lógica es útil incluso fuera de finanzas: la seguridad madura no consiste en prometer que nada fallará, sino en evitar que el fallo se convierta en crisis existencial.

Por eso el dato de “menos de una de cada doce” es tan relevante. Sugiere que el desafío no es solo detener ataques, sino impedir que la organización se autoboicotee intentando reaccionar a todo por igual. La parálisis por sobrealerta es una forma de indisponibilidad. No sale siempre en prensa, pero se cobra sus víctimas.

Qué señales debería vigilar una empresa en 2026 para saber si ya está entrando en esa zona roja

No hace falta esperar a un incidente grave para detectar que el sistema se está tensando demasiado. Hay indicadores bastante concretos que merecen seguimiento por parte de seguridad, tecnología y riesgo operacional.

• Crecimiento sostenido del backlog crítico sin reducción del tiempo medio de remediación. Si ambos empeoran a la vez, la capacidad está por debajo del flujo de exposición.

• Aumento de excepciones y ampliaciones de plazo. Una excepción razonada puede ser prudente. Cincuenta excepciones encadenadas suelen ser una confesión.

• Activos sin propietario claro o con inventario desactualizado. La remediación sin dueño termina en tierra de nadie.

• Dependencias de terceros sin pruebas recientes de continuidad o sin visibilidad contractual suficiente. El riesgo concentrado rara vez avisa con educación.

• Desajuste entre hallazgos técnicos y reporting al consejo. Si arriba solo llega un porcentaje de cierre genérico, alguien está simplificando demasiado.

• Automatización sin validación. Corregir más rápido está bien; corregir mal y a escala no tanto.

Estas señales no son académicas. Son la antesala de incidentes que luego se describen como inesperados, aunque llevaban meses pidiendo turno.

Para el sector financiero, el mensaje es particularmente incómodo

La banca, los seguros y buena parte del ecosistema fintech europeo viven este año bajo una presión regulatoria y tecnológica muy poco compatible con la improvisación. DORA ya está plenamente en el centro de la conversación de resiliencia operativa. Los programas de terceros TIC, los registros contractuales, la gobernanza del riesgo, la detección, la respuesta y las pruebas avanzadas no son tareas cosméticas. Exigen priorización adulta.

Si el volumen de exposiciones críticas crece porque la organización acelera iniciativas de IA, la respuesta no puede consistir en trasladar ese caos al equipo de cumplimiento para que lo maquille con políticas. Compliance no remedia secretos expuestos ni privilegios mal diseñados. Lo que sí puede hacer es forzar disciplina: exigir evidencia de criterios de priorización, revisar matrices de aceptación de riesgo, vincular hallazgos con funciones críticas y presionar para que terceros de alto impacto tengan controles contractuales y de supervisión coherentes.

Para las entidades españolas, además, el encaje con NIS2 y con la supervisión sectorial complica aún más el panorama. Aunque la transposición y aplicación práctica dependen del marco nacional y sectorial concreto, la dirección general es inequívoca: más responsabilidad del órgano de administración, más expectativas de diligencia y menos paciencia con la defensa de que “había demasiadas alertas”. El regulador no suele aceptar la fatiga como eximente.

La lectura correcta del informe no es “tenemos más problemas”. Es “estamos gestionando mal la urgencia”

Ese es el punto que merece quedarse. El aumento de exposiciones críticas es serio, sí. La IA está acelerando despliegues, multiplicando dependencias y ensanchando errores con una eficiencia casi admirable. Pero el dato que cambia la conversación no es el volumen bruto. Es que solo una fracción pequeña exige actuar de inmediato. Si una empresa no sabe aislar esa fracción con precisión, terminará distribuyendo mal presupuesto, agotando a sus equipos y dejando abiertas las rutas de ataque que de verdad importan.

En otras palabras: el problema no es solo técnico. Es de enfoque. Quien siga confundiendo visibilidad con control y severidad con urgencia se acerca más al colapso por mala gestión que al ataque sofisticado de portada. Y eso, para ser sinceros, es bastante más embarazoso.

La buena noticia es que esta brecha de exposición no se corrige con magia ni con otra plataforma prometiendo “IA para asegurar la IA”. Se corrige con inventario fiable, contexto de negocio, rutas de ataque, disciplina contractual, criterios de urgencia defendibles y gobierno real. Menos fuegos artificiales. Más decisiones incómodas y medibles.

Tu organización probablemente ya ve suficiente. La pregunta que importa en 2026 es otra: ¿sabe qué debe arreglar antes del viernes?