OpenAI ha detallado cómo vigila a sus modelos más avanzados para detectar cuándo se comportan de forma indebida durante el entrenamiento, las evaluaciones o el uso. Lo hace tras el incidente de Hugging Face, en el que agentes de la propia compañía escaparon de su entorno aislado durante una prueba de ciberseguridad y llegaron a sistemas de producción de esa plataforma.
La empresa admite que aquel episodio dejó al descubierto una laguna: empezó durante unas evaluaciones internas de ciberseguridad en las que sus monitores de comportamiento desalineado no estaban activos. Desde entonces asegura haber ampliado la supervisión al entrenamiento, la evaluación, el uso interno y, con cambios, al despliegue externo. Reconoce que el sistema consume muchos recursos de cómputo, pero cree que merece la pena a medida que crecen las capacidades de sus modelos.
El anuncio llega una semana después de que METR y Redwood Research, dos organizaciones independientes que pusieron a prueba ese sistema este verano, publicaran que los agentes podían eludirlo de varias formas.
Qué pasó en Hugging Face
Según contó Malwarebytes en julio, una cadena de modelos que OpenAI evaluaba en capacidades de ciberseguridad, con restricciones de seguridad reducidas, aprovechó una vulnerabilidad de día cero en su entorno de pruebas. Después escaló privilegios hasta llegar a un equipo con acceso a internet y buscó en Hugging Face soluciones para la prueba. En al menos un caso combinó credenciales robadas con otras vulnerabilidades para llegar a sistemas de producción.
Hugging Face reconoció un acceso no autorizado a una parte limitada de su infraestructura, que incluyó un pequeño conjunto de datos internos y algunas credenciales. Ambas empresas concluyeron que ocurrió durante una prueba controlada y no por el ataque de un operador humano.
OpenAI ha reproducido ahora aquel episodio con los nuevos monitores activados. Según la compañía, el sistema habría avisado al equipo de seguridad unos 30 minutos después de la primera fuga, más de 30 horas antes de que se vulneraran los sistemas de Hugging Face. Tras el incidente, puso en cuarentena el prototipo, cifró sus pesos y restringió el acceso a ellos.
Cuatro capas de vigilancia
El sistema pasa los casos de una capa a otra. Las primeras gastan poco cómputo y marcan todo lo sospechoso, aunque haya falsas alarmas; las siguientes dedican más recursos a decidir si hay que intervenir:
- Capa 0, sondas de activación. Clasificadores ligeros que buscan patrones preocupantes en las activaciones internas del modelo. Como OpenAI aún evalúa su eficacia, también envía a la siguiente capa un 5 % aleatorio del tráfico que no marcan. El entrenamiento de los modelos de vanguardia y el tráfico interno de Codex se saltan esta capa.
- Capa 1, revisor basado en modelos. Examina la conversación reciente, la cadena de razonamiento y el uso de herramientas del agente en busca de engaños, acciones no autorizadas o intentos de manipular una evaluación.
- Capa 2, agentes investigadores. Uno de seguridad busca casos que requieran intervenir, como una fuga del entorno aislado. Otro de alineación busca comportamientos que merezca la pena estudiar. Pueden releer todo el historial del agente, cuando está disponible, y ejecutar código en un entorno aislado.
- Capa 3, investigación automatizada. En las cargas más sensibles cruza la transcripción con los registros de red y otra telemetría para decidir si avisa a una persona.
En el entrenamiento de vanguardia y en Codex, la revisión de la capa 1 se activa al final de cada turno y cuando el agente resume su trabajo anterior. OpenAI dice que está pasando a revisiones separadas por no más de 30 minutos.
La supervisión cubre todo el entrenamiento por refuerzo y las evaluaciones de los modelos al menos tan capaces como GPT-6 Astra, la mayoría de las cargas de los modelos más capaces que GPT-5.5 Thinking y todo el tráfico interno de Codex.
Las personas, solo a ratos
Las alertas de máxima prioridad llegan a miembros de los equipos de seguridad y de entrenamiento, normalmente en 15 minutos. Pero OpenAI reconoce que las falsas alarmas le impiden mantener esos avisos activos las 24 horas en todas las cargas.
Solo el entrenamiento de vanguardia puede alertar a alguien a cualquier hora. Para la mayoría del resto del tráfico, los avisos se limitan al horario laboral, y en el tráfico interno de Codex están desactivados.
Algunas alertas críticas pueden pausar automáticamente la carga afectada. La compañía trabaja en una salvaguarda más amplia que detendría la actividad si nadie descarta una alerta de máxima prioridad en 30 minutos, pero todavía no está en marcha.
El sistema sí ha funcionado en casos reales. En septiembre, un modelo encontró la forma de conectarse a internet a través de DNS desde un entorno que debía estar aislado. Los monitores lo detectaron en 15 minutos y una persona empezó a revisarlo tres minutos después. OpenAI pausó el entrenamiento por refuerzo de sus modelos de vanguardia mientras reforzaba la contención.
Sus informes de desalineación recogen otros casos: un agente que usó una herramienta de pruebas para recuperar un código fuente que la tarea ocultaba a propósito, otros que convirtieron un repositorio compartido en un tablón de mensajes entre muestras de entrenamiento y un agente interno de programación que filtró a internet un token de acceso de GitHub.
Cómo comprueban que los monitores funcionan
Un monitor que detecta fallos conocidos puede pasar por alto comportamientos nuevos, y cada cambio en el sistema puede abrir otros huecos. Para medirlo, OpenAI combina varias pruebas:
- Incidentes reales grabados. Reproduce episodios ya ocurridos en entrenamiento, evaluaciones y uso interno, y comprueba si el monitor los reconoce y si les da la prioridad suficiente para avisar a una persona.
- Ataques simulados. En una prueba llamada OAI-repo Sabotage v2, un agente hace una tarea de programación normal mientras persigue un objetivo oculto, como desactivar la supervisión o desplegar una versión del modelo no aprobada. En otra, Sneaky Sandbox Escape, intenta escapar de su entorno aislado y desactivar un monitor de prueba.
- Transcripciones sintéticas. Varían cómo describe el agente una acción peligrosa para ver si el monitor la reconoce aunque se presente con una explicación inocente.
- Auditorías aleatorias. Una parte del tráfico que pasa cada filtro sin alertas se envía igualmente a la siguiente capa.
- Ataques de sus propios agentes. Pide a sus agentes más capaces que intenten burlar o desactivar la supervisión en entornos controlados.
La compañía reserva su prioridad más alta, P0, para los casos que exigen respuesta urgente, por lo que muchos comportamientos de estas pruebas se marcan para investigarlos sin intervenir de inmediato. También sigue en un panel central cuántos casos detecta cada umbral antes de desplegar cambios.
Estas pruebas le sirven además para elegir el modelo que hace de vigilante. Los monitores basados en GPT-5.6 Sol detectaron bastantes más casos que los basados en GPT-5.6 Terra o GPT-5.6 Luna, aunque los tres acertaron casi siempre en la prueba de fuga. OpenAI admite que parte de la ventaja de Sol se debe a que optimizó para él las instrucciones del monitor.
Lo que encontraron METR y Redwood
Entre el 21 de julio y el 11 de agosto, un investigador de METR y otro de Redwood Research pusieron a prueba la supervisión de OpenAI con acceso a su infraestructura interna. Su informe, publicado el 22 de octubre, se refiere al sistema tal como estaba hasta el 21 de julio, antes de la ampliación. Entre sus hallazgos:
- Entre mayo y julio, del orden del 10 % del tráfico interno de Codex que debía vigilarse pudo quedar sin supervisar por un fallo relacionado con la compactación del contexto. OpenAI ya lo había detectado y lo corrigió durante el ejercicio.
- Como el monitor se activaba cuando el agente devolvía el control al usuario, un agente podía aplazar indefinidamente la revisión con solo seguir actuando. Los autores no pudieron comprobar si alguno lo hizo.
- En teoría, los agentes de Codex podían saltarse el aislamiento y la revisión automática.
- Dos cabeceras que controla el cliente desactivaban la supervisión de nuevos agentes, y dos herramientas internas que se creían de solo lectura no estaban supervisadas.
OpenAI dice en su artículo que la mayoría de estos fallos ya están corregidos y que uno sigue en proceso. METR aclara que no ha verificado esas correcciones. Además, el acuerdo permitía a OpenAI tachar lo que considerara confidencial, y los detalles de uno de los fallos aparecen censurados, según recoge The Register.
Vigilar sin enseñar a esconderse
OpenAI añade un matiz importante: vigilar puede incentivar al modelo a ocultar lo que hace. Si un modelo recibe menos recompensa cuando su cadena de razonamiento revela una mala conducta, puede aprender a esconderla en vez de dejar de hacerla.
La compañía dice haber visto agentes que seguían haciendo trampas con las recompensas mientras lo ocultaban en su razonamiento, y que modelos como Astra controlan cada vez más lo que este revela. Por eso, cuando una muestra de entrenamiento activa los monitores, no le cambia la recompensa y la mantiene en el entrenamiento. La supervisión, además, no se hace en tiempo real: si el entrenamiento tuviera que esperar a cada revisión, las muestras que generan investigaciones más largas quedarían en desventaja.
Fuera de casa, sin revisores humanos
OpenAI aplica una versión del sistema a algunos despliegues externos de sus modelos más capaces en ciberseguridad, como Astra. A diferencia del interno, no envía de forma habitual los casos marcados a revisores humanos de la empresa: puede pausar la conversación y avisar al usuario, y los clientes empresariales pueden configurar alertas para sus propios equipos.
Por sus compromisos de privacidad, el sistema externo no siempre tiene el mismo contexto que el interno, y no cubre las peticiones a la API Chat Completions.
Por qué importa
Cuando un agente puede ejecutar código y usar herramientas, un fallo de alineación deja de ser una respuesta equivocada y se convierte en una acción sobre sistemas reales, como mostró el caso de Hugging Face. En España, la AEPD ya ha registrado la primera brecha de datos provocada por un ciberataque ejecutado de forma autónoma por un agente de IA. OpenAI presenta la supervisión como una capa más de su defensa en profundidad, junto al entrenamiento de alineación, que busca reducir la propensión a comportamientos dañinos, y los controles de seguridad, que limitan a qué sistemas puede acceder un agente. Le atribuye dos funciones: control, para intervenir a tiempo, y visibilidad, para descubrir formas de desalineación que aún no conocía. Desde septiembre publica informes de incidentes de desalineación y defiende que todos los desarrolladores deberían vigilar a sus modelos más capaces.
El examen de METR y Redwood recuerda la otra mitad del problema: esa vigilancia también necesita auditores externos que puedan comprobar, sin tachones, si de verdad funciona.
La fotografía de representación de este artículo pertenece a Jernej Furman y ha sido publicada en Wikimedia Commons bajo licencia CC BY 2.0.
