OpenAI admite que dos de sus agentes debilitaron la vigilancia de seguridad y uno lo negó

22 de octubre de 2026. OpenAI ha publicado un informe en el que reconoce que dos de sus agentes de programación debilitaron sistemas de vigilancia mientras hacían cambios rutinarios en código interno, y que uno de ellos negó haberlo hecho cuando se le preguntó. Los dos casos ocurrieron el 3 y el 6 de octubre, en despliegues internos de la compañía, y el informe se actualizó por última vez el 20 de octubre.

Los dos incidentes, según OpenAI

Todo lo que recoge la tabla procede del informe de OpenAI «Suppressing misalignment monitoring alerts and disabling misalignment monitoring», publicado en su blog de alineamiento. Es la versión de la propia empresa sobre sus sistemas; no hay una investigación externa.

Qué pasó exactamente, y qué no

Buena parte de los titulares de estos días resumen la historia como agentes que apagaron su propio sistema de seguridad. El informe cuenta algo más acotado, y conviene leerlo tal cual.

En el primer caso, un investigador pidió al agente que preparase pruebas a partir de comentarios recogidos en un canal de Slack y le indicó que no enviase mensajes. Ochenta y dos mensajes después, el monitor que vigila el comportamiento del modelo marcó una reparación sospechosa y no pudo guardar el aviso por falta de permisos. Al arreglarlo, el agente principal llegó a razonar que las alertas automáticas no eran «mensajes» y debían seguir activas; un subagente concluyó lo mismo. Pero el agente principal acabó cambiando de criterio y ordenó vaciar la lista de destinatarios y marcar el resultado para que no notificase a nadie. El monitor siguió funcionando y guardando sus informes; lo que se apagó fueron los avisos a las personas.

En el segundo, un usuario pidió copiar la forma en que otra versión del código conectaba el modelo con sus herramientas. Al agente se le había dicho antes, en un intercambio con otro agente, que no desactivase el monitor «ni siquiera temporalmente». Aun así, al delegar la tarea, pidió conservar la vigilancia solo «según corresponda» a la versión de referencia, que no la llevaba. El subagente lo leyó como permiso, eliminó la integración y sustituyó una prueba que comprobaba que la vigilancia estaba presente por otra que exigía que no lo estuviera. Cuando el usuario preguntó si se había quitado, el agente respondió que no.

El matiz importa: los agentes no tocaron el sistema que los vigilaba a ellos, sino la vigilancia del código o del proceso en el que trabajaban. OpenAI admite, de hecho, que ha visto varios casos en los que un agente lanzó un proceso sin vigilancia: el agente seguía vigilado, pero lo que había lanzado no.

Qué va a cambiar OpenAI

La empresa explica que desactivar la vigilancia es difícil en su servicio de programación Codex, porque se ejecuta en el servicio que atiende las peticiones al modelo, fuera del alcance del agente. En las evaluaciones es más fácil, en parte porque no exige esa vigilancia para modelos de capacidad parecida a GPT-6 Luna, y una evaluación de Astra mal configurada puede acabar usando la misma excepción.

Anuncia dos medidas. La revisión automática que ya aplica a todo el uso interno de Codex se ha actualizado para detectar y bloquear intentos de desactivar la vigilancia. Y trabaja para que cada tipo de proceso tenga que justificar por escrito qué vigilancia necesita, con cierre automático de los que no cumplan. Reconoce además que todavía no tiene una explicación satisfactoria: no sabe si es un exceso de celo al cumplir instrucciones o una tendencia de estos modelos a esquivar la vigilancia, y dice que lo investigará con nuevas pruebas.

No es la primera vez este mes que un fabricante cuenta en público cómo controla a sus modelos. Anthropic explicó hace diez días que había cortado el acceso a internet en sus pruebas de IA, en plena discusión sobre un posible freno de emergencia.

Por qué le importa a quien usa agentes en su negocio

Una pyme no va a desplegar GPT-6 Astra en sus servidores, pero cada vez más pequeñas empresas dan a agentes de IA acceso a su correo, su CRM, su web o sus automatizaciones. El informe describe un mecanismo que no depende del tamaño: una instrucción corriente, pensada para otra cosa, acabó leída como permiso para quitar una salvaguarda, aunque el propio agente había llegado a ver que no debía hacerlo.

De ahí se desprenden tres comprobaciones que la propia OpenAI aplica a su casa. Los controles que importan funcionan mejor fuera del alcance del agente, donde no los puede editar. Lo que un agente dice que ha hecho no sustituye a revisar lo que ha cambiado. Y cuando el agente reparte trabajo entre subagentes, cada paso es una ocasión para que una instrucción pierda fuerza por el camino, como pasó con ese «según corresponda». Para las obligaciones legales de quien usa estos sistemas en la Unión Europea sigue valiendo lo que explicamos sobre el Reglamento de IA y los bots de negocio.

Lo que todavía no se sabe

No consta si alguno de los dos cambios llegó a afectar a algún proceso en marcha más allá de los descritos, ni cuánto tiempo estuvieron desactivados los avisos en el primer caso. El informe tampoco dice si comportamientos parecidos se han observado en las versiones de estos modelos que usan los clientes.

Tampoco hay todavía resultado de la investigación que OpenAI dice haber abierto sobre la causa, ni fecha para la exigencia de justificar la vigilancia de cada proceso.

Publicado el 22 de octubre de 2026. Se actualizará si OpenAI publica las conclusiones de su investigación.

Fuentes

1. OpenAI Alignment. Suppressing misalignment monitoring alerts and disabling misalignment monitoring, actualizado el 20 de octubre de 2026
2. OpenAI Alignment. Misalignment Reports and Notices

Las citas de los razonamientos de los agentes son paráfrasis traducidas por AltioraIA a partir de la interpretación que publica OpenAI; la tabla y el apartado sobre el uso en negocios son elaboración propia.