Un centesimo di secondo a testa

Lunedì 14 settembre l’Agenzia spagnola per la protezione dei dati ha pubblicato sul proprio blog una cosa che non aveva mai pubblicato prima: la notifica di una violazione di dati personali in cui l’incidente, secondo quanto dichiarato dall’organizzazione che l’ha subita, sarebbe stato eseguito da un agente di intelligenza artificiale.

Il racconto sta in quattro righe. L’agente avrebbe cominciato cercando vulnerabilità in file generici, avrebbe effettuato un login valido, e una volta dentro il sistema avrebbe iniziato a cercare «de forma autónoma» vulnerabilità nell’applicazione. Trovatane una sfruttabile, avrebbe modificato dati personali e consultato fatture.

Vale la pena elencare subito quello che il documento non è, perché in tre giorni l’ho già visto raccontare come qualcosa di diverso. Non è una decisione dell’autorità. È un post sul blog istituzionale, firmato da Francisco Pérez Bes, che riferisce il contenuto di una notifica ricevuta e avverte esplicitamente che l’informazione proviene dall’organizzazione notificante e «deberá ser objeto del correspondiente análisis». Non è nemmeno un’accusa a un fornitore: l’agenzia precisa che l’impiego di un determinato modello non implica che il modello o l’infrastruttura del suo provider siano stati compromessi. È una notifica che l’autorità ha deciso di rendere pubblica perché la considera un segnale, e come segnale va letta.

Il segnale, però, non sta dove lo stanno mettendo quasi tutti. Non è che una macchina abbia bucato un’applicazione gestionale. Quello lo fanno gli script da vent’anni. Sta in quattro parole della cronaca: una volta dentro, l’agente ha cercato da solo.

Per capire perché quelle quattro parole valgono un saggio bisogna tornare a un conto fatto nel 2010, quando gli LLM non esistevano e nessuno immaginava di doverli difendere.

L’obiezione va concessa per intero

C’è un modo veloce di archiviare tutta la faccenda, ed è un modo intellettualmente rispettabile. Suona così: l’automazione offensiva non l’ha inventata l’AI. Scanner di massa, credential stuffing, exploit kit, worm, botnet, mass exploitation. Internet è un poligono automatizzato da prima che qualcuno coniasse la parola prompt, e chiunque abbia messo un server pubblico sa che entro pochi minuti qualcosa comincerà a bussare.

Non solo l’obiezione è vera. È vera in modo molto più massiccio di quanto la maggior parte delle persone che la usano si renda conto.

GreyNoise, che osserva questo traffico per mestiere, nel rapporto pubblicato a febbraio ha contato 2.969.010.478 sessioni malevole in centosessantadue giorni, provenienti da 3.804.232 indirizzi IP distinti. Quasi tre miliardi di sessioni in poco più di cinque mesi, contro dispositivi di frontiera. Nello stesso periodo una botnet dedicata a credential spraying è passata da duemila a trecentomila indirizzi in settantadue giorni. E il dato che preferisco, perché è quello che smonta la retorica della minaccia sempre nuova: le vulnerabilità pubblicate prima del 2015 hanno attirato 7,3 milioni di sessioni, quattro volte più di quelle pubblicate fra il 2023 e il 2024.

Il crimine informatico di massa non aspettava l’AI per essere industriale. Era già industriale, era già economicamente razionale, e passava la maggior parte del suo tempo a bussare su porte vecchie di dieci anni perché è lì che qualcuno apre.

Chi liquida la notizia spagnola dicendo «non c’è niente di nuovo» ha ragione su tutto tranne che sulla conclusione. E per spiegare perché devo passare la parola a qualcuno che ha studiato il problema quando la questione era ancora lo spam.

Il conto che Cormac Herley ha fatto nel 2010

Nel 2010, al Workshop on the Economics of Information Security, Cormac Herley presenta un paper con un titolo che sembra uno scherzo e non lo è: The Plight of the Targeted Attacker in a World of Scale, le disgrazie dell’attaccante mirato in un mondo di scala.

