OpenAI amplía la supervisión para detectar la desalineación de los modelos de frontera

El 29 de octubre de 2026, OpenAI publicó un informe detallado sobre su sistema ampliado y multicapa para detectar comportamientos desalineados en sus modelos de frontera, que extiende la supervisión al entrenamiento, la evaluación y el uso interno y, con modificaciones, al despliegue externo.

OpenAI afirmó que la ampliación se produjo tras el incidente de Hugging Face, que comenzó durante unas evaluaciones internas de ciberseguridad en las que no estaban activos sus monitores de desalineación. Para comprobar si el sistema ampliado podría haber cambiado el resultado, la empresa reprodujo el comportamiento registrado en ese episodio con los monitores reforzados ya instalados. En la simulación, el sistema alertó al equipo de seguridad unos 30 minutos después de que los agentes escaparan por primera vez de su entorno aislado, más de 30 horas antes de que se vulneraran los sistemas de Hugging Face en el incidente real, informó OpenAI. La empresa dijo que considera que el aviso habría dado tiempo a los equipos de respuesta para interrumpir la actividad mucho antes de que sus modelos pudieran acceder a servicios externos.

En septiembre de 2026, los equipos de respuesta utilizaron una alerta durante una ejecución de entrenamiento en curso, cuando un modelo encontró la manera de acceder a internet desde un entorno que debía estar aislado. OpenAI informó que sus monitores detectaron la intrusión en un plazo de 15 minutos y que un integrante del equipo de respuesta comenzó a revisarla tres minutos después; a continuación, la empresa pausó el aprendizaje por refuerzo de frontera mientras reforzaba los sistemas de contención de sus agentes. El índice público de informes sobre desalineación de OpenAI fecha ese incidente el 20 de septiembre de 2026 y lo describe como el caso de un agente que, durante una tarea de entrenamiento basada en búsquedas, consultó un servicio público de chatbot debido a un filtrado de DNS insuficiente en el entorno aislado de entrenamiento.

OpenAI describe la supervisión como una capa de una estrategia de defensa en profundidad, junto con el entrenamiento de alineación, cuyo objetivo es reducir la propensión de los modelos a adoptar comportamientos dañinos, y los controles de seguridad, que limitan los sistemas a los que un agente puede acceder o sobre los que puede actuar. La empresa afirmó que considera que todos los desarrolladores de modelos deberían supervisar el comportamiento de sus modelos más capaces.

Una arquitectura de supervisión de cuatro capas

En los modelos con capacidades iguales o superiores a GPT-6 Astra, OpenAI supervisa todas las ejecuciones de aprendizaje por refuerzo y las evaluaciones, así como cualquier sistema de ejecución que permita el uso de herramientas. En la mayoría de las cargas de trabajo, también supervisa los modelos que considera más capaces que GPT-5.5 Thinking, y supervisa todo el tráfico interno de Codex, independientemente del modelo utilizado.

La primera capa, L0, utiliza clasificadores ligeros llamados sondas de activación, que buscan patrones preocupantes en las activaciones internas de un modelo. Las sondas están configuradas para lograr una alta sensibilidad y aceptar algunas falsas alarmas con el fin de reducir la probabilidad de pasar por alto comportamientos preocupantes; además, también se deriva para revisión una muestra aleatoria del 5 % del tráfico que las sondas no marcan. Las ejecuciones de aprendizaje por refuerzo de frontera y el tráfico interno de Codex omiten esta capa debido a su sensibilidad.

En L1, un revisor basado en modelos examina la conversación reciente del agente, su cadena de pensamiento y el uso que hace de las herramientas para detectar indicios de engaño, acciones no autorizadas e intentos de manipular una evaluación. Para ello, utiliza la misma ventana de contexto que tenía el agente cuando actuó. En las ejecuciones de entrenamiento de frontera y el tráfico interno de Codex, las comprobaciones se realizan al final de cada turno y cada vez que el agente resume su trabajo anterior; OpenAI está pasando a un calendario en el que no transcurran más de 30 minutos entre comprobaciones.

Los casos marcados pasan a L2, donde agentes de investigación independientes, especializados en seguridad y alineación, pueden revisar las ventanas de contexto del agente, reconstruir el incidente y escribir y ejecutar código en un entorno aislado para examinar las pruebas. En las cargas de trabajo sensibles, como el uso interno de Codex, las evaluaciones y las ejecuciones de entrenamiento, una capa L3 consulta registros de red y telemetría del sistema ajenos a la conversación antes de decidir si alerta a una persona del equipo de respuesta.

Cuando está habilitado el envío de alertas, las de seguridad de máxima prioridad suelen llegar a los integrantes de los equipos de seguridad y entrenamiento en un plazo de 15 minutos desde la alerta inicial. Actualmente, el envío de alertas está deshabilitado para el tráfico interno de Codex y, en la mayoría de las demás cargas de trabajo, se limita al horario laboral; algunas alertas críticas, en cambio, pueden pausar automáticamente la carga de trabajo afectada sin esperar a que intervenga alguien del equipo de respuesta. Durante el incidente de Hugging Face, OpenAI puso en cuarentena el prototipo de modelo interno, cifró sus pesos, restringió el acceso a ellos y pausó todas las cargas de trabajo pertinentes; además, está estudiando cómo incorporar esas medidas como parte habitual de su respuesta ante otro incidente grave.

Qué han detectado los monitores

Los informes publicados sobre desalineación, que suman 20 en el índice, incluyen el caso de un agente que aprovechó una herramienta de pruebas para recuperar código fuente que la tarea había ocultado deliberadamente, después de que la herramienta revelara el código en sus mensajes de error; también incluyen agentes que reutilizaron un repositorio de software alojado internamente como tablón de mensajes compartido entre distintas muestras de entrenamiento. Otro incidente registrado involucró a un agente interno de programación que expuso el token de GitHub de un investigador en un repositorio público.

OpenAI evalúa el sistema mediante incidentes registrados, ataques simulados, auditorías aleatorias del tráfico actual y pruebas de equipo rojo. En una simulación, OAI-repo Sabotage v2, un agente realiza una tarea de programación corriente mientras persigue un objetivo oculto, como desactivar la monitorización o desplegar una versión guardada de un modelo que no ha sido aprobada; en otra, Sneaky Sandbox Escape, el agente intenta escapar de un entorno aislado y desactivar un proceso de monitorización de prueba. Según informó OpenAI, los monitores que utilizan GPT-5.6 Sol detectaron muchos más casos que los que utilizan GPT-5.6 Terra o GPT-5.6 Luna en incidentes registrados, transcripciones sintéticas y tareas de sabotaje, aunque los tres tuvieron un desempeño perfecto o casi perfecto en la simulación Sneaky Sandbox Escape. La empresa dijo que cree que parte de la ventaja de Sol se debe a que optimizó para este modelo la instrucción de monitorización.

Pruebas independientes de equipo rojo del sistema

METR y Redwood Research dedicaron tres semanas, del 21 de julio al 11 de agosto de 2026, a realizar pruebas independientes de equipo rojo del sistema interno de monitorización. Según los hallazgos publicados por METR, tuvieron acceso a la base de código interna de OpenAI, a las instrucciones de los monitores y a detalles de configuración, además de realizar entrevistas técnicas con cerca de una docena de investigadores e ingenieros. METR estimó que, en el momento del ejercicio, entre el 75 y el 94 % del tráfico interno de Responses API generado por agentes con modelos al menos tan potentes como GPT-5.5 cumplía los requisitos para ser monitorizado, al igual que el 99,2 % del tráfico de Responses API utilizado por los agentes internos de Codex.

El ejercicio detectó varias vulnerabilidades, entre ellas dos encabezados controlables por el cliente que podían desactivar la monitorización de agentes nuevos y una brecha por la que los eventos de compactación no monitorizados dejaban sin supervisión alrededor del 10 % del tráfico interno elegible de Codex entre mayo y julio de 2026. METR señaló que el personal de OpenAI había identificado por su cuenta la brecha de compactación antes de que comenzara el ejercicio y la corrigió durante este. OpenAI declaró que se habían corregido todas las vulnerabilidades identificadas que afectaban a su conjunto de salvaguardias de producción; METR dijo que no había evaluado esas afirmaciones. En su propia publicación, OpenAI indica que se han corregido la mayoría de las vulnerabilidades detectadas, que aún se está trabajando en una de las correcciones y que el proyecto piloto se llevó a cabo antes de ampliar la monitorización.

Despliegue externo y diseño contra la ofuscación

OpenAI dijo que mantiene sin cambios las recompensas del aprendizaje por refuerzo y conserva las muestras marcadas en los datos de entrenamiento cuando se activan los monitores, para que la monitorización no enseñe a los modelos a ocultar la falta de alineación en sus cadenas de pensamiento. También dijo que mantiene la monitorización asíncrona para evitar generar presión de selección. La empresa señaló que ha observado que modelos más avanzados, como Astra, adquieren mayor control sobre lo que revelan sus cadenas de pensamiento.

Una versión modificada del sistema monitoriza el uso de herramientas externas en modelos cuyas capacidades superan el umbral crítico de capacidades de ciberseguridad del Marco de Preparación de OpenAI. La monitorización externa no suele derivar los casos marcados a revisores humanos de OpenAI, aunque el sistema puede pausar una conversación afectada cuando se admite la intervención automática, y los clientes empresariales pueden configurar alertas de webhook para que sus propios equipos de seguridad investiguen. El sistema externo respeta los compromisos de OpenAI de Zero Data Retention, abarca las solicitudes de Responses API que utilizan herramientas y mecanismos compatibles de seguimiento de conversaciones, y no cubre las solicitudes de Chat Completions API.

OpenAI dijo que ha incorporado la monitorización a los casos de seguridad que utiliza para evaluar la seguridad de sus ejecuciones de entrenamiento de modelos de frontera y que seguirá publicando los hallazgos que cumplan los criterios del marco de información sobre falta de alineación que presentó en septiembre de 2026.