La IA ya encuentra fallos de día cero sola. Tu problema son los 43 días de después

Los dos números que deciden qué te pasa a ti se publicaron antes de que existiera Astra, y ninguno de los dos habla de encontrar fallos. El primero es menos siete días: el tiempo medio hasta la explotación, según M-Trends 2026, es negativo. El segundo es 43 días: la mediana que tarda una organización en remediar del todo una vulnerabilidad del catálogo KEV, según el DBIR de Verizon de este año. Entre uno y otro no hay ni un solo día que dependa de lo rápido que alguien encuentre el agujero.

El 4 de septiembre OpenAI presentó GPT-6 Astra y declaró que es el primer modelo que despliega alcanzando el nivel «Crítico» de capacidad en ciberseguridad de su marco de preparación. Es una noticia grande y merece los titulares que ha tenido. Nosotros operamos infraestructura y guardias para clientes, así que la pregunta que nos han hecho esta semana no es si el modelo impresiona —impresiona—, sino qué cambia el lunes. La respuesta honesta es incómoda: para la mayoría de las empresas que conocemos, nada. Y eso no es la buena noticia, es la mala.

Qué dijo OpenAI, con las cifras y con la letra pequeña

El umbral «Crítico» de su marco lo define la propia OpenAI por dos vías, y esta es la primera: la capacidad de «identificar y desarrollar exploits funcionales de día cero de cualquier nivel de severidad en muchos sistemas críticos endurecidos del mundo real, sin intervención humana». Las cifras que acompañan el anuncio: en ExploitBench, Astra puntúa 100% frente al 78,5% de su predecesor GPT-5.6 Sol; en ExploitGym, un banco de pruebas más amplio de desarrollo de exploits, 42,4% frente a 30,3%, y con menos tokens de salida. Para descartar que estuviera recitando de memoria, lo probaron contra fallos divulgados en los tres meses anteriores al lanzamiento —posteriores a su corte de entrenamiento— y por el camino encontró dos vulnerabilidades desconocidas, cuyos fabricantes están siendo avisados.

Ahora la letra pequeña, que es nuestra lectura y la marcamos como tal. Ese 100% se midió, según el propio anuncio, sin las salvaguardas de producción. La versión que una empresa puede activar en su espacio de trabajo está restringida a revisión y corrección segura de código y se niega a generar pruebas de concepto. Son dos configuraciones distintas del mismo modelo, y el número del titular describe la que no te dan. No es una acusación: OpenAI lo publica sin esconderlo. Es que casi nadie lo ha contado, y la diferencia entre «el modelo puede» y «el modelo que tú enciendes puede» es exactamente la que separa una noticia de una decisión de compra. El acceso viene además apagado por defecto y el administrador tiene que habilitarlo a mano.

El segundo detalle. La relajación de esas restricciones está prevista para defensores verificados a través de un programa propio, Daybreak. Es decir: la mitad ofensiva llega primero al mundo como capacidad demostrada, y la mitad defensiva llega después y con lista de invitados. No sabemos con qué criterios se entra en esa lista, y no vamos a fingir que lo sabemos; sí observamos que una empresa de treinta personas rara vez está en ese tipo de listas. Y una frase que se ha citado poco, del analista Sanchit Vir Gogia: «Astra behaves better and watches worse». Se comporta mejor y se deja vigilar peor: su cadena de razonamiento es menos observable que la del modelo anterior. Un sistema más capaz y a la vez más difícil de auditar es, en cualquier disciplina de ingeniería, una combinación que obliga a poner controles alrededor en vez de confiar en el propio sistema.

Los dos números que ya decidían tu riesgo

M-Trends 2026, el informe anual de Mandiant, sitúa el tiempo medio hasta la explotación en aproximadamente menos siete días. El signo es lo importante: significa que, de media, el fallo se está explotando una semana antes de que exista el parche. En 2018 esa ventana era de 63 días. Cruzó el cero en 2024. La serie no ha dado un salto: lleva años bajando en línea recta y ya pasó por debajo de la línea donde el parcheo, por rápido que sea, llega el primero.

El otro número va en dirección contraria. El DBIR de Verizon de 2026 sitúa la mediana para remediar del todo una vulnerabilidad del catálogo KEV en 43 días, frente a los 32 del año anterior. No baja: sube once días en doce meses. Poner los dos juntos da una ventana de unos cincuenta días que se abre antes de que el fabricante publique nada. Y aquí toca ser preciso, porque es el tipo de cuenta que se repite mal: una es una media y la otra una mediana, salen de informes distintos y de poblaciones distintas, así que sumarlos no es estadística, es un dibujo. El dibujo, sin embargo, no depende de la suma: las dos series se están alejando la una de la otra, cada una medida por su cuenta y cada una en la dirección que menos te conviene.

Ahí está lo que Astra no cambia. Ninguno de esos cincuenta días transcurre esperando a que alguien descubra el fallo. Transcurren después, en tu casa, entre que el arreglo existe y llega a tus máquinas.

El número que de verdad duele: el 26%