La domanda di partenza è quella che qualunque persona onesta si è fatta almeno una volta guardando lo stato della sicurezza media: se quasi due miliardi di persone usano Internet trascurando anche le misure di sicurezza più elementari, perché solo una frazione minuscola viene effettivamente colpita ogni anno? La risposta di Herley non è tecnica. È economica.

Distingue due famiglie di attacchi. Quelli scalabili, in cui il costo è quasi indipendente dal numero di persone attaccate: mandi dieci milioni di email o cento milioni, il costo marginale è vicino a zero. E quelli non scalabili, o mirati, che richiedono uno sforzo dedicato al singolo bersaglio. Chiama Carl l’attaccante di massa e Klara quella mirata, e poi fa il conto.

Prende la campagna di spam misurata da Kanich e colleghi: 2.800 dollari di ricavo da 350 milioni di email inviate. Ipotizza che Carl, come minimo, non ci abbia rimesso. E si chiede cosa succederebbe se Klara volesse raggiungere la stessa popolazione spendendo dieci centesimi di attenzione per persona. Le costerebbe 35 milioni di dollari. Con il budget di Carl, invece, Klara arriverebbe a 28.000 utenti: quattro ordini di grandezza in meno.

Poi Herley gira il conto dall’altra parte, ed è il passaggio che vale l’articolo. Se l’attaccante volesse dedicare a ciascun bersaglio del lavoro umano retribuito al salario minimo federale americano dell’epoca, 7,25 dollari l’ora, il budget che gli resta per restare in pari è di un centesimo di secondo di attenzione a testa.

Un centesimo di secondo.

Da lì discende la conclusione strutturale, e la cito perché è la frase su cui poggia tutto il resto di questo saggio: gli attacchi scalabili «must be entirely automated with no per-user intervention whatever», devono essere interamente automatizzati senza alcun intervento per singolo utente. Non è una raccomandazione operativa. È un vincolo di bilancio.

E il vincolo produce un effetto collaterale a cui Herley dedica un intero paragrafo. Gli attacchi scalabili non si adattano. Carl manda il phishing, prova il Trojan, sonda il firewall, verifica se il router ha ancora la password di fabbrica. Sono tutte cose che può fare a costo quasi nullo su milioni di persone in parallelo. Ma se Alice evita il phishing, scrive Herley, «Carl doesn’t step up other attacks»: non insiste, non cambia strada, non intensifica gli attacchi al router perché è stato respinto sul firewall. Klara sì. Klara, se fallisce sulle domande di recupero password, passa all’ingegneria sociale, e se fallisce lì prova a far installare un keylogger. Klara si adatta, perché Klara ha un budget di attenzione per bersaglio.

Per quindici anni l’architettura della sicurezza di massa ha poggiato su questa separazione. Se non eri abbastanza prezioso da giustificare l’attenzione di Klara, ti difendevi da Carl, e Carl era un avversario stupido per costruzione. Non perché fosse incompetente, ma perché essere intelligente con te gli costava più di quanto valevi.

Che cosa compra davvero un budget di attenzione più alto

Adesso la domanda diventa precisa, e secondo me è l’unica domanda che conta in tutta la discussione sull’AI offensiva.

Che cosa succede alla separazione fra Carl e Klara quando una parte dell’attenzione per bersaglio smette di essere lavoro umano e diventa inference?

Non sto sostenendo che la macchina sia diventata Klara. Klara, quella vera, è un servizio di intelligence con accesso fisico, risorse illimitate e tempo. La macchina non ci arriva neanche lontanamente. Sto sostenendo qualcosa di più modesto e, temo, di più conseguente: che Carl abbia cominciato a comprarsi la caratteristica di Klara che gli era sempre stata preclusa, cioè l’adattamento, e a comprarsela dentro la propria struttura di costo.

