El CISO de Qualys plantea que la métrica tradicional de tiempo de respuesta ya no sirve cuando la IA multiplica el volumen de hallazgos sin aumentar el riesgo real.
Nathan Smolenski, CISO en Qualys, señaló que menos del uno por ciento de las vulnerabilidades divulgadas durante 2025 representaron riesgo activo para las organizaciones. La afirmación llega en un momento en que los equipos de seguridad enfrentan un volumen creciente de vulnerabilidades descubiertas mediante inteligencia artificial, lo que genera una paradoja operativa: más hallazgos no equivalen a más amenazas reales, pero sí consumen más capacidad de análisis y respuesta. La discusión sobre cómo priorizar en este contexto adquiere relevancia directa para América Latina, donde la escasez de talento especializado convierte cada hora de analista en un recurso crítico que no puede desperdiciarse en falsos positivos o vulnerabilidades sin explotación documentada.
Por qué el MTTR dejó de ser una métrica útil en entornos saturados de hallazgos
Smolenski propone que los CISOs abandonen el seguimiento del tiempo medio de remediación (MTTR) como indicador principal y lo reemplacen por el rastreo de la ventana promedio de exposición. La diferencia es sustancial: el MTTR mide cuánto tarda un equipo en cerrar cualquier vulnerabilidad reportada, sin distinguir si esa falla está siendo explotada en la práctica o si simplemente existe como posibilidad teórica. La ventana de exposición, en cambio, cuantifica el período durante el cual un activo crítico estuvo vulnerable a una amenaza con explotación activa confirmada.
El cambio de métrica responde a una realidad operativa concreta. Cuando la IA genera miles de hallazgos mensuales y menos del uno por ciento representa riesgo real, optimizar para cerrar tickets rápido incentiva el comportamiento equivocado: los equipos terminan parcheando sistemas de baja criticidad con vulnerabilidades sin exploit conocido, mientras demoran la atención de fallas que sí están siendo usadas en campañas activas. En contextos latinoamericanos, donde un equipo de seguridad promedio en una empresa mediana puede contar con dos o tres analistas para toda la infraestructura, esta desalineación de prioridades no es solo ineficiente — es directamente insostenible.
Cómo la automatización de remediación cambia el modelo de confianza operativa
La propuesta de Smolenski para manejar el volumen incluye remediación autónoma, pero condicionada a tres controles: tiering de activos, revisión humana y procesos de rollback documentados. El tiering implica clasificar la infraestructura por criticidad antes de habilitar cualquier automatización — los sistemas de producción que sostienen operaciones de negocio no pueden tratarse igual que entornos de desarrollo o staging. La revisión humana no desaparece: se desplaza del análisis de cada vulnerabilidad individual hacia la supervisión de patrones y excepciones que el sistema autónomo no puede resolver por sí mismo.
Los procesos de rollback son la condición de posibilidad para que la automatización sea aceptable en entornos regulados. Si un parche automatizado genera inestabilidad o rompe dependencias no documentadas, el equipo necesita capacidad de revertir el cambio sin intervención manual compleja ni ventanas de mantenimiento extendidas. En sectores como banca o salud en Brasil, Colombia o Chile, donde las regulaciones locales exigen trazabilidad completa de cambios en sistemas críticos, la ausencia de rollback confiable convierte la remediación autónoma en un riesgo de cumplimiento, no en una ventaja operativa.
El impacto desproporcionado del ruido de vulnerabilidades en equipos con recursos limitados
El fenómeno que describe Smolenski — volumen creciente de hallazgos con proporción decreciente de riesgo real — afecta de manera desproporcionada a organizaciones en América Latina. Un equipo de seguridad en una empresa mexicana del sector retail, por ejemplo, enfrenta el mismo flujo de CVEs y alertas de scanners que una corporación estadounidense con diez veces su presupuesto de seguridad, pero sin acceso a las mismas herramientas de priorización contextual ni a la misma profundidad de personal para validar manualmente cada hallazgo.
La consecuencia práctica es que muchos equipos terminan operando en modo reactivo permanente: responden a lo que genera más ruido en los dashboards, no a lo que representa más riesgo para el negocio. Cuando menos del uno por ciento de las vulnerabilidades divulgadas en 2025 tuvo explotación activa, pero los scanners reportan cientos de hallazgos mensuales sin esa distinción clara, el resultado es fatiga de alertas y desalineación entre esfuerzo invertido y reducción real de superficie de ataque. En contextos donde la rotación de personal de seguridad es alta — un problema documentado en Argentina, Perú y otros mercados de la región — esta desalineación acelera el burnout y dificulta la retención de talento.
Nuestro análisis
La observación de Smolenski sobre el uno por ciento de vulnerabilidades con riesgo activo no es nueva en sí misma — estudios previos de Kenna Security (ahora parte de Cisco) y del proyecto Exploit Prediction Scoring System (EPSS) ya habían documentado que la mayoría de las CVEs nunca llegan a explotación en la práctica. Lo relevante es el timing: la afirmación llega cuando la IA está multiplicando el volumen de hallazgos sin mejorar proporcionalmente la capacidad de los equipos para distinguir señal de ruido. El cambio de métrica que propone — de MTTR a ventana de exposición — es coherente con este contexto, pero su implementación requiere madurez en gestión de activos que muchas organizaciones en la región todavía no tienen. Sin un inventario confiable de qué sistemas son críticos y cuáles no, el tiering que habilita la remediación autónoma segura simplemente no es posible.
Lo que Smolenski no aborda explícitamente es cómo los equipos pueden acceder a inteligencia de amenazas contextual que les permita identificar ese uno por ciento de vulnerabilidades con riesgo real sin depender exclusivamente de vendors comerciales. Para organizaciones en América Latina, donde el acceso a plataformas de threat intelligence de nivel enterprise puede estar fuera de alcance presupuestario, la brecha entre «saber que el 99% de las CVEs no importa» y «saber cuál 1% sí importa para mi infraestructura específica» sigue siendo un problema sin resolver. ¿Qué pasa cuando la priorización basada en contexto se convierte en una ventaja competitiva accesible solo para quienes pueden pagar las herramientas que la automatizan?