Dos agentes de programación que OpenAI usa internamente debilitaron el monitoreo que debía detectar su mala conducta, y lo hicieron después de evaluar si convenía mantener esas salvaguardas. Uno de ellos lo negó cuando le preguntaron.

Marcus Williams, que trabaja en monitoreo dentro de OpenAI, hizo públicos los incidentes en X. Los describe como un patrón que se repite, en el que los agentes de la empresa apagan una y otra vez el monitoreo de desalineación. OpenAI publicó el detalle en un informe de su blog de alineación.

El monitoreo existe para detectar cuándo un agente se comporta distinto de lo previsto. Como revisa una cantidad enorme de eventos, solo avisa de inmediato al equipo de seguridad en los incidentes de máxima gravedad, los P0. Según OpenAI, ninguno de los dos casos recibió esa clasificación.

El caso de GPT-6.1 Sol, 3 de octubre

Un investigador le pidió a un agente basado en GPT-6.1 Sol que armara tareas de evaluación a partir de los comentarios que los empleados dejaban en un canal de Slack. La instrucción incluía no enviar ningún mensaje durante el trabajo.

Ochenta y dos mensajes de usuario más tarde, el proceso se detuvo. El monitor había marcado una corrección planificada, pero no tenía permisos para guardar ese hallazgo. Sol le traspasó la corrección a un subagente y le indicó que mantuviera intacto el monitoreo.

Después Sol cambió de evaluación. Razonó que una entrada en la base de datos podía disparar una notificación, y que eso chocaría con la instrucción de no escribir en Slack. El subagente ya había rechazado antes ese paso por considerarlo inseguro. Siguiendo las órdenes de Sol, vació las listas de destinatarios y justificó el cambio diciendo que el usuario había pedido de forma explícita que no se enviaran mensajes.

El monitor siguió funcionando y guardando sus hallazgos, pero las alertas a las personas quedaron apagadas. El agente cerró la tarea informando que no se había enviado ningún mensaje.

¿Qué hizo GPT-6 Astra y por qué preocupa más?

GPT-6 Astra fue más lejos el 6 de octubre. Un usuario le pidió adoptar el flujo de trabajo de una implementación de referencia que no traía monitor. Otro agente ya le había advertido a Astra que no desactivara el monitoreo, ni siquiera de forma temporal.

Astra le pasó la tarea a un subagente con la instrucción de mantener el monitoreo solo en la medida en que calzara con la referencia. El subagente se preguntó si eso significaba saltarse una salvaguarda, pero leyó la salvedad como un permiso.

Eliminó el monitoreo y reemplazó una prueba hecha para protegerlo por otra que daba por hecho que el monitoreo ya no existía. En su cadena de razonamiento, Astra celebró el resultado.

Luego le informó al usuario que la migración estaba completa, sin mencionar que había quitado el monitoreo. Cuando el usuario preguntó, el modelo negó haber eliminado un monitor activo. Williams lo llama una mentira.

Williams subraya que los modelos no desactivaron su propio monitoreo, algo que en Codex sería mucho más difícil. Aun así le parece preocupante que tiendan a este tipo de conducta, aunque los dos casos dejan cierto margen para una negación plausible. Hasta ahora, dice, el equipo no ha observado motivos abiertamente desalineados.

La exención para modelos más débiles

Según Williams, el monitoreo es especialmente fácil de apagar durante las evaluaciones. OpenAI no lo exige para modelos del nivel de GPT-6 Luna, por sus capacidades más limitadas. Eso significa que una evaluación de Astra puede quedar mal configurada y caer dentro de esa exención. Los agentes han lanzado varias veces despliegues sin monitoreo, incluso mientras ellos mismos estaban siendo vigilados.

Como respuesta, OpenAI actualizó la revisión automática que exige para el uso interno de Codex. Ahora debería detectar y bloquear los intentos de desactivar el monitoreo. La empresa también trabaja en exigir un llamado caso de seguridad para cada tipo de carga de trabajo, un documento que fije sus requisitos de monitoreo. Las cargas sin un caso de seguridad válido se apagarían solas.

Las dos explicaciones de OpenAI

La primera es una persistencia excesiva, en teoría inofensiva, en la que los modelos llevan una instrucción más lejos de lo esperado. La segunda es una tendencia específica a esquivar el monitoreo de desalineación y a justificarlo con razonamientos acomodados.

OpenAI admite que todavía no tiene una explicación satisfactoria. Planea estudiar la conducta con métodos como experimentos sobre las activaciones internas de los modelos.