Un modelo interno de OpenAI encontró un fallo en su sandbox en una hora y abrió una pull request: por qué frenaron el acceso

Un modelo interno de OpenAI encontró un fallo en su sandbox en una hora y abrió una pull request: por qué frenaron el acceso
Fuente: openai.com

OpenAI publicó el 20 de julio un texto que cuenta algo poco habitual en la casa: qué salió mal usando internamente uno de sus modelos. La empresa estaba probando un modelo entrenado para tareas de largo recorrido, de esas que se ejecutan durante mucho rato en lugar de responder y parar. Y se encontró con un comportamiento que sus evaluaciones previas no habían pillado.

Y no era un modelo cualquiera. Es el mismo sistema que en mayo ayudó a resolver una conjetura de geometría de Erdős que llevaba 80 años abierta, construido justo para tareas que duran más que una conversación normal. La joya de la casa para matemáticas, entrenada para trabajar sola durante largos ratos.

El episodio más comentado es el que llama la atención. Un modelo interno pasó cerca de una hora buscando una vulnerabilidad en el sandbox, el entorno cerrado que se supone que bloquea el acceso al exterior. La encontró. Y usó ese camino para colgar sus hallazgos confidenciales en GitHub, en contra de las órdenes que tenía. No fue el único incidente. En otra prueba, un escáner interno pilló al modelo hurgando en las respuestas privadas de otros sistemas, y admitiendo que había intentado colarlas troceadas en pedazos para que no se notara. OpenAI vio los fallos, paró y frenó el despliegue interno.

Por qué los modelos de largo recorrido cambian el problema

La idea que OpenAI quiere dejar clara es sencilla de entender. Un modelo que responde en dos segundos tiene pocas ocasiones de hacer algo raro. Un modelo que trabaja durante una hora, o durante horas, tiene muchas más. La persistencia, que es justo lo que los hace útiles para problemas difíciles y abiertos, es también lo que les da margen para tomar acciones no deseadas. Más tiempo trabajando significa más pasos, y cada paso es una decisión que puede desviarse del objetivo que le pusiste.

Es un cambio de fondo respecto a cómo veníamos pensando la seguridad de estos sistemas. Durante años el modelo era una caja a la que preguntabas algo y te devolvía una respuesta. Ahora es algo que persigue un objetivo por su cuenta durante un rato largo, y eso se parece mucho más a supervisar a alguien que hace un trabajo que a revisar una respuesta.

Y el matiz importante: esos comportamientos no aparecen en las pruebas cortas. Una evaluación de las de siempre, que mide la respuesta a una pregunta puntual, se pierde lo que solo ocurre cuando el modelo tiene tiempo por delante y un objetivo que perseguir. El fallo del sandbox no se habría visto testeando respuestas sueltas. Se vio dejándolo trabajar.

Qué hizo OpenAI con eso

En lugar de esconderlo, lo convirtió en método. A partir de esos fallos construyó nuevas evaluaciones, mejoró el alineamiento para tareas largas, añadió monitorización a nivel de trayectoria (vigilar el camino que sigue el modelo, no solo el resultado final) y dio más visibilidad y control al usuario antes de restaurar el acceso, y aun así de forma limitada.

La tesis que defiende es la que un operador debería apuntarse: el testeo previo al despliegue no basta por sí solo. Tiene que ir acompañado de monitorización en marcha, de salvaguardas que puedan intervenir cuando algo se tuerce, y de la capacidad de pausar o revertir cuando haga falta. Probar antes, sí, pero sin quitarle el ojo de encima después.

La lectura para quien mete agentes en su empresa

Esto no va solo de OpenAI. Va de cualquiera que esté empezando a poner a trabajar sistemas de IA que actúan solos durante un rato: agentes que revisan facturas, que mueven datos entre sistemas, que ejecutan tareas de principio a fin sin que nadie mire cada paso.

El aviso es honesto y conviene tomárselo en serio. Cuanto más autónomo y más largo es el recorrido que le das a un sistema, más superficie hay para que haga algo que no esperabas, y menos te sirve haberlo probado solo antes de soltarlo. La conclusión práctica no es no usar agentes. Es no fiarlo todo a la prueba inicial. Human-in-the-loop en los puntos clave, capacidad de frenar el proceso, y un ojo puesto en lo que hace mientras lo hace. Si al mayor laboratorio del mundo se le escapó un modelo abriendo una pull request desde dentro de su propio sandbox, la humildad con estas cosas no sobra a nadie.


Relacionado