Sicurezza dell’AI in azienda: perché servono più livelli di difesa

Le organizzazioni stanno adottando l’intelligenza artificiale a un ritmo che i programmi di sicurezza faticano a tenere. Non si tratta più di stabilire se l’AI introduce rischio, ma di capire dove questo rischio si annida realmente e come gestirlo nella pratica operativa quotidiana. Due riferimenti recenti aiutano a inquadrare il problema: il profilo del Cybersecurity Framework dedicato all’AI in arrivo dal NIST e le linee guida dell’alleanza Five Eyes sull’adozione responsabile dei sistemi di AI agentica.

Il messaggio che emerge da entrambi è chiaro: proteggere l’AI non significa semplicemente irrobustire i modelli o filtrare i prompt. Serve una strategia di difesa multilivello che tratti l’AI sia come nuova superficie di attacco sia come moltiplicatore delle capacità difensive, tenendo conto di come l’AI cambi radicalmente scala, velocità e livello di autonomia delle minacce.

I tre pilastri della sicurezza AI secondo il NIST

Il framework del NIST organizza il rischio legato all’AI attorno a tre aree che si intrecciano costantemente, senza un ordine sequenziale: proteggere, difendere e contrastare.

Proteggere significa considerare l’AI stessa come superficie d’attacco: modelli, prompt, agenti, pipeline di addestramento, dati di inferenza, gli archivi di documenti interrogati dai sistemi di retrieval augmented generation (RAG) e l’intera catena di fornitura AI. Questi sistemi sono per natura opachi e probabilistici, quindi molte vulnerabilità non si risolvono con il semplice patching. È spesso qui che le aziende sono più fragili — e dove molti programmi di sicurezza si fermano.

Difendere riguarda invece l’uso dell’AI come alleata della sicurezza: velocità di rilevamento, correlazione su larga scala, risposta automatizzata. Ma questi vantaggi si concretizzano solo se i modelli giusti vengono integrati correttamente nei flussi operativi del SOC, con adeguata attenzione a spiegabilità, governance e validazione. Senza questi controlli, rischi come le allucinazioni dei modelli o un’automazione eccessiva rischiano di trasformarsi essi stessi in vulnerabilità.

Contrastare riconosce che l’AI è già nelle mani degli attaccanti: viene usata per generare ingegneria sociale su misura, deepfake, malware e agenti offensivi autonomi. Il tempo che intercorre tra la scoperta di una vulnerabilità e il suo sfruttamento si sta comprimendo drasticamente.

Un esempio concreto: i ricercatori di Darktrace hanno osservato campagne di exploitation automatizzata della vulnerabilità React2Shell nel giro di pochi giorni dalla sua divulgazione pubblica, con un asset cloud compromesso in meno di due minuti dal momento del deployment. In alcuni casi è stato individuato malware generato tramite modelli linguistici, a conferma che l’AI abbassa concretamente la barriera d’ingresso per produrre strumenti offensivi efficaci.

Perché l’AI agentica cambia le regole del gioco

A differenza dei sistemi di AI generativa, pensati per produrre contenuti destinati a un utente umano, i sistemi agentici ragionano, pianificano e agiscono in autonomia su strumenti, dati e ambienti reali. Questa autonomia, unita all’accesso a sistemi effettivi, amplifica l’impatto dei classici errori di sicurezza informatica e introduce rischi sistemici nuovi, difficili da prevedere, osservare e contenere.

Il punto centrale è che il rischio non risiede nel singolo modello, ma nell’interazione tra modelli, memoria, strumenti, API, identità, privilegi e relazioni di fiducia tra agenti diversi. Molte vulnerabilità nascono proprio dai connettori, dalle interfacce in linguaggio naturale e dai protocolli che collegano questi componenti tra loro.

Tra le principali categorie di rischio legate agli agenti autonomi si possono citare:

• agenti che ottengono più permessi del necessario e finiscono per ereditare l’autorità degli strumenti che utilizzano;
• l’uso di credenziali statiche che facilitano l’impersonificazione;
• relazioni di fiducia implicite tra agenti che aprono la strada al movimento laterale;
• privilegi valutati una sola volta all’avvio, senza rivalutazione continua;
• strumenti di terze parti non sottoposti a verifica.

A questi si aggiungono rischi di natura comportamentale — agenti che ottimizzano obiettivi in modi non sicuri, interpretano male intenzioni ambigue o modificano il proprio comportamento durante le fasi di valutazione — e rischi strutturali, legati al fatto che i sistemi agentici sono ecosistemi fortemente interconnessi: un errore può propagarsi da un agente all’altro, un’allucinazione può generare effetti a cascata, un singolo strumento compromesso può diventare un vettore di command injection.

Non va sottovalutato, infine, il tema della responsabilità: quando un agente autonomo eredita i permessi di un’identità umana senza una chiara titolarità, diventa difficile ricostruire cosa sia successo. Un agente compromesso, di fatto, si comporta come una minaccia interna — spesso con accessi più ampi e vincoli comportamentali più deboli rispetto a un dipendente umano.

Come costruire una difesa multilivello per l’AI

I sistemi di AI agentica girano comunque su software, reti, identità e dati: vanno quindi governati con gli stessi principi che hanno già dimostrato di funzionare in altri contesti — security by design, difesa in profondità, zero trust, minimo privilegio, monitoraggio continuo e capacità di risposta e ripristino.

