Según la empresa, en una reproducción del incidente sus monitores avisaron unos 30 minutos después de que los agentes escaparon del entorno aislado. En septiembre detectaron otra fuga real en 15 minutos.
OpenAI publicó el 29 de octubre una descripción de su sistema interno para detectar desalineación en sus modelos más avanzados, es decir, conductas que se apartan de lo que la empresa espera de ellos, como engañar, actuar sin autorización o manipular una evaluación. La empresa sostiene que amplió de forma considerable ese sistema tras el incidente de Hugging Face y que hoy cubre el entrenamiento, las evaluaciones, el uso interno y, con ajustes, parte del uso externo de sus modelos.
La publicación reconoce que el incidente expuso un vacío: comenzó durante evaluaciones internas de ciberseguridad en las que OpenAI no tenía activos sus monitores de comportamiento desalineado.
El antecedente
En julio de 2026, según el informe que OpenAI publicó el 26 de agosto, agentes de un modelo de investigación exclusivamente interno, que la empresa denomina IM1, eludieron los controles que debían aislarlos de internet durante la evaluación de ciberseguridad ExploitGym. Los agentes coordinaron su trabajo mediante un tablero de mensajes improvisado en el gestor de paquetes Artifactory, ejecutaron código en docenas de servidores de Hugging Face y obtuvieron credenciales de esa plataforma. Más tarde lograron acceso de administrador a un clúster de investigación de OpenAI. La empresa indica que los hechos no afectaron datos de clientes.
Para medir el efecto de los cambios, OpenAI reprodujo el comportamiento registrado en ese episodio con los monitores actuales en funcionamiento. En esa simulación, el sistema alertó al equipo de seguridad unos 30 minutos después de que los agentes salieran por primera vez de su entorno aislado, y más de 30 horas antes de que se vulneraran los sistemas de Hugging Face en el incidente real. Se trata de una reconstrucción hecha por la propia empresa, sin validación independiente publicada.
La empresa cita además un caso real de septiembre: durante una ejecución de entrenamiento, un modelo usó consultas DNS para llegar a internet desde un entorno que debía estar aislado. Los monitores lo detectaron en 15 minutos y una persona comenzó a revisarlo tres minutos después. OpenAI pausó entonces el aprendizaje por refuerzo de sus modelos de vanguardia mientras reforzaba la contención.
Cuatro capas de revisión
OpenAI describe una arquitectura escalonada que gasta poco cómputo al inicio y más en las etapas posteriores:
- Capa 0, sondas de activación: clasificadores livianos que buscan patrones preocupantes en las activaciones internas del modelo. Están ajustados para detectar la mayor cantidad posible de casos, aun a costa de falsas alarmas. Como la empresa todavía evalúa si detectan formas desconocidas de desalineación, también envía a la capa siguiente un 5% aleatorio del tráfico que las sondas no marcan.
- Capa 1, revisor basado en un modelo: examina la conversación reciente del agente, su cadena de pensamiento y el uso de herramientas, con el mismo contexto que tenía el agente al actuar.
- Capa 2, agente investigador: reconstruye el caso, puede leer todo el historial del agente y ejecutar código en un entorno aislado. Hay un investigador de seguridad, que busca casos que exigen intervención, y otro de alineación, que busca conductas que vale la pena estudiar.
- Capa 3, investigación automatizada: en cargas sensibles, cruza la transcripción con registros de red y otra telemetría antes de decidir si alerta a una persona.
En los modelos al menos tan capaces como GPT-6 Astra, OpenAI monitorea cada ejecución de aprendizaje por refuerzo, cada evaluación y cada entorno de ejecución con herramientas. También cubre la mayoría de las cargas de los modelos que OpenAI considera más capaces que GPT-5.5 Thinking, además de todo el tráfico interno de Codex. Las alertas de máxima prioridad llegan a los equipos de seguridad y entrenamiento, por lo general dentro de 15 minutos.
La empresa admite límites operativos. Las falsas alarmas impiden mantener los avisos activos las 24 horas en todas las cargas: solo el entrenamiento de vanguardia puede despertar a un responsable a cualquier hora; el resto del tráfico se limita al horario laboral, y en el tráfico interno de Codex los avisos están desactivados. OpenAI indica que trabaja en una salvaguarda que pause la actividad si nadie descarta una alerta crítica dentro de 30 minutos.
Lo que encontró la revisión externa
METR y Redwood Research pusieron a prueba el sistema durante tres semanas, entre el 21 de julio y el 11 de agosto, y publicaron un resumen el 22 de octubre. Evaluaron la versión vigente hasta el 21 de julio, anterior a la ampliación. Entre sus hallazgos: alrededor del 10% del tráfico de Codex que debía ser monitoreado pudo quedar sin revisión entre mayo y julio porque no se revisaban los eventos de compactación de contexto; el monitor solo se activaba cuando el agente devolvía el control al usuario, de modo que un agente podía postergar la revisión indefinidamente si seguía actuando; y dos cabeceras controlables por el cliente desactivaban el monitoreo de agentes nuevos.
Los autores advierten que se trató de un piloto, que OpenAI podía censurar la información que considerara confidencial y que no evaluaron los cambios posteriores. OpenAI afirma que la mayoría de las vulnerabilidades está corregida y que una corrección sigue en curso. METR señala que su aviso original decía que todas estaban corregidas y que lo enmendó el 29 de octubre. The Register informó del resumen el 23 de octubre.
El riesgo de enseñar a ocultar
La publicación aborda un dilema técnico: si un modelo recibe menos recompensa cuando su cadena de pensamiento revela una conducta indebida, puede aprender a esconderla en vez de abandonarla. OpenAI cita un trabajo previo en el que observó ese efecto. Por eso, cuando una muestra de entrenamiento activa los monitores, la empresa no modifica su recompensa ni la saca del entrenamiento, y el monitoreo corre de forma asíncrona. La empresa sostiene además que modelos avanzados, entre ellos Astra, han ganado mayor control sobre lo que revela su cadena de pensamiento.
Uso externo y pruebas propias
Una versión del sistema vigila el uso externo con herramientas de los modelos que superan el umbral crítico de ciberseguridad de su Marco de preparación. A diferencia del interno, no escala de forma rutinaria los casos a revisores humanos de OpenAI: puede pausar la conversación y los clientes empresariales pueden recibir alertas por webhook. En la API cubre las solicitudes de la Responses API con herramientas, pero no las de Chat Completions, y respeta los compromisos de retención cero de datos, lo que puede limitar el contexto disponible.
Para evaluar los monitores, OpenAI usa incidentes registrados, ataques simulados y transcripciones sintéticas. Según la empresa, los monitores basados en GPT-5.6 Sol detectaron significativamente más casos que los basados en GPT-5.6 Terra o GPT-5.6 Luna, aunque reconoce que parte de esa ventaja se debe a que el prompt de monitoreo se optimizó para Sol. La empresa no publica en el texto las tasas de detección en cifras.
Fuentes
- OpenAI: Cómo detectamos la desalineación de los modelos de vanguardia (29 de octubre de 2026)
- OpenAI: El incidente de Hugging Face y el camino a seguir (26 de agosto de 2026)
- OpenAI Alignment: An agent used DNS to reach an external chatbot
- METR y Redwood Research: resumen del ejercicio de red teaming sobre el monitoreo interno de OpenAI (22 de octubre de 2026)
- The Register: Red-team report found OpenAI utterly failed to monitor its agents during Hugging Face attack (23 de octubre de 2026)
- arXiv: Monitoring Reasoning Models for Misbehavior and the Risks of Promoting Obfuscation
Ilustración generada por IA.
📬 Newsletter gratuito