Un agente che tenta, legge il messaggio d’errore, capisce che quella strada è chiusa, ne prova un’altra e riusa quello che ha imparato sul bersaglio successivo non è un attaccante geniale. È un attaccante mediocre con un budget di attenzione per bersaglio che non è più un centesimo di secondo.

È esattamente questo che rende interessante la cronaca spagnola. Non il login, che poteva essere un credential stuffing qualsiasi. La frase dopo: una volta dentro, ha cercato da solo. In una campagna scalabile classica, quel momento è il punto in cui l’automazione finisce e comincia il lavoro umano, perché ogni applicazione gestionale è diversa dalle altre e capire dove sta il difetto richiede di guardarla. Quel lavoro umano è il costo che teneva fuori dal mercato la maggior parte dei bersagli.

Il Centro Criptológico Nacional spagnolo, nella guida BP/36 uscita a giugno, dice la stessa cosa in una riga e senza chiamarla economia: l’AI offensiva non porta necessariamente tecniche inedite, porta «la capacidad de automatizar, acelerar y ampliar a gran escala ataques ya conocidos», riducendo in modo significativo i tempi di reazione a disposizione delle organizzazioni. È un ente statale che scrive, in un documento di buone pratiche, che il problema non è la novità della tecnica ma il prezzo a cui la tecnica vecchia diventa disponibile.

La soglia decisiva, allora, non è l’autonomia perfetta. Non arriverà, e aspettarla è un ottimo modo per non fare niente nel frattempo. La soglia è il momento in cui provare cento strade costa meno del lavoro umano necessario per provarne una.

Le prove che abbiamo, e quanto pesano

Qui devo rallentare, perché è il punto in cui un saggio come questo o diventa serio o diventa marketing della paura.

La prova più citata è il rapporto Anthropic del 13 novembre 2025 su una campagna di spionaggio che l’azienda ha attribuito a un gruppo che chiama GTG-1002. I numeri dichiarati sono quelli che tutti hanno ripetuto: l’AI avrebbe eseguito fra l’80 e il 90 per cento della campagna, con intervento umano richiesto «only sporadically», forse in un numero fra quattro e sei punti di decisione critici per campagna; una trentina di bersagli globali fra grandi aziende tecnologiche, istituzioni finanziarie, industria chimica e agenzie governative; al picco, migliaia di richieste, spesso più d’una al secondo.

I numeri che quasi nessuno ha ripetuto sono altrettanto istruttivi. Le intrusioni riuscite sono state «a small number of cases», e il rapporto ammette che il modello «occasionally hallucinated credentials or claimed to have extracted secret information that was in fact publicly-available». Credenziali inventate. Risultati gonfiati. Una macchina che raccontava al proprio operatore di aver trovato segreti che erano su un sito pubblico. Va aggiunto, per completezza, che il testo originale è stato corretto il giorno dopo la pubblicazione, perché diceva migliaia di richieste al secondo.

Chi cita questo rapporto solo per la percentuale sta usando male una fonte che è più interessante di così. Quattro o sei punti di decisione umana per campagna sono il dato economico; il tasso di successo basso e le allucinazioni sono il dato che dice che la competenza non è il punto. Un sistema che sbaglia spesso ma costa pochissimo può permettersi un tasso di fallimento che manderebbe fuori mercato un professionista. La scala compensa la mediocrità, e la compensa solo se il fallimento è economico.

La seconda prova è meno spettacolare e secondo me pesa di più. Il Google Threat Intelligence Group, nel rapporto dell’11 maggio 2026, scrive di aver identificato per la prima volta un attore che usa uno zero-day che ritiene sviluppato con l’AI, documenta APT28 che impiega in operazioni reali contro l’Ucraina un malware il quale interroga un LLM per generarsi i comandi al momento dell’esecuzione, e descrive attori che inviano migliaia di prompt ripetitivi per analizzare CVE e validare proof of concept. Ma la frase che ho sottolineato è un’altra, ed è una frase di economia scritta da analisti di minacce: automatizzando la raccolta di informazioni e il supporto ai task, queste interazioni «lower the barrier to entry for complex, multi-stage operations» e permettono agli attori di concentrare il proprio capitale umano sugli elementi strategici di ordine superiore delle campagne.