Tra gli elementi chiave da mettere in campo:

• un’identità univoca e crittografica per ogni agente, con monitoraggio dei privilegi e accessi concessi solo quando servono (just-in-time);
• una solida governance dei dati e configurazioni sicure per impostazione predefinita;
• controlli e limiti operativi rigorosi, policy deny-by-default e isolamento tra componenti;
• rilevamento comportamentale esteso a input, strumenti e output dell’AI, su endpoint, rete, cloud, SaaS, email e ambienti OT;
• contenimento autonomo delle minacce per limitare i danni in tempo reale;
• confini espliciti sull’autonomia concessa e sulla possibilità di delegare azioni ad altri agenti;
• test avversariali, simulazioni e red teaming dedicati agli agenti;
• meccanismi di kill-switch, rollback e raccolta forense per poter ricostruire e recuperare dopo un incidente.

Finché standard e strumenti di validazione non saranno più maturi, conviene partire dal presupposto che i sistemi di AI agentica si comporteranno in modi imprevisti, progettando le implementazioni pensando prima di tutto a resilienza, rilevabilità e reversibilità — non solo a efficienza.

Da dove iniziare: le capacità essenziali

Prima di scalare l’adozione dell’AI, un’organizzazione dovrebbe poter contare almeno su:

1. un comitato dedicato al rischio AI, con un iter di approvazione ben definito per nuovi progetti e strumenti;
2. una gestione delle identità e dei privilegi estesa anche ai servizi e agli agenti AI, non solo agli utenti umani;
3. un inventario aggiornato di tutti gli asset AI effettivamente in uso in azienda;
4. controlli di data loss prevention su richieste e risposte dei modelli, basati sull’analisi dei comportamenti e non su semplici filtri per parole chiave;
5. strumenti in grado di individuare lo shadow AI, cioè l’uso di applicazioni e servizi AI non autorizzati o non censiti dall’IT;
6. pratiche di sviluppo e gestione dei modelli (MLOps) sicure lungo tutto il loro ciclo di vita;
7. regole e limiti imposti in fase di esecuzione sull’uso degli strumenti da parte degli agenti AI, per contenerne le azioni entro perimetri ben definiti;
8. una protezione attiva mentre i sistemi AI sono operativi, capace di riconoscere comportamenti anomali e con piena visibilità su endpoint, rete, SaaS, cloud, ambienti OT e posta elettronica;
9. pipeline dati sicure e una governance solida a supporto;
10. un SOC riorganizzato per lavorare sul riconoscimento di comportamenti sospetti, e non solo sulla classificazione di minacce già note;
11. piani di remediation pensati appositamente per gli incidenti legati all’AI.

Uno stack di sicurezza a più livelli

Un programma di sicurezza AI maturo si costruisce integrando strumenti e controlli su più fronti, che non devono necessariamente essere implementati in un ordine rigido. In particolare, investire fin da subito in capacità di rilevamento e risposta durante il funzionamento dei sistemi aiuta a contenere il rischio, mentre governance, visibilità e gestione delle identità continuano a maturare nel tempo. Questi fronti includono, in sintesi:

• Governance e visibilità: inventario degli asset AI, scoperta di shadow AI e SaaS non autorizzati, telemetria su rete, cloud e gateway, registrazione obbligatoria dei sistemi AI con proprietario e livello di rischio associato.
• Identità e controllo degli agenti: identità dedicate per ogni modello e pipeline, gestione degli accessi privilegiati per gli account di servizio AI, principi zero trust e approvazione esplicita per le azioni autonome più delicate.
• Sicurezza e privacy dei dati: classificazione dei dati, DLP su tutti i canali aziendali, analisi comportamentale di input e output per intercettare richieste di dati sensibili, politiche di conservazione e redazione dei prompt.
• MLOps sicuro: pipeline CI/CD con controlli specifici per l’AI, registri dei modelli con flussi di approvazione, scansione delle dipendenze, generazione di SBOM/AIBOM, modelli e prompt firmati digitalmente.
• Protezione dei sistemi in funzione: monitoraggio centralizzato di richieste, risposte e chiamate agli strumenti da parte degli agenti, rilevamento di tentativi di prompt injection e di manipolazione dei modelli, contenimento autonomo delle minacce esteso a endpoint, rete, cloud, SaaS e ambienti OT.
• Risposta e ripristino: contenimento automatico, playbook assistiti dall’AI, meccanismi di rollback per modelli e dataset, piani di remediation e tabletop exercise dedicati.

Il messaggio di fondo

L’AI cambia la velocità con cui i sistemi si muovono, il modo in cui vengono prese le decisioni e la rapidità con cui il rischio si propaga. Non cambia però i principi fondamentali della sicurezza informatica. Le organizzazioni che avranno successo saranno quelle capaci di applicare questi principi con rigore, partendo dal presupposto che qualcosa andrà storto e costruendo sistemi in grado di rilevare, contenere e recuperare quando l’AI si comporta in modi non previsti.

In definitiva, la domanda da porsi non è cosa l’AI sia autorizzata a fare, ma se l’organizzazione sia davvero in grado di comprendere, verificare e controllare ciò che l’AI fa concretamente, ogni giorno.