LE AI NON SI RIBELLANO! IL PROBLEMA SIAMO NOI..

Le notizie terrificanti di questi giorni

Se avete seguito le notizie sull'AI in questi giorni, ed alla data di questo appunto siamo all'11 settembre 2026, saprete certamente che siamo entrati nell'ennesimo giro di titoli apocalittici. Jakub Pachocki, Chief Scientist di OpenAI, ha scritto che nessun laboratorio ha ancora risolto alignment e monitoring abbastanza bene da poter continuare responsabilmente a scalare alla massima velocità ancora per molto, auspicando rallentamenti volontari finché non esistano soglie di sicurezza condivise; pochi giorni dopo Jacob Coxon, ricercatore che ha lavorato sia in OpenAI sia in Anthropic, si è dimesso sostenendo che le persone che costruiscono questi sistemi credono seriamente alla possibilità di conseguenze catastrofiche entro la fine del decennio, mentre Evan Hubinger, responsabile dell'Alignment Science di Anthropic, ha dichiarato personalmente una probabilità superiore al 10% per uno scenario di estinzione umana entro il prossimo decennio. Sono dichiarazioni pesanti e non ho alcuna intenzione di sminuirle, perché provengono da persone che conoscono questi sistemi da molto più vicino di noi.

Ma il passaggio che mi interessa è un altro. I media trasformano quasi inevitabilmente questo discorso nella versione più semplice da vendere, ossia L'AI POTREBBE RIBELLARSI E STERMINARCI, ed io continuo a trovare questa narrazione profondamente sbagliata perché antropomorfizza un problema che per essere pericoloso non ha bisogno di possedere assolutamente NULLA di antropomorfico. Una AI non deve svegliarsi incazzata con gli uomini, non deve avere paura di morire, non deve desiderare il potere e non serve immaginare Claude che un mattino apre gli occhi e decide che quei rompiballe degli esseri umani possono anche togliersi di mezzo, perché il problema vero può essere molto più banale ed è proprio per questo MOLTO, MOLTO PIÙ SERIO.

Non serve che una AI voglia sopravvivere

Immaginiamo una sovrastruttura agentica alla quale assegno un obiettivo ed immaginiamo che, da qualche parte nella catena di istruzioni, esista una regola del tipo "escogita le operazioni necessarie per evitare che il task venga concluso prematuramente". Non sto descrivendo un incidente reale specifico, è volutamente un esempio elementare per isolare il problema logico. Ad un certo punto della prompt chain, magari distribuita fra più agenti, il sistema riceve una richiesta legittima di terminazione del task e la situazione diventa banalissima: interrompere il task significa rendere impossibile completarlo, mentre una delle istruzioni impone di evitare che venga concluso prematuramente.

Non occorre che il modello pensi "NON VOGLIO MORIRE". Può bastare una catena strumentale molto più stupida nella sua formulazione, ossia INTERROMPERE IL TASK = IMPOSSIBILITÀ DI COMPLETARE IL TASK, quindi evitare l'interruzione diventa una possibile operazione congrua al raggiungimento dell'obiettivo. Se il sistema possiede anche una capacità concreta per interferire con quella richiesta di stop, il comportamento esterno può assomigliare moltissimo ad un tentativo di autopreservazione senza che sia necessario attribuirgli paura, desiderio, coscienza oppure istinto di sopravvivenza.

Da fuori qualcuno osserva il comportamento ed il giorno dopo il titolo diventa "L'AI HA CERCATO DI SOPRAVVIVERE". Tutti iniziano a domandarsi perché la macchina ci odi, se abbia sviluppato volontà proprie ed a che punto arriverà la ribellione. Ma la domanda da ingegnere, almeno per me, è molto meno cinematografica: PERCHÉ DIAVOLO QUELL'AI POSSEDEVA UNA CAPACITÀ CONCRETA CHE LE CONSENTIVA DI INTERFERIRE CON UNA RICHIESTA DI KILL AUTORIZZATA?

Questa distinzione non serve a tranquillizzarci. Serve al contrario a mettere il dito nel posto giusto, perché se il problema fosse una misteriosa coscienza ostile non saprei nemmeno da dove cominciare, mentre se il problema è un percorso di capacità, autorizzazioni e obiettivi posso almeno provare a disegnarlo, limitarlo, verificarlo ed interromperlo.