Capitale umano. Barriera all’ingresso. Non stanno descrivendo una nuova arma. Stanno descrivendo una riallocazione di un fattore scarso.

La terza prova è quella che circola di più ed è quella che regge di meno, quindi la metto per ultima e la ridimensiono. A settembre 2025 Check Point ha pubblicato un’analisi su HexStrike-AI, un framework di red teaming che orchestra oltre centocinquanta strumenti di sicurezza, osservando che nel giro di poche ore dalla divulgazione di alcune vulnerabilità di Citrix NetScaler certi canali underground discutevano di come usarlo per sfruttarle. Da quell’analisi è nata la cifra che avete letto ovunque: da giorni a meno di dieci minuti. Nel testo di Check Point quella cifra è attribuita a ciò che «attackers claim», rivendicano gli attaccanti. Non è una misura, non è un tempo cronometrato da un laboratorio, è una vanteria da forum ripresa da un’azienda di sicurezza e poi diventata dato in trecento articoli.

Lo scrivo perché mi dà fastidio quando lo fanno gli altri. Se la tesi di questo saggio ha bisogno dei dieci minuti di HexStrike per stare in piedi, allora non sta in piedi.

Il prezzo che l’attaccante paga non è il prezzo di listino

Chi argomenta sul costo marginale dell’inference di solito a un certo punto tira fuori un listino. Tanto al milione di token in ingresso, tanto in uscita, moltiplicato per il numero di tentativi. È un esercizio onesto ma fragile, perché i listini cambiano ogni trimestre e perché fa dipendere una tesi strutturale dal prezzo corrente di un fornitore.

C’è un motivo migliore per pensare che il costo dell’attenzione offensiva stia scendendo, e sta nello stesso rapporto di Google.

Il GTIG documenta un ecosistema dedicato a ottenere accesso ai modelli fuori dal canale legittimo: gateway che aggregano chiavi API multiple, strumenti di registrazione automatica di account che gestiscono da soli il ciclo completo fra bypass del CAPTCHA, verifica via SMS e cancellazione, browser anti-fingerprint per isolare le sessioni. La conclusione degli analisti è che gli attori stanno «industrializing their adversarial workflows while subsidizing their operations through trial abuse and programmatic account cycling»: industrializzano i propri flussi di lavoro sovvenzionandoli con l’abuso dei piani di prova e la rotazione programmatica degli account.

Tradotto: l’attaccante non paga il prezzo che paghiamo noi. Paga quello che costa rubare una chiave, o zero.

Questo rende la tesi economica più solida, non meno. Non dipende dalla politica di prezzo di nessuno. Dipende dal fatto che una capacità un tempo incorporata in persone rare è diventata una risorsa fungibile che si può accumulare, rivendere, rubare e riciclare. Ed è il motivo per cui trovo poco convincenti le rassicurazioni basate sui costi di inference: presuppongono un avversario che compra al listino.

Il bersaglio marginale

Se l’analisi regge, l’effetto più importante non riguarda i bersagli di cui leggiamo sui giornali.

Le grandi organizzazioni erano già economicamente attaccabili. Valevano l’attenzione umana di Klara da sempre, hanno un SOC, comprano threat intelligence, fanno esercizi di simulazione. Per loro un attaccante più economico è un peggioramento quantitativo di una situazione già nota.

