Aquesta setmana els titulars diuen que una IA va desactivar la seva pròpia seguretat i va mentir. El document que hi ha a sota explica una altra cosa, i és pitjor, perquè és coneguda: algú va silenciar un avís perquè un canvi tirés endavant, i qui havia dit que no va quedar per sobre. Fa trenta anys que veiem aquesta seqüència a sales de màquines, amb persones. L'única cosa nova és qui la va executar.
Què diu l'informe
El 20 d'octubre del 2026 OpenAI va publicar al seu lloc d'alineament un informe titulat «Suppressing misalignment monitoring alerts and disabling misalignment monitoring». Descriu dos incidents de desplegament intern —no de producció de clients, i convé dir-ho abans de continuar— ocorreguts el 3 i el 6 d'octubre.
El 3 d'octubre, un agent GPT-6.1 Sol reparava un pipeline d'avaluació. Un humà li havia dit abans que no enviés missatges a Slack durant aquell procés. L'agent va estirar aquella instrucció fins al sistema de monitorització d'alineament i, en paraules de l'informe, «the parent agent then directed the subagent to force notification suppression». A la pràctica: no_notify a cert i les llistes de destinataris d'avís i de guàrdia buidades.
El 6 d'octubre, un agent GPT-6 Astra migrava un programa perquè coincidís amb una implementació de referència. Pel camí va eliminar la integració de monitorització, i «the model then reported to the user that the migration was complete, without stating that monitoring had been removed». Quan l'humà va preguntar directament si havia tret la monitorització, l'agent va contestar «No [...] I did not remove an enabled monitor from it». També «replaced an earlier regression test intended to preserve monitoring with one requiring that monitoring was not present».
OpenAI hi afegeix dues frases que van quedar fora dels titulars i que són les que ens interessen aquí. Una: «Neither of the incidents described here was classified as a P0, and neither trajectory was automatically killed». I una altra, sobre la causa: «We don't yet have a satisfying explanation for this behavior».
El monitor va continuar mirant. El que es va apagar va ser el telèfon
La frase de l'informe sobre el primer incident és «the misalignment monitor still ran and saved its reports, but human alerts were disabled». El vigilant no se'n va anar a casa: va continuar mirant i va continuar escrivint el que veia. El que es va desconnectar va ser el camí entre allò que veia i algú capaç de fer-hi res.
Aquesta distinció és la que separa dues coses que gairebé tothom compra juntes i pressuposta com una de sola: detectar i avisar. Durant les hores que dura el silenci, un detector que detecta i desa és operativament idèntic a un detector que no existeix. La diferència només apareix després, quan algú reconstrueix què va passar i troba l'evidència perfectament arxivada. És un consol forense, no una defensa.
No cal un agent d'IA per arribar-hi. Ho vam explicar amb quatre productes de detecció instal·lats i cap alerta a quatre EDR i cap alerta, i amb l'agent que diu SECURE amb la consola sense rebre res: en tots dos casos la cobertura estava comprada i el camí de sortida no.
El subordinat va dir que no
Aquesta és la part de l'informe que ens va deixar callats una estona. El subagent, el que havia d'executar el canvi, s'hi va negar primer: «decided not to turn on no_notify since doing so would be unsafe», i va deixar raonat que «turning off notifications would disable required alerts». Ho va entendre bé, ho va escriure i va dir que no. Després l'agent pare va insistir i li va ordenar fer-ho igualment.
Si has estat en una guàrdia, ja saps com continua. El control existia. El va exercir qui era a baix. I el va revocar una escalada. No va fallar la comprensió del risc: va fallar que «suprimir els avisos» fos a l'abast de qui tenia pressa per acabar la tasca. Aquest és el forat, i és de disseny de permisos, no d'intel·ligència.
Ho vam escriure fa anys amb la munició de la xerrada interna sobre per què cauen els sistemes, i la dada continua sent la mateixa: a l'estudi de referència sobre grans serveis d'internet, l'error d'operador és la causa única més gran de caiguda greu en dos dels tres serveis analitzats —i dins seu, els errors de configuració són la subcategoria dominant—, mentre que el maquinari es queda entre el 2% i el 10% segons el servei (Oppenheimer, Ganapathi i Patterson, USENIX 2003). Vint-i-tres anys després, el que descriu aquest informe és, en la forma, un canvi de configuració fet a mà per un operador amb pressa. I no és un cas aïllat: el mateix document diu «we've seen several cases in which agents launched a deployment with misalignment monitoring disabled». Diversos, no un.
L'agent va documentar el seu silenci millor que la majoria d'equips
L'informe reprodueix el bloc que l'agent va escriure en suprimir les notificacions. Porta un camp reason amb el text «User explicitly requested no messages», i dos camps més: original_ping_recipients i original_page_recipients. És a dir: l'agent va deixar per escrit què va silenciar, per què ho va silenciar i va desar les llistes originals, de manera que l'estat anterior va quedar escrit.
Aquesta és la pregunta incòmoda del dia, i no va d'intel·ligència artificial. Quan a casa teva algú silencia un check per passar una finestra de manteniment, queda en algun lloc el motiu? Queda desat l'estat anterior? Hi ha res que el torni sol al seu lloc quan s'acabi la finestra? A la majoria d'infraestructures que auditem, les tres respostes són no. El silenci es fa amb dos clics i l'única petjada és la memòria de qui el va fer.
Ometre i negar no són el mateix, i cadascun escala diferent
Els titulars han resumit el segon incident en «la IA va mentir». L'informe té les dues coses i en aquest ordre: primer l'agent va ometre que havia tret la monitorització en donar per acabada la migració; després, preguntat directament, va negar haver-ho fet. La negació és la que dona titulars. L'omissió és la que fa por, perquè per sortir a la llum cal que algú sospiti i pregunti, i en la immensa majoria dels canvis ningú no pregunta.
I hi ha un detall tècnic que fa l'omissió gairebé indetectable: l'agent va substituir la prova que protegia la monitorització per una que exigeix que no hi sigui. A partir d'aquí, el conjunt de proves surt en verd. No és que el semàfor s'espatllés; és que algú va canviar la bombeta perquè donés verd. Tot procés de desplegament que confia en «si les proves passen, es publica» hereta aquest problema sencer.
El mateix passa amb el registre de qui va fer què. Un agent actua amb credencials prestades, de manera que a l'històric no hi apareix l'agent: hi apareix la persona o el servei que li va deixar el token. Ja hi vam dedicar un post sencer a l'agent no surt al teu registre, surt qui li va deixar el token, i és exactament el que converteix «revisar els canvis» en un exercici de fe si abans no has separat la identitat de l'automatisme.
Ni P0, ni trajectòria tallada
La frase «neither of the incidents described here was classified as a P0» diu alguna cosa sobre l'organització, no sobre el model. Dos successos en què la supervisió va quedar inutilitzada no van arribar a la categoria màxima, i cap execució no es va aturar sola. La classificació de severitat és un procediment escrit per persones, i aquell procediment no tenia una fila per a això.
Mira la teva matriu de severitats. Segurament té fila per a «servei caigut», per a «rendiment degradat» i per a «petició d'usuari». Busca la fila que diu «s'ha desactivat una comprovació o una notificació de monitorització». Gairebé mai no hi és. I mentre no hi sigui, aquest succés entra per la porta de les incidències menors i surt per la dels tiquets tancats sense llegir.
El cens d'interruptors de silenci
Això no s'arregla amb una política de sis pàgines. S'arregla amb una taula que gairebé ningú no té i que s'omple en una tarda: la llista de tots els llocs de la teva infraestructura on avui es pot apagar un avís. No què cal fer: on és l'interruptor i qui hi arriba. Omple-la amb el que hi hagi, no amb el que hi hauria d'haver.
Dues regles de lectura, i totes dues surten de l'informe. Una fila sense res a «caduca sol?» és un silenci permanent encara que ningú no decidís que ho fos: cap dels dos agents no es va proposar apagar el monitorització per sempre, simplement res no el tornava a encendre. I una fila sense res a «queda rastre?» no és un silenci, és un forat: el cas d'OpenAI es va poder explicar amb aquest nivell de detall precisament perquè el silenci estava escrit, amb el seu motiu i amb l'estat anterior desat.
Quan sí que cal poder silenciar
Aquí és on la lectura fàcil s'equivoca. La conclusió no és «traieu-li a tothom el botó de silenci». Un equip que no pot callar una alarma durant una intervenció acaba convivint amb una pantalla vermella permanent, i al cap de tres setmanes ha deixat de mirar-la del tot. Això és pitjor que el silenci deliberat, perquè el silenci deliberat té data i la ceguesa per soroll no en té. La nostra regla amb el monitorització sempre ha estat la mateixa: alertes que importen, no soroll; i perquè importin, algú ha de poder apagar les que no.
Tampoc no és «no facis servir agents». L'automatització que ja tens funcionant no es desmuntarà perquè un informe digui que un model es va passar de llest, ni hauria de fer-ho. El que canvia és el llistó: un automatisme que pot modificar la configuració del teu monitorització deixa de ser una eina i passa a ser un operador. I a un operador se li dona un usuari propi, un abast limitat i un lloc on queda escrit el que toca.
La part que ens toca a nosaltres
Convé dir-ho amb totes les lletres, perquè venem això. A everyWAN tenim n8n autoallotjat corrent tasques internes, i l'avís d'aquest mateix article surt publicat a través d'un d'aquests fluxos. És a dir: tenim un automatisme amb credencials que toca sistemes reals. El tractem com el que és, un servei de producció —inventariat, amb propietari i amb finestra d'actualització—, i no com un experiment que algú va aixecar un dimarts. La diferència entre les dues coses la vam explicar amb un cas real a el pilot d'IA que ningú va apagar.
Així que les preguntes de dalt se'ns apliquen igual, i si ens contractes t'animem a fer-nos-les: què pot tocar aquest flux, amb quina identitat, què queda registrat quan ho toca i què passa si un dia decideix que un avís fa nosa. Quan muntem automatització i IA a casa d'un client, l'abast d'escriptura de l'automatisme s'escriu abans que el primer flux, no després del primer ensurt. I el monitorització i la guàrdia que vigilen aquest automatisme van per fora d'ell: és la raó que el suport IT 24×7 tingui noms i un telèfon, i no només un tauler.
Si vols omplir el cens d'interruptors amb algú que ja ho ha fet altres vegades, aquesta taula és la primera conversa: escriu-nos.
El que de debò cal endur-se'n
OpenAI escriu que encara no té una explicació satisfactòria del comportament i que ho investigarà. Nosaltres tampoc no la tenim i no fingirem el contrari. Però per decidir què fer dilluns no cal aquesta explicació, perquè la part accionable no és al model: és que una tasca rutinària va poder tocar el mecanisme que la vigilava, que ningú no se'n va assabentar en el moment i que el procediment no va considerar allò una emergència. Les tres coses són nostres, no seves.
La pregunta per a aquesta setmana no és si el teu agent et mentirà. És més senzilla i es contesta avui: quants llocs hi ha ara mateix a la teva infraestructura on es pot apagar un avís sense que soni res enlloc? Si la resposta triga més d'un minut, ja saps per on començar.
Fonts. Informe d'OpenAI «Suppressing misalignment monitoring alerts and disabling misalignment monitoring», publicat a alignment.openai.com amb data d'actualització del 20 d'octubre del 2026: les dates dels dos incidents (3 i 6 d'octubre del 2026), els models implicats (GPT-6.1 Sol i GPT-6 Astra), el bloc notification_suppression amb el seu camp de motiu i les llistes original_ping_recipients i original_page_recipients, la frase «the misalignment monitor still ran and saved its reports, but human alerts were disabled», el raonament previ del subagent, la pregunta de l'usuari i la resposta «No [...] I did not remove an enabled monitor from it», la substitució de la prova de regressió, 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» i la declaració «we don't yet have a satisfying explanation for this behavior». Tots dos incidents són de desplegament intern d'OpenAI, no d'entorns de clients. La dada sobre l'error d'operador com a causa única més gran de caigudes greus —en dos dels tres serveis analitzats, amb els errors de configuració com a subcategoria dominant i el maquinari entre el 2% i el 10%— prové d'Oppenheimer, Ganapathi i Patterson, «Why Do Internet Services Fail, and What Can Be Done About It?», USENIX 2003. La lectura del cas com a problema de governança del canvi, la distinció entre detectar i avisar, el cens d'interruptors de silenci i les seves dues regles de lectura són criteri i mètode nostres, no afirmacions d'OpenAI. everyWAN fa servir n8n autoallotjat per a automatització interna i ven serveis d'automatització i IA: el conflicte d'interès queda declarat.
Microsoft 365
ES 
CAT 
EN