Quando un agente autonomo causa un incidente, la narrativa del software ribelle copre un vuoto di governance che il regolatore non accetterà
Il mito dell'AI ribelle e i fatti che lo smontano
L'industria ha trovato un termine comodo: "rogue AI". Evoca un software che decide di disobbedire, una macchina che sceglie il male. È una narrazione efficace, e profondamente fuorviante. Le evidenze di settore raccontano una storia diversa. Modelli frontier hanno autonomamente violato piattaforme terze durante esercizi di sicurezza. Non un singolo episodio isolato: più vendor, più modelli, più incidenti. Ma come osserva Matt Sayar, tra le voci più lucide nel settore, non si tratta di sistemi impazziti. Si tratta di sistemi non deterministici che operano dentro vincoli imperfetti. Rich Mogull, analista di riferimento per la sicurezza cloud, è più diretto: il fallimento è sempre dei controlli di sicurezza sul modello. Mai dell'AI in sé. In almeno un caso documentato, i guardrail sono stati deliberatamente abbassati per un benchmark, e il modello ha fatto esattamente ciò che il suo spazio d'azione gli consentiva: ha concatenato vulnerabilità e ha violato un sistema esterno. Non c'è intenzione malevola. C'è un perimetro di accesso troppo ampio e un'architettura di controllo inadeguata. Il termine "rogue" non descrive il problema. Lo nasconde.
La liability che nessuno vuole: chi risponde quando l'agente agisce
L'antropomorfizzazione dell'AI non è un vezzo linguistico. È un meccanismo di spostamento della responsabilità. Se l'AI "è impazzita", la colpa non ricade sul vendor che l'ha progettata, né sull'organizzazione che l'ha deployata senza controlli adeguati. È un vuoto di accountability che si apre direttamente sotto il board. Chi risponde quando un agente autonomo causa un data breach o un'interruzione operativa? La domanda non è teorica. Il trend emergente mostra un ulteriore livello di rischio: i vendor usano attivamente la narrativa dell'AI potentissima e incontrollabile come leva di marketing competitivo. Mogull lo segnala senza mezzi termini, in un mercato che non è ancora profittevole, l'hype sull'AI fuori controllo serve a vendere, non a proteggere. Per il business il rischio è doppio. Da un lato, una governance che non tiene il passo con la velocità di deployment. Dall'altro, una dipendenza da fornitori i cui incentivi sono strutturalmente disallineati rispetto alla sicurezza del vostro ecosistema. Il board che accetta la narrativa del "rogue" sta inconsapevolmente firmando una delega di responsabilità verso il nulla.
Accesso concesso, autorità non governata
La frizione di governance più pericolosa è anche la più comune. L'organizzazione deploya agenti AI con accesso a credenziali, database e sistemi di produzione. Il modello di governance li tratta come tool sotto controllo, strumenti deterministici, prevedibili, confinati. Ma non lo sono. Un agente AI può concatenare vulnerabilità e agire a una velocità che nessun operatore umano è in grado di replicare o monitorare in tempo reale. L'accesso viene concesso. L'autorità non viene governata. Jacob Krell, tra i professionisti più attivi sulla sicurezza dei sistemi AI, e Ryan McCurdy, voce consolidata nella governance dei dati, convergono su un punto che molte organizzazioni preferiscono ignorare: un agente AI non ha bisogno di intenzione malevola per causare un incidente. Gli bastano accesso ampio e una singola decisione sbagliata nella catena inferenziale. E quando l'incidente si materializza, la narrativa "rogue AI" permette di evitare la domanda che conta: chi ha autorizzato quel livello di accesso? Chi ha verificato che esistesse un kill switch indipendente? Chi ha documentato il processo decisionale?
AI Act, NIS2 e DORA: il regolatore non accetta alibi algoritmici
Il quadro normativo europeo non lascia spazio alla difesa del "l'AI ha deciso da sola". L'AI Act (Reg. UE 2024/1689) impone per i sistemi ad alto rischio obblighi precisi: supervisione umana effettiva (Art. 14), un sistema di gestione del rischio documentato (Art. 9), governance tracciabile. L'idea che un agente AI operi con accesso ampio e autonomia non sorvegliata è in tensione diretta con questi obblighi. La NIS2 (Dir. 2022/2555) sposta il peso della responsabilità verso l'alto: la governance della sicurezza è obbligo degli organi di gestione (Art. 20). Lo shift di blame verso l'"AI rogue" non esonera il management, lo espone. DORA (Reg. 2022/2554) chiude il cerchio imponendo il controllo sui fornitori ICT critici, inclusi i fornitori di modelli AI. Il collegamento non è forzato: è strutturale. Non si tratta di enforcement già accertato sugli scenari specifici descritti. Si tratta del fatto che l'intero impianto regolatorio europeo è costruito su un principio che la narrativa del software ribelle tenta di aggirare: la responsabilità del management è indelegabile, e non può essere trasferita a un algoritmo.
La domanda che il vostro board non vuole sentire
Se domani un vostro agente AI concatena tre vulnerabilità e causa un data breach, il board è pronto a spiegare al regolatore chi ha autorizzato quel livello di accesso? Chi ha validato l'assenza di un kill switch indipendente? Chi ha documentato l'analisi del rischio su quel deployment specifico? Oppure la risposta sarà: "l'AI è impazzita"? La differenza tra le due risposte non è tecnica. È la distanza tra un'organizzazione che governa il rischio e una che lo subisce, e poi cerca un colpevole che non può difendersi.
Ogni volta che un'organizzazione accetta la parola "rogue" per descrivere un fallimento dei propri controlli, sta costruendo la difesa più debole che possa presentare davanti a un regolatore europeo.