El 18 de agosto, OpenAI hizo pública una decisión que llevaba tiempo gestionándose internamente: la evaluación de las capacidades de ciberseguridad de Astra, su modelo de próxima generación, no logró concluir que fuera "seguro", por lo que la empresa detuvo de inmediato el entrenamiento por aprendizaje por refuerzo (RL) del modelo más reciente en producción, durante dos semanas. Hasta el momento de la publicación, la mayor tanda de RL de frontera seguía sin reanudarse; solo continuaban con normalidad los entrenamientos y evaluaciones de menor escala.
La noticia salió a la luz por primera vez el 7 de agosto, cuando lo que se conocía externamente era la versión de que "OpenAI retrasa el lanzamiento de Astra". El artículo del 18 de agosto expone la cadena de razonamiento detrás de ese retraso: las evaluaciones internas mostraron que el avance de Astra en programación autónoma y en ataque/defensa cibernética era tal que la empresa no podía descartar que el modelo ya hubiera alcanzado el nivel Critical.
Un umbral más concreto de lo que parece
El Preparedness Framework de OpenAI concreta el umbral Critical de ciberseguridad en dos descripciones de capacidad verificables: que el modelo pueda escribir de forma autónoma exploits de día cero utilizables contra múltiples sistemas críticos reales ya reforzados; o que, con solo un objetivo de alto nivel, el modelo pueda diseñar y ejecutar por sí solo un ataque novedoso de principio a fin contra un objetivo reforzado.
La conclusión de la evaluación interna se quedó en "no se puede descartar", sin confirmar que se hubiera alcanzado el umbral. Pero, a juzgar por las medidas posteriores de la empresa, ese nivel ya bastó para activar una ronda de desaceleración preventiva: sin esperar confirmación, se detuvieron primero los entrenamientos que más capacidad de cómputo consumen y que con más probabilidad seguirían elevando esa capacidad.
Lo que se detiene es el entrenamiento, lo que cambia es el centro de datos
La pausa es solo la mitad de la historia. OpenAI enumeró además una serie de cambios a nivel de infraestructura: aislamiento de sandbox y segmentación de red más estrictos, eliminación de servicios compartidos fáciles de vulnerar, reducción de permisos de larga duración y finalización de los registros de seguridad. Buena parte de las cargas de trabajo de Astra sigue detenida a día de hoy, a la espera de migrar a entornos que cumplan los nuevos requisitos.
El área de supervisión es la que aporta las cifras más directas. El nuevo sistema de monitoreo consta de dos partes: un clasificador de activaciones que opera a nivel de token y marca comportamientos sospechosos durante la generación, y un investigador automatizado que revisa lo marcado. Esta supervisión consume alrededor del 20% de la capacidad de cómputo de inferencia. La ventana de respuesta objetivo para las alertas es de menos de 30 minutos, y el equipo de seguridad dispone también de 30 minutos para descartar falsos positivos.
El 20% sobre el papel parece un parámetro de ingeniería, pero traducido a costes es otra cosa. El gasto anual en cómputo de inferencia de los laboratorios de frontera suele situarse en el orden de miles de millones de dólares (estimación aproximada, cada empresa calcula de forma distinta), y destinar de forma permanente una quinta parte a la supervisión equivale a un coste fijo de miles de millones de dólares, dinero que no genera ninguna capacidad orientada al usuario. La disposición a asumir ese gasto a largo plazo sugiere que la empresa no espera que la ventana de riesgo se cierre en unas semanas, sino que cubra todo el ciclo de vida del modelo de próxima generación.
Otra vía comparable sería priorizar entregar la capacidad de ataque/defensa al lado defensor, abriendo modelos de búsqueda de vulnerabilidades a una lista restringida y cambiando una superficie de despliegue controlada por tiempo de margen. Esta vez OpenAI ha optado por una vía más aguas arriba, frenando directamente en el propio entrenamiento. Ambas vías responden al mismo diagnóstico: la capacidad de ataque de los modelos crece más rápido que el ritmo de parcheo del lado defensivo.
Una barrera que la empresa se impone a sí misma
En este proceso no hay lugar para la supervisión externa. Las condiciones que lo activan, los criterios de evaluación, la duración de la pausa y los estándares para reanudar: todo lo escribe, lo juzga y lo ejecuta la propia OpenAI, y hacia fuera solo queda un comunicado posterior a los hechos. El artículo no ofrece cifras verificables por terceros sobre cómo se mide en concreto el umbral Critical ni qué puntuación obtuvo Astra en cada prueba. La empresa también aclaró un punto: el incidente del sandbox de Hugging Face, que generó debate anteriormente, no está relacionado con Astra.
Para los desarrolladores que siguen de cerca el progreso, el impacto a corto plazo se concentra en dos puntos: los hitos de lanzamiento de las capacidades relacionadas con Astra se retrasarán, y las cargas de trabajo de Astra ya en marcha tendrán que migrar de entorno en consecuencia, a un ritmo controlado unilateralmente por OpenAI. Sobre cuándo se reanudará la mayor tanda de RL de frontera, la empresa no ha dado ninguna indicación.
Fuentes: blog oficial de OpenAI, Axios, CocoLoop, AIGC News; la definición del umbral Critical en el Preparedness Framework, la proporción del 20% de cómputo dedicado a supervisión y la ventana de alerta de 30 minutos se han verificado con las declaraciones públicas de OpenAI.