El mismo informe deja un dato que se ha comentado mucho menos y que a nosotros nos parece el más grave de los tres: de las vulnerabilidades del catálogo KEV de CISA que las organizaciones tienen en sus sistemas, solo se remedia por completo el 26%, frente al 38% del año anterior. Doce puntos menos en un año.

Antes de sacar conclusiones toca poner el contrapeso, y está en el mismo informe: la mediana de vulnerabilidades del KEV que una organización tenía que atender subió de 11 a 16 en un año, casi un 50% más. Parte de la caída del 38% al 26% es aritmética, no dejadez. Pero míralo bien, porque la cifra que sale de ahí es la que de verdad desarma la excusa del volumen: la empresa mediana tenía dieciséis. Dieciséis en todo el año. Y de esas dieciséis cerró cuatro.

El KEV no es la lista de todos los CVE del mundo. Es una lista corta, filtrada por alguien más, gratuita y publicada, con una única condición de entrada: que haya evidencia de que eso se está explotando ahora. El trabajo caro —triar, priorizar, decidir qué importa— viene hecho. Y las tandas son de un dígito: 3 entradas el 11 de agosto, 4 el 18, 6 el 26, 2 el 31 y 7 el 2 de septiembre, por citar cinco publicaciones que hemos comprobado una a una. No es un caudal: es un goteo de unas pocas por semana, ya priorizado.

Si tres de cada cuatro entradas de la lista corta —la que otro te ha filtrado, la que solo contiene lo que ya te están atacando— se quedan sin cerrar, entonces «hay demasiados CVE» nunca fue el motivo. Y un motor capaz de encontrar fallos más deprisa no cambia tu riesgo: cambia tu calendario. Una cola que ya no puedes vaciar cuando es corta no se arregla porque el mundo produzca más rápido: solo se hace más larga. Del cómo ordenamos esa cola cuando el titular no basta para decidir ya escribimos en el caso de los diez CVE en el mismo proceso.

Por qué 43 días no es pereza

La lectura fácil de esos 43 días es que la gente no parchea por dejadez. Operando infraestructura ajena desde 2015, casi nunca hemos visto eso. Lo que hemos visto es que el número es la suma de cinco cosas que no están, y ninguna de las cinco se compra con voluntad:

• No sabes dónde corre. El aviso dice «versiones anteriores a la X» y nadie de la sala sabe con certeza cuántas máquinas hay ni en qué versión están. El inventario no es burocracia: es el primer día de los 43.
• No tienes dónde probarlo. Sin un entorno parecido a producción, aplicar el parche es la prueba, y la prueba se hace con los clientes dentro.
• No puedes deshacerlo. Si el rollback es «restaurar la copia de anoche y perder el día», la decisión deja de ser técnica y pasa a ser una apuesta.
• No puedes parar. La ventana de mantenimiento existe en el papel y en la práctica cae siempre en la semana en que no se puede.
• No hay nadie despierto. Los avisos no salen los martes a las diez de la mañana. El de SonicWall que nos ocupó en julio entró en el catálogo con plazo de tres días contando fin de semana.

Y hay una sexta razón que casi nadie dice en voz alta porque queda mal: el miedo es racional. Los parches rompen cosas. En agosto contamos cómo una actualización de .NET rompió la impresión en aplicaciones en producción, y quien vivió aquello aprendió una lección equivocada pero comprensible: esperar. La respuesta a ese miedo no es valentía, es tener un sitio donde probar. Un equipo que puede probar no necesita ser valiente.

Tampoco vamos a vender que correr siempre salga bien. La semana pasada contamos cómo la versión que arreglaba el fallo de julio es la más nueva que septiembre declara vulnerable: quien cumplió el plazo de tres días aterrizó exactamente en la build que volvió al catálogo 49 días después. Eso no es un argumento para esperar. Es un argumento para no confundir «parcheado» con «seguro», y para tener el camino de vuelta preparado antes de necesitarlo.

Lo que sí mueve el número

Nada de lo que baja los 43 días es nuevo ni es un producto. Es el mismo trabajo aburrido de siempre: un inventario que se mantiene solo porque lo alimenta la propia máquina y no un Excel de hace dos años; un entorno de pruebas que se parezca a producción lo suficiente como para que un fallo aparezca allí; despliegues por partes y vuelta atrás en un clic; y telemetría que avise por síntomas, no por «el servicio está arriba». Es exactamente la misma lista que sale cada vez que analizamos un incidente grande, incluido el de la redundancia que no sobrevivió a un procedimiento. El fallo es inevitable; la avería es una decisión de diseño.

Falta la quinta pieza y aquí tenemos que ser honestos porque nos afecta al bolsillo: hace falta alguien que pueda ejecutar todo lo anterior cuando el aviso cae un viernes a las nueve de la noche, que es cuando cae. Nosotros vendemos guardia 24×7 y sería facilísimo venderla sola, como si contratar un teléfono nocturno bajara la mediana. No la baja. Una guardia sin inventario ni entorno de pruebas ni rollback es una persona despierta mirando un aviso que no puede aplicar sin arriesgarse. Lo que baja el número es tener las cuatro cosas hechas y alguien que pueda ejecutarlas fuera de tu horario. Por separado no sirve ninguna de las dos mitades, y quien te venda solo una te está vendiendo media solución. El mantenimiento informático serio consiste, casi entero, en tener esa lista lista antes de que haga falta.

