L’esplosione dell’utilizzo dell’AI dal 2023 a oggi è senza precedenti. In termini di adozione, l’AI sta avanzando più rapidamente del cloud, del mobile e, certamente, di quanto abbia fatto Internet. Secondo le previsioni di Gartner, quest’anno l’80% delle aziende implementerà soluzioni di AI.
Quando analizziamo il percorso di adozione dell’AI nelle organizzazioni, possiamo identificare quattro livelli di maturità:
- Categoria 1: AI per uso generale e produttività, ad esempio dipendenti che utilizzano ChatGPT, Gemini, Copilot e strumenti simili.
- Categoria 2: casi d’uso interni, in cui le organizzazioni sviluppano chatbot personalizzati per funzioni come le risorse umane e l’IT.
- Categoria 3: casi d’uso esterni, come applicazioni di AI generativa rivolte ai clienti, ad esempio i chatbot per il customer service.
- Categoria 4: workflow agentici, costituiti da sistemi complessi in grado di eseguire azioni autonomamente per conto degli utenti.
Queste categorie spesso si sviluppano in parallelo anziché in modo sequenziale, ma è nelle ultime tre che la sicurezza diventa un fattore critico. Questo perché le organizzazioni stanno costruendo software complessi su modelli di AI non deterministici, introducendo vulnerabilità che i firewall tradizionali semplicemente non sono in grado di rilevare.
La sicurezza è da sempre una priorità per le aziende, ma con l’AI la sfida è diversa: si tratta di un vero e proprio punto cieco. Negli ultimi vent’anni, i responsabili della sicurezza hanno implementato e configurato firewall e web application firewall (WAF) per proteggere le reti aziendali. Tuttavia, questi strumenti analizzano il traffico di rete e il comportamento delle applicazioni, mentre gli attacchi contro i sistemi di AI sfruttano il linguaggio naturale. E una conversazione non può essere protetta da un firewall.
Per questo il 75% dei CISO dichiara di aver già registrato incidenti di sicurezza legati all’AI: le difese esistenti non sono state progettate per intercettare questo tipo di minacce. Per lo stesso motivo, il 91% ha già rilevato tentativi di attacco alla propria infrastruttura di AI e ben il 94% considera oggi prioritario sottoporre i propri sistemi di AI a test e valutazioni di sicurezza.
Nuove categorie di attacchi cognitivi
Esistono numerosi esempi concreti di come l’AI stia ridefinendo il panorama delle minacce. Una violazione verificatasi presso Asana la scorsa estate è derivato da un errore logico relativo all’isolamento dei tenant nel server MCP , che ha consentito l’esposizione di dati tra organizzazioni diverse. Si tratta di un classico bug multi-tenant, ma nei sistemi basati su LLM risulta particolarmente pericoloso perché i dati compromessi vengono restituiti sotto forma di linguaggio naturale fluido, rendendo l’anomalia molto più difficile da individuare.
Un incidente che ha coinvolto Lenovo ha invece evidenziato una diversa tipologia di vulnerabilità: la compromissione dei confini di fiducia. Un prompt injection ha ridefinito il ruolo di un chatbot Lenovo e i sistemi di back-end hanno accettato le sue richieste di utilizzo degli strumenti senza applicare adeguati controlli di autorizzazione lato server. Il problema non era che il modello di AI ignorasse le regole, bensì che l’autorizzazione fosse stata delegata al modello stesso.
Questi sono solo due esempi che si inseriscono in un panorama di rischi emergenti molto più ampio. Le organizzazioni non devono più affrontare esclusivamente la vulnerabilità del codice, ma si trovano a fronteggiare categorie completamente nuove di attacchi cognitivi, tra cui:
- Prompt injection, sia diretta che indiretta
- Data poisoning durante la fase di addestramento
- Tecniche avanzate di jailbreak, come gli attacchi basati sul linguaggio simbolico
- Token compression, in cui gli aggressori nascondono istruzioni malevole in formati leggibili dai modelli di AI ma non dagli esseri umani
Se i tradizionali controlli di sicurezza sono progettati per gestire input deterministici, la prompt injection e gli altri attacchi basati sul linguaggio naturale rappresentano problemi semantici, non semplici questioni di riconoscimento di pattern. Non si tratta di vulnerabilità isolate, ma di rischi aziendali sistemici introdotti dalle nuove architetture basate sull’AI.
Il settore sta lavorando per classificare e comprendere queste vulnerabilità. Stanno emergendo framework come l’OWASP Top 10 for GenAI and Agentic Applications, il MITRE ATLAS e il NIST AI Risk Management Framework, ma manca ancora un database di riferimento o uno standard condiviso che definisca in modo univoco cosa significhi realmente essere sicuri.
Il vecchio approccio non riesce più a tenere il passo
La pressione che oggi grava sulle aziende per adottare l’AI è enorme. Gli sviluppatori utilizzano l’intelligenza artificiale per scrivere codici a una velocità fino a dieci volte superiore rispetto al passato e le organizzazioni rilasciano letteralmente nuove funzionalità, e persino nuovi prodotti, nel giro di poche ore.
Allo stesso tempo, anche il quadro normativo sta evolvendo rapidamente. L’AI Act dell’Unione Europea, ad esempio, prevede esplicitamente attività di adversarial testing per i sistemi di AI ad alto rischio e per i modelli di uso generale.
In pratica, ciò significa che il red teaming appositamente progettato, ovvero la verifica dei sistemi di AI attraverso attacchi avversariali simulati, deve ormai essere considerato una componente fondamentale dello stack di sicurezza dell’AI e progettato per rispecchiare le minacce e gli scenari reali a cui questi sistemi sono esposti.
Ai CISO e ai team di sicurezza viene quindi chiesto di proteggere cambiamenti che avvengono alla velocità delle macchine. Come? Digitando manualmente prompt in una finestra di chat? È come cercare di fermare uno tsunami con un secchio. L’approccio non è sostenibile. I tempi non sono sostenibili. La superficie di attacco dell’AI è profondamente diversa da quella dei sistemi tradizionali e i metodi di sicurezza del passato non sono più sufficienti a tenere il passo.
È evidente che il red-teaming tradizionale non sia più sufficiente e che è necessario adottare un approccio di AI red-teaming per risolvere la tensione tra velocità e controllo. Dalle conversazioni con i clienti che supportiamo nella protezione dei loro sistemi di AI emergono quattro aspetti fondamentali da considerare:
- Evoluzione delle minacce: gli attacchi ai sistemi di AI evolvono più rapidamente delle suite di test statiche. Non appena i controlli vengono automatizzati, il modello o la tecnica di attacco cambiano, e i team di sicurezza finiscono per dedicare il proprio tempo alla manutenzione dei test anziché alla riduzione del rischio.
- Complessità degli agenti: poiché gli agenti AI non sono sistemi deterministici, una volta introdotti retrieval, strumenti e memoria, le possibili combinazioni diventano pressoché infinite. Non si sta più testando un codice, ma una conversazione che cambia continuamente in base al contesto.
- Automazione e scalabilità: il red-teaming manuale non è scalabile per questi sistemi. Un chatbot può essere gestibile, ma centinaia o migliaia di chatbot non lo sono. E non è possibile affidarsi a operatori umani per riprodurre migliaia di conversazioni avversariali ogni volta che il modello o il system prompt vengono aggiornati.
- Reporting azionabile: i risultati devono essere riproducibili e tradursi in interventi concreti. Dire che “il bot si è comportato male” non è sufficiente. Gli ingegneri hanno bisogno dei parametri della conversazione e delle condizioni che hanno innescato il comportamento, altrimenti le attività di correzione e mitigazione rischiano di bloccarsi.
Garantire che i sistemi di AI si comportino come previsto, anche sotto attacco
Queste sono le lacune concrete che i team di sicurezza stanno cercando di colmare oggi, ed è per questo che l’AI red-teaming sta assumendo un ruolo sempre più centrale. Ad esempio, uno dei nostri clienti è una banca globale che opera in un contesto altamente regolamentato.
Quando abbiamo iniziato a collaborare, questa organizzazione disponeva di oltre 50 casi d’uso dell’AI nelle aree HR, procurement e cybersecurity, ma non poteva portarne in produzione nessuno perché non era in grado di dimostrarne la sicurezza ai propri auditor interni. L’AI red-teaming ha fornito alla banca le evidenze necessarie per comprendere come si comportassero realmente i suoi sistemi di AI: dove potevano verificarsi perdite di dati, in che modo i prompt potevano essere sfruttati in modo improprio e in quali punti i controlli risultavano inefficaci all’interno del suo ambiente operativo.
La banca sta ora utilizzando i risultati delle attività di red-teaming per rafforzare la propria postura di sicurezza attraverso controlli personalizzati. Questa combinazione le consente di scalare l’adozione dell’AI in tutta l’organizzazione con fiducia nella propria strategia di sicurezza e nel programma di governance.
Nel settore pubblico, invece, l’approccio passa da attività di testing volontarie a verifiche obbligatorie, negli Stati Uniti guidate da enti come il NIST (National Institute of Standards and Technology) e la CISA (Cybersecurity and Infrastructure Security Agency), che prevedono, ad esempio, l’esecuzione di stress test avversariali per individuare rischi mission-critical, come l’utilizzo malevolo di dati biologici. In questo contesto, l’AI red-teaming non serve soltanto a ridurre il rischio, ma anche a mantenere l’autorizzazione a operare e a garantire la continuità operativa.
In altre parole, che si tratti di proteggere i dati dei clienti o i servizi pubblici, l’esigenza è la stessa: disporre di una garanzia continua, supportata da evidenze, che i sistemi di AI si comportino come previsto, anche quando qualcuno tenta deliberatamente di comprometterli.
Implementare l’AI con fiducia
È evidente che le organizzazioni che adottano l’AI necessitano di test automatizzati sulle vulnerabilità note, anche solo per definire una baseline di sicurezza. Il contesto rappresenta la nuova superficie di attacco: le difese statiche non sono efficaci contro gli attacchi agentici e, per questo, è necessario testare i workload, non soltanto i modelli.
Infine, la conformità può rappresentare un vantaggio competitivo. Con una reportistica adeguata, la sicurezza smette di essere un ostacolo e diventa un fattore abilitante, in grado di accelerare il percorso di adozione dell’AI e il time-to-market delle iniziative aziendali. In questo scenario, l’80% delle aziende che prevede di implementare l’AI quest’anno potrà farlo con fiducia anziché con timore, indipendentemente dal livello di maturità raggiunto nel proprio percorso di adozione.
