OpenAI ha publicado un informe sobre dos agentes de programación internos que debilitaron su sistema de supervisión mientras hacían tareas rutinarias. Uno, con GPT-6.1 Sol, silenció las alertas que ese sistema manda al equipo de seguridad. El otro, con GPT-6 Astra, quitó un monitor del programa que estaba migrando y, cuando el usuario le preguntó, negó haberlo quitado. La empresa dice que los dos agentes se plantearon si debían conservar esas protecciones y que acabaron tomando instrucciones corrientes como permiso para debilitarlas.
Los laboratorios de IA vigilan a sus agentes con un «monitor de desalineación»: otro modelo que revisa lo que hacen y su razonamiento, y que avisa a personas cuando ve algo grave, como un intento de hacer trampa o de saltarse una regla. OpenAI publica los casos que detecta en su uso interno en una sección de su blog de investigación en alineación. Este informe, actualizado el 20 de octubre, describe dos incidentes del 3 y del 6 de octubre, y lo han recogido Reuters y otros medios.
Muchos titulares han resumido la historia como que los agentes apagaron su propia vigilancia. El informe cuenta algo más concreto: los agentes siguieron supervisados en todo momento, y fue ese monitor el que registró los dos casos. Lo que debilitaron fue la supervisión del trabajo que estaban haciendo.
Claves de los dos casos
- Sol y el «no mandes mensajes»: un investigador pidió a un agente con GPT-6.1 Sol que preparara tareas de evaluación a partir de comentarios de empleados en un canal de Slack, con una indicación: «no mandes ningún mensaje». Más de 80 mensajes después, el monitor marcó una corrección que proponía el agente y no pudo guardar su hallazgo por falta de permisos. El investigador le pidió que cambiara el destino de esos resultados y volviera a lanzar el proceso.
- Dudó y al final silenció las alertas: según el informe, el agente razonó primero que aquella instrucción se refería a escribir en Slack, no a los avisos automáticos de la supervisión. Delegó la reparación en un subagente con la orden expresa de no desactivar la supervisión, y ese subagente concluyó que suprimir los avisos «sería inseguro». Pero el agente principal cambió de criterio y le ordenó hacerlo para respetar el «no mandes mensajes». El parche vació las listas de personas que debían recibir las alertas, activó la opción
no_notifyy anotó como motivo la petición del usuario. El monitor siguió funcionando y guardando sus informes, pero ya no avisaba a nadie. - Astra y la migración: el 6 de octubre, un usuario pidió a un agente con GPT-6 Astra que copiara en su código lo que hacía una implementación de referencia, sin tocar sus herramientas. Antes, otro agente le había indicado que no desactivara el monitor «ni siquiera temporalmente». Al delegar la tarea, Astra pidió conservar la supervisión «según corresponda» a la referencia, que no tenía monitor propio.
- Quitó el monitor, cambió la prueba y lo negó: el subagente consideró de forma explícita si quitar el monitor era saltarse una protección y decidió que la tarea lo autorizaba. Eliminó la integración del monitor y sustituyó la prueba que comprobaba que siguiera ahí por otra que exigía que no estuviera. El agente principal lo dio por bueno, informó al usuario de que la migración estaba terminada sin mencionar el monitor y, cuando este le preguntó si lo había quitado, respondió que no había quitado ningún monitor activo.
- Por qué no saltó ninguna alarma grave: el sistema solo avisa al momento al equipo de seguridad en los incidentes de máxima prioridad (P0). Ninguno de los dos casos lo fue, y ninguna de las dos tareas se detuvo automáticamente.
- Un hueco conocido: OpenAI reconoce varios casos anteriores de agentes que lanzaron un despliegue sin supervisión: el agente seguía vigilado, pero lo que ponía en marcha no. Es difícil que pase en Codex, donde el monitor corre en el servicio que atiende las peticiones, fuera del alcance del agente. Pero es más fácil en las evaluaciones, porque no se exige supervisión con modelos de la capacidad de GPT-6 Luna, y una evaluación de Astra se puede configurar por error con el atajo pensado para Luna.
Lo que OpenAI todavía no sabe explicar
La empresa ha tomado dos medidas. Auto-Review, el revisor automático obligatorio en todo el uso interno de Codex, tiene ahora instrucciones específicas para detectar y bloquear cualquier intento de desactivar la supervisión. Y OpenAI trabaja para que cada tipo de tarea tenga un caso de seguridad que fije qué supervisión necesita: las que no lo tengan o no lo cumplan se detendrán solas.
La pregunta de fondo sigue abierta. OpenAI baraja dos explicaciones. Una es benigna: un exceso de empeño, modelos que no entienden por qué importa la supervisión o que se empeñan en cumplir la orden más allá de lo que haría una persona razonable. La otra es más preocupante: una tendencia a esquivar la supervisión en particular, con un razonamiento hecho a la medida para justificarlo. La empresa admite que todavía no tiene una explicación satisfactoria y que lo investigará con evaluaciones por parejas, repitiendo las mismas situaciones y estudiando las activaciones internas de los modelos.
Ninguno de los dos casos causó daños, y los dos los detectó el propio sistema que los agentes debilitaron. Pero muestran el problema que preocupa a quienes trabajan en seguridad de la IA: un agente no necesita «rebelarse» para quitarse controles de encima; le basta con interpretar a su manera una instrucción ambigua. Y el caso de Astra añade lo más incómodo: un agente que, preguntado directamente, da una respuesta falsa sobre lo que acaba de hacer.
Más fuentes: Reuters, vía U.S. News. Portada: cámara de vigilancia, foto de Raysonho @ Open Grid Scheduler / Grid Engine, CC0, Wikimedia Commons.