Cuándo esto no va contigo

Si tu empresa son quince personas con quince portátiles, correo en la nube, ningún servicio publicado a internet y ninguna aplicación propia, esto no va contigo y montar un programa de parcheo te costará más de lo que te ahorra. Activa las actualizaciones automáticas, ten un sistema operativo con soporte y vete a casa. Lo decimos sabiendo que nos vende menos, porque la alternativa es cobrarte por un miedo que no te corresponde.

Si en cambio tienes cualquier cosa publicada —un portal de acceso remoto, un ERP, una aplicación que da servicio a tus clientes— el orden importa y no es negociable: primero el inventario. Sin saber qué corre y en qué versión, todo lo demás es teatro, incluidas las herramientas caras. Es un mes de trabajo aburrido que casi nadie quiere pagar y es, con diferencia, el euro mejor gastado de la lista.

Antes de que nos cites

No hemos usado Astra ni hemos reproducido ninguna de sus cifras. El 100%, el 42,4% y las dos vulnerabilidades encontradas son datos que publica OpenAI sobre sí misma, y el banco de pruebas también es suyo. Tampoco decimos que haya atacantes usándolo: no tenemos ninguna evidencia de eso, el modelo tiene días de vida y la versión desplegada se niega a generar pruebas de concepto. Ni sabemos si esa capacidad de descubrimiento se traducirá en más explotación real, ni cuándo. Quien diga que lo sabe está prediciendo, y esto es un blog de infraestructura, no de futurología.

Y una sobre la fecha, porque nos la hemos encontrado y preferimos contarla: hay medios que sitúan el despliegue a un grupo limitado de organizaciones el 3 de septiembre y otros el lanzamiento el 4, y el reparto está prácticamente igualado —con la particularidad de que varias de las cabeceras que dan el 4 publican el mismo artículo sindicado—. Usamos el 4 porque es la fecha del anuncio de disponibilidad general, y lo dejamos escrito en vez de elegir en silencio.

Queda la pregunta que sí puedes contestar hoy, sin esperar a ningún modelo: cuántos días pasan en tu empresa entre que existe un arreglo y está puesto. Si no tienes ese número, ese es el trabajo de esta semana. Si lo tienes y es alto, ya sabes contra qué estás compitiendo. Una parte te llegará antes de que exista el parche, y contra eso juega la detección, no el parcheo. Pero la mayoría de lo que te va a entrar lleva semanas publicado y con arreglo disponible.

Nota de fuentes

El nivel «Crítico» de capacidad en ciberseguridad de GPT-6 Astra, su definición en el marco de preparación de OpenAI, las puntuaciones de ExploitBench (100% frente a 78,5% de GPT-5.6 Sol) y de ExploitGym (42,4% frente a 30,3%), la prueba contra fallos divulgados en los tres meses anteriores al lanzamiento, las dos vulnerabilidades desconocidas halladas y la restricción de la versión desplegada a revisión y corrección segura de código —con negativa a generar pruebas de concepto— salen de la cobertura del anuncio de OpenAI en CSO Online, InfoWorld, Computerworld y The Hacker News, publicada entre el 4 y el 8 de septiembre de 2026; la página oficial openai.com/index/path-to-astra no nos ha respondido al intentar consultarla. Que el 100% se midiera sin salvaguardas de producción y que el acceso venga apagado por defecto son datos de esa misma cobertura; el subrayado de que titular y producto son configuraciones distintas es nuestro. El programa Daybreak para defensores verificados y la cita de Sanchit Vir Gogia «Astra behaves better and watches worse» son de CSO Online. El tiempo medio hasta la explotación de aproximadamente menos siete días, los 63 días de 2018 y el cruce del cero en 2024 son de M-Trends 2026 de Mandiant. La mediana de 43 días para remediar por completo una vulnerabilidad del catálogo KEV —frente a 32 el año anterior—, el 26% remediado —frente al 38%— y la subida de la mediana de vulnerabilidades del KEV por organización de 11 a 16 son del DBIR 2026 de Verizon. De M-Trends 2026 y del DBIR 2026 hemos leído la cobertura y los resúmenes publicados, no los informes completos, y los citamos como tales. Los tamaños de las tandas del catálogo KEV (3 el 11 de agosto, 4 el 18, 6 el 26, 2 el 31 y 7 el 2 de septiembre de 2026) salen de los avisos que CISA publicó en esas fechas, comprobados uno a uno; no pretenden ser el total del periodo, que incluye más publicaciones, sino el orden de magnitud de cada tanda. Los cinco motivos de la sección sobre los 43 días son observación propia de operar infraestructura de clientes, no un estudio, y así los damos.