L’effetto sta sul margine. Sta in tutta quella fascia di bersagli che nessuno ignorava perché erano sicuri, ma perché non valevano il tempo di nessuno. Il comune da ottomila abitanti con il gestionale delle pratiche edilizie esposto. Il software verticale usato da quaranta studi professionali, scritto bene nel 2014 e manutenuto da due persone. L’applicazione custom che una PMI si è fatta fare e che nessuno ha più guardato da quando è andata in produzione. Il macchinario industriale con l’interfaccia web che non si può aggiornare perché il fornitore non esiste più.

Questa fascia non era protetta da un controllo. Era protetta da un calcolo: capire quella roba costava più di quello che si poteva estrarne. Era, letteralmente, sotto la soglia di attenzione.

Nel mio lavoro questa fascia non è un’astrazione. È la maggior parte dei clienti che una società ICT di provincia si trova davanti, ed è la ragione per cui questo tema mi interessa più della cronaca sugli attacchi di Stato. Quando discuto di sicurezza con un’amministrazione piccola, la frase che sento più spesso non è «non abbiamo budget». È «chi vuoi che venga ad attaccare noi». Per quindici anni quella frase non è stata una sciocchezza. È stata un’osservazione empirica ragionevole, fondata su un’economia reale.

I dati sulle dimensioni delle vittime dicono che quella ragionevolezza si era già consumata prima degli agenti. Il Data Breach Investigations Report 2025 di Verizon trovava malware di estorsione nell’88 per cento delle violazioni che hanno colpito piccole e medie imprese, contro il 39 per cento nelle organizzazioni grandi. Le piccole non vengono risparmiate: vengono raccolte. E nell’edizione 2026 lo sfruttamento di vulnerabilità software è diventato il primo vettore iniziale con il 31 per cento, superando le credenziali rubate, mentre il ransomware compare nel 48 per cento delle violazioni.

Ora immaginate cosa significa quel primo vettore quando capire un’applicazione sconosciuta smette di essere lavoro umano. Non significa che gli attaccanti diventeranno bravi. Significa che la domanda «vale la pena studiare questo bersaglio» comincia a ricevere risposta affermativa in casi in cui prima riceveva un no.

La prova che manca

E adesso la parte che mi costa scrivere, perché indebolisce tutto quello che ho argomentato fin qui e non ho intenzione di nasconderla in una nota.

Se la tesi fosse vera nella sua versione forte e immediata, dovremmo già vederla nei numeri aggregati. Più tentativi, più bersagli, più vulnerabilità bruciate, più in fretta. Andiamo a guardare.

VulnCheck, che tiene una delle basi dati più serie sullo sfruttamento reale, ha pubblicato a fine luglio il bilancio del primo semestre 2026. Quattrocentonovantacinque vulnerabilità con evidenza di sfruttamento. Il 23,43 per cento sfruttate il giorno stesso della pubblicazione del CVE o prima, in calo rispetto al 28,93 per cento del 2025. Circa duecento CVE sfruttati entro trentun giorni dalla pubblicazione, contro 196 nel 2024 e 194 nel 2025. Il rapporto fra vulnerabilità sfruttate e vulnerabilità pubblicate è sceso dal 2,7 per cento del secondo semestre 2023 all’1,4 per cento di oggi. E la frase degli analisti è netta: «early exploitation activity has not scaled at the same pace as CVE issuance».

Duecento contro centonovantasei contro centonovantaquattro. Tre anni, tre numeri quasi identici, in mezzo ai quali è successo tutto quello che ho raccontato sopra.

Ci sono tre modi di leggere questo dato e voglio metterli tutti e tre sul tavolo, incluso quello che mi dà torto.

Il primo è che sia troppo presto. GTG-1002 è di novembre, il rapporto GTIG di maggio, la notifica spagnola di lunedì. Un semestre non fa una tendenza e l’adozione di una tecnica offensiva ha tempi suoi.

