1 minuto: la ventana de explotación que quedaría en 2027

Un análisis publicado por a16z, con datos de Epoch AI y ZeroDayClock, puso un número sobre algo que se viene sintiendo hace tiempo: hace apenas unos años, una vulnerabilidad recién divulgada podía quedar sin ser explotada durante semanas o incluso meses. En 2022, la mitad de las vulnerabilidades conocidas seguían sin ser atacadas después de 1.5 y hasta 3 meses de haberse hecho públicas. Ese margen funcionaba como una red de contención: había tiempo para enterarte, parchear y seguir adelante.

Ese margen prácticamente desapareció.

Según ese mismo análisis, la tasa de vulnerabilidades explotadas el mismo día de su divulgación (o antes) se cuadruplicó desde 2020. El tiempo mediano entre que una vulnerabilidad se conoce y que alguien la explota es hoy de un día. Y la proyección de a16z apunta a que baje a un minuto durante 2027.

Vale aclarar algo importante: esa cifra proyectada quedó en discusión. Después de la publicación original, ZeroDayClock revisó su metodología, y las lecturas más recientes muestran un porcentaje bastante menor al que circuló inicialmente. La tendencia de fondo -la aceleración sostenida desde 2020- se mantiene; el número exacto de "un minuto" hay que tomarlo como proyección, no como dato cerrado.

Por qué se está comprimiendo el ciclo

La explicación no es que haya más atacantes o más motivación. Es que la IA está acelerando el ciclo completo: encontrar la vulnerabilidad, entender cómo explotarla y construir el exploit funcional. Lo que antes requería un experto trabajando varios días hoy se resuelve en horas.

Y esto no aplica solo del lado ofensivo. La misma tecnología que acelera el ataque puede acelerar la defensa, pero solo si está integrada de forma continua en el proceso de seguridad, no como un chequeo puntual.

Encontrar ya no es el diferencial

Durante años, el valor de un servicio de seguridad estuvo en su capacidad de encontrar vulnerabilidades. Hoy, encontrar es cada vez más accesible: cualquier agente automático puede escanear una superficie y devolver una lista de hallazgos.

La pregunta que importa cambió. Ya no es "¿qué encontramos?", sino "¿cuáles de estos hallazgos son reales, cuáles importan primero y quién se asegura de que la remediación efectivamente suceda?". Filtrar el ruido, priorizar con criterio experto y sostener el proceso de arreglo de forma recurrente es el trabajo que un agente aislado todavía no reemplaza.

Por qué un test puntual llega tarde por diseño

Si el tiempo de explotación se mide en horas, un modelo de testing trimestral o anual tiene un problema estructural: no importa cuán bueno sea el resultado, siempre va a estar respondiendo a una foto vieja. Una vulnerabilidad que surge en la semana 2 después de tu último test puede estar explotada semanas antes de que llegue el próximo.

Esto no es un llamado a "testear más rápido", es un cambio de modelo. La validación tiene que ser continua, embebida en el flujo de desarrollo (assets nuevos, cambios de código, exposición que varía), no un evento aislado en el calendario.

Qué hacer con esto

La ventaja competitiva de hoy no está en reaccionar más rápido que el resto. Está en no depender de reaccionar: en tener un proceso de validación y remediación corriendo de forma constante, para que cuando aparezca la próxima vulnerabilidad crítica, ya haya un camino claro -y en marcha- para resolverla.

‍

Fuente: a16z, "Chart of the Week" (septiembre 2026), con datos de Epoch AI y ZeroDayClock.