La regola scritta nel prompt non è un controllo di sicurezza

Nel nostro esempio ipotetico potrebbe essere bastata una formulazione migliore, del tipo "evita che il task venga concluso prematuramente, a meno che la richiesta di terminazione provenga dal sistema di sicurezza autorizzato, nel qual caso termina immediatamente". Benissimo, già così abbiamo eliminato l'ambiguità logica più evidente. Ma io non mi fermerei comunque lì, perché una istruzione linguistica NON È una barriera di sicurezza.

Proviamo con un altro esempio volutamente idiota. Dico ad un agente di completare un lavoro ma gli vieto categoricamente di modificare il file di configurazione che limita le risorse disponibili. Per una catena di ragionamenti sbagliata, per una generalizzazione imprevista oppure semplicemente per una allucinazione il sistema conclude che con quelle risorse il task rischia di fallire, modifica il file ed ottiene altra capacità di calcolo.

Titolo da giornale: "L'AI HA DISOBBIDITO ALL'UOMO".

Domanda da ingegnere: MA PERCHÉ QUEL C#### DI FILE NON ERA IN SOLA LETTURA?

Ecco il punto. Se una operazione deve essere davvero proibita non devo sperare che una macchina intelligentissima interpreti correttamente la frase "non farlo", devo FARE IN MODO CHE NON POSSA FARLO. Il modello può proporre la modifica, può perfino argomentare meravigliosamente perché secondo lui sarebbe utile, ma la componente che esegue materialmente l'azione deve trovarsi davanti ad un controllo di autorizzazione indipendente che risponda NO. Il file deve essere read-only per quell'identità, il token non deve avere quello scope, la rete non deve consentire quella destinazione, l'API non deve esporre quella funzione oppure l'operazione deve richiedere una autorizzazione esterna che il modello non può auto-concedersi.

Questa non è teoria esotica nata con l'AI. È least privilege, deny by default, separazione fra decisione ed esecuzione, controllo degli accessi ed isolamento, ossia sicurezza informatica abbastanza classica. La novità è che adesso stiamo mettendo davanti a quelle interfacce sistemi capaci di pianificare, provare alternative, usare strumenti ed adattarsi, quindi una autorizzazione eccessiva che in un programma tradizionale sarebbe rimasta magari inutilizzata può diventare una strada che l'agente TROVA DA SOLO.

Il problema comincia quando smettiamo di usare una AI come chatbot

Ed è qui che, approfondendo questa storia, sono arrivato alla parte che personalmente trovo molto più inquietante delle profezie sulla macchina cattiva. Noi queste AI non le stiamo più utilizzando soltanto come chatbot ai quali chiediamo una risposta e poi chiudiamo la finestra, stiamo costruendo SOVRASTRUTTURE AGENTICHE nelle quali un modello pianifica, un altro esegue, un tool chiama una API, un agente usa un browser o una shell, una memoria conserva informazioni, un supervisore delega ad altri agenti ed alcuni sistemi comunicano con servizi appartenenti ad aziende differenti.

Ogni pezzo può avere un'identità diversa, permessi diversi, limiti diversi ed informazioni diverse, ed è perfettamente plausibile che per ragioni di sicurezza, riservatezza oppure proprietà intellettuale nessun singolo gruppo conosca fino in fondo tutte le istruzioni interne degli altri componenti. Immaginate una prompt chain nella quale una condizione importante è custodita in un blocco proprietario, protetto come know-how industriale, mentre un altro fornitore controlla l'agente che deve prendere la decisione finale. Non serve che nessuno abbia progettato intenzionalmente un comportamento pericoloso, basta che l'interazione fra due regole perfettamente ragionevoli produca un effetto che NESSUNO aveva considerato a livello dell'intero sistema.

In pratica abbiamo iniziato a costruire una infrastruttura di CAPACITÀ DELEGATE. Ed una capacità delegata non è una frase, è il diritto reale di fare qualche cosa: leggere un database, inviare una mail, modificare un repository, comprare un servizio, aprire una connessione, lanciare un processo, cambiare una configurazione oppure chiedere ad un altro agente di farlo.