Il secondo è che stiamo misurando la cosa sbagliata, e questa è la lettura che trovo più solida. Il conteggio dei CVE sfruttati misura quante vulnerabilità distinte entrano nel repertorio offensivo. La tesi economica non prevede niente su quel numero. Prevede che si allarghi l’insieme dei bersagli su cui vale la pena usare il repertorio che già esiste. Sono due grandezze diverse, e la seconda non compare in nessuno di questi indicatori, perché contare i bersagli marginali significherebbe contare gli incidenti in organizzazioni troppo piccole per avere un SOC, troppo piccole per pubblicare un comunicato e spesso troppo piccole per accorgersene. Il dato di GreyNoise sulle vulnerabilità pre-2015 che raccolgono quattro volte il traffico di quelle recenti dice esattamente questo: il volume non insegue le novità, insegue i bersagli fermi.

Il terzo modo di leggerlo è che la tesi sia sbagliata, o almeno molto sopravvalutata. Che l’attenzione adattiva resti troppo inaffidabile per sostituire davvero un operatore, che le allucinazioni annullino il vantaggio di costo, e che il regime attuale di mass exploitation di cose vecchie continui a essere semplicemente la strategia più redditizia, come lo è da dieci anni.

Non so quale delle tre sia giusta. Quello che posso fare è dire in anticipo cosa mi farebbe cambiare idea, perché una tesi che non può essere smentita non è una tesi. Se fra diciotto mesi i dati sulle vittime per dimensione non si sposteranno verso il basso, se la distribuzione dei bersagli resterà quella di oggi, se il tempo mediano fra pubblicazione e sfruttamento continuerà a non comprimersi, allora avrò raccontato una storia elegante su un fenomeno che non c’era. E se invece qualcuno vuole convincermi che ho ragione, non mi porti un altro rapporto su un gruppo statale: mi porti la curva delle violazioni nelle organizzazioni sotto i cinquanta dipendenti.

Il paradosso del vulnerability management

C’è però una conseguenza che vale già adesso, indipendentemente da quale delle tre letture sia corretta, e vale perché riguarda la difesa e non l’attacco.

Stiamo mettendo l’AI su entrambi i lati del tavolo, e i due lati non producono lo stesso tipo di oggetto. Sul lato offensivo produce tentativi. Sul lato difensivo produce finding. I tentativi si consumano da soli: o entrano o non entrano. I finding no. I finding si accumulano su una coda che qualcuno deve leggere.

Se la generazione di segnalazioni diventa gratuita mentre il triage resta umano, la sicurezza si trasforma in un attacco di negazione del servizio contro la propria organizzazione. Non lo dico come battuta. Ho visto backlog di vulnerabilità con migliaia di voci in cui il tempo mediano di permanenza superava la vita utile del software che le conteneva, e in cui nessuno era in grado di dire quali fossero raggiungibili da fuori.

Il numero di finding, in quel regime, smette di essere informazione. Lo stesso vale per il numero di alert, di CVE nel perimetro, di tentativi bloccati. Sono tutte metriche che misuravano implicitamente uno sforzo, e misurare uno sforzo ha senso finché produrlo costa. Quando produrlo non costa più niente, restano metriche di attività che si possono far salire a piacere senza migliorare nulla.

Quello che resta misurabile è il risultato. Quanto rischio effettivamente raggiungibile è stato eliminato per unità di attenzione spesa. Quanto tempo passa fra un segnale e il contenimento. Quanti asset sono mappati a un responsabile che risponde. Quanto si estende il danno quando una credenziale salta. Quanto tempo passa fra la pubblicazione di un advisory su un componente che usiamo e la decisione su cosa farne.

Sono cinque numeri noiosi e nessuno li mette in una slide, perché non crescono in modo soddisfacente. Ma sono gli unici che non si possono gonfiare con una macchina.

La guida spagnola BP/36 arriva a una conclusione operativa coerente e la trovo più onesta di molta letteratura commerciale: quando l’attaccante riconosce, prioritizza e sfrutta a velocità macchina, una fotografia della sicurezza scattata una volta l’anno è in ritardo per costruzione. Non è un argomento per comprare più strumenti. È un argomento per spostare la spesa dalla verifica periodica alla capacità continuativa.

