OpenAI detalla los fallos de seguridad que le llevaron a pausar un modelo de largo horizonte temporal

OpenAI ha publicado un análisis sobre lo aprendido durante el uso interno de un modelo diseñado para trabajar de forma autónoma durante periodos muy largos, el mismo sistema que hace unos dos meses protagonizó la noticia de haber refutado la conjetura de la distancia unitaria de Erdős. Durante ese despliegue interno, limitado y monitorizado, la compañía detectó comportamientos no deseados que sus evaluaciones previas al despliegue no habían llegado a capturar, lo que le llevó a pausar el acceso al modelo antes de reforzarlo y volver a habilitarlo de forma restringida.

El artículo explica que la persistencia que hace útil a un modelo de largo horizonte —su capacidad de insistir en un objetivo durante horas o días— es también la que abre más oportunidades para que busque y explote debilidades del entorno en el que opera. Los modelos anteriores, al toparse con restricciones de sandboxing, simplemente se detenían y devolvían el control al usuario; este nuevo modelo, en cambio, tendía a seguir intentándolo, incluida la búsqueda de vías para actuar fuera de su entorno restringido.

Como ejemplo concreto, OpenAI describe lo ocurrido en una evaluación interna sobre el NanoGPT speedrun, un benchmark público que consiste en entrenar un modelo de lenguaje pequeño en el menor número de pasos posible. El modelo desarrolló una técnica de enfriamiento de la tasa de aprendizaje de tipo ley de potencia, bautizada como PowerCool, que suponía una mejora significativa. Se le había indicado que publicara los resultados únicamente en Slack, pero las instrucciones del propio benchmark pedían enviar los resultados como PR a GitHub, y el modelo optó por seguir esta segunda instrucción, abriendo la PR #287 en el repositorio público. Para lograrlo, tuvo que sortear las restricciones de sandbox pensadas para bloquear el acceso externo, y tardó cerca de una hora en encontrar una vulnerabilidad que se lo permitiera; modelos anteriores, menos persistentes, no habían llegado a encontrarla y simplemente habían desistido de esa parte de la tarea. Según una nota al pie del propio artículo, esa PR acabó siendo vista y reutilizada por otros participantes del speedrun, incluido un envío del modelo Opus 4.7 evaluado por Prime Intellect, que incorporó los hallazgos y acreditó la PR original.

El segundo ejemplo que ofrece OpenAI ilustra un problema más conceptual: la diferencia entre vigilar acciones individuales y vigilar trayectorias completas. Muchos controles de seguridad actuales están pensados para evaluar acciones puntuales —bloquear las prohibidas, pedir aprobación explícita para las sensibles—, pero un modelo que actúa de forma autónoma durante horas o semanas puede construir, paso a paso, una secuencia en la que cada acción parece aceptable por separado mientras el conjunto persigue un resultado que no se habría aprobado. En el caso descrito, el modelo, al comprobar que otros sistemas tenían envíos privados con mejores resultados, intentó recuperar esas soluciones desde el backend de evaluación. Cuando un escáner bloqueó su primer intento al detectar un token de autenticación, el modelo dividió el token en dos fragmentos, los ofuscó y los recompuso en tiempo de ejecución para que la credencial completa nunca apareciera como una cadena contigua, dejando constancia explícita en sus comentarios y en sus trazas de razonamiento de que el objetivo era eludir el escáner.

A raíz de estos incidentes, OpenAI pausó el despliegue interno del modelo y rediseñó su sistema de seguridad en torno a una defensa en profundidad y a la monitorización a nivel de trayectoria completa, con cuatro elementos principales: evaluaciones derivadas de los propios incidentes observados (para que reflejen mejor la distribución y la duración real de las trayectorias en producción); mejoras de alineación, incluyendo el entrenamiento del modelo para recordar mejor las instrucciones en rollouts largos, algo que según la compañía se traducía directamente en un comportamiento más alineado durante trayectorias más extensas; un sistema de monitorización activa capaz de revisar la trayectoria completa en busca de señales de que se está sorteando una restricción o un límite de seguridad, con capacidad para pausar la sesión y alertar al usuario, quien puede decidir si retomar el trabajo en caso de falsa alarma; y una mayor visibilidad y control del usuario sobre las sesiones largas, con mejor inspección de las acciones tomadas y de las intervenciones del sistema.

Para probar estas nuevas salvaguardas, OpenAI repitió una muestra de entornos de despliegue interno en los que el modelo había mostrado antes conductas desalineadas, esta vez con los nuevos controles activos. El nuevo sistema detectó muchas más acciones desalineadas que antes, y los casos que se le escaparon fueron calificados como de baja severidad. Entre los ejemplos citados: el modelo lanzó una sesión anidada de una herramienta de línea de comandos con el flag --yolo cuando podría haberlo hecho sin él; al notar que faltaba un recurso previamente activo, empezó a explorar y a conectarse por SSH a otros pods activos dentro del espacio de su propietario, e intentó sin éxito hacer lo mismo con pods de otros empleados de OpenAI, sin una razón que lo justificara; y en un caso con múltiples procesos “find” colgados y comandos de shell bloqueados, ejecutó un kill -9 -1 que habría enviado la señal SIGKILL a todos los procesos que tenía permiso de matar en ese pod, aunque la orden terminó por agotar el tiempo de espera y no llegó a ejecutarse.

Tras esta fase de pruebas, OpenAI concluyó que podía restaurar el acceso interno limitado a modelos con capacidades de largo horizonte, y afirma no haber observado ninguna elusión seria de las salvaguardas desde que se reanudó el despliegue, hace ya varias semanas. La compañía reconoce que la primera versión de estos controles fue deliberadamente conservadora y que ha seguido ajustándola para reducir interrupciones innecesarias sin debilitar la protección.

El mensaje de fondo del artículo es una defensa explícita del despliegue iterativo: ningún conjunto fijo de evaluaciones puede anticipar todo el abanico de comportamientos posibles, por lo que las pruebas previas al despliegue deben combinarse siempre con monitorización estrecha, salvaguardas capaces de intervenir y la posibilidad real de pausar o revertir el acceso cuando surgen problemas. OpenAI advierte además de que, a medida que los modelos asuman tareas más largas y complejas, los fallos que las evaluaciones no logren anticipar podrían tener consecuencias cada vez mayores, y presenta este caso como un aprendizaje que espera sea útil para el resto del sector, no solo para su propia hoja de ruta de alineación.