L’adozione massiva di sistemi di intelligenza artificiale riproduce, amplificandoli, gli stessi errori commessi durante la migrazione verso il cloud: dati non protetti adeguatamente, governance formale priva di fondamenta tecniche solide, e una fiducia implicita nelle infrastrutture che si rivela spesso infondata.
Indice degli argomenti
Il parallelo con Stranger Things: quando il “sottosopra” diventa realtà
Se dovessimo riassumere Stranger Things in poche parole, potremmo dire questo: un gruppo di scienziati conduce un esperimento senza prestare particolare attenzione alla sicurezza e, come risultato, apre un portale verso un mondo “sottosopra”, molto simile al nostro, ma nel quale dei minacciosi mostri “demogorghi” sono liberi di attaccare il mondo di sopra. I protagonisti ne affrontano e sconfiggono diversi, salvo poi scoprire che il problema non era limitato a singole creature. Esisteva un Sottosopra più vasto, sistemico, che puntava a fondersi con il nostro mondo.
Mi fa sorridere creare un parallelo con quanto accaduto con il cloud. I nostri ordinati e rassicuranti sistemi on-prem degli anni Ottanta e Novanta hanno iniziato a dialogare con un “sottosopra” esterno, inizialmente percepito come distante, astratto e controllabile. In quel contesto abbiamo trasferito dati e sistemi con entusiasmo e con una consapevolezza limitata dei rischi, spesso, ignari del fatto che quel nuovo ambiente avrebbe finito per inglobare parti sempre più ampie del nostro perimetro operativo. Ed infine l’AI, rende il mondo reale e il “sottosopra” sempre meno distinguibili, fino a farli coincidere.
Gli anni Novanta: l’era dell’on-premises e della fiducia implicita
Negli anni le applicazioni erano monolitiche: un database centrale, un application server, client desktop installati localmente. Allo stesso tempo, la nostra generazione portava un vento di novità nel mondo applicativo dell’epoca, sviluppando le prime applicazioni web-based.
A prescindere dall’architettura, la logica applicativa era comunque fortemente accoppiata ai dati. L’infrastruttura rifletteva quel modello: server on-premises, spesso sovradimensionati rispetto al carico reale, con CPU e storage abbondanti con ampi margini operativi. Le prestazioni raramente costituivano un problema: pochi utenti concorrenti e workload prevedibili.
I primi problemi non furono di natura cyber, ma fisica. Dischi che si guastavano, controller difettosi, alimentatori instabili. Il rischio percepito era la perdita di disponibilità, il downtime. Le risposte erano coerenti con quel contesto: RAID, backup più frequenti, server di scorta. La sicurezza nasceva come reazione al guasto hardware, non come protezione del dato.
Il modello di sicurezza basato sulla fiducia interna
In quel contesto il modello di fiducia era implicito. Se eri dentro la rete, eri autorizzato. La sicurezza era fisica e organizzativa. Le minacce erano guasti ed errori umani. L’attaccante remoto non faceva ancora parte del modello mentale.
I dati, anche quando erano dati sanitari, erano trattati come contenuto funzionale, non come asset di rischio. Non c’era una vera classificazione, e i backup servivano a ripartire, non a proteggere.
La migrazione cloud: lift & shift del caos
L’adozione iniziale del cloud è stata spesso un lift & shift del caos. Stesse architetture, stessi difetti, su infrastruttura elastica. La fiducia implicita è stata replicata. L’assenza di separazione tra applicazione e dato è stata portata pari pari nel cloud. L’idea che “l’infrastruttura ci salverà” è sopravvissuta anche quando l’infrastruttura non era più nostra.
API e frammentazione dei dati: la perdita del controllo
Nel frattempo sono arrivate le API ed i dati hanno iniziato a essere distribuiti e trasformati in varie declinazioni. Improvvisamente la domanda “dove sono i dati?” ha smesso di avere una risposta semplice ma la classificazione è rimasta statica. L’access control è rimasto centrato sulle applicazioni, non sui dati.
La cifratura è diventata un cerotto: at rest e in transit, e dobbiamo ringraziare WhatsApp se la cifratura end-to-end è diventata mainstream ma raramente appare nelle applicazioni. Tuttavia Il cloud ha spostato il focus dall’hardware al dato, e ha fatto esplodere assunti che prima erano protetti dall’attrito operativo.
La nascita della cybersecurity moderna e il GDPR
Parallelamente, tra gli anni 2000 e 2010, nasce la cybersecurity moderna. Prima arrivano le leggi sui reati informatici: l’accesso non autorizzato diventa reato. Poi arrivano le normative sulla protezione dei dati.
Con il GDPR, la perdita di dati smette di essere solo un incidente tecnico e diventa un problema di compliance, con obblighi formali e un regime sanzionatorio esplicito.
Il dato diventa un rischio economico.
Il cloud oggi: IAM, monitoring e responsabilità condivisa
Grazie al cloud oggi l’IAM è al centro della protezione, con logging e monitoring diffusi e integrati con strumenti di incident response praticamente ovunque anche se il focus resta sull’infrastruttura più che sui dati.
Il cloud ci ha insegnato anche il modello di shared responsibility e ha reso familiari, a tutti i livelli, le responsabilità legate a SaaS, PaaS e IaaS, ma ha lasciato irrisolti problemi strutturali nella protezione dei dati ed è su questi problemi che oggi cresce l’AI. Il dato inserito, nuovamente, è parte dell’applicativo.
L’AI e il problema architetturale della sicurezza
L’analisi della sicurezza dei sistemi di AI richiede un cambio di prospettiva. Problemi come prompt injection e data leakage non derivano da implementazioni difettose, ma da un modello architetturale in cui input, istruzioni e dati condividono lo stesso spazio di esecuzione. Non stiamo più difendendo interfacce ben definite, come API o query, ma cercando di imporre vincoli di sicurezza al comportamento emergente di un sistema probabilistico. Questo spostamento rende inadeguati molti dei paradigmi tradizionali della sicurezza applicativa.
Valutazioni dei modelli: un’illusione di controllo
Le valutazioni dei modelli, per quanto sofisticate, restano intrinsecamente incomplete: dipendono dal prompt, osservano solo una frazione delle capacità latenti e non permettono inferenze negative affidabili.
Il fatto che un comportamento non emerga in fase di test non implica che esso non possa manifestarsi in produzione. In questo quadro, certificazioni e attestazioni di sicurezza non solo risultano fragili, ma rischiano di fornire una falsa percezione di controllo su sistemi il cui comportamento non è pienamente prevedibile.
L’opacità dei dati di addestramento e il rischio cristallizzato
Scendendo più in profondità nell’addestramento dei modelli, emerge come la provenienza dei dati utilizzati sia in larga misura opaca. L’audit dei dataset risulta difficile in assenza di accesso completo e rimane problematico anche quando tale accesso è disponibile, a causa di limiti fisici e computazionali. La rimozione dei dati è inoltre tecnicamente complessa e giuridicamente ambigua.
È sufficiente osservare il numero crescente di petizioni e iniziative pubbliche che contestano l’uso di dati personali o protetti da diritto d’autore nell’addestramento dei modelli per cogliere la portata del problema.
Nella maggior parte dei casi, riaddestrare un LLM a seguito dell’individuazione di dati non conformi nel training set non rappresenta un’opzione realistica. Una situazione analoga si osserva da anni nei sistemi cloud rispetto alla rimozione effettiva di dati personali e dei relativi backup, nonostante l’esistenza del diritto all’oblio. In questo contesto, il rischio viene di fatto cristallizzato nel modello.
L’inspiegabilità dei modelli e i limiti dell’allineamento
La conseguenza è che, in ultima analisi, non siamo in grado di spiegare perché un modello si comporti in un certo modo. Il collegamento tra dati di addestramento e output specifici rimane in larga parte irrisolto. I meccanismi di allineamento, costituiti da strati più superficiali del modello e spesso costruiti a loro volta tramite altri modelli, introducono ulteriori livelli di opacità.
Computing power: un proxy fragile del rischio
A un livello ancora più basso, quello hardware, il computing power viene utilizzato come proxy di rischio in quanto misurabile, ma si tratta di un surrogato fragile.
Non sappiamo quali proprietà hardware siano realmente determinanti per il training o per l’inference: misuriamo il “quanto”, ma non il “cosa”.
Agenti AI: il territorio inesplorato del controllo
Infine, gli agenti AI rompono i modelli di controllo tradizionali. Pianificano, utilizzano strumenti, e agiscono autonomamente, introducendo nuovi problemi di responsabilità, controllo e valutazione. È qui che il parallelismo con il cloud si interrompe: questo è un territorio sostanzialmente nuovo.
La dimensione economica: capex hardware e tassa di maturità
C’è poi una dimensione economica che rende il quadro ancora più interessante.
Negli anni della grande adozione cloud, l’aumento della spesa in infrastruttura è stato seguito, con qualche anno di ritardo, da un aumento strutturale della spesa in cybersecurity. Non come rapporto uno a uno, ma come “tassa di maturità“: identity, logging, compliance, governance. Il valore del cloud è stato ottimizzato solo dove è arrivata la disciplina.
Oggi la spesa in AI cresce a ritmi comparabili, se non superiori. Ma a differenza del cloud, una parte enorme di questa spesa è capex fisico: GPU, data center, energia. È un ritorno dell’hardware al servizio del dato.
Obsolescenza delle GPU e sostenibilità degli investimenti
Questo crea una tensione nuova. Gli hyperscaler stanno allungando l’ammortamento contabile delle infrastrutture verso sei anni.
Ma l’obsolescenza economica delle GPU, soprattutto per il training di frontiera, può essere di due o tre anni. Il riutilizzo per inference può estendere la vita, ma solo se l’architettura e i workload sono governati.
Investimenti in cybersecurity: una necessità non opzionale
Lo stesso vale per la sicurezza. Se l’AI entra in processi core e tratta dati sensibili, la spesa in cybersecurity non è opzionale. È ragionevole aspettarsi un investimento incrementale dell’ordine del 10% della spesa AI solo per rendere i sistemi governabili: data governance, controlli sul contesto, valutazioni continue, incident response specifico per AI.
Dalle fondamenta fragili alla governance verificabile
Negli anni Novanta la sicurezza nasceva come risposta al guasto dell’hardware. Oggi l’hardware è di nuovo centrale, ma il guasto non è fisico. È semantico. Abbiamo imparato, lentamente, che senza capacità tecniche la governance resta un’intenzione ma stiamo costruendo governance su fondamenta tecniche che non sono ancora solide. Servono meccanismi affidabili di valutazione continua dei modelli, in grado di rilevare capacità latenti, comportamenti emergenti e variazioni nel tempo, oltre i limiti dei benchmark statici. È necessario rendere tracciabile, almeno in parte, la relazione tra dati di addestramento, fasi di fine-tuning e comportamenti osservabili, sapendo che l’attribuzione perfetta potrebbe non essere raggiungibile.
Occorre distinguere in modo operativo tra la capacità computazionale utilizzata per il training e quella utilizzata per l’inference, perché è spesso nell’uso su larga scala, non nell’addestramento iniziale, che si manifesta l’impatto reale. Devono esistere controlli tecnici sul contesto di utilizzo dei modelli, inclusi input, output, strumenti e integrazioni, per prevenire abusi, esfiltrazioni e comportamenti non previsti.
Infine, la governance richiede capacità di verifica, ossia la possibilità di dimostrare che un controllo funziona effettivamente, che un dato non è stato utilizzato, o che una determinata funzionalità non è presente nel sistema. Senza queste capacità tecniche, audit, certificazioni e attestazioni restano dichiarazioni di principio. La governance diventa formale, ma non verificabile.