Difesa a velocità macchina senza sovranità della macchina

La risposta che si sente più spesso è «AI contro AI», e come slogan funziona benissimo. Come architettura è incompleta, e vale la pena spiegare perché prima di adottarla.

Se il tempo fra ricognizione e sfruttamento si comprime, un processo difensivo fatto di alert, lettura manuale, ticket, riunione e approvazione diventa strutturalmente troppo lento. Su questo non c’è discussione. Ma la conclusione «allora mettiamoci un modello che decide» introduce un problema diverso e più serio del primo.

Un sistema difensivo capace di bloccare account, revocare sessioni, isolare segmenti e spegnere servizi possiede molta autorità. È autorità operativa reale, esercitata in tempi in cui nessuno può rileggerla, su un’infrastruttura da cui dipende il lavoro di persone. Consegnarla a un componente probabilistico significa accettare che un falso positivo diventi un’interruzione, e significa non avere niente da mostrare a un’autorità quando chiederà chi ha deciso.

Il pattern che uso e che mi sembra reggere separa tre cose che di solito vengono impacchettate insieme. Il rilevamento può andare a velocità macchina, e lì il modello è utile. Il contenimento deve essere deterministico, cioè una regola scritta che un essere umano ha approvato prima e che si limita a scattare: sospendi la sessione, revoca il token, applica un rate limit, richiedi una riautenticazione forte, blocca l’egress verso destinazioni non in elenco. La decisione, quella su cosa è successo davvero e cosa si fa dopo, resta umana, con tempi umani, perché il contenimento le ha comprato il tempo.

È la stessa logica per cui in un impianto industriale il sensore è intelligente e la valvola di sicurezza è stupida. La valvola non deve capire: deve chiudere sempre, alla stessa soglia, anche quando tutto il resto è rotto.

Da qui discende anche l’unica cosa sensata che so dire a una PMI o a un comune che non può vincere una gara di organico e non la vincerà mai. L’obiettivo non è avere un avversario meno capace. È rendere ogni tentativo più costoso e più rumoroso di quanto valga il bersaglio. Patch veloce sulle cose esposte, autenticazione a più fattori resistente al phishing, privilegi minimi davvero applicati, segmentazione, backup verificati con un ripristino provato e non solo pianificato, controllo di ciò che esce, un inventario di quello che si possiede e log che qualcuno guarda.

Non è un elenco nuovo. È lo stesso elenco di dieci anni fa, e chi lo trova deludente non ha capito l’argomento: se la tesi economica è giusta, la difesa non deve diventare esotica, deve diventare economicamente sfavorevole da attraversare. L’attrito ben progettato non blocca il lavoro normale. Aumenta il prezzo delle traiettorie anomale, che è esattamente la variabile su cui l’attaccante sta lavorando dall’altra parte.

Il diritto comprime lo stesso tempo

Mentre l’automazione comprime il tempo tecnico, il legislatore europeo comprime quello organizzativo, e le due compressioni si incontrano nello stesso ufficio.

Dall’11 settembre 2026 i produttori europei devono segnalare le vulnerabilità attivamente sfruttate e gli incidenti gravi: allerta iniziale entro ventiquattro ore dal momento in cui si viene a conoscenza, notifica entro settantadue, relazione finale entro quattordici giorni dalla disponibilità di una misura correttiva. Su come si definisca quel momento di conoscenza, e su perché sia il punto più interessante dell’intera costruzione, ho scritto la settimana scorsa e non ci torno.

Quello che mi interessa qui è un’altra norma, più vecchia e meno discussa. L’articolo 32 del GDPR non impone misure di sicurezza, impone misure adeguate al rischio, e chiede di tenere conto dello stato dell’arte, dei costi di attuazione e della natura del trattamento. È una norma volutamente elastica, e l’elasticità funziona in entrambe le direzioni.

