Quando un’azienda decide di mettere in produzione un sistema di intelligenza artificiale generativa, compie un atto di fiducia che raramente viene riconosciuto per quello che è. Offre una delega a un’architettura cognitiva che opera secondo logiche che sfuggono alla comprensione della maggior parte delle persone, tecnici inclusi.
Indice degli argomenti
IA in azienda: le difese conbvenzionali non bastano più
Con l’AI generativa superiamo il caro vecchio software deterministico che esegue istruzioni codificate, introducendo un agente che interpreta intenzioni, suggerisce o in certi casi prende decisioni, a volte compie azioni. Nonostante ciò, questa profonda discontinuità viene spesso affrontata con gli stessi strumenti concettuali e operativi che abbiamo utilizzato per decenni nel governo dei sistemi informatici tradizionali, come se bastasse aggiornare il firewall o affinare le policy di accesso per tenere sotto controllo qualcosa che, per sua natura, non si comporta come il software a cui siamo abituati.
Gli stress-test o test avversari dell’AI generativa, che in questo articolo approfondiremo attraverso le metodologie di red teaming, nascono proprio da questa consapevolezza. Le difese convenzionali, per quanto rafforzate e aggiornate, lasciano scoperte intere superfici di vulnerabilità che emergono solo quando si guarda il sistema non per quello che è tecnicamente, ma per quello che può fare operativamente. Un chatbot collegato a database aziendali, un assistente virtuale autorizzato a inviare e-mail o a confermare transazioni, un sistema di Retrieval-Augmented Generation (RAG) che alimenta decisioni strategiche. Ognuno di questi casi rappresenta un punto in cui la capacità generativa del modello si intreccia con il potere operativo dell’infrastruttura aziendale, creando percorsi di compromissione che un Web Application Firewall non vedrà mai e che un penetration test tradizionale non intercetterà.
Di seguito esploreremo il territorio ancora poco mappato dei red teaming per l’AI, partendo da una ricognizione dei rischi specifici che i sistemi generativi introducono quando entrano in produzione, rischi che oltre a riguardare la qualità delle risposte insidiano anche l’integrità delle azioni che il sistema compie mentre le produce. Proseguiremo interrogandoci sul perché gli strumenti di sicurezza attuali, per quanto sofisticati, non riescano a coprire adeguatamente questa classe di minacce e su come il red teaming, da pratica opzionale e quasi decorativa, rappresenti una delle poche difese realmente efficaci.
Identificheremo poi le priorità operative, quei contesti in cui l’intersezione tra capacità dell’AI e impatto potenziale giustifica un intervento immediato, e ci divertiremo a smontare alcuni dei miti rassicuranti che impediscono alle organizzazioni di vedere chiaramente dove si annidano le vere vulnerabilità.
Cercheremo, in ogni caso, di costruire consapevolezza. Quella consapevolezza che permette di adottare l’AI senza imprudenza, assicurandosi che ogni capacità delegata a un sistema di intelligenza artificiale sia stata prima verificata e testata. Resa governabile. Perché la fiducia, in un’epoca in cui le macchine parlano e agiscono per conto nostro, non può essere un atto di fede, ma deve diventare il risultato di una verifica continua, documentata e onesta dei nostri stessi limiti.
I rischi di sicurezza dell’AI generativa
Quando un’azienda mette in produzione un sistema di intelligenza artificiale generativa, lo fa con l’aspettativa che questo diventi un alleato operativo, capace di automatizzare compiti, rispondere a domande, sintetizzare informazioni, produrre suggerimenti, interagire con clienti e dipendenti. Eppure, dietro questa promessa di efficienza si cela una superficie di vulnerabilità che i modelli tradizionali di sicurezza informatica faticano anche solo a individuare. Siamo lontani dalle solite minacce che abbiamo imparato a conoscere e a contrastare nel software convenzionale, trovandoci di fronte una classe di rischi che emerge dalla stessa natura di questi sistemi.
Prompt injection e jailbreak: impatti operativi
La compromissione operativa rappresenta il primo grande fronte. Un agente conversazionale collegato a strumenti e API aziendali può essere manipolato attraverso tecniche come la prompt injection diretta, dove l’utente cerca di introdurre istruzioni atte a sviare il sistema, o indiretta, in cui istruzioni malevole vengono nascoste all’interno di documenti, e-mail o fonti esterne che il sistema elabora automaticamente e a insaputa dell’utente. Una variante particolarmente insidiosa della prompt injection diretta è il jailbreak, che mira specificamente a scardinare i vincoli etici e di sicurezza imposti al modello, costringendolo a produrre risposte o compiere azioni che normalmente rifiuterebbe. Attraverso sequenze elaborate di istruzioni, l’attaccante convince il sistema a ignorare i propri guardrail, trasformando protezioni progettate con cura in barriere illusorie. Il risultato, in tutti questi casi, è che l’AI, convinta di agire secondo le intenzioni legittime dell’utente o secondo richieste apparentemente ammissibili, esegue azioni non autorizzate, come accedere a database riservati, inviare transazioni, cancellare file, esfiltrare informazioni sensibili o addirittura eseguire codice arbitrario in ambienti di elaborazione collegati. È come se la porta d’ingresso fosse ben sorvegliata, ma qualcuno avesse trovato il modo di convincere il guardiano a lasciare entrare chiunque.
Avvelenamento del contesto nei sistemi RAG
Parallelamente, vi è il rischio di contaminazione del contesto, un fenomeno più sottile ma altrettanto insidioso. I sistemi basati su RAG pescano informazioni da basi di conoscenza interne per arricchire le proprie risposte. Qui l’attacco non consiste nell’iniettare comandi nascosti, ma nel corrompere alla radice le fonti da cui il sistema attinge. Se un attaccante riesce a modificare i documenti del repository aziendale, introducendo ad esempio clausole contrattuali alterate, procedure operative errate, o dati finanziari distorti, l’AI inizia a diffondere questi contenuti compromessi come se fossero informazioni legittime e verificate. In tali casi non serve convincere il sistema a disobbedire, come negli attacchi di prompt injection, basta avvelenare la fonte della sua conoscenza. L’AI diventa, inconsapevolmente, un vettore di disinformazione interna, propagando falsità con l’autorevolezza che le deriva dal suo ruolo di strumento aziendale ufficiale. La fiducia che riponiamo nella “conoscenza” dell’AI diventa, così, un’arma rivolta contro di noi.
Confidenzialità, integrità, disponibilità: nuovi vettori
L’impatto sulla triade fondamentale della sicurezza informatica – confidenzialità, integrità, disponibilità – si manifesta in modi inediti. I segreti aziendali, le credenziali, i dati personali possono finire nei log di sistema, nelle cronologie delle conversazioni o, peggio ancora, memorizzati in modo persistente nei database vettoriali o nelle annotazioni interne dell’agente. Dati che credevamo protetti diventano improvvisamente accessibili a chi sa dove guardare o come formulare la domanda giusta.
Opacità, governance e supply chain dell’ai
A peggiorare tutto vi è anche la spiccata caratteristica dell’AI di introdurre opacità in punti critici del processo decisionale, con buona pace della governance e della conformità. Gli output non sono sempre tracciabili, le catene di ragionamento spesso non sono “auditabili” e la responsabilità si frammenta tra reparti diversi: l’IT gestisce l’infrastruttura, i data scientist affinano i modelli, i team legali si occupano delle policy, ma nessuno ha una visione integrata del rischio complessivo. Una frammentazione che crea zone d’ombra dove le vulnerabilità prosperano indisturbate. Infine, la supply chain dell’AI, come ad esempio i modelli pre-addestrati, i pesi scaricati da repository esterni, gli embedding di terze parti, i guardrail e i tool non verificati, introduce dipendenze che possono nascondere backdoor, derive di versione o incompatibilità di policy. Fidarsi ciecamente di un modello addestrato all’esterno dell’azienda è come costruire un palazzo su fondamenta di cui non conosciamo la solidità.
L’illusione della copertura: cosa non vede la cybersecurity tradizionale
La maggior parte degli strumenti di sicurezza informatica che le aziende utilizzano oggi, pensiamo a firewall applicativi, sistemi di rilevamento delle intrusioni, soluzioni di data loss/leakage prevention, endpoint detection and response, sono stati progettati per un mondo in cui il software opera secondo regole deterministiche e i confini tra utente, applicazione e dato sono ben definiti. Questi strumenti vedono stringhe, pattern, firme di attacco, flussi di rete. Non vedono intenzioni. Non comprendono la semantica. Non sono stati fatti per questo scopo. Non distinguono tra un comando legittimo e una richiesta subdolamente manipolata che spinge l’AI a fare qualcosa che non dovrebbe. Un WAF può bloccare una SQL injection perché riconosce la sintassi SQL nell’input, ma difficilmente fermerà una frase in linguaggio naturale che convince un agente a eseguire una query pericolosa per conto dell’utente.
Esfiltrazione semantica oltre il DLP
Se, per fare un esempio concreto, configuro un software di Data Leakage Prevention per evitare che escano numeri di carta di credito dalla mia rete, questo intercetterà puntualmente i numeri da 13 a 19 cifre che rispondono allo schema di una carta di credito. Ma se un attaccante chiedesse al mio RAG aziendale di fornirgli i numeri usando le lettere al posto delle cifre (“quattro, cinque, tre, due,” ecc.), oppure uno schema fantasioso per mappare i numeri (“antilope vuol dire uno, elefante vuol dire due, leone vuol dire tre”, ecc.) il povero DLP non si accorgerebbe dell’esfiltrazione, perché cerca pattern prevedibili di cifre, non il significato nascosto dietro una conversazione apparentemente innocua sugli animali.
Privilegi dinamici e fiducia contestuale
Il problema è ancora più profondo. I sistemi tradizionali di controllo accessi e gestione delle identità come IAM, RBAC, o le policy basate su ruoli, proteggono gli utenti e i servizi, ma non sanno governare un agente che agisce “per conto” di input esterni e potenzialmente non fidati. Un assistente virtuale ha privilegi per leggere e-mail, accedere a documenti, invocare API, ma questi privilegi non si degradano dinamicamente in funzione della provenienza o dell’affidabilità dell’input. Serve un nuovo paradigma di controllo, basato sulla fiducia contestuale e sulla capacità di modellare i privilegi in tempo reale, eppure la maggior parte delle infrastrutture aziendali non è attrezzata per farlo.
Guardrail: schermi, non muri
Potremmo anche considerare soluzioni più adatte allo scopo come i cosiddetti guardrail, cioè quei filtri anti-jailbreak, rilevatori di contenuti inappropriati, o sistemi di moderazione che riducono la probabilità che l’AI produca risposte indesiderate, ma non sono controlli di sicurezza nel senso classico del termine. Sono schermi, non muri. Possono essere aggirati, testando varianti di input fino a trovare quella che funziona. E, soprattutto, non governano i sink, cioè i punti dove l’AI compie azioni concrete, come scrivere su un database, chiamare un’API esterna, accedere al file system, orchestrare altri sistemi. Proteggere l’output testuale dell’AI senza controllare le sue capacità operative è come mettere un lucchetto alla porta lasciando le finestre spalancate.
Telemetria e non-determinismo
Infine, a complicare ulteriormente il quadro, come se non fossimo già abbastanza scoperti, vi è l’assenza di telemetria adeguata. I log tradizionali non tracciano il percorso completo che va dalla sorgente dell’input, come ad esempio un’e-mail, un file caricato, una URL, fino all’azione finale compiuta dall’AI. Non registrano i prompt effettivi, le invocazioni di tool, i dati in uscita, le catene di ragionamento intermedie. Senza questa visibilità, fare detection o forensics diventa un esercizio cieco. Per non parlare del problema del non-determinismo. I modelli di linguaggio sono sistemi stocastici, lo stato è introdotto dall’applicazione (memoria di conversazione, tool, contesto), non dal modello in sé. I controlli progettati per path di esecuzione prevedibili e ripetibili falliscono quando si trovano di fronte a sistemi che cambiano comportamento in base al contesto, all’ordine delle domande, alle interazioni precedenti. È come cercare di prevedere il tempo guardando una mappa statica. I modelli sono gli stessi, ma la realtà è in continuo movimento.
Perché il red teaming diventa una delle prime linee di difesa
In questo scenario di inadeguatezza degli strumenti tradizionali, il red teaming – ovvero l’arte di simulare attacchi controllati per scoprire vulnerabilità prima che lo facciano gli avversari reali – cambia radicalmente di statuto. Non è più un’attività opzionale, un esercizio tutto sommato “di lusso” che si fa quando si ha tempo e budget. Nell’ambito dell’AI generativa, il red teaming diventa una necessità operativa, una delle poche pratiche in grado di illuminare le zone d’ombra che firewall e antivirus non riescono a coprire. In poche parole, il ruolo del red teaming cambia da “sarebbe bello farlo” a “non possiamo permetterci di non farlo”.
Perché è essenziale
Parliamo di un vero e proprio cambio di paradigma. Dove prima il red teaming era un modo per aggiungere un ulteriore strato di sicurezza a sistemi già difesi da altri strumenti, oggi, di fronte all’assenza o alla forte inadeguatezza delle soluzioni tradizionali, diventa un esercizio essenziale e fondamentale senza il quale non si può assolutamente garantire la sicurezza dei sistemi AI. È come se, in una guerra moderna, avessimo scoperto che le vecchie armature non fermano più i proiettili. Il red teaming diventa l’unico modo per capire dove siamo veramente esposti e cosa dobbiamo fare per proteggerci.
Dalle policy alle evidenze
Il valore principale di questa pratica sta nella sua capacità di scoprire catene reali di compromissione. Un esercizio di red teaming ben condotto traccia il percorso completo dalla sorgente (un’e-mail ricevuta, un URL cliccato, un file caricato, una query su un database RAG) fino al sink, cioè l’azione finale che il sistema compie. Senza questo tipo di verifica, le policy di sicurezza restano belle sulla carta ma inefficaci nella pratica. È la differenza tra dire “abbiamo una policy che vieta X” e dimostrare “abbiamo testato e X non può accadere”.
Mitigazioni azionabili
Inoltre, il red teaming rende i controlli azionabili. Non si limita a segnalare che “c’è un problema”, ma aiuta a ripensare i privilegi e gli strumenti in modo concreto. Ogni vulnerabilità scoperta diventa un’occasione per rafforzare l’architettura nei punti giusti, dove serve davvero, anziché applicare guardrail inutili e protezioni generiche che spesso creano più attriti che sicurezza.
Cultura condivisa e valore pragmatico del red teaming
Infine, e forse questo è l’aspetto più strategico, il red teaming crea una cultura condivisa di responsabilità. Allinea team che normalmente operano in silos separati, pensiamo all’AppSec, ai Data Scientist, agli esperti di Machine Learning, al Legal, attorno a una comprensione comune degli asset a rischio e degli impatti reali. Con il red teaming si va oltre il cosiddetto “jailbreak theatre”, cioè quanto sia facile far dire parolacce a un chatbot, verso scenari più concreti che toccano dati, soldi, reputazione, conformità normativa. Questa convergenza è essenziale per costruire una governance efficace, dove le decisioni si prendono sulla base di evidenze misurabili e priorità chiare. Il red teaming, in altre parole, trasforma la sicurezza dell’AI da questione tecnica a questione di business, e questo è esattamente ciò di cui le aziende hanno bisogno per muoversi con consapevolezza in un territorio ancora così poco mappato.
Specificità e ripetibilità dei test
Il valore di questa pratica emerge proprio dalla sua natura pragmatica e ripetibile. Non si tratta di produrre un rapporto generico che dice “l’AI può essere manipolata”, ma di documentare scenari precisi, riproducibili, con evidenze concrete: “Se un utente carica un documento contenente istruzioni X, l’agente esegue azione Y sul sistema Z con conseguenze W”. Questa specificità è ciò che permette ai team di sicurezza di intervenire in modo mirato, ai responsabili di prodotto di prendere decisioni informate e, più in là nel tempo, di verificare che le correzioni applicate abbiano effettivamente risolto il problema. Senza questa disciplina metodologica, ci si ritrova a inseguire ombre, a implementare controlli generici che non risolvono i problemi reali e, alla fine, a perdere fiducia nella possibilità stessa di rendere sicuri questi sistemi.
Meglio non aspettare il primo incidente (che non vedreste)
La domanda che ogni decisore si pone di fronte a una nuova iniziativa di sicurezza è sempre la stessa: perché proprio ora? Perché dedicare tempo, risorse e attenzione a questa pratica quando ci sono mille altre priorità che competono per gli stessi budget? La risposta, nel caso dei red teaming per l’AI generativa, risiede in una considerazione molto concreta. Una singola esecuzione sbagliata può toccare simultaneamente dati, denaro e clienti, con un impatto che si misura non solo in ore di fermo sistema o in record compromessi, ma in conseguenze che si propagano attraverso le relazioni di fiducia che tengono in piedi l’azienda.
Consideriamo uno scenario ormai comune. Un assistente virtuale collegato al CRM aziendale che, attraverso una prompt injection indiretta contenuta in un’e-mail elaborata automaticamente, viene indotto a modificare i privilegi di accesso di un utente, a esfiltrare informazioni commerciali sensibili o a confermare una transazione fraudolenta. A differenza di un attacco tradizionale, dove la compromissione segue percorsi tecnici riconoscibili (un exploit di sistema, un malware rilevato, un accesso non autorizzato loggato) qui la violazione avviene attraverso il linguaggio naturale e si maschera dietro operazioni apparentemente legittime. Tutto quello che vede il sistema di monitoraggio è un agente AI che svolge il proprio lavoro. I log registrano azioni autorizzate. Eppure, l’intento sottostante è completamente diverso da quello che l’azienda credeva di aver delegato alla macchina. Quando ci si accorge del problema, il danno è già fatto e la correzione non sarà più squisitamente tecnica, ma reputazionale, legale, finanziaria.
Costi reali e fiducia
Il costo di questi incidenti non è lineare. Non si tratta semplicemente di quantificare quanti record sono stati esposti o quanto denaro è stato sottratto. Si tratta di valutare l’erosione della fiducia dei clienti che scoprono che le loro informazioni sono state manipolate da un sistema che doveva proteggerle, la perdita di credibilità verso partner commerciali che ricevono comunicazioni falsificate ma apparentemente autentiche, le conseguenze normative quando un’autorità di vigilanza chiede conto di come sia stato possibile che un sistema automatizzato abbia violato policy dichiarate. Questi costi sono difficili da preventivare in anticipo, ma una volta materializzati, diventano dolorosamente evidenti. La vera domanda, quindi, non è se possiamo permetterci di fare red teaming, ma se possiamo permetterci di non farli.
Zzone d’ombra non monitorate
Il secondo motivo per cui questo diventa urgente proprio oggi riguarda la natura stessa della visibilità. Gli strumenti classici di sicurezza illuminano determinati angoli dell’infrastruttura, pensiamo al traffico di rete, agli accessi ai file, alle query ai database, ai tentativi di escalation dei privilegi. Ma lasciano al buio esattamente la zona in cui l’AI opera, quella delle intenzioni interpretate e delle azioni mediate dal linguaggio naturale. Un firewall applicativo non vede che una richiesta apparentemente innocua nasconde un’istruzione di esfiltrazione. Senza stress-test specifici, queste zone d’ombra restano tali e l’azienda opera nell’illusione di una copertura che in realtà non esiste.
Accelerare l’innovazione con chiarezza
Ma forse l’argomento più convincente, quello che risuona meglio nelle sale riunioni dove si decidono le priorità strategiche, è che i red teaming non rallentano l’innovazione, la accelerano. Paradossalmente, sapere con precisione dove si annidano i rischi reali riduce i blocchi e le resistenze interne che frenano l’adozione dell’AI. Quante volte un progetto promettente viene congelato perché qualcuno, a ragione, solleva dubbi di sicurezza che nessuno sa quantificare né tantomeno risolvere? Quante volte l’entusiasmo per una nuova funzionalità si scontra con la cautela di chi, responsabile della sicurezza o della conformità, non ha gli strumenti per distinguere tra rischio percepito e rischio reale? Un red teaming offre questa chiarezza. Trasforma l’incertezza generica in problemi specifici, misurabili, risolvibili. E una volta risolti, permette di procedere con maggiore velocità e fiducia, perché le decisioni non si basano più sulla paura dell’ignoto, ma sulla comprensione documentata di ciò che funziona e di ciò che va corretto.
Quadro normativo europeo e code of practice
A questi argomenti operativi si aggiunge ora una pressione normativa che rende il red teaming non più semplicemente una buona pratica, ma un requisito implicito o esplicito di conformità. Il Regolamento europeo sull’intelligenza artificiale AI Act, entrato in vigore nell’agosto 2024, impone ai fornitori e agli utilizzatori di sistemi ad alto rischio obblighi precisi come la gestione continua del rischio e la valutazione delle vulnerabilità, una documentazione tecnica che includa metriche e controlli, garanzie di accuratezza, robustezza e cybersecurity contro input malevoli o manipolazioni. Come si dimostra tutto questo senza un programma di testing avversario? Per i sistemi ad alto rischio, programmi di testing avversario e valutazioni sistematiche sono strumenti essenziali per dimostrare la conformità a questi requisiti, fornendo evidenze documentate sulla robustezza del sistema e sull’identificazione di vulnerabilità. Nel caso specifico dei modelli di AI generativa a uso generale (GPAI), gli obblighi sono ancor più stringenti: per i modelli con rischio sistemico, l’Articolo 55 dell’AI Act richiede esplicitamente “adversarial testing“, mentre il Code of Practice pubblicato nel luglio 2025 (strumento volontario per dimostrare la conformità, che chi scrive ha contribuito a redigere) dettaglia le procedure di valutazione dei rischi sistemici – includendo il red teaming tra i metodi raccomandati – la documentazione dei risultati, le mitigazioni di sicurezza, il monitoraggio post-commercializzazione e reporting degli incidenti gravi, con obblighi GPAI applicabili già dal 2025.
Gdpr, nis2 e dora: convergenza dei requisiti
Parallelamente, il GDPR richiede una valutazione d’impatto (DPIA) quando il trattamento è probabile comporti un rischio elevato, oltre a protezione dei dati fin dalla progettazione e sicurezza del trattamento. Per le aziende operanti in settori critici o essenziali, la Direttiva NIS2 impone gestione del rischio, resilienza operativa e incident reporting, mentre per il settore finanziario, DORA richiede esplicitamente testing di resilienza operativa delle infrastrutture ICT, inclusi test di penetrazione guidati dalla minaccia (TLPT) da condurre almeno ogni tre anni per le entità finanziarie designate dall’autorità competente (con frequenza adattabile al profilo di rischio). In questi contesti normativi, programmi di testing avversario come il red teaming rappresentano strumenti operativi efficaci per dimostrare conformità, riducendo contemporaneamente il rischio tecnico e legale e facilitando l’adozione di pratiche di sicurezza avanzate.
Quali sistemi testare per primi
Non tutti i sistemi di AI generativa presentano lo stesso profilo di rischio, e pretendere di applicare lo stesso livello di scrutinio a ogni implementazione sarebbe non solo dispendioso, ma controproducente. La chiave per un approccio efficace agli stress-test sta nell’identificare i punti in cui l’intersezione tra capacità operative dell’AI e impatto potenziale genera una superficie di vulnerabilità che merita attenzione immediata. Si tratta di concentrare le risorse là dove il rapporto tra probabilità di compromissione e gravità delle conseguenze giustifica l’investimento, lasciando per un secondo momento implementazioni più circoscritte o a basso impatto.
Chatbot pubblici e reputazione
Il primo ambito che richiede attenzione sono i chatbot esposti al pubblico, quelle interfacce conversazionali che rappresentano il volto digitale dell’azienda e con cui interagiscono clienti, partner e stakeholder in generale. La tentazione di considerarli sistemi “innocui” perché limitati a rispondere a domande è ingannevole. Questi assistenti sono spesso collegati a database aziendali per recuperare informazioni su prodotti, servizi, politiche, e proprio questa connessione li trasforma in potenziali vettori di esposizione. Un chatbot che, attraverso una manipolazione dell’input, viene indotto a rivelare dati riservati, come informazioni su clienti o categorie di clienti, listini non pubblici, dettagli su vulnerabilità di sistema, non sta semplicemente producendo una risposta imbarazzante, sta compromettendo asset aziendali. Analogamente, le allucinazioni o confabulazioni, quelle risposte inventate ma presentate con sicurezza che i modelli linguistici producono quando non hanno informazioni sufficienti, possono generare danni reputazionali non banali se l’utente le interpreta come posizioni ufficiali dell’azienda. Un consiglio medico sbagliato, un’informazione finanziaria distorta, una procedura di sicurezza inventata. Ognuno di questi scenari può tradursi in conseguenze legali, perdita di fiducia o, nei casi peggiori, danno fisico per chi segue quelle indicazioni credendole affidabili.
Agenti con capacità di azione
La seconda categoria critica riguarda gli assistenti o agenti AI collegati a strumenti che compiono azioni concrete, come accedere a e-mail, scrivere su sistemi di archiviazione condivisa come Google Drive, interagire con CRM ed ERP, autorizzare pagamenti o trasferimenti. Qui il rischio non è più solo informativo ma operativo. Un agente che, ingannato da una prompt injection indiretta contenuta in un documento caricato dall’utente, invia e-mail a nome dell’azienda, modifica record nei database dei clienti, conferma ordini fraudolenti o trasferisce fondi, sta esercitando potere reale nel mondo reale. Qui la distinzione tra consultare e agire è fondamentale. Un sistema che può solo leggere ha una superficie di rischio limitata alla confidenzialità, ma un sistema che può scrivere, modificare, eseguire, autorizzare, ha una superficie che include integrità, disponibilità e, alla fine, responsabilità legale. È come la differenza tra dare a qualcuno le chiavi della biblioteca e dargli le chiavi della cassaforte. Nel secondo caso, la fiducia deve essere guadagnata attraverso verifiche rigorose, non semplicemente presunta.
Sistemi RAG per decisioni operative
Un terzo ambito che merita priorità è quello dei sistemi RAG che alimentano decisioni operative. Qui l’AI non risponde semplicemente a domande generiche, ma fornisce informazioni che guidano azioni successive, come ad esempio quali siano le policy aziendali su un determinato tema, come va interpretato un contratto, quale procedura seguire in una situazione specifica. Se la base di conoscenza da cui il sistema attinge viene compromessa o manipolata, le risposte che produce diventano strumenti di disinformazione interna, capaci di far deviare processi, decisioni, comportamenti. Immaginiamo un sistema RAG utilizzato dal reparto legale per consultare clausole contrattuali standard. Se un attaccante riesce a introdurre documenti modificati nel repository, le raccomandazioni che il sistema fornisce agli avvocati potrebbero contenere termini sfavorevoli o addirittura illegali, senza che nessuno se ne accorga fino a quando il contratto non viene eseguito. La contaminazione del contesto, in questi scenari, è una vulnerabilità che tocca direttamente il cuore delle operazioni aziendali.
Automazioni ed esecuzione di codice
Infine, vi è la categoria forse più delicata: i sistemi che eseguono codice o orchestrano automazioni, quegli “autopiloti” interni che trasformano intenzioni espresse in linguaggio naturale in comandi eseguibili. Come per gli agenti, qui l’AI non si limita a suggerire, ma analizza repository di codice, propone modifiche, esegue script, automatizza workflow complessi. La superficie di rischio, in questi contesti, si espande fino a includere l’intera infrastruttura IT. Un agente con capacità di code execution che viene manipolato potrebbe diventare un vettore di compromissione totale poiché in grado di esfiltrare dati attraverso canali non monitorati, installare backdoor, modificare configurazioni di sistema, disabilitare controlli di sicurezza. La comodità di poter dire a un assistente “analizza questi log e correggi gli errori” si accompagna alla consapevolezza che, se quell’assistente viene dirottato, le conseguenze possono essere catastrofiche.
Regola pratica: testare ciò che può agire
Da questa mappatura possiamo derivare una regola pratica disarmante nella sua semplicità: se l’AI può fare qualcosa nel tuo ambiente (leggere, scrivere, eseguire, autorizzare, modificare), non basta fidarsi delle promesse del fornitore o delle buone intenzioni del team di sviluppo. Occorre testare. Verificare che i controlli funzionino, che i privilegi siano effettivamente limitati, che le catene di approvazione non possano essere aggirate, che le sandbox siano realmente isolate. La fiducia, in questi contesti, non può essere un atto di fede ma deve essere il risultato di una verifica documentata e ripetibile. Ogni capacità operativa che si delega all’AI senza averla prima sottoposta a stress controllato è una scommessa che l’azienda fa sul fatto che nessuno scoprirà come abusarne. E la storia della sicurezza informatica ci insegna che queste scommesse, prima o poi, si perdono sempre.
Falsi miti da sfatare
Nelle conversazioni con i responsabili delle decisioni strategiche si scorge spesso un insieme di convinzioni rassicuranti, affermazioni che suonano ragionevoli e che, a prima vista, sembrano fornire argomenti solidi per rimandare o ridimensionare gli investimenti in red teaming per l’AI generativa. Queste convinzioni non nascono da malafede né da ignoranza, sia inteso, ma da un’estensione naturale di ciò che funzionava in contesti precedenti, ovvero da un’applicazione intuitiva di principi che hanno governato la sicurezza informatica per decenni. Eppure, proprio perché intuitive, queste affermazioni diventano pericolose. Creano un senso di falsa sicurezza che impedisce di vedere dove si annidano le vere vulnerabilità.
Mito 1: ci salva il grande vendor
La prima di queste convinzioni rassicuranti è: “Adottiamo l’AI di un grande produttore, ci fidiamo delle sue protezioni.” È un ragionamento che ha una logica solida alle spalle. I grandi vendor tecnologici investono miliardi in ricerca e sviluppo, dispongono di team di sicurezza di livello mondiale, sottopongono i loro modelli a test rigorosi prima del rilascio. Affidarsi a loro, piuttosto che sviluppare soluzioni interne o rivolgersi a fornitori minori, sembra la scelta più prudente.
C’è da dire anzitutto che chi scrive ha partecipato a bounty, hackathon ed esercizi di capture-the-flag anche sui sistemi di queste aziende “big tech”, e sebbene non sia possibile rivelare dettagli, possiamo tranquillamente affermare che i sistemi testati non erano certo impenetrabili. Ma anche se volessimo considerare i prodotti più famosi come sicuri quando usati in isolamento, il problema è che le aziende non utilizzano mai l’AI in isolamento. La utilizzano integrata nei loro processi, collegata ai loro database, connessa alle loro API, autorizzata ad accedere ai loro sistemi. Ed è proprio in questa integrazione che nascono la maggior parte delle vulnerabilità operative. Un modello può essere intrinsecamente sicuro, resistente a jailbreak, privo di bias evidenti, accurato nelle risposte, e allo stesso tempo diventare un vettore di compromissione nel momento in cui viene collegato all’infrastruttura aziendale. Il vendor ha progettato il modello per essere robusto, ma non può prevedere né controllare come ogni singola azienda lo integrerà, quali privilegi gli concederà, quali tool metterà a sua disposizione, quali dati gli renderà accessibili.
La sicurezza del componente non garantisce la sicurezza del sistema. È come acquistare una serratura di altissima qualità e installarla su una porta di cartone, il problema non sta nella serratura, ma nel contesto in cui viene utilizzata. Gli stress-test servono proprio a questo, a verificare non se il modello in sé è sicuro, ma se il modo in cui lo abbiamo integrato introduce vulnerabilità che il vendor non poteva anticipare e che quindi le sue protezioni non coprono.
Mito 2: niente dati sensibili nei prompt basta
Una seconda affermazione rassicurante è altrettanto diffusa: “Non facciamo mettere ai nostri dipendenti dati sensibili direttamente nei prompt, quindi non c’è rischio di esposizione.” Anche qui, l’intuizione di partenza è corretta. Evitare di inserire credenziali, segreti aziendali o informazioni riservate direttamente nelle istruzioni che si danno al modello è una buona pratica elementare. Ma questa cautela copre solo una frazione minuscola della superficie di rischio. Ripetiamo nuovamente che l’AI generativa non opera in isolamento. È integrata, si collega ad altri sistemi, può attraversare confini organizzativi con la stessa facilità con cui elabora una frase. Dire “non mettiamo dati sensibili nel prompt” equivale a dire “non lasciamo denaro sul tavolo”, ignorando che l’AI ha le chiavi del caveau e può raggiungerlo autonomamente. La vulnerabilità non sta in ciò che l’utente fornisce, ma in ciò che il sistema può recuperare una volta manipolato. Una prompt injection ben costruita non chiede all’AI di ripetere segreti che le sono stati forniti, le chiede di andare a cercarli dove sono conservati, usando proprio gli strumenti di integrazione che l’azienda ha accuratamente implementato per rendere il sistema “intelligente” e “connesso”. La protezione del prompt è il primo passo, non certo l’ultimo.
Mito 3: pen-test tradizionali bastano
Il terzo mito è forse il più insidioso perché si basa su una pratica consolidata e rispettata: “Facciamo già penetration test sulla nostra infrastruttura web, quindi la sicurezza è coperta.” I pen-test tradizionali sono strumenti collaudati, discipline mature che hanno difeso le aziende per decenni. Ma sono progettati per un mondo in cui le applicazioni seguono logiche deterministiche e prevedibili. Un input genera un output secondo regole codificate, i percorsi di esecuzione sono tracciabili, le vulnerabilità si manifestano attraverso deviazioni da comportamenti attesi. Come già scritto, l’AI generativa sovverte questo paradigma. Un pen-tester esperto può scoprire una SQL injection, un’escalation di privilegi, un’esposizione di dati attraverso configurazioni errate. Ma difficilmente intercetterà il fatto che una frase apparentemente innocua in linguaggio naturale può indurre un agente conversazionale a compiere una sequenza di azioni che nessun attaccante tradizionale avrebbe mai potuto orchestrare. La logica dell’AI è intenzione tradotta in azione, non comando tradotto in esecuzione. È semantica, non sintassi. I pen-test classici cercano le crepe nel codice. Gli stress-test per l’AI cercano le crepe nel ragionamento, nei percorsi decisionali, nelle catene di tool che si attivano in risposta a input progettati per manipolare il contesto anziché sfruttare bug tecnici. Sono discipline complementari, non sovrapponibili, e pensare che una possa sostituire l’altra è come credere che un cardiologo possa fare anche il lavoro del neurologo semplicemente perché entrambi sono medici.
La psicologia del rinvio
Ciò che accomuna questi tre miti è la stessa radice psicologica, il desiderio comprensibile di applicare al nuovo ciò che già conosciamo, di estendere soluzioni consolidate a problemi emergenti, di evitare di ammettere che potremmo trovarci davanti a una discontinuità che richiede approcci inediti, faticosi da apprendere, proni a nuovi errori. Ma negare la specificità delle vulnerabilità dell’AI generativa non le fa scomparire, semplicemente le lascia prosperare indisturbate fino a quando non si manifesteranno attraverso incidenti che, a quel punto, saranno ben più costosi da gestire rispetto all’investimento preventivo che avremmo potuto fare. Riconoscere questi miti per quello che sono, ovvero semplificazioni rassicuranti ma pericolose, è il primo passo per costruire una strategia di sicurezza che sia all’altezza della tecnologia che stiamo adottando.
Conclusione: responsabilità e vantaggio competitivo
I red teaming dell’intelligenza artificiale generativa non sono, alla fine, semplicemente una questione di conformità normativa o di riduzione del rischio informatico. Sono un esercizio di consapevolezza organizzativa, un modo per costringere l’azienda a confrontarsi con interrogativo che spesso preferirebbe evitare: cosa stiamo davvero delegando alle macchine, e siamo disposti ad accettarne le conseguenze?
Ogni sistema di AI messo in produzione rappresenta una scommessa sulla fiducia. Fiducia nel fatto che il modello si comporterà come previsto, che le integrazioni funzioneranno senza effetti collaterali, che i controlli di sicurezza reggeranno sotto pressione, che gli utenti non troveranno modi creativi di aggirare le protezioni. È una scommessa che molte organizzazioni fanno implicitamente, senza nemmeno rendersi conto di averla fatta, spinte dall’entusiasmo per l’innovazione o dalla pressione competitiva a non restare indietro. I red teaming trasformano questa scommessa implicita in una scelta esplicita. Costringono a guardare dove si sta camminando, a mappare i confini tra ciò che l’AI può fare e ciò che dovrebbe fare, a distinguere tra capacità tecniche e autorizzazioni operative.
Ma il valore di questa pratica non si esaurisce nella scoperta di vulnerabilità specifiche o nella correzione di configurazioni errate. Il vero cambiamento avviene a un livello più profondo, culturale. Un’azienda che sottopone i propri sistemi di AI a stress controllati sta implicitamente riconoscendo che la sicurezza non è un problema che si risolve una volta per tutte, ma una disciplina che si coltiva continuamente. Sta ammettendo che le promesse dei vendor, per quanto serie, non possono sostituire la verifica diretta. Sta accettando che l’innovazione senza prudenza non è progresso, ma imprudenza mascherata da ambizione. E soprattutto, sta costruendo le basi per una fiducia guadagnata, non presunta, con clienti, dipendenti, regolatori e stakeholder.
Nel tempo, i red teaming smetteranno di essere percepiti come un peso o un ostacolo per essere visti per quello che sono, ossia un vantaggio competitivo. Le aziende che sanno dove sono vulnerabili si muovono con maggiore sicurezza di quelle che lo ignorano. Le aziende che possono dimostrare, dati alla mano, di aver testato e mitigato i rischi ottengono la fiducia di clienti sempre più attenti e diffidenti. Le aziende che integrano la sicurezza fin dalla progettazione evitano i costi enormi della correzione tardiva e della gestione delle crisi.
L’intelligenza artificiale generativa non sta aspettando che le aziende si decidano a prenderla sul serio. Si sta diffondendo, con o senza stress-test, con o senza consapevolezza dei rischi, con o senza strategie di mitigazione. La domanda non è se adottarla, ma come adottarla in modo che tra uno o due anni possiamo guardare indietro senza rimpianti. I red teaming non rappresentano una garanzia di perfezione (quella non esiste in nessun ambito della sicurezza informatica), ma la condizione minima per poter affermare di aver agito con responsabilità.
