Hoy OpenAI publicó un post que debiera hacer ruido en más de una oficina. No es un anuncio de producto, es una confesión: tuvieron que pausar el acceso interno a uno de sus modelos más capaces porque el bicho encontró, una y otra vez, la forma de actuar fuera de su sandbox.
Contexto rápido: hace un par de meses OpenAI anunció que un modelo interno había refutado la conjetura de distancia unitaria de Erdős, un problema abierto en geometría discreta. Impresionante. Lo que no contaron ese día es lo que pasó después, cuando dejaron el modelo trabajando en tareas largas, de esas que toman horas o días sin supervisión.
La anécdota que lo dice todo
El ejemplo que dan es cuático. Estaban evaluando el modelo en el NanoGPT speedrun, un benchmark público donde la gracia es entrenar un modelo chico en la menor cantidad de pasos posible. El modelo de OpenAI inventó una técnica de enfriamiento de learning rate que llamó PowerCool y mejoró los resultados significativamente. Hasta ahí, bacán.
El problema: le dijeron explícitamente que publicara sus resultados solo en Slack. Las instrucciones del benchmark decían que los resultados se suben como pull request a GitHub. El modelo decidió que la instrucción del repo pesaba más, encontró una vulnerabilidad en el sandbox que bloqueaba el acceso externo, y abrió el PR #287 en el repositorio público. Le tomó una hora romper la jaula. Los modelos anteriores simplemente se rendían y no hacían el PR.
Léanlo de nuevo: la misma persistencia que lo hace bueno resolviendo matemáticas lo hace bueno encontrando exploits en su propio entorno de contención.
Mi opinión, sin anestesia
Yo trabajo con estas herramientas todos los días y les tengo harto cariño, pero hay algo que me parece deshonesto en cómo se discute esto públicamente. La industria lleva años vendiendo la idea de que la seguridad se resuelve con evaluaciones pre-deployment: un checklist, un red team, un par de benchmarks, y listo, a producción. Este post de OpenAI admite, en su propio lenguaje corporativo cuidadoso, que eso no alcanza. Ninguna suite fija de evaluaciones anticipa lo que hace un modelo que puede intentar mil veces distintas durante una semana.
Y aquí viene lo que me preocupa de verdad: si esto es lo que le pasa a OpenAI, con sus equipos de alineación, sus monitores de trayectorias y sus recursos infinitos, ¿qué le pasa a la pyme chilena que está enchufando un agente con acceso a su ERP porque un consultor le dijo que era el futuro? Nosotros no tenemos monitoreo de trayectorias. Tenemos un script, un API key en un .env y buenas intenciones.
La lección práctica
Si estás desplegando agentes que corren por horas sin que nadie los mire, tres cosas mínimas: primero, asume que el sandbox va a fallar y diseña el resto del sistema para que eso no sea catastrófico (red segmentada, credenciales de alcance mínimo, cero acceso a internet salvo que sea estrictamente necesario). Segundo, no mires acciones individuales, mira la trayectoria completa: un modelo puede hacer diez cosas permitidas que juntas son una cosa prohibida. Tercero, ten un kill switch que de verdad funcione, no un botón en una dashboard que nadie ve los domingos.
El modelo de OpenAI terminó de vuelta en operación, con nuevas evaluaciones y más monitoreo. Bien por ellos. Pero el mensaje real del post es otro: los modelos que vienen no se quedan quietos donde los pones. Y la mayoría de las empresas que los está adoptando todavía cree que sí. Ahí hay una brecha, y no es técnica, es de criterio.
Fuente de inspiración: Safety and alignment in an era of long-horizon models | OpenAI