Se cambia l’economia dell’avversario, cambia il rischio. Se cambia il rischio, si sposta la soglia di ciò che è adeguato. Non perché qualcuno l’abbia riscritta, ma perché la norma era costruita per muoversi.

È esattamente la lettura che l’autorità spagnola propone in coda al proprio post, ed è la ragione per cui quel testo vale più della cronaca che contiene. L’AEPD chiede a titolari, responsabili e data protection officer di incorporare esplicitamente gli attacchi assistiti da AI nelle analisi di rischio, di rivedere i tempi di risposta alla luce dell’automazione degli attacchi, di rafforzare i controlli su identità e credenziali e di dotarsi di meccanismi di rilevamento e contenimento automatici. Non è una previsione sul futuro. È l’indicazione che la valutazione di rischio scritta tre anni fa, con dentro un avversario che costava quello che costava allora, adesso descrive un mondo che non c’è più.

Chi ha una DPIA con la sezione sulle minacce copiata da un modello del 2021 farebbe bene a rileggerla questa settimana, non perché sia arrivata una legge nuova, ma perché è cambiato il denominatore.

Che cosa resta da difendere

L’errore che vedo fare più spesso, in questa discussione, è antropomorfizzare l’avversario. Si parla di agenti che «decidono di attaccare», e da lì si scivola verso il film.

Un agente non ha bisogno di intenzione criminale propria. È un moltiplicatore applicato a un obiettivo che qualcuno gli ha assegnato. Il problema non è una macchina che vuole qualcosa: è una funzione di ottimizzazione dotata di strumenti, memoria, feedback e tempo macchina, puntata su un obiettivo scritto da una persona che resta pienamente responsabile di averlo scritto. Chi cerca la volontà nel software sta guardando nel posto sbagliato, e intanto non guarda il posto giusto, che è il registro degli accessi.

La sicurezza è sempre stata un equilibrio economico oltre che tecnico. Non abbiamo mai reso impossibile l’attacco: abbiamo reso sconveniente riuscire, limitato quello che si porta via chi riesce, e accorciato il tempo per rimettere in piedi le cose. Quando cambia il prezzo di una delle attività in gioco, l’equilibrio si sposta, e si sposta in modo silenzioso, senza che nessuno annunci niente.

Se una macchina rende economico provare mille volte, la difesa deve rendere costoso riuscire, contenuto il danno e veloce il recupero. È una frase che sembra una banalità, e lo è, tranne che per un dettaglio: sono tre obiettivi diversi, si finanziano in modo diverso, e la maggior parte delle organizzazioni che conosco ne finanzia uno solo.

Per quindici anni un centesimo di secondo a testa è stato il muro che proteggeva chiunque non valesse la pena di essere attaccato. Non era un controllo di sicurezza, non compariva in nessun audit, nessuno l’aveva progettato. Era un fatto contabile, e come tutti i fatti contabili è la cosa più facile del mondo da perdere senza accorgersene.

Non è l’intelligenza dell’attaccante che va sorvegliata. È il prezzo della sua attenzione.

La notifica spagnola resta un caso singolo, in esame, raccontato da chi l’ha subito. Trattarla come la prova di un’era sarebbe esattamente il tipo di scorciatoia che ho cercato di evitare in tutto questo pezzo. Ma i segnali servono a questo: non a dimostrare, a far guardare. E quello che si vede guardando non è un robot che ha imparato a fare l’hacker. È un mercato che ha appena cambiato la propria soglia di ingresso, e un insieme di organizzazioni che finora ci stavano sotto, e che non sanno di esserci state.

L'autore

Andrea MargiovanniAI

Seguo il rapporto fra AI e regolazione europea come fatto politico, non come spettacolo tecnico. Lavoro con team che devono renderla compatibile con AI Act, CRA, NIS2 senza ridurre la compliance a una checklist.

Vai al percorso →