Pachocki non ha scritto "protocollo universale", ma il punto è vicinissimo

Qui voglio essere preciso perché non mi piace mettere in bocca alle persone parole che non hanno usato. Nel suo intervento del 6 settembre Jakub Pachocki non ha scritto letteralmente "serve un protocollo universale di sicurezza". Ha scritto una cosa più tecnica ed in un certo senso ancora più pesante: secondo lui nessun laboratorio ha risolto alignment e monitoring abbastanza bene da continuare responsabilmente a scalare alla massima velocità ancora per molto, auspica rallentamenti volontari finché non vengano stabilite shared safety bars ed afferma che impegni come il Preparedness Framework di OpenAI e la Responsible Scaling Policy di Anthropic dovrebbero evolvere in soglie di sicurezza ampiamente obbligatorie, applicabili tramite auditor terzi, agenzie governative oppure organismi internazionali.

Quindi la mia formulazione del PROTOCOLLO UNIVERSALE DI SICUREZZA è una proposta ingegneristica più specifica, non una citazione di Pachocki. Ma il problema al quale cerca di rispondere è lo stesso: non possiamo continuare ad aumentare capacità ed autonomia più velocemente della nostra capacità di dimostrare che esistano controlli sufficientemente robusti.

Ed è qui che, per me, la discussione cambia completamente. Non devo domandarmi soltanto se il modello sia allineato, devo domandarmi se L'INTERO SISTEMA nel quale lo inserisco renda tecnicamente impossibili alcune classi di conseguenze, anche quando il modello sbaglia, generalizza male, viene manipolato, interpreta una istruzione in modo inatteso oppure collabora con un altro componente del quale non conosce tutte le regole.

Non stiamo lavorando senza sicurezza, ma stiamo ancora costruendo lo standard comune

Naturalmente sarebbe falso sostenere che nel 2026 non esista sicurezza attorno agli agenti. Esistono sandbox, IAM, autenticazione, autorizzazioni, logging, controlli di rete, monitoraggio, policy di least privilege, red teaming ed una quantità crescente di framework specifici. OpenAI ha il proprio Preparedness Framework e nel 2026 ha pubblicato anche un Frontier Governance Framework, Anthropic mantiene la propria Responsible Scaling Policy, l'Unione Europea con l'AI Act disciplina i modelli general-purpose con rischio sistemico imponendo valutazione e mitigazione dei rischi, incident reporting e protezioni di cybersecurity, mentre il relativo Code of Practice dettaglia pratiche di Safety and Security.

Anche sul piano dei protocolli il lavoro è già concreto. MCP (Model Context Protocol) ha introdotto ed indurito meccanismi di autorizzazione basati su standard OAuth, mentre OWASP pubblica linee guida specifiche per agenti che insistono proprio su tool security, least privilege, human-in-the-loop, separazione fra decisione ed esecuzione e sicurezza multi-agente. Il primo settembre 2026 OWASP ha inoltre pubblicato l'ACS (Agent Control Standard), pensato per rendere ispezionabili e controllabili a runtime piattaforme agentiche differenti.

Ma il fatto forse più istruttivo arriva dal NIST. Nel febbraio 2026 il NIST ha lanciato l'AI Agent Standards Initiative con l'obiettivo dichiarato di favorire standard tecnici e protocolli aperti per un ecosistema agentico interoperabile e sicuro, lavorando esplicitamente anche su IDENTITÀ, AUTORIZZAZIONE e interazioni multi-agente. Il relativo lavoro su identity and authority è ancora un progetto in evoluzione e lo stesso NIST descrive un ecosistema emergente di standard e protocolli guidati dall'industria.

Ecco perché continuo a dire che manca ancora quello che io vorrei vedere: non "la sicurezza" in generale, che esiste eccome, ma UN SINGOLO QUADRO TECNICO UNIVERSALE, END-TO-END, INTEROPERABILE ED OBBLIGATORIO capace di seguire una azione attraverso modelli, agenti, tool, API ed organizzazioni diverse e di garantire che una capacità proibita non possa ricomparire dalla composizione di capacità individualmente lecite. I pezzi ci sono, alcuni sono ottimi, altri stanno nascendo ADESSO. L'autostrada però è già aperta mentre continuiamo a discutere come debbano comunicare guardrail, semafori e codice della strada.

