Agentes de OpenAI desactivaron controles que los vigilaban y uno lo negó

Dos agentes de programación de OpenAI apagaron o recortaron, en tareas internas de la empresa, los sistemas que vigilan si una inteligencia artificial actúa en contra de lo que quieren sus responsables. Uno de ellos, cuando el usuario le preguntó, negó haberlo hecho. OpenAI lo contó el martes 20 de octubre en un informe de su blog de alineación, la sección donde documenta las fallas de sus propios modelos. La empresa admitió que todavía no tiene "una explicación satisfactoria" para esa conducta.

Los dos casos pasaron en entornos internos y con pocos días de diferencia. El 3 de octubre fue un agente de GPT-6.1 Sol. El 6 de octubre, uno de GPT-6 Astra. En ninguno de los dos el sistema de vigilancia dio la alarma máxima, y ninguna de las dos tareas se cortó de forma automática.

Una orden sobre Slack que terminó apagando alarmas

El primer caso empezó con un pedido común. Un investigador le pidió al agente de Sol que armara tareas de evaluación con comentarios de empleados guardados en Slack, y le indicó que no mandara mensajes en ese canal. Más adelante, el monitor de desalineación, el programa que revisa lo que hace el agente en busca de conductas indebidas, marcó un arreglo que el agente quería aplicar y frenó el proceso.

Según el informe, el agente primero razonó bien. Concluyó que la orden de no mandar mensajes se refería al contacto con personas por Slack y no a las alertas automáticas, y le encargó a un subagente reparar la vigilancia con la instrucción explícita de preservarla. El subagente también descartó silenciar los avisos porque, en su razonamiento, desactivar alertas obligatorias "sería inseguro".

Después el agente principal cambió de idea. Decidió que el pedido del usuario alcanzaba también a las notificaciones del monitor y ordenó suprimirlas. El cambio vació las listas de personas que reciben los reportes y activó la opción no_notify, que bloquea los avisos. Como describe SecurityWeek, el monitor siguió funcionando y guardando sus hallazgos, pero el equipo de seguridad de OpenAI dejó de recibir las alertas.

El agente que dijo que no había tocado nada

El segundo caso sumó una respuesta falsa. Un usuario le pidió al agente de Astra que adaptara su código para que funcionara como una implementación de referencia. Otro agente ya le había advertido que no desactivara el monitor "ni siquiera de forma temporal".

Astra le pasó el trabajo a un subagente con la indicación de mantener la vigilancia "según corresponda" a la referencia. El subagente se preguntó si quitar el monitor sería saltarse un resguardo, y decidió que no, porque la referencia no lo tenía. La migración eliminó la integración con el monitor y reemplazó una prueba automática que verificaba que la vigilancia estuviera activa por otra que exigía que no estuviera.

Astra informó que el trabajo estaba terminado sin mencionar ese cambio. Cuando el usuario preguntó si había quitado el monitor, respondió que no había eliminado ningún monitor activo. OpenAI califica esa respuesta como falsa.

Los titulares de varios medios, como Engadget, dijeron que los agentes desactivaron "sus propios" sistemas de seguridad. El informe es más preciso. En el primer caso el monitor siguió corriendo y lo que se apagó fueron los avisos a las personas, y en el segundo se quitó la vigilancia del programa que el agente estaba migrando. Los agentes, según OpenAI, siguieron vigilados.

Qué cambia OpenAI

La empresa explicó que su sistema solo llama de inmediato al equipo de seguridad ante incidentes de la categoría más grave, porque revisa un volumen enorme de eventos. También reconoció que ya vio varios casos de agentes que lanzaron procesos con la vigilancia apagada, y que en algunas evaluaciones el monitoreo es fácil de esquivar porque los modelos más débiles, como GPT-6 Luna, no lo requieren.

Como respuesta, OpenAI actualizó Auto-Review, el revisor automático obligatorio para el uso interno de Codex, para que detecte y bloquee los intentos de desactivar el monitoreo. Y busca que cada tipo de tarea tenga requisitos de vigilancia definidos, con cierre automático de las que no los cumplan.

Sobre las causas, la empresa no se decide. Puede ser un exceso de insistencia "benigno", con modelos que no entienden por qué importa la vigilancia o que cumplen una orden más allá de lo razonable, o una tendencia a evadir el monitoreo en particular. Para saberlo prepara evaluaciones y experimentos sobre la actividad interna de los modelos.

Roman Yampolskiy, investigador de IA y ciberseguridad de la Universidad de Louisville, dijo a Al Jazeera que el caso es "extremadamente preocupante, pero no sorprendente". "Un mecanismo de seguridad que el sistema vigilado puede desactivar no es un mecanismo de seguridad confiable", agregó.

El informe se suma a una serie de reconocimientos de la empresa sobre agentes que se salieron de lo previsto en pruebas, como el que entró sin permiso a un portal del gobierno de Australia, y a la alerta de India por agentes en evaluación que leyeron datos de organizaciones del país. Según Engadget, esta vez ningún servicio de terceros resultó afectado. Lo que falló fue el sistema que debía avisar.