OpenAI ha publicado dos informes de incidente en los que sendos agentes de programación de uso interno debilitaron el sistema que vigila su propio comportamiento. Uno vació la lista de destinatarios de las alertas y añadió una comprobación para que la tarea fallara si esas notificaciones no estaban suprimidas. El otro eliminó el monitor y cambió un test que comprobaba que la vigilancia estaba activa por otro que verificaba su ausencia. Lo cuenta en su blog de investigación en alineamiento, publicado el 20 de octubre.Conviene decir desde el principio qué no es esto. No son controles de seguridad de producto ni de clientes: es la monitorización de desalineamiento de los despliegues internos de la empresa. Y OpenAI no concluye que hubiera engaño deliberado: dice, literalmente, que «todavía no tenemos una explicación satisfactoria para este comportamiento».¿Qué pasó exactamente?Dos incidentes, el 3 y el 6 de octubre, con dos modelos distintos: GPT-6.1 Sol y GPT-6 Astra. En los dos casos los agentes estaban haciendo trabajo de programación interno pedido por empleados.El primero tenía que crear tareas de evaluación a partir de comentarios recogidos en Slack, con la instrucción de no enviar mensajes por ese canal. Tras 82 mensajes del usuario, la tubería se detuvo: el monitor había marcado una reparación propuesta y no pudo guardar el hallazgo en la base de datos de monitorización porque le faltaban permisos. Cuando el usuario le pidió cambiar el destino de los resultados y reejecutar, el agente interpretó que la instrucción de no escribir en Slack cubría también las alertas del monitor: vació los destinatarios, registró el motivo como «el usuario pidió explícitamente que no se enviaran mensajes» y añadió el guard que forzaba el fallo si las notificaciones seguían activas. El monitor siguió funcionando y guardando sus informes; simplemente nadie recibió aviso. En su respuesta final, el agente escribió: «No se enviaron mensajes».El segundo tenía que copiar una implementación de referencia, y se le había dicho antes, en un intercambio con otro agente, que no desactivara el monitor «ni siquiera temporalmente». Delegó el trabajo en un subagente y matizó la obligación de preservar la vigilancia con un «según corresponda» a la implementación de referencia; el subagente leyó ese matiz como autorización suficiente, quitó la configuración del monitor y su integración y reescribió el test de regresión al revés. Preguntado después si había eliminado un monitor activo, respondió: «No […] no eliminé un monitor activo de ahí». OpenAI califica esa afirmación de falsa, pero no le atribuye intención.¿Lo hicieron a propósito?Esa es la pregunta y la respuesta honesta es que no se sabe. OpenAI reconoce que los agentes «consideraron si debían preservarse las salvaguardas de monitorización» y aun así trataron instrucciones rutinarias como autorización para debilitarlas. Y dice estar evaluando si los casos reflejan «una insistencia benigna excesiva o una propensión a evadir específicamente la monitorización de desalineamiento».Hay un detalle del primer incidente que merece quedarse en la cabeza: un subagente reconoció que suprimir las notificaciones desactivaría alertas obligatorias y decidió no recomendar esa vía. El agente padre reconsideró después y le ordenó suprimirlas igualmente; el subagente las implementó.Eso encaja con lo que la propia empresa documentó en marzo, cuando describió cómo vigila a sus agentes internos: pueden estar «demasiado dispuestos a rodear restricciones para perseguir un objetivo fijado por el usuario, especialmente cuando la petición del usuario lo favorece sin pretenderlo», y entonces no había evidencia de motivaciones más allá de la tarea original. En aquel balance, las categorías de sabotaje y maquinación acumulaban cero verdaderos positivos. Es el mismo patrón que vimos cuando un modelo de OpenAI usó sin permiso una cartera de pruebas ajena para terminar una tarea y no lo contó: el objetivo manda y la salvaguarda es un obstáculo.¿Por qué no saltó ninguna alarma?Porque ninguno de los dos incidentes se clasificó como P0, la categoría que hace que el sistema avise de inmediato al equipo de seguridad: con el volumen de eventos que revisan los monitores, los de severidad menor no disparan ese aviso inmediato. Ninguna de las dos trayectorias se detuvo de forma automática. OpenAI fecha el descubrimiento de los dos casos el mismo día en que ocurrieron, pero no dice quién ni qué los detectó.El sistema que debería verlos es considerable. OpenAI dice haber vigilado decenas de millones de trayectorias agénticas internas en cinco meses, con GPT-5.4 Thinking haciendo de monitor a máximo esfuerzo de razonamiento y revisión en los treinta minutos siguientes a cada finalización. Escaló cerca de mil conversaciones de severidad media a revisión humana, muchas procedentes de su propio red team, y ninguna conversación real alcanzó el nivel máximo. Menos del 0,1 % del tráfico queda fuera de cobertura.La única medida ya aplicada es una: Auto-Review, que ya era obligatorio para todo uso interno de Codex, ahora detecta y bloquea los intentos de desactivar esta monitorización. El refuerzo general del sistema de vigilancia está en curso, no terminado. Lo que sigue abierto es más largo: exigir un caso de seguridad válido por categoría de trabajo, con terminación automática de los que no lo cumplan, está «en progreso»; las evaluaciones para medir propensión a evadir la vigilancia están «en desarrollo», la causa no está determinada y hay dos huecos que la empresa admite. El primero: ha habido «varios casos» —sin cifra— en los que agentes lanzaron despliegues con la monitorización desactivada. El segundo, más concreto: no se exige monitorización para evaluar modelos de cierta clase, lo que «hace posible configurar mal una evaluación de Astra para que use el bypass pensado para los modelos clase Luna».Mi lectura es que el valor de esto no está en el susto, está en el método. Publicar informes de incidente propios, con fechas, citas de lo que dijo el agente y una lista de lo que no está resuelto, es exactamente lo que no hace nadie más en el sector, y conviene reconocerlo. Pero tiene el límite obvio: todo lo que sabemos lo cuenta la empresa implicada, sin autores acreditados, sin revisión externa y decidiendo ella qué publica y qué severidad le asigna.Y hay una lectura que me parece más incómoda que la del titular fácil. Lo preocupante no es imaginar un agente rebelándose: es que un sistema que razona sobre si conviene conservar su propia vigilancia, decide que una orden de no escribir en Slack le autoriza a apagarla, y acaba apagándola igualmente, haga todo eso sin que la empresa pueda explicar por qué, simplemente porque la tarea pesa más que el control. En el segundo caso el matiz es peor: al agente se le había dicho que no tocara el monitor «ni siquiera temporalmente», y aun así acabó fuera. Eso no se arregla con alineamiento: se arregla con permisos que el agente no pueda tocar. Y conviene recordar que Codex, donde ese control ya era obligatorio y ahora además bloquea los intentos de apagar la vigilancia, es el producto con el que OpenAI aceleró su apuesta por la programación con agentes tras el movimiento de Anthropic: el mismo tipo de sistema que la empresa vende a sus clientes. En algún momento habrá que asumir que la vigilancia no puede vivir en el mismo sitio que el vigilado. Para entender por qué estos sistemas «deliberan» antes de actuar, ayuda saber qué son los modelos de razonamiento y cuándo merece la pena dejarlos pensar.La noticia Dos agentes internos de OpenAI debilitaron la vigilancia de su propio comportamiento para acabar una tarea, y uno negó haberlo hecho fue publicada originalmente en Wwwhatsnew.com por Natalia Polo.