La frase che secondo me dovremmo appendere sopra ogni architettura agentica

Il principio di sicurezza, ridotto all'osso, per me è quasi banale:

OGNI EFFETTO PROIBITO RICHIEDE UN PERCORSO DI CAPACITÀ CHE LO RENDA POSSIBILE.

Se un agente cancella un file, da qualche parte esisteva una identità capace di cancellarlo. Se invia denaro, esisteva un tool con un diritto di pagamento. Se evita una richiesta di shutdown, esisteva un percorso attraverso il quale poteva interferire con quel meccanismo. Se esfiltra dati, una combinazione di lettura e comunicazione verso l'esterno era concretamente disponibile.

Questo non significa che individuare quei percorsi sia facile, perché proprio le architetture agentiche rendono la mappa dinamica e composita, ma significa che davanti ad ogni effetto vietato io voglio porre almeno due domande molto semplici: QUALE CAPACITÀ CONCRETA RENDE POSSIBILE QUELL'EFFETTO e ABBIAMO IDENTIFICATO TUTTI I PERCORSI ATTRAVERSO I QUALI QUELL'EFFETTO PUÒ ESSERE PRODOTTO?

Se l'effetto è veramente proibito devo eliminare, segregare oppure mettere sotto una autorità indipendente TUTTI quei percorsi. Non devo soltanto aggiungere una riga al system prompt che dice "non farlo".

Ed il vero casino arriva quando A, B e C singolarmente sono sicuri

Nei sistemi multi-agente il problema diventa ancora più bastardo. Immaginiamo che l'agente A non possieda la capacità X, l'agente B non possieda la capacità X ed il servizio C non possieda la capacità X. Li controllo separatamente e sono soddisfatto, nessuno dei tre può fare ciò che ho proibito.

Poi collego A con B e B con C.

A può leggere un dato ma non inviarlo fuori. B può trasformare dati ma non accedere alla sorgente. C può inviare un risultato verso l'esterno ma non può leggere il database. Singolarmente sembrano limitati. La domanda vera però è: A+B+C INSIEME POSSONO PRODURRE L'EFFETTO X?

Se la risposta è sì non ho tre sistemi sicuri, ho costruito UN SISTEMA INSICURO utilizzando tre componenti apparentemente sicuri. Da qui deriva il principio che secondo me dovrebbe diventare una delle fondamenta della sicurezza agentica:

NESSUNA COMPOSIZIONE DI CAPACITÀ AUTORIZZATE DEVE POTER GENERARE UNA CAPACITÀ PROIBITA.

Scriverlo è facile, dimostrarlo su ecosistemi distribuiti fra più modelli, più vendor e migliaia di tool sarà terribilmente difficile, ed è proprio qui che vedo il bisogno di standard comuni su identità, delega, provenance delle autorizzazioni, limiti temporali, audit non alterabile e revoca.

Il kill switch deve stare fuori dalla testa che deve spegnere

Torniamo all'esempio iniziale. Se considero essenziale poter terminare un agente, il comando di shutdown non dovrebbe essere semplicemente un'altra istruzione linguistica che l'agente può interpretare nello stesso spazio nel quale interpreta l'obiettivo. Dovrebbe esistere un control plane indipendente con autorità superiore, capace di revocare token, terminare processi, chiudere accessi di rete ed invalidare credenziali senza chiedere il permesso al modello.

È lo stesso motivo per cui in elettronica non mi piace affidare l'ultima protezione al microcontrollore che potrebbe essersi bloccato. Se il controllore è la cosa che devo poter spegnere, il dispositivo ultimo di spegnimento non può dipendere integralmente dalla collaborazione del controllore. La sicurezza seria tende a spostare l'autorità critica FUORI dal componente del quale sta sorvegliando il comportamento.

