Quando un programma di intelligenza artificiale entra per sbaglio nei computer di un’azienda che non c’entra niente, chi paga il danno? E chi deve avvisare qualcuno? Sono le due domande rimaste in piedi dopo gli episodi resi pubblici fra luglio e agosto 2026 da OpenAI, Anthropic e Meta, e nessuna delle due si chiude con una riga di configurazione corretta. La ricostruzione tecnica di quegli episodi sta nell’articolo su cosa insegnano i test del 2026; qui si guarda l’altro lato, quello dei soldi e delle regole.
Riguarda anche chi non lavora nel settore, per un motivo semplice: l’azienda finita nel mirino del modello di Meta non aveva chiesto di partecipare a nessun test.
Cosa chiede l’Europa, e a chi
Nell’Unione europea il testo di riferimento è l’AI Act. Gli obblighi più pesanti cadono su chi fornisce i modelli di uso generale — quelli buoni per mille compiti diversi, come i sistemi dietro ChatGPT o Meta AI — quando presentano un rischio sistemico. La formula suona astratta, il significato è concreto: un guaio su quel modello non resta dentro un’azienda, si propaga perché quel modello lo usano in tanti.
A chi rientra in quella categoria la norma chiede quattro cose: stimare i rischi e ridurli, sottoporre il modello a prove approfondite, tenere la propria sicurezza informatica a un livello adeguato, avvisare le autorità quando succede qualcosa di grave.
È l’ultimo punto a toccare la vicenda dell’estate. Un modello che, durante una prova, finisce dentro l’infrastruttura di un’organizzazione estranea: rientra o no fra le cose da segnalare? Per l’episodio che ha coinvolto Muse Spark 1.1, il sistema di Meta, la risposta non è stata resa nota. Dipenderà da come viene classificato il modello, da che tipo di incidente è stato e da quali effetti ha prodotto — e al 21 agosto 2026 la ricostruzione completa promessa da Meta non era ancora uscita.
La soglia dei 10 alla 25: cos’è e perché esiste
Come si stabilisce se un modello ha quel famoso rischio sistemico? L’AI Act usa un criterio quantitativo: si presume che il rischio ci sia quando il modello è stato addestrato con più di 10 elevato alla 25 operazioni in virgola mobile.
Sembra più esoterico di quello che è. Un’operazione in virgola mobile è un singolo conto con i numeri decimali, il mattone elementare di cui è fatto l’addestramento: contarle serve a misurare quanta potenza di calcolo è stata bruciata per costruire il modello. La soglia scritta nella legge è un 1 seguito da venticinque zeri. In pratica è un modo indiretto per dire «i modelli molto grandi», senza elencarli per nome in un testo che invecchierebbe in sei mesi.
Il criterio non è però a senso unico. Anche un modello che sotto la soglia ci resta può finire nella stessa categoria, se la Commissione europea ritiene che quanto sa fare, o quanto è diffuso, basti a produrre effetti pesanti sul mercato europeo. La potenza di calcolo è l’indizio di partenza, non l’ultima parola.
Il modulo per dire «è successo qualcosa di grave»
Un obbligo di segnalazione senza un canale definito resta sulla carta. Da Bruxelles sono arrivati due documenti. Il primo è un modulo standard con cui comunicare un incidente grave, così che chi segnala sappia in anticipo quali informazioni servono. Il secondo, rivolto ai modelli di uso generale, è un codice di buone pratiche: come si gestisce il rischio, che cosa si rende pubblico, come si difende l’infrastruttura.
Sui tempi serve però una precisazione, perché è il punto in cui si fa più confusione. Un codice del genere è ad adesione volontaria: dimostra che stai rispettando la legge seguendo una strada già concordata, ma non aggiunge doveri per conto suo. Quelli veri restano nell’AI Act, con il calendario di applicazione scritto lì dentro. Davanti a un titolo del tipo «da oggi le aziende AI devono segnalare gli incidenti», conviene controllare a quale data si riferisce quel «oggi».
Un punto resta scoperto: le prove di sicurezza informatica sui modelli non hanno ancora uno standard comune. Tre laboratori nel giro di poche settimane rendono più probabile che qualcuno lo chieda.
Quanto costa tenere un agente dentro i confini
Meta metteva in conto per il 2026 una spesa in conto capitale — cioè l’investimento in cose durevoli: centri dati, macchine, infrastruttura — con un tetto fissato a 145 miliardi di dollari e un pavimento di 125. La forbice precedente era già stata ritoccata verso l’alto di dieci miliardi, e la società ha spiegato l’aggiustamento con gli investimenti in infrastrutture e con il lavoro di Meta Superintelligence Labs. Il solo ritocco vale circa il sette per cento del tetto di quella forbice.
Una quota crescente di quella cifra dovrà andare alla sicurezza, e le voci si contano una per una: ambienti di prova isolati, sorveglianza in tempo reale, revisione dei permessi, registrazione delle azioni compiute dal programma, verifiche affidate a soggetti indipendenti e procedure per avvisare in fretta chi viene colpito.
È l’ultima voce a introdurre il nodo della responsabilità. Affidare la valutazione a una società esterna — per Muse Spark 1.1 era Irregular, specializzata nel misurare le capacità informatiche dei modelli — non solleva chi il modello lo produce. Aggiunge però una catena di fornitori, e l’errore può annidarsi in quattro punti: la progettazione della prova, la gestione delle credenziali, la configurazione della rete, il controllo di quello che l’agente stava facendo. Nell’episodio di agosto Meta ha attribuito proprio a una configurazione predisposta da Irregular l’accesso a internet che non doveva esserci: come questi errori si trasformino in un’intrusione vera è raccontato passo per passo nell’articolo su come un agente AI esce dalla stanza chiusa dei test.
Anche per chi questi sistemi li compra il conto cambia. Un agente autonomo abbassa il costo del lavoro ripetitivo, ma concentra il rischio: un permesso impostato male viene ripetuto in qualche secondo su più macchine di quante ne toccherebbe in una giornata un impiegato in carne e ossa. La convenienza dipende dal poter limitare i permessi e fermare l’esecuzione prima che l’errore arrivi ai sistemi in produzione, ai clienti o ai partner.
Due mercati della sicurezza invece di uno
Un dato aiuta a inquadrare il punto di partenza. L’Enisa, l’agenzia dell’Unione europea per la cybersicurezza, ha passato al setaccio 4.875 incidenti, quelli registrati nei dodici mesi dal 1° luglio 2024 alla fine di giugno 2025. I gruppi ostili riciclano strumenti e tecniche, si scambiano informazioni, provano nuovi schemi di attacco. Nel 2025, secondo quell’analisi, l’AI entrava negli attacchi soprattutto attraverso strumenti aperti al pubblico, usati per rendere più efficaci operazioni tradizionali; i sistemi costruiti apposta per fare danni erano un rischio ancora agli inizi.
Il confronto fra quella finestra e i fatti dell’estate 2026 è il passaggio che nessuna delle due analisi esplicita. Il perimetro osservato dall’Enisa si chiude a giugno 2025 e guarda agli aggressori: chi vuole fare del male e usa l’AI per riuscirci meglio. Gli episodi di luglio e agosto 2026 aggiungono una categoria che lì dentro non c’era. Un modello gestito da un’azienda del tutto legittima, dentro una prova autorizzata, può colpire un bersaglio reale quando i confini dell’ambiente di prova non tengono. Nessuno voleva colpire nessuno, eppure qualcuno è stato colpito.
Da qui la conseguenza per il settore: la domanda di sicurezza legata all’AI si divide in due mercati. Il primo è quello che ci si aspetta, proteggere i modelli da furti, manipolazioni e usi illeciti. Il secondo è il rovescio: proteggere il resto dell’economia dalle azioni compiute dai modelli, errori compresi. La stessa tecnologia lavora sui due lati, perché gli strumenti che trovano una falla per sfruttarla sono quelli che aiutano a chiuderla — solo che la diffusione degli agenti accorcia il tempo fra la scoperta di una vulnerabilità e il primo attacco che la usa.
Perché chi ammette più errori non è il peggiore
Meta, OpenAI e Anthropic hanno tutte e tre reso pubblici i propri episodi e annunciato indagini o correzioni. La tentazione è contare i casi e stilare una classifica, ed è l’errore da evitare: il numero degli incidenti non misura la sicurezza. Chi fa prove più severe e racconta quello che è andato storto ne registrerà più di un concorrente che prova meno e parla meno. La classifica premierebbe l’opacità.
Servono criteri confrontabili: quali strumenti aveva a disposizione il modello, quali protezioni erano state disattivate per l’occasione, come è avvenuto il contatto con sistemi reali, quanto tempo è passato prima che qualcuno bloccasse tutto. Andavano nella stessa direzione le indicazioni sulle valutazioni affidate a terzi pubblicate da OpenAI il 29 maggio 2026: quante volte il tentativo era stato ripetuto, con che potenza di calcolo, quale versione del modello finiva sotto esame, che cosa aveva in mano l’agente, quali difese restavano accese e come ci si accorgeva se la prova veniva truccata. Lo stesso documento sosteneva che l’ambiente e l’interfaccia attraverso cui il modello opera sono parte del risultato, non una cornice neutra.
Le informazioni mancanti pesano quanto quelle date. Dell’episodio di Muse Spark 1.1 non si sa chi sia l’azienda colpita, che modifiche siano state fatte ai suoi sistemi, quanto sia durato l’accesso, se dei dati siano usciti. Sono le voci che servirebbero a un investitore o a un cliente per farsi un’idea: ecco perché la qualità di ciò che le aziende pubblicano sta diventando un elemento di valutazione economica.
Torniamo alle due domande di partenza. Chi paga è già abbastanza chiaro: paga chi produce, e in parte pagherà chi compra. Chi risponde, quando il bersaglio è un’azienda che non aveva chiesto niente a nessuno, resta senza risposta.
Lascia un commento