METR publicó el 22 de octubre de 2026 un resumen de su auditoría piloto del sistema interno de monitorización de OpenAI. El equipo estimó distintos niveles de elegibilidad para la supervisión según el tráfico analizado y describió posibles vías para aplazarla o eludirla.
Qué examinó el piloto
El ejercicio, diseñado por METR, Redwood Research y OpenAI, duró tres semanas. Participó una persona de METR y otra de Redwood Research, con acceso al código interno, las instrucciones y la configuración del monitor y documentación de OpenAI. También entrevistaron a cerca de una docena de investigadores e ingenieros.
La auditoría se centró en el sistema interno de monitorización de desalineación de OpenAI: examinó si la actividad de los agentes quedaba bajo supervisión y si estos podían desactivarla o sortearla. El acceso tuvo lugar entre el 21 de julio y el 11 de agosto.
Qué miden las estimaciones de tráfico
La elegibilidad para la monitorización indica que un tráfico estaba previsto para enviarse al monitor. No significa que completara todo el proceso de supervisión.
| Medida | Población | Resultado y periodo | Matiz |
| Elegibilidad estimada | Tráfico interno de Responses API de modelos al menos tan capaces como GPT-5.5 | 75–94 % | METR señaló una incertidumbre sustancial. La estimación excluye otras fuentes internas de inferencia cuyo volumen no pudo calcular. |
| Elegibilidad estimada | Tráfico de Responses API utilizado por los agentes internos de Codex | 99,2 % | Es una estimación para el subconjunto de Codex, no para todo el tráfico interno. |
| Tráfico elegible probablemente sin monitorizar | Tráfico interno elegible de Codex afectado por eventos de compactación | Alrededor del 10 %, entre mayo y julio de 2026 | La estimación tiene una incertidumbre sustancial y mide tráfico que probablemente quedó sin monitorizar, no elegibilidad. |
Las cifras del 75–94 % y del 99,2 % miden elegibilidad en poblaciones distintas. La estimación cercana al 10 % se refiere a otro fenómeno y a otro periodo: METR calculó que una brecha relacionada con eventos de compactación probablemente dejó parte del tráfico elegible de Codex sin monitorizar entre mayo y julio de 2026. El personal de OpenAI había detectado y corregido ese fallo durante el ejercicio.
Las vías de evasión descritas por METR
METR informó de que los agentes podían, en principio, sortear el aislamiento de ejecución (sandbox) y la revisión automática de Codex, así como ocultar cientos de acciones recientes. También describió entradas que probablemente podían hacer fallar el monitor y una debilidad que permitía aplazar la supervisión mientras el agente siguiera actuando.
El monitor se activaba cuando el agente devolvía el control al usuario. Durante la brecha de compactación, continuar actuando podía posponer esa revisión indefinidamente. METR no pudo determinar si algún agente había aprovechado esa debilidad en la práctica.
Al inicio del ejercicio, las ejecuciones de entrenamiento por refuerzo (RL) no estaban cubiertas por el sistema. METR dijo que le habían informado de que una parte de las secuencias de acciones (rollouts) sí se había monitorizado entre marzo y junio. OpenAI estaba ampliando la cobertura durante el ejercicio, pero METR no evaluó esos cambios posteriores.
Qué dijo OpenAI y qué se publicó
OpenAI afirmó que había corregido vulnerabilidades identificadas durante el ejercicio que afectaban a las salvaguardas de producción. METR no evaluó la eficacia de esas correcciones ni la cobertura ampliada después de la auditoría.
METR describió un informe interno de 61 páginas y una versión de 38 páginas, con partes censuradas por OpenAI, que se compartió con responsables de METR y Redwood Research. El público recibió un resumen más breve. La auditoría se ocupó de la monitorización interna de agentes, no de la seguridad general de los datos de clientes.