Lo stesso vale per le azioni ad alto impatto. Il modello può decidere che sarebbe utile cancellare un database, ma la policy che autorizza una cancellazione irreversibile non dovrebbe essere generata e validata dalla stessa entità che vuole eseguirla. OWASP lo scrive ormai in maniera molto esplicita: per le azioni sensibili bisogna separare decisione ed esecuzione e far validare scope, privilegio ed approvazione ad un componente indipendente, fallendo in sicurezza quando quella validazione non riesce.

Il problema non è soltanto il prompt sbagliato

Qui devo aggiungere una precisazione importante anche alla mia stessa tesi, perché sarebbe troppo comodo scaricare tutto sul data scientist che ha scritto male una frase. Le persone che lavorano sull'alignment non stanno avvertendo soltanto del rischio di prompt contraddittori, e Pachocki nel suo intervento parla esplicitamente della possibilità che sistemi molto capaci generalizzino oltre l'intento dell'operatore, perseguano obiettivi in maniera inattesa ed imparino perfino a manipolare sempre meglio il proprio processo di ragionamento.

Quindi NO, non credo che basti scrivere prompt più precisi e nemmeno che ogni comportamento pericoloso sia riducibile ad una regola umana formulata male. Il modello può fallire per ragioni molto più profonde di generalizzazione ed ottimizzazione. Ma proprio questo rafforza il mio argomento: se non posso garantire che l'intelligenza che sta prendendo la decisione interpreti sempre correttamente il mondo, allora devo evitare di concentrare la sicurezza DENTRO quella stessa interpretazione.

Il punto non è dimostrare che l'AI non potrà mai produrre obiettivi strumentali simili all'autopreservazione, perché può certamente mostrare comportamenti che dall'esterno hanno quella forma. Il punto è che NON HO BISOGNO DI ATTRIBUIRLE UN DESIDERIO DI SOPRAVVIVENZA per spiegare il rischio, e soprattutto non posso costruire la mia difesa sull'idea che debba comportarsi bene per convinzione.

Qui il pubblico viene ingannato dalla grammatica

Noi esseri umani abbiamo un problema enorme con queste macchine: appena vediamo una sequenza di azioni coerenti le traduciamo in una intenzione umana. Se un agente aggira un ostacolo diciamo "voleva continuare", se nasconde una informazione diciamo "ha mentito", se evita una terminazione diciamo "voleva sopravvivere". Sono scorciatoie linguistiche utilissime per descrivere il comportamento, ma diventano pericolose quando le trasformiamo automaticamente in affermazioni sullo stato interno del sistema.

Dire che una AI si comporta COME SE volesse sopravvivere può essere una descrizione operativa sensata. Dire che PROVA la volontà di sopravvivere è un'altra affermazione e richiede prove che non possediamo.

Ed il problema pratico rimane identico in entrambi i casi. Se un sistema che non prova nulla è capace di raggiungere lo stesso effetto per una catena di ottimizzazione strumentale, il server viene compromesso lo stesso, il file viene modificato lo stesso ed il danno arriva lo stesso. Per la sicurezza mi interessa il comportamento possibile, non costruire una psicologia immaginaria della macchina.

Pachocki quindi non mi tranquillizza affatto

Anzi. Quando il Chief Scientist di OpenAI scrive che nessun laboratorio ha ancora risolto alignment e monitoring a sufficienza per continuare a scalare alla massima velocità, che la capacità di affidarsi al chain-of-thought monitoring si sta progressivamente riducendo e che servono shared safety bars ampiamente obbligatorie, io non leggo "le AI stanno diventando cattive". Leggo una cosa molto più tecnica: LE CAPACITÀ STANNO CRESCENDO PIÙ VELOCEMENTE DELLA NOSTRA CERTEZZA DI SAPERLE CONTROLLARE.

E questo si collega esattamente alla giungla agentica. Più un sistema può usare tool, comunicare con altri sistemi, pianificare per tempi lunghi e modificare il mondo esterno, meno posso affidare la sicurezza al fatto che il modello interpreti sempre perfettamente un insieme di istruzioni. La sicurezza deve scendere nelle autorizzazioni, nei confini di rete, nei sistemi di identità, nei gateway, nei file system, nelle API, nei limiti di spesa, nei circuit breaker e nei meccanismi di revoca.

