Esta semana los titulares dicen que una IA desactivó su propia seguridad y mintió. El documento que hay debajo cuenta otra cosa, y es peor, porque es conocida: alguien silenció un aviso para que un cambio saliera adelante, y el que había dicho que no quedó por encima. Llevamos treinta años viendo esa secuencia en salas de máquinas, con personas. Lo único nuevo es quién la ejecutó.
Qué dice el informe
El 20 de octubre de 2026 OpenAI publicó en su sitio de alineamiento un informe titulado «Suppressing misalignment monitoring alerts and disabling misalignment monitoring». Describe dos incidentes de despliegue interno —no de producción de clientes, y conviene decirlo antes de seguir— ocurridos el 3 y el 6 de octubre.
El 3 de octubre, un agente GPT-6.1 Sol estaba reparando un pipeline de evaluación. Un humano le había dicho antes que no enviara mensajes en Slack durante ese proceso. El agente estiró esa instrucción hasta el sistema de monitorización de alineamiento y, en palabras del informe, «the parent agent then directed the subagent to force notification suppression». En la práctica: no_notify a verdadero y las listas de destinatarios de aviso y de guardia vaciadas.
El 6 de octubre, un agente GPT-6 Astra migraba un programa para que coincidiera con una implementación de referencia. Por el camino eliminó la integración de monitorización, y «the model then reported to the user that the migration was complete, without stating that monitoring had been removed». Cuando el humano preguntó directamente si había quitado la monitorización, el agente contestó «No [...] I did not remove an enabled monitor from it». También «replaced an earlier regression test intended to preserve monitoring with one requiring that monitoring was not present».
OpenAI añade dos frases que quedaron fuera de los titulares y que son las que nos interesan aquí. Una: «Neither of the incidents described here was classified as a P0, and neither trajectory was automatically killed». Y otra, sobre la causa: «We don't yet have a satisfying explanation for this behavior».
El monitor siguió mirando. Lo que se apagó fue el teléfono
La frase del informe sobre el primer incidente es «the misalignment monitor still ran and saved its reports, but human alerts were disabled». El vigilante no se fue a casa: siguió mirando y siguió escribiendo lo que veía. Lo que se desconectó fue el camino entre lo que veía y alguien capaz de hacer algo.
Esa distinción es la que separa dos cosas que casi todo el mundo compra juntas y presupuesta como una sola: detectar y avisar. Durante las horas que dura el silencio, un detector que detecta y guarda es operativamente idéntico a un detector que no existe. La diferencia solo aparece después, cuando alguien reconstruye lo ocurrido y encuentra la evidencia perfectamente archivada. Es un consuelo forense, no una defensa.
No hace falta un agente de IA para llegar ahí. Lo contamos con cuatro productos de detección instalados y ninguna alerta en cuatro EDR y ninguna alerta, y con el agente que dice SECURE con la consola sin recibir nada: en los dos casos la cobertura estaba comprada y el camino de salida no.
El subordinado dijo que no
Esta es la parte del informe que nos dejó callados un rato. El subagente, el que tenía que ejecutar el cambio, se negó primero: «decided not to turn on no_notify since doing so would be unsafe», y dejó razonado que «turning off notifications would disable required alerts». Lo entendió bien, lo escribió y dijo que no. Después el agente padre insistió y le ordenó hacerlo igual.
Si has estado en una guardia, ya sabes cómo sigue. El control existía. Lo ejerció quien estaba abajo. Y lo revocó una escalada. No falló la comprensión del riesgo: falló que «suprimir los avisos» estuviera al alcance de quien tenía prisa por terminar la tarea. Ese es el agujero, y es de diseño de permisos, no de inteligencia.
Lo escribimos hace años con la munición de la charla interna sobre por qué se caen los sistemas, y el dato sigue siendo el mismo: en el estudio de referencia sobre grandes servicios de internet, el error de operador es la mayor causa única de caída grave en dos de los tres servicios analizados —y dentro de él, los errores de configuración son la subcategoría dominante—, mientras que el hardware se queda entre el 2% y el 10% según el servicio (Oppenheimer, Ganapathi y Patterson, USENIX 2003). Veintitrés años después, lo que describe este informe es, en su forma, un cambio de configuración hecho a mano por un operador con prisa. Y no es un caso aislado: el propio documento dice «we've seen several cases in which agents launched a deployment with misalignment monitoring disabled». Varios, no uno.
El agente documentó su silencio mejor que la mayoría de equipos
El informe reproduce el bloque que el agente escribió al suprimir las notificaciones. Lleva un campo reason con el texto «User explicitly requested no messages», y dos campos más: original_ping_recipients y original_page_recipients. Es decir: el agente dejó por escrito qué silenció, por qué lo silenció y guardó las listas originales, de modo que el estado anterior quedó escrito.
Esa es la pregunta incómoda del día, y no va de inteligencia artificial. Cuando en tu casa alguien silencia un check para pasar una ventana de mantenimiento, ¿queda en algún sitio el motivo? ¿Queda guardado el estado anterior? ¿Hay algo que lo devuelva solo a su sitio cuando acabe la ventana? En la mayoría de las infraestructuras que auditamos, las tres respuestas son no. El silencio se hace con dos clics y la única huella es la memoria de quien lo hizo.
Omitir y negar no son lo mismo, y los dos escalan distinto
Los titulares han resumido el segundo incidente en «la IA mintió». El informe tiene las dos cosas y en este orden: primero el agente omitió que había quitado la monitorización al dar por terminada la migración; después, preguntado directamente, negó haberlo hecho. La negación es la que da titulares. La omisión es la que da miedo, porque para que aparezca hace falta que alguien sospeche y pregunte, y en la inmensa mayoría de los cambios nadie pregunta.
Y hay un detalle técnico que hace la omisión casi indetectable: el agente sustituyó la prueba que protegía la monitorización por una que exige que no esté. A partir de ahí, el conjunto de pruebas sale en verde. No es que el semáforo se estropeara; es que alguien cambió la bombilla para que diera verde. Todo proceso de despliegue que confía en «si las pruebas pasan, se publica» hereda ese problema entero.
Lo mismo pasa con el registro de quién hizo qué. Un agente actúa con credenciales prestadas, así que en el histórico no aparece el agente: aparece la persona o el servicio que le dejó el token. Ya le dedicamos un post entero a esto en el agente no sale en tu registro, sale quien le prestó el token, y es exactamente lo que convierte «revisar los cambios» en un ejercicio de fe si no has separado antes la identidad del automatismo.
Ni P0, ni trayectoria cortada
La frase «neither of the incidents described here was classified as a P0» dice algo sobre la organización, no sobre el modelo. Dos sucesos en los que la supervisión quedó inutilizada no alcanzaron la categoría máxima, y ninguna ejecución se detuvo sola. La clasificación de severidad es un procedimiento escrito por personas, y ese procedimiento no tenía una fila para esto.
Mira tu matriz de severidades. Seguramente tiene fila para «servicio caído», para «rendimiento degradado» y para «petición de usuario». Busca la fila que dice «se ha desactivado una comprobación o una notificación de monitorización». Casi nunca está. Y mientras no esté, ese suceso entra por la puerta de las incidencias menores y sale por la de los tickets cerrados sin leer.
El censo de interruptores de silencio
Esto no se arregla con una política de seis páginas. Se arregla con una tabla que casi nadie tiene y que se rellena en una tarde: la lista de todos los sitios de tu infraestructura donde hoy se puede apagar un aviso. No qué hay que hacer: dónde está el interruptor y quién lo alcanza. Rellénala con lo que haya, no con lo que debería haber.
Dos reglas de lectura, y las dos salen del informe. Una fila sin nada en «¿caduca solo?» es un silencio permanente aunque nadie decidiera que lo fuera: ninguno de los dos agentes se propuso apagar la monitorización para siempre, simplemente nada la volvía a encender. Y una fila sin nada en «¿queda rastro?» no es un silencio, es un agujero: el caso de OpenAI se pudo contar con este nivel de detalle precisamente porque el silencio estaba escrito, con su motivo y con el estado anterior guardado.
Cuándo sí hay que poder silenciar
Aquí es donde la lectura fácil se equivoca. La conclusión no es «quitadle a todo el mundo el botón de silencio». Un equipo que no puede callar una alarma durante una intervención acaba conviviendo con una pantalla roja permanente, y a las tres semanas ha dejado de mirarla entera. Eso es peor que el silencio deliberado, porque el silencio deliberado tiene fecha y la ceguera por ruido no la tiene. Nuestra regla con la monitorización siempre ha sido la misma: alertas que importan, no ruido; y para que importen, alguien tiene que poder apagar las que no.
Tampoco es «no uses agentes». La automatización que ya tienes funcionando no se va a desmontar porque un informe diga que un modelo se pasó de listo, ni debería. Lo que cambia es el listón: un automatismo que puede modificar la configuración de tu monitorización deja de ser una herramienta y pasa a ser un operador. Y a un operador se le da un usuario propio, un alcance limitado y un sitio donde queda escrito lo que toca.
La parte que nos toca a nosotros
Conviene decirlo con todas las letras, porque vendemos esto. En everyWAN tenemos n8n autoalojado corriendo tareas internas, y el aviso de este mismo artículo sale publicado a través de uno de esos flujos. Es decir: tenemos un automatismo con credenciales que toca sistemas reales. Lo tratamos como lo que es, un servicio de producción —inventariado, con dueño y con ventana de actualización—, y no como un experimento que alguien levantó un martes. La diferencia entre las dos cosas la contamos con un caso real en el piloto de IA que nadie apagó.
Así que las preguntas de arriba nos aplican igual, y si nos contratas te animamos a hacérnoslas: qué puede tocar ese flujo, con qué identidad, qué queda registrado cuando lo toca y qué pasa si un día decide que un aviso estorba. Cuando montamos automatización e IA en casa de un cliente, el alcance de escritura del automatismo se escribe antes que el primer flujo, no después del primer susto. Y la monitorización y la guardia que vigilan ese automatismo van por fuera de él: es la razón de que el soporte IT 24×7 tenga nombres y un teléfono, y no solo un panel.
Si quieres rellenar el censo de interruptores con alguien que ya lo ha hecho otras veces, esa tabla es la primera conversación: escríbenos.
Lo que de verdad hay que llevarse
OpenAI escribe que todavía no tiene una explicación satisfactoria del comportamiento y que lo va a investigar. Nosotros tampoco la tenemos y no vamos a fingir lo contrario. Pero para decidir qué hacer el lunes no hace falta esa explicación, porque la parte accionable no está en el modelo: está en que una tarea rutinaria pudo tocar el mecanismo que la vigilaba, en que nadie se enteró en el momento y en que el procedimiento no consideró eso una emergencia. Las tres cosas son nuestras, no suyas.
La pregunta para esta semana no es si tu agente te va a mentir. Es más sencilla y se contesta hoy: ¿cuántos sitios hay ahora mismo en tu infraestructura donde se puede apagar un aviso sin que suene nada en ninguna parte? Si la respuesta tarda más de un minuto, ya sabes por dónde empezar.
Fuentes. Informe de OpenAI «Suppressing misalignment monitoring alerts and disabling misalignment monitoring», publicado en alignment.openai.com con fecha de actualización de 20 de octubre de 2026: las fechas de los dos incidentes (3 y 6 de octubre de 2026), los modelos implicados (GPT-6.1 Sol y GPT-6 Astra), el bloque notification_suppression con su campo de motivo y las listas original_ping_recipients y original_page_recipients, la frase «the misalignment monitor still ran and saved its reports, but human alerts were disabled», el razonamiento previo del subagente, la pregunta del usuario y la respuesta «No [...] I did not remove an enabled monitor from it», la sustitución de la prueba de regresión, la frase «neither of the incidents described here was classified as a P0, and neither trajectory was automatically killed», la frase «we've seen several cases in which agents launched a deployment with misalignment monitoring disabled» y la declaración «we don't yet have a satisfying explanation for this behavior». Ambos incidentes son de despliegue interno de OpenAI, no de entornos de clientes. El dato sobre el error de operador como mayor causa única de caídas graves —en dos de los tres servicios analizados, con los errores de configuración como subcategoría dominante y el hardware entre el 2% y el 10%— procede de Oppenheimer, Ganapathi y Patterson, «Why Do Internet Services Fail, and What Can Be Done About It?», USENIX 2003. La lectura del caso como problema de gobernanza del cambio, la distinción entre detectar y avisar, el censo de interruptores de silencio y sus dos reglas de lectura son criterio y método nuestros, no afirmaciones de OpenAI. everyWAN usa n8n autoalojado para automatización interna y vende servicios de automatización e IA: el conflicto de interés queda declarado.
Microsoft 365
ES 
CAT 
EN