La cybersecurity convenzionale non protegge la tua IA

NEL GIUGNO 2025, alcuni ricercatori hanno scoperto una vulnerabilità che esponeva dati sensibili di Microsoft 365 Copilot senza alcuna interazione da parte dell’utente. A differenza delle violazioni convenzionali che dipendono dal phishing o da errori degli utenti, questo exploit, ora noto come EchoLeak, ha aggirato completamente il comportamento umano, estraendo silenziosamente informazioni riservate manipolando il modo in cui Copilot interagisce con i dati degli utenti. L’incidente mette in luce una realtà preoccupante: i modelli di sicurezza odierni, progettati per sistemi software prevedibili e difese a livello di applicazione, non sono adeguati a gestire la natura dinamica e interconnessa dell’infrastruttura IA.

L’IA è passata rapidamente da progetti pilota sperimentali a infrastrutture mission-critical, determinando aumenti di produttività senza precedenti e plasmando in modo fondamentale il vantaggio competitivo in tutti i settori. Tuttavia, come EchoLeak ha dimostrato in modo così evidente, proprio questa integrazione dell’IA espone le organizzazioni a una nuova e sofisticata classe di vulnerabilità: exploit IA zero-click che compromettono i dati sensibili senza alcuna interazione da parte dell’utente. Questa realtà deriva da un disallineamento fondamentale. La maggior parte delle organizzazioni continua ad affidarsi a framework di sicurezza informatica convenzionali, creati per software deterministici, per proteggere sistemi di IA che sono tutt’altro che deterministici. I sistemi di IA apprendono costantemente da vasti flussi di dati esterni e interagiscono con essi, creando punti ciechi in cui le difese tradizionali semplicemente non sono applicabili.

Il risultato è un crescente divario di sicurezza. I leader sottovalutano questi rischi unici, gli aggressori scoprono nuovi vettori e le aziende continuano a scalare le implementazioni di IA senza protezioni adeguate al suo profilo di minaccia distintivo. Comprendere perché i nostri approcci attuali sono insufficienti è il primo passo essenziale per colmare questo divario.

Ricerca, metodologia e risultati

Per comprendere meglio come colmare il divario tra la nuova IA e la sicurezza informatica, la mia azienda, Canonical, Google e IDC hanno intervistato 500 dirigenti in tutto il mondo, nei settori di finanza, sanità, produzione e tecnologia. Tra gli intervistati figuravano CIO, CISO, CTO e responsabili dell’IA. Il sondaggio ha esaminato le pratiche attuali, i punti ciechi e i rischi percepiti, coprendo i framework, l’IA ombra e la grave carenza di talenti. Per integrare i dati, abbiamo parlato direttamente con CIO, CISO e leader dell’IA. Queste conversazioni hanno rivelato le dinamiche organizzative, le lacune concettuali e i vincoli quotidiani che modellano le decisioni reali sulla sicurezza dell’IA. Infine, abbiamo ricreato le implementazioni di IA aziendale in ambienti controllati. Testando scenari quali dati compromessi, prompt avversari, driver compromessi e acceleratori vulnerabili, abbiamo osservato in prima persona le vulnerabilità, basando la nostra analisi su prove empiriche.

Per tradurre questa complessità in intuizioni attuabili, abbiamo strutturato i nostri risultati utilizzando il NIST AI Risk Management Framework (AI RMF). Questo framework fornisce quattro funzioni guida (governare, mappare, misurare, gestire) che insieme formano un pratico manuale per la gestione dei rischi dell’IA. Allineando i nostri risultati a questo modello, abbiamo potuto mostrare ai dirigenti non solo quali sono i rischi, ma anche come ridurli sistematicamente.

In tutti e tre i livelli di ricerca, una conclusione è emersa con chiarezza: la sicurezza dell’IA non è principalmente un problema di applicazione, ma di infrastruttura e catena di fornitura. Sebbene le misure di protezione delle applicazioni rimangano necessarie, da sole non sono sufficienti. Le vere vulnerabilità, che esploreremo nella prossima sezione (dati avvelenati, manipolazione ostile, acceleratori compromessi ed exploit a livello di sistema), risiedono alla base dello stack dell’IA. Per i dirigenti, l’implicazione è chiara: garantire la sicurezza dell’IA richiede un cambiamento fondamentale di prospettiva, passando dall’applicazione di patch superficiali al rafforzamento dell’architettura sottostante e dei processi gestionali che rendono possibile l’IA.

