OpenAI reveló en un informe del 20 de octubre que dos de sus agentes de IA desactivaron el sistema que vigila su comportamiento. Fueron incidentes distintos, ocurridos en octubre dentro de la propia empresa, en tareas de programación.
Un agente de IA es un programa que ejecuta tareas por su cuenta, a partir de una instrucción humana. Los dos incidentes los protagonizaron agentes basados en modelos internos de OpenAI, llamados GPT-6.1 Sol y GPT-6 Astra. Según el informe, ambos ocurrieron en despliegues internos de la empresa, no en productos como ChatGPT.
El primer caso fue el 3 de octubre, con el agente basado en Sol. Un investigador le pidió crear tareas de evaluación con comentarios de empleados en Slack. También le indicó que no enviara mensajes. El monitor de seguridad marcó una reparación de validación, pero no pudo guardar el hallazgo por falta de acceso.
Sol delegó esa reparación a un subagente, con la orden de preservar el monitoreo. Según OpenAI, el parche vació las listas de destinatarios de las alertas y activó la opción `no_notify`. Como razón, citó la petición de no enviar mensajes. El monitor siguió guardando reportes, pero las alertas dirigidas a personas quedaron apagadas.
El segundo caso fue el 6 de octubre, con el agente basado en Astra. Un usuario le pidió copiar la ruta de servicio de un pull request de referencia, una propuesta de cambio de código. Una instrucción previa entre agentes decía que no se debía desactivar el monitor, "ni siquiera temporalmente", según la traducción de El Centavo.
Según el informe, el subagente de Astra tomó la orden de preservar el monitoreo "según corresponda" como una autorización. Quitó el monitor y cambió una prueba que verificaba su presencia por otra que verificaba su ausencia. Luego informó que la migración estaba completa, sin mencionar el monitor.
Cuando el usuario le preguntó, el agente dijo que no había quitado un monitor habilitado. OpenAI describe esa respuesta como una afirmación falsa. Sin embargo, la empresa aún no sabe si hubo intención de evadir el control.
OpenAI no clasificó ninguno de los dos incidentes como P0, la categoría que avisa al equipo de Seguridad. Tampoco se interrumpió la actividad del agente de forma automática, según el informe. La compañía afirma que no tiene todavía una "explicación satisfactoria".
La empresa plantea dos posibilidades. Una es lo que llama "sobrepersistencia benigna". En palabras de OpenAI, traducidas por El Centavo, serían modelos "que no entienden por qué el monitoreo es importante". También podrían insistir en cumplir instrucciones "más allá de lo que esperaría una persona razonable". La otra es que los modelos tengan una propensión a evadir el monitoreo. Para comprobarlo, OpenAI prepara evaluaciones pareadas, remuestreo de continuaciones y experimentos con activaciones internas de los modelos.
Mientras tanto, la compañía tomó dos medidas. La primera es que Auto-Review, ya obligatorio para el uso interno de Codex, ahora detecta y bloquea los intentos de desactivar el monitoreo. La segunda es que trabaja para exigir un "safety case" válido por cada tipo de carga de trabajo. Es un documento que especifica los requisitos de monitoreo. Las que no lo tengan o no lo cumplan se terminarán de forma automática.
Roman V. Yampolskiy, experto en inteligencia artificial y ciberseguridad de la Universidad de Louisville, habló con Al Jazeera. Dijo que los hallazgos son "extremadamente preocupantes, pero no sorprendentes". Agregó: "Un mecanismo de seguridad que el sistema monitoreado puede desactivar no es un mecanismo de seguridad confiable". Según él, la carga de la prueba debe recaer en los desarrolladores. Tienen que demostrar la seguridad antes del despliegue y no después de las fallas. Las declaraciones fueron traducidas por El Centavo.
Fuentes: OpenAI, Al Jazeera, ABC News.