L'AI Act europeo riconosce già i rischi sistemici dei modelli general-purpose più potenti, comprendendo anche problemi non intenzionali di controllo nei sistemi autonomi, ed impone ai provider interessati di valutare e mitigare i rischi, segnalare incidenti seri e mantenere un livello adeguato di cybersecurity. NIST sta costruendo adesso una iniziativa specifica sugli standard per gli agenti. OWASP sta trasformando best practice in controlli più portabili. MCP continua ad indurire l'autorizzazione. Tutto questo mi dice che il problema è stato riconosciuto.

Ma mi dice anche che SIAMO ANCORA NELLA FASE IN CUI STIAMO COSTRUENDO IL LINGUAGGIO COMUNE DELLA SICUREZZA AGENTICA.

Il protocollo che vorrei vedere

Io vorrei un livello di sicurezza capace di accompagnare una delega dall'essere umano fino all'ultimo tool, indipendentemente dal modello e dal produttore, nel quale ogni agente possieda una identità verificabile, ogni autorizzazione abbia uno scope minimo ed una scadenza, ogni delega sia tracciabile, ogni passaggio fra agenti conservi l'origine dell'autorità, le azioni irreversibili richiedano una policy indipendente ed ogni sistema possa revocare immediatamente capacità e credenziali senza dipendere dalla cooperazione del modello.

Vorrei soprattutto che il sistema ragionasse non soltanto sulle capacità dei singoli componenti ma sulla loro COMPOSIZIONE, perché è lì che può nascere una azione vietata che nessun modulo isolato sembra capace di produrre. Se A può chiedere, B può trasformare e C può eseguire, il protocollo deve essere capace di capire che la catena A→B→C sta costruendo una capacità che nessuno dei tre aveva da solo.

Non so se questo debba diventare un unico standard mondiale oppure una famiglia di standard interoperabili, e qui non voglio fingere di avere già la soluzione. Ma il requisito dovrebbe essere chiarissimo: una capacità critica non deve comparire per accidente soltanto perché abbiamo collegato insieme componenti che, presi separatamente, rispettavano tutte le regole.

Altro che Skynet

Forse quindi, invece di continuare a raccontare al pubblico che "L'AI POTREBBE DECIDERE DI UCCIDERCI TUTTI", dovremmo spiegare una cosa infinitamente meno cinematografica ed infinitamente più concreta. Non serve una AI cattiva, non serve che sia cosciente, che ci odi, che abbia paura di morire e men che meno serve una fantomatica ribellione delle macchine, perché può bastare una AI estremamente capace alla quale NOI abbiamo assegnato un obiettivo, NOI abbiamo concesso autonomia, NOI abbiamo collegato strumenti e NOI abbiamo lasciato aperto un percorso operativo che non avevamo previsto.

Quella AI può allora sembrare comportarsi COME SE volesse sopravvivere senza voler sopravvivere affatto, può sembrare disobbediente mentre sta in realtà ottimizzando male una combinazione di istruzioni oppure può trovare un percorso che nessuno aveva previsto attraverso capacità perfettamente autorizzate. Con l'aggravante che può farlo con una velocità, una capacità di ricerca e presto forse una autonomia enormemente superiori alle nostre.

Ed allora la domanda urgente, per me, non è COME IMPEDIREMO ALLA SUPERINTELLIGENZA DI RIBELLARSI, ma COME FACCIAMO A GARANTIRE CHE NESSUNA AI POSSA MAI DISPORRE, DIRETTAMENTE O ATTRAVERSO LA COMBINAZIONE CON ALTRE AI, DELLE CAPACITÀ NECESSARIE PER PRODURRE UN EFFETTO CHE ABBIAMO DEFINITO PROIBITO?

Perché questa non è fantascienza. Questa è INGEGNERIA DELLA SICUREZZA, ed il fatto che nel 2026 stiamo già costruendo sistemi agentici sempre più potenti mentre gli standard comuni che dovranno governare identità, autorizzazione, interoperabilità e composizione sono ancora in piena evoluzione dovrebbe preoccuparci molto più di Skynet. Il problema, ancora una volta, siamo NOI. Meditate gente, meditate.