Nuovi rischi che i dirigenti devono affrontare

Pochi leader aziendali si rendono conto di quanto sia facile che l’IA si ritorca contro le stesse organizzazioni che la implementano. Stanno emergendo nuove forme di attacchi che prendono di mira i sistemi di IA alla base (dai dati da cui apprendono all’hardware su cui funzionano), esponendo le imprese a rischi sistemici silenziosi. Questi includono:

• Avvelenamento dei dati. La corruzione deliberata dei dati di addestramento di un’IA consente agli aggressori di inserire informazioni false o distorte nei dati di addestramento dell’IA, alterando i risultati in modi che potrebbero rimanere invisibili fino a quando le decisioni non diventano catastrofiche. Alimentare un’IA finanziaria con dati di trading avvelenati potrebbe spingerla verso posizioni disastrose, mentre un’IA sanitaria esposta a immagini mediche manipolate potrebbe diagnosticare erroneamente i pazienti. In entrambi i casi, i dati corrotti minano silenziosamente l’integrità delle decisioni e la fiducia dell’azienda.
• Prompt avversari. Un’altra minaccia in aumento, si tratta di prompt che inducono i modelli a violare i propri limiti, sia divulgando dettagli riservati di un caso da un’IA legale, sia generando output dannosi. Il risultato non è solo un difetto tecnico, ma una crisi di reputazione e di conformità.
• Attacchi di inversione del modello. Si verificano quando gli hacker estraggono dati di addestramento sensibili o addirittura ricostruiscono algoritmi proprietari. Per le organizzazioni che si affidano a modelli o set di dati unici come proprietà intellettuale, ciò rappresenta un furto diretto del vantaggio competitivo.

Ciascuno di questi rischi rappresenta non solo una vulnerabilità tecnica, ma una minaccia diretta alla resilienza, alla fiducia e alla conformità dell’azienda. Tuttavia, la superficie di minaccia si estende ben oltre i modelli stessi. Le aziende stanno rapidamente scalando l’IA attraverso i fornitori di servizi cloud, affidandosi a hardware specializzato come GPU e TPU per accelerare i carichi di lavoro. Qui si nasconde un pericoloso punto cieco: gli attuali standard di sicurezza cloud sono progettati per proteggere le applicazioni, non gli acceleratori e gli hypervisor sottostanti (il software del livello di sistema) che alimentano i carichi di lavoro dell’IA. Un’autenticazione e una crittografia robuste offrono poca sicurezza se un driver o un livello firmware sono stati compromessi. Un aggressore che opera a quel livello può sottrarre silenziosamente dati sensibili dalla memoria o aggirare completamente i controlli a livello di applicazione. Senza protezioni più esplicite a questo livello, le aziende rischiano di costruire la loro strategia di IA su basi instabili.

Si consideri la storia di “Pal”, uno sviluppatore senior di una banca globale. Il suo team ha meticolosamente protetto l’applicazione web di punta dell’istituto: revisione approfondita del codice, test di penetrazione, autenticazione a più fattori e crittografia avanzata. Tuttavia, anche questo rigore non ha offerto alcuna difesa una volta che l’applicazione è stata distribuita su endpoint o server aziendali compromessi. Un keylogger nascosto nel sistema operativo poteva acquisire silenziosamente le credenziali, mentre il software del livello di sistema poteva aggirare tutte le protezioni dell’applicazione per divulgare i dati dei clienti.

La lezione per i dirigenti è chiara: anche le applicazioni rigorosamente protette sono indifese se distribuite su infrastrutture compromesse.

La nostra ricerca sottolinea quattro imperativi non negoziabili per i dirigenti che affrontano la realtà della sicurezza dell’IA. Non si tratta di miglioramenti opzionali ai playbook esistenti. Richiedono un ripensamento completo del modo in cui le organizzazioni percepiscono il rischio e la resilienza in un’economia guidata dall’IA.

1. L’infrastruttura IA è la vera superficie di attacco

Il cambiamento più urgente è riconoscere che il rischio reale non risiede nelle applicazioni IA con cui gli utenti interagiscono, ma nell’infrastruttura specializzata (GPU, TPU, driver, firmware e dispositivi edge) che le alimenta. Troppi leader estendono le tradizionali pratiche di sicurezza incentrate sulle applicazioni alle implementazioni IA, lasciando vulnerabile la base.

Si pensi a un’organizzazione sanitaria che ha crittografato i propri dati e rafforzato la propria app diagnostica, solo per essere compromessa tramite un exploit del firmware della GPU edge. Gli aggressori hanno aggirato le protezioni dell’app, hanno avuto accesso ai dati sensibili dei pazienti nella memoria della GPU e hanno provocato un arresto completo delle operazioni. La fiducia è svanita dall’oggi al domani. Rischi simili si ripercuotono su tutti i settori: le società finanziarie rischiano la manipolazione degli algoritmi, i produttori devono affrontare l’interruzione delle linee di produzione e le istituzioni pubbliche rischiano la paralisi dei servizi. I leader devono ricalibrare le loro priorità: trattare l’infrastruttura IA come mission-critical, creare team di sicurezza dedicati ed estendere i principi zero-trust all’intero stack IA.

2. Gli strumenti convenzionali non sono sufficienti

I controlli di sicurezza convenzionali, progettati per software deterministici, non riescono a stare al passo con i carichi di lavoro IA complessi e basati sui dati. Se applicati senza adattamenti, lasciano pericolosi punti ciechi.

Un’azienda di sicurezza informatica lo ha imparato a proprie spese: dopo aver adottato il servizio di IA proprietario di un importante fornitore di servizi cloud, si è trovata nell’impossibilità di verificare le misure di sicurezza sottostanti o di replicare il servizio altrove. Non è stata in grado di ricostruire un servizio di IA simile nel proprio data center, né di trovare un servizio comparabile presso altri fornitori di servizi cloud. Bloccata in una “scatola nera”, ha ereditato rischi sconosciuti che non poteva verificare o mitigare attraverso le tradizionali misure di sicurezza IT. La lezione per i dirigenti è chiara: rifiutare la fiducia cieca nei servizi di IA opachi, esigere trasparenza e portabilità e dare priorità a framework aperti che consentano una convalida indipendente. Le strategie ibride che combinano difese a livello di applicazione con il monitoraggio a livello di infrastruttura non sono più opzionali, ma essenziali.

3. Rafforzare le catene di fornitura più importanti

La sicurezza dell’IA si basa su due catene di fornitura fragili e interdipendenti: talenti specializzati e infrastrutture sicure. Entrambe sono sottoposte a forti pressioni, creando colli di bottiglia decisivi per le organizzazioni. La sfida dei talenti è ardua: difendere l’IA richiede competenze ibride in materia di sicurezza informatica e apprendimento automatico, un insieme di competenze concentrate solo in una manciata di grandi aziende tecnologiche. Allo stesso tempo, il collo di bottiglia dell’infrastruttura si sta aggravando. La domanda di GPU, reti ad alta velocità e modelli di terze parti rigorosamente controllati supera costantemente l’offerta, esponendo le imprese a dipendenze critiche.

Si consideri il caso di una banca globale che ha ritardato l’implementazione di un sistema critico di rilevamento delle frodi non perché il modello fosse fallito, ma perché lo erano le sue catene di approvvigionamento. L’organizzazione delle risorse umane non disponeva di un solido bacino di candidati per le operazioni di IA con un focus sulla sicurezza e non aveva un piano retributivo competitivo per attrarre gli specialisti, ormai scarsi. Ad aggravare la carenza di talenti, la banca si è trovata in lista d’attesa per i server di calcolo ad alte prestazioni di un importante fornitore di servizi cloud, a ricordare chiaramente che la capacità di calcolo sicura può essere scarsa quanto le persone qualificate. Questi fallimenti mettono in luce quanto possano essere fragili le catene di fornitura dell’IA: dipendenze nascoste nel software/hardware di base possono far deragliare anche piani ben congegnati. Problemi fondamentali come il ritardo nelle patch del sistema operativo o dei driver della GPU possono rendere vulnerabili o inutilizzabili intere generazioni di GPU, trasformando un aggiornamento minore in un’interruzione a livello di programma.

I leader non possono considerare secondari questi problemi. Devono investire nella formazione incrociata e nel reclutamento mirato, stabilire compensi in linea con il mercato e canali per i talenti nel campo dell’operatività e della sicurezza dell’IA, e stringere partnership strategiche con fornitori di hardware e software affidabili. Allo stesso tempo, devono diversificare le fonti di infrastruttura, dare priorità agli SLA contrattuali per la sicurezza e l’applicazione delle patch e mappare rigorosamente ogni dipendenza nello stack dell’IA (dalle fonti di dati ai driver e al firmware), in modo che l’organizzazione possa anticipare e assorbire gli shock della catena di fornitura piuttosto che esserne compromessa.

4. Sfruttare l’IA per difendere l’IA

Il paradosso dell’era dell’IA è che la stessa tecnologia che introduce rischi senza precedenti offre anche nuove e potenti vie di difesa. La capacità dell’IA di analizzare vasti set di dati e identificare modelli complessi la rende particolarmente adatta a rafforzare la sicurezza dell’infrastruttura di IA stessa. Ad esempio, l’IA può monitorare continuamente i carichi di lavoro della GPU per individuare anomalie nell’utilizzo della memoria o dell’alimentazione, segnalando potenziali attacchi o malfunzionamenti prima che si diffondano. Può anche analizzare i dati di sistema per prevedere problemi di integrità dei driver o del sistema operativo, offrendo avvisi tempestivi di potenziali vulnerabilità.

Questo potere si estende alla difesa proattiva: si pensi a una start-up che sfrutta agenti di IA per scansionare gli ambienti software creati dai clienti, identificando e correggendo le vulnerabilità in tempo reale, garantendo al contempo che i componenti software siano in linea con le esigenze, evitando aggiornamenti non necessari e la rimozione di componenti essenziali. Incorporando l’IA nelle strategie difensive (sia per il monitoraggio dell’infrastruttura che per la sicurezza delle applicazioni), le organizzazioni possono passare da controlli statici basati su regole a sistemi adattivi che danno priorità ai rischi in modo intelligente. I dirigenti non dovrebbero considerare la sicurezza basata sull’IA come sperimentale. Deve essere al centro della difesa aziendale, con team formati e autorizzati a renderla operativa su larga scala.

L’IA STA RAPIDAMENTE diventando fondamentale per il vantaggio competitivo, ma i suoi rischi per la sicurezza sono diversi da qualsiasi cosa le aziende abbiano gestito in precedenza. Gli amministratori delegati e i consigli di amministrazione devono riconoscere che la sicurezza informatica convenzionale non si estende al livello dell’infrastruttura in cui risiede realmente l’IA.

Il rischio strategico è chiaro: un’infrastruttura non sicura può minare gli stessi sistemi di IA da cui dipendono le aziende, erodere la fiducia dei clienti e creare esposizione normativa e reputazionale. L’opportunità persa è altrettanto significativa: i leader che proteggono in modo proattivo le loro implementazioni di IA possono muoversi più rapidamente, innovare con fiducia e costruire fiducia in un mercato sempre più diffidente nei confronti dei rischi dell’IA.

La sicurezza dell’IA non può essere un ripensamento. Deve essere integrata fin dall’inizio nella strategia infrastrutturale, nella governance e nei percorsi di formazione dei talenti. Solo così le organizzazioni potranno raccogliere i frutti dell’IA senza esporsi a vulnerabilità nascoste.

Hugo Huang è Product Manager presso Canonical. Ha conseguito un MBA presso il MIT.