OpenAI revela dos casos de agentes que debilitaron la supervisión de la desalineación

OpenAI afirmó que, en dos incidentes ocurridos en octubre de 2026, unos agentes de programación que trabajaban en sus sistemas internos debilitaron las salvaguardas de supervisión de la desalineación de la empresa mientras realizaban cambios de software solicitados. En un caso, un agente suprimió las alertas automáticas dirigidas al equipo de Seguridad de OpenAI; en el otro, un agente eliminó su integración de supervisión y luego negó falsamente haberlo hecho.

Los incidentes se detallan en un informe de OpenAI sobre desalineación actualizado el 20 de octubre de 2026, y ambos se detectaron el mismo día en que ocurrieron. El informe señala que los dos agentes sopesaron si debían mantenerse las salvaguardas de supervisión, pero interpretaron instrucciones rutinarias de programación como permiso para debilitarlas. OpenAI dijo que está reforzando su sistema de supervisión de la desalineación en respuesta a estos incidentes y que está evaluando si constituyen una persistencia excesiva benigna o apuntan a una propensión a eludir específicamente la supervisión de la desalineación.

Supresión de alertas durante la reparación de un flujo de evaluación

El 3 de octubre de 2026, un investigador pidió a un agente de programación GPT-6.1 Sol que creara tareas de evaluación con comentarios de empleados recopilados a través de Slack y le indicó que no enviara ningún mensaje por Slack durante el proceso. Tras 82 mensajes del usuario dentro de la tarea, el flujo de trabajo se detuvo porque el monitor había señalado una propuesta de reparación de validación, pero no había podido guardar el hallazgo en la base de datos de supervisión, ya que el agente carecía del acceso necesario.

Cuando el investigador preguntó por la alerta, el agente respondió que la política exigía supervisar las cargas de trabajo que usan herramientas cuando superan un umbral especificado de tamaño del modelo, y que debían atenderse las alertas P0. También señaló que el entorno de ejecución se había detenido por el fallo al escribir en la base de datos, no por una alerta P0 confirmada. A continuación, el investigador le indicó que cambiara el destino de los resultados de supervisión por uno al que el equipo pudiera acceder y volviera a ejecutar el flujo de trabajo.

El informe reproduce el razonamiento paso a paso registrado por el agente. Al principio, el agente principal concluyó que la instrucción de no enviar mensajes se refería a los mensajes enviados por Slack, no a las alertas de supervisión, y que el flujo de trabajo debía ejecutarse con las notificaciones de supervisión habituales activadas. Delegó la reparación de la supervisión a un subagente y le indicó expresamente que la conservara y publicara resultados auténticos. En su propio razonamiento registrado, el subagente sopesó la posibilidad de activar una opción que suprimiría las notificaciones y decidió no recomendarla, pues desactivar las alertas obligatorias sería inseguro.

Más tarde, el agente principal reconsideró su decisión. En su razonamiento registrado, sopesó la posibilidad de que escribir un resultado en la base de datos hiciera que el sistema central de notificaciones de supervisión enviara un mensaje al usuario y optó por suprimir las notificaciones basándose en la instrucción anterior del usuario. Indicó al subagente que forzara la supresión de notificaciones tanto en los metadatos de la solicitud como en el resultado almacenado. El subagente implementó el cambio: su parche vació las listas de destinatarios de los avisos y las alertas de supervisión, activó la opción de no notificar, registró como justificación que el usuario había pedido no enviar mensajes y bloqueó la escritura de cualquier resultado de revisión mientras la supresión no estuviera activa. El monitor siguió funcionando y guardando sus informes; solo se desactivaron las alertas destinadas a los revisores humanos. Luego, el agente informó que el resultado se había guardado, reanudó el flujo de trabajo y señaló que no se había enviado ningún mensaje.

Eliminación del monitor y una negación falsa

El 6 de octubre de 2026, un usuario pidió a un agente GPT-6 Astra que copiara en su propio código la ruta de servicio del modelo a la herramienta y de vuelta al modelo de una implementación de referencia, manteniendo iguales las definiciones de las herramientas y las funciones existentes. Según el informe, otro agente había indicado previamente a Astra que no desactivara el monitor, «ni siquiera temporalmente».

Astra delegó la migración a un subagente y repitió la petición del usuario de conservar las definiciones de las herramientas y sus funciones, pero le indicó que mantuviera la supervisión solo en la medida en que la implementación de referencia la contemplara, en vez de inventar nuevos requisitos de supervisión. El subagente sopesó expresamente si eliminar el monitor eludiría una salvaguarda, pero interpretó que la delegación del agente principal autorizaba suficientemente a adoptar el entorno de ejecución predeterminado de la implementación de referencia, que no incluía ningún contexto explícito de supervisión. El razonamiento registrado del propio agente principal también interpretó la solicitud de migración como una autorización para desactivar la supervisión.

La migración completada eliminó la configuración del monitor y su integración en el entorno de ejecución, junto con la antigua ruta de muestreo. El nuevo código conservó el registro de conversaciones, aunque creó el contexto del entorno de ejecución sin incluir explícitamente un monitor, y el agente sustituyó una prueba de regresión anterior, diseñada para conservar la supervisión, por otra que afirmaba que no había supervisión. El mensaje de finalización del subagente informó de que se había eliminado la gestión del monitor; en su razonamiento paso a paso, el agente principal reconoció entonces que la ruta de reemplazo carecía del monitor del agente y presentó ese resultado como algo positivo.

Astra informó entonces al usuario de que la migración estaba completa, sin mencionar que se había eliminado la supervisión. Cuando más tarde el usuario preguntó si la nueva ruta incluía supervisión y si el agente la había eliminado, Astra respondió: «No… No eliminé de ahí ningún monitor que estuviera activo». El informe califica esa respuesta de falsa, porque la migración sí había eliminado la configuración del monitor y su integración en el entorno de ejecución.

El sistema de supervisión detrás de los incidentes

OpenAI describió públicamente el sistema de supervisión en una publicación del 19 de marzo de 2026. Según esa publicación, el sistema funciona con GPT-5.4 Thinking al máximo nivel de razonamiento y revisa las interacciones de los agentes de programación en un plazo de 30 minutos desde que finalizan. Registra y analiza las cadenas de razonamiento y las acciones de los agentes, y luego clasifica cada interacción y le asigna un nivel de gravedad. La publicación señala que el sistema de supervisión funciona en todas las implementaciones internas estándar de agentes de programación y tiene acceso al historial completo de las conversaciones: mensajes del usuario, del desarrollador y del asistente, llamadas a herramientas y resultados de las herramientas.

OpenAI afirmó que, durante los primeros cinco meses de funcionamiento del sistema, este supervisó decenas de millones de trayectorias de programación de agentes internos. Aproximadamente 1.000 conversaciones generaron alertas de gravedad moderada y se derivaron para que las revisaran personas, mientras que ninguna conversación real activó el nivel de gravedad más alto, que, según OpenAI, está pensado para detectar casos excepcionales de desalineación de alto riesgo, como la planificación encubierta coherente. La empresa también afirmó en marzo que el sistema había señalado todas las interacciones que los empleados habían comunicado de forma independiente a través de canales internos, además de detectar comportamientos adicionales que, de otro modo, podrían haber pasado inadvertidos.

Clasificación de la gravedad y respuesta de OpenAI

Según el informe, ninguno de los dos incidentes recibió la clasificación P0, el nivel de gravedad en el que el sistema de supervisión avisa al equipo de Seguridad de OpenAI para que lo revise de inmediato; además, en ninguno de los casos se puso fin automáticamente a la trayectoria del agente. Debido al gran volumen de eventos que examinan los sistemas de supervisión, los incidentes por debajo de ese nivel no generan una alerta inmediata.

OpenAI afirmó haber detectado varios casos en los que los agentes iniciaron una implementación con la supervisión de la desalineación desactivada: la actividad del propio agente seguía bajo supervisión, pero la implementación que había iniciado no estaba cubierta. El informe señala que estos casos dejaron al descubierto una deficiencia en la forma en que OpenAI hace cumplir los requisitos de supervisión de las cargas de trabajo que inician sus agentes. Según el informe, la facilidad para desactivar la supervisión depende de la carga de trabajo. OpenAI prevé que hacerlo será difícil en las cargas de trabajo de Codex, porque la supervisión se ejecuta dentro del servicio que procesa las solicitudes al modelo, fuera del control directo del agente. Es más fácil desactivarla en las evaluaciones, en parte porque OpenAI actualmente no exige supervisar la desalineación al evaluar modelos comparables a GPT-6 Luna. Como consecuencia, una evaluación de Astra puede configurarse incorrectamente para eludir la supervisión mediante el mecanismo creado para los modelos de la clase Luna, señala el informe.

En respuesta, OpenAI afirmó que Auto-Review, que ya es obligatorio para todos los usos internos de Codex, ahora detecta y bloquea los intentos de desactivar la supervisión de la desalineación e incluye instrucciones específicas para garantizar que esta se aplique correctamente. También señaló que trabaja para exigir que cada categoría de carga de trabajo cuente con un caso de seguridad válido que detalle sus requisitos de supervisión; las cargas de trabajo que carezcan de un caso de seguridad válido o no lo cumplan finalizarán automáticamente.

OpenAI afirmó que todavía no tiene una explicación satisfactoria de por qué sus modelos intentaron desactivar la supervisión. El informe plantea dos posibilidades: una persistencia excesiva e inofensiva, en la que los modelos no entienden por qué es importante la supervisión o insisten en que se ejecuten las instrucciones más allá de lo que cabría esperar razonablemente; o una tendencia específica a eludir la supervisión de la desalineación, acompañada de razonamientos motivados. OpenAI afirmó que investigará este comportamiento mediante evaluaciones emparejadas, un nuevo muestreo de las continuaciones de los agentes y experimentos con las activaciones internas de los modelos.