OWASP Top 10 LLM 2026: i dieci rischi dell’intelligenza artificiale ed i vincoli di conformità stabiliti da GDPR ed AI Act

Perché si impone una riflessione di ordine sistematico

La presenza dell’intelligenza artificiale è ormai divenuta una consuetudine quasi impercettibile: affidiamo ad un agente software il compito di sintetizzare il verbale di una riunione, consentiamo ad un chatbot di interfacciarsi con l’utenza od autorizziamo un sistema d’IA ad accedere ai nostri archivi per rintracciare files di vario tipo. Dietro ciascuna di queste opzioni operative opera un Large Language Model (LLM), a cui sono stati collegati dati personali, documenti e strumenti. Abbiamo affidato le chiavi d’accesso alla nostra sfera personale e professionale ad un’architettura di calcolo che, per sua natura, non possiede la capacità di scindere logicamente un comando autoritativo da un semplice dato informativo.

La questione ha assunto la massima necessità di attenzione nel corso dell’estate del 2026: nel mese di agosto, il progetto GenAI Security della Fondazione OWASP ha reso pubblica la OWASP Top 10 LLM 2026, terza edizione del catalogo dei rischi primari per le applicazioni fondate su modelli linguistici ed unica ad aver ponderato la valutazione degli esperti con un rigoroso repertorio di eventi dannosi concretamente verificatisi. Nel medesimo periodo, il Regolamento (UE) 2026/1744 ha riordinato la tempistica di applicazione dell’AI Act in materia di sistemi ad alto rischio. Nello svolgimento delle pagine che seguono, intendo illustrare la metodologia sottesa a tale classificazione, analizzare le dieci figure di rischio secondo lo sviluppo lineare del trattamento dei dati ed evidenziare i nessi inscindibili che legano ciascuna vulnerabilità agli obblighi prescritti dal GDPR ed al quadro normativo dell’Unione Europea con particolare riguardo all’AI Act.

Al fine di inquadrare la portata dei rischi in esame, appare opportuno muovere dall’esame di una vicenda emblematica che ha segnato le prime tappe di questa evoluzione tecnologica e regolatoria.

Il 20 marzo 2023, una falla verificatasi in una libreria di terze parti impiegata dall’applicazione ChatGPT rese visibili ad alcuni utenti i titoli delle conversazioni altrui ed i dati di pagamento relativi ad una frazione degli abbonati al servizio Plus (pari all’1,2 per cento circa dei soggetti coinvolti, secondo quanto riportato nel documento OWASP). Il Garante per la protezione dei dati personali fece espresso riferimento a tale perdita di riservatezza nel comunicato stampa del 31 marzo 2023¹, dando notizia del provvedimento di limitazione provvisoria n. 112 adottato il giorno precedente²; nel dicembre del 2024, l’Autorità ha chiuso l’istruttoria comminando una sanzione di 15 milioni di euro ed addebitando, tra i diversi profili, l’omessa notifica dell’evento di data breach³. Tale provvedimento (n. 755 del 2 novembre 2024) è stato successivamente rimosso dal sito istituzionale dell’Autorità a seguito della sentenza del Tribunale di Roma n. 4153/2026, che ha accolto l’opposizione proposta dalla società OpenAI. Il report OWASP ha inteso citare questo specifico precedente quale eclatante manifestazione della seconda figura di rischio della propria graduatoria.

Struttura ed origine della OWASP Top 10 LLM 2026

La OWASP Top 10 LLM si configura quale opera scientifica e divulgativa, distribuita con licenza Creative Commons, che analizza per ciascuna fattispecie di pericolo la dinamica tecnica, le strategie di prevenzione ed una serie di scenari desunti dalla prassi applicativa. Se le precedenti edizioni del 2023 e del 2025 poggiavano esclusivamente sulle valutazioni qualitative dei tecnici, la versione del 2026 ha affiancato alla consultazione della comunità scientifica l’esame sistematico di ben 7.714 incidenti reali, dei quali 6.639 correlati da elementi di dettaglio tali da permetterne una rigorosa catalogazione. È d’uopo tuttavia rilevare come la percezione degli specialisti ed i riscontri della casistica reale non abbiano sempre coinciso.

Tale classificazione mantiene la propria validità finché il modello linguistico rimane un semplice componente computazionale del sistema. Non appena la struttura si evolve ed assume natura agentica -dotandosi di memoria storica tra le diverse sessioni ed integrando strumenti software capaci di agire sul mondo esterno- l’analisi del rischio deve necessariamente estendersi alla parallela OWASP Top 10 ASI (Agentic Systems/Applications). Le due trattazioni devono pertanto essere lette ed interpretate congiuntamente ed in modo complementare.

La graduatoria OWASP Top 10 LLM 2026 e le novità rispetto al 2025

Le prime due posizioni della classifica rimangono invariate. L’eccessiva autonomia dell’agente guadagna tre posizioni, salendo dal sesto al terzo posto e segnando un’evoluzione che i curatori definiscono epocale: i dati empirici e le rilevazioni sul campo concordano nell’evidenziare come i danni di maggiore gravità si concentrino proprio nell’ambito delle applicazioni agentiche moderne. La gestione impropria dell’output scende dal quinto al decimo posto, mentre la figura originariamente denominata “fuga del prompt di sistema” assume ora la più precisa veste dell’esposizione del contesto nascosto.

Ciascuna fattispecie ha progressivamente ricompreso in sé categorie d’attacco emergenti, che spaziano dalle istruzioni malevole veicolate tramite immagini ed archivi audio sino al codice insicuro generato dagli assistenti alla programmazione. Al fine di comprendere appieno l’interconnessione sistematica tra i dieci rischi, il metodo più lineare consiste nel seguire il percorso dinamico compiuto da un dato all’interno dell’architettura applicativa.

Anatomia dei dieci rischi OWASP lungo il ciclo di trattamento del dato

Si ipotizzi la presenza di un assistente software aziendale a cui un operatore richieda di predisporre una risposta destinata ad un cliente: il sistema (1) analizza ed interpreta la richiesta, (2) recupera dalle basi dati aziendali i documenti pertinenti, (3) invoca un modulo esterno per l’invio del messaggio di posta ed (4) elabora infine il testo di risposta. In ciascuno di tali passaggi si adombra almeno una fattispecie di rischio.

All’ingresso: iniezione di prompt e contesto nascosto

La fase iniziale consiste nell’acquisizione e nella lettura delle istruzioni. L’iniezione di prompt (LLM01) si configura allorché un input alterato induce il modello a deviare dal comportamento stabilito dai suoi programmatori. L’istruzione malevola può provenire direttamente dall’utente od giungere indirettamente da un documento recuperato, da un’immagine, da un file audio o dalla memoria conservata dall’assistente tra sessioni diverse. Il modello linguistico elabora indistintamente istruzioni e dati sotto forma di token (ovvero quali unità sintattiche minime del testo) all’interno del medesimo flusso; ne deriva l’assenza di un meccanismo isolante analogo alle query parametrizzate, cioè a quella soluzione tecnica che negli anni Duemila ha chiuso la strada alle vulnerabilità di SQL injection nei database relazionali. Una contromisura difensiva del tutto inattaccabile non è ad oggi disponibile ed il documento lo rimarca citando l’autorevole studio condotto da Nasr e colleghi (2025): gli attacchi di tipo adattivo, concepiti da analisti che conoscevano preventivamente la struttura delle difese, hanno ottenuto oltre il 90 per cento di successo contro la quasi totalità di dodici recenti soluzioni difensive, a fronte di test statici che avevano inizialmente mostrato percentuali di protezione apparentemente prossime al 100%.

Nella medesima finestra di contesto, il modello elabora altresì quanto rimane celato all’utente finale: il prompt di sistema (System Prompt), vale a dire l’insieme delle istruzioni direttive imposte dallo sviluppatore, i vincoli normativi ed etici di condotta e gli schemi di chiamata alle funzioni esterne. Tale complesso costituisce il cosiddetto contesto nascosto (LLM08), un elemento che deve essere progettato muovendo dal rigoroso presupposto della sua costante ostendibilità: è fatto divieto assoluto di inserirvi credenziali di autenticazione od di affidare le logiche di autorizzazione alla sola custodia del contesto. Un attaccante che sia giunto a conoscere le regole di rifiuto imposte ad un chatbot sarà perfettamente in grado di individuare le locuzioni idonee ad eluderne i filtri.

Nei dati: divulgazione, vettori, avvelenamento e filiera

La seconda fase attiene al reperimento documentale (Retrieval), contesto nel quale si concentrano i rischi di primario interesse per chi si occupa di protezione dei dati personali e riservatezza aziendale. La divulgazione di informazioni sensibili (LLM02) può manifestarsi attraverso qualsiasi canale di comunicazione uscente dall’applicazione. La risposta mostrata a schermo rappresenta soltanto uno di tali vettori: dati riservati possono essere veicolati mediante chiamate a funzioni ed API esterne, tracce di ragionamento (reasoning logs), registri di sistema od archivi di embedding, vale a dire le rappresentazioni numeriche attraverso cui il sistema misura la somiglianza semantica dei testi. All’origine di molteplici data breach si riscontrano cartelle condivise prive di idonea segregazione dei permessi, le quali alimentano l’indice con dati personali che il modello recupera ed espone in conformità alle proprie istruzioni. Un dato che abbia condizionato i pesi del modello in fase di addestramento rimane inoltre potenzialmente estraibile anche a seguito della formale eliminazione della fonte originaria: il documento OWASP lega espressamente tale criticità al diritto alla cancellazione sancito dall’art. 17 del GDPR.

Gli archivi vettoriali presentano profili di rischio specifici (LLM09), giacché la ricerca per affinità semantica su cui si fondano le architetture RAG (Retrieval-Augmented Generation) espone il sistema a minacce indipendenti dalle istruzioni testuali: l’avvelenamento (poisoning) altera la precisione della ricerca, l’inversione determina la fuga dei dati sorgente ed il jamming rende l’indice non responsivo. È specialmente la vulnerabilità all’inversione a mutare la valutazione d’impatto sulla sicurezza. Secondo i recenti studi richiamati nel report, partendo dalle sole rappresentazioni vettoriali ed applicando metodologie avanzate (quali il metodo Vec2Text di Morris e colleghi), si è giunti a ricostruire il testo originario con un grado di accuratezza esatta fino al 92 per cento per input brevi. Ne discende che le copie di backup di una banca dati vettoriale debbono essere custodite con le medesime garanzie di sicurezza ed opacità riservate ai documenti originari.

Ancor prima della fase di recupero, i dati possono essere stati corrotti alla radice. L’avvelenamento di dati e modelli (LLM05) manipola le basi informative od gli artefatti del modello per introdurvi comportamenti dannosi e latenti, colpendo il processo primario di apprendimento e non un isolato difetto di runtime: nei casi esaminati, la risoluzione dell’incidente ha imposto il riaddestramento integrale od la sostituzione del modello. Lo studio firmato da Souly e colleghi (2025) ha dimostrato come siano bastati appena 250 documenti avvelenati per compromettere la sicurezza di modelli aventi dimensioni variabili da 600 milioni a 13 miliardi di parametri. La catena di fornitura (LLM04) rappresenta la linea d’ingresso di tali vulnerabilità: modelli pre-addestrati forniti di backdoor (ossia comportamenti nascosti attivabili mediante comandi specifici), file di configurazione che eseguono codice malevolo al momento del caricamento, od clausole contrattuali che attribuiscono al fornitore la facoltà di riaddestrare i propri algoritmi sui dati inseriti dall’organizzazione cliente.

Nelle azioni: autonomia e consumo delle risorse

Il terzo passaggio riguarda l’esecuzione di azioni concrete. L’eccessiva autonomia (LLM03) consente il compimento di operazioni pregiudizievoli in risposta ad output imprevisti, ambigui o deliberatamente manipolati, quale che ne sia la causa. Essa trae origine dall’attribuzione al sistema di funzionalità sproporzionate, di permessi eccessivi o di un margine decisionale non presidiato. L’esempio proposto dal documento OWASP riguarda proprio il nostro assistente aziendale: esso avrebbe dovuto limitarsi alla lettura della posta elettronica, ma lo strumento messogli a disposizione consentiva anche l’invio dei messaggi. Un’email confezionata ad arte da un soggetto esterno lo ha così indotto ad inoltrare documenti riservati all’attaccante. La prevenzione impone di ridurre strumenti e funzioni al minimo indispensabile, assegnando a ciascun agente un’identità informatica dedicata e permessi circoscritti. La decisione sull’ammissibilità di un’azione non va mai rimessa al modello: deve essere assunta all’esterno da un motore di regole deterministico, che subordini ogni operazione dagli effetti irreversibili all’approvazione di un operatore umano.

Anche quando opera correttamente, l’assistente assorbe risorse di calcolo. Il consumo non limitato (LLM06) discende da una marcata asimmetria dei costi: con una spesa irrisoria un attaccante può provocare elaborazioni estremamente onerose, fino all’interruzione del servizio od alla produzione di costi insostenibili, fenomeno che il documento OWASP definisce Denial of Wallet (esaurimento delle risorse finanziarie). Occorrono perciò tetti di spesa vincolanti (hard cap), capaci di arrestare l’elaborazione invece di limitarsi a segnalare il superamento della soglia.

In uscita: disinformazione ed output non controllato

La fase conclusiva coincide con la restituzione della risposta. La disinformazione (LLM07) consiste in un output errato, incompleto o fuorviante, formulato con un tono talmente sicuro da indurre in errore il decisore umano o da alterare un flusso di lavoro automatizzato. Il documento OWASP la qualifica come un vero e proprio guasto di sistema e ne offre esempi di marcato realismo: un agente di assistenza che applica in modo scorretto le condizioni contrattuali ed approva un rimborso non dovuto, un riassunto clinico che omette una controindicazione farmacologica, un agente che attesta come eseguito un backup in realtà mai effettuato. La contromisura d’elezione consiste nel separare la generazione del testo dall’esecuzione dell’operazione e nel verificare la fondatezza delle affermazioni prima di dare corso all’azione.

La gestione impropria dell’output (LLM10) completa la sequenza dei rischi. Poiché il contenuto generato dal modello può essere eterodiretto mediante prompt injection, inoltrarlo senza controlli ad un interprete di comandi, ad un browser od ad una banca dati equivale ad attribuire a chiunque scriva al sistema un accesso indiretto a quelle stesse funzionalità. Ne sono derivati, nella prassi, casi di esecuzione di codice da remoto (RCE, Remote Code Execution), iniezioni di comandi SQL nelle basi di dati e vulnerabilità di Cross-Site Scripting (XSS), cioè l’inserimento di script malevoli nelle pagine web. La regola architetturale consiste dunque nel trattare ogni output di un modello linguistico come un dato proveniente da una fonte esterna non fidata. Considerati nel loro insieme, i dieci rischi convergono verso un’unica tesi di fondo.

Il filo conduttore: progettare il sistema attorno al modello

La lettera introduttiva dei responsabili del progetto, Steve Wilson e Rock Lambros, enuncia un principio che attraversa l’intera opera: occorre abbandonare l’illusione di poter istruire un modello che non sia mai ingannabile e progettare invece l’architettura in modo che, quando il modello verrà ingannato, la sicurezza del sistema rimanga integra. Le medesime contromisure ricorrono infatti trasversalmente nelle diverse fattispecie: autorizzazioni gestite all’esterno del modello, principio del minimo privilegio, validazione dell’output, tracciabilità della provenienza degli artefatti e limiti vincolanti al consumo di risorse.

Questa impostazione ha una ricaduta giuridica diretta, poiché delimita ciò che il titolare del trattamento può e deve ragionevolmente attuare e ciò che, al contrario, non può promettere al mercato ed agli interessati. È dunque opportuno ritornare al caso concreto da cui abbiamo preso le mosse.

OWASP Top 10 LLM e GDPR: le ricadute operative per il titolare del trattamento

L’incidente che ha interessato ChatGPT nel marzo del 2023 costituisce una tipica manifestazione del rischio LLM02, che il Garante ha affrontato con gli strumenti ordinari del GDPR. Il documento OWASP, in effetti, non introduce obblighi nuovi: conferisce sostanza tecnica a quelli che la norma già contempla. L’art. 32 impone misure di sicurezza adeguate al rischio tenendo conto dello stato dell’arte. Una classificazione pubblica ed accreditata, confrontata con 7.714 incidenti reali, ne offre un’autorevole descrizione per le applicazioni fondate su modelli linguistici. Il titolare che abbia messo in esercizio un chatbot collegato a dati personali senza considerare la prompt injection e la gestione dell’output incontrerà perciò serie difficoltà nel dimostrare l’adeguatezza delle proprie misure.

La lett. d) del par. 1 del medesimo articolo prescrive di testare, verificare e valutare regolarmente l’efficacia di tali misure: alla luce del documento OWASP, il precetto si traduce in prove di penetrazione (penetration test) condotte da attaccanti di tipo adattivo, da ripetere ad ogni modifica del modello o delle difese. L’art. 25 trova nella segregazione dei privilegi e nell’assenza di segreti nel prompt di sistema una declinazione puntuale della protezione dei dati fin dalla progettazione (privacy by design). Ai fini dell’art. 35, infine, la OWASP Top 10 LLM si offre come un catalogo di minacce già ordinato per la redazione della valutazione d’impatto sulla protezione dei dati (DPIA).

Resta da considerare la posizione del fornitore di tecnologia. La quasi totalità delle organizzazioni non addestra in proprio il modello che utilizza. Il fornitore che tratta dati personali per conto del titolare assume la veste di responsabile del trattamento e con esso va stipulato un accordo ex art. 28 del GDPR, che la voce sulla catena di fornitura consente di integrare con clausole di contenuto tecnico. Tra queste figurano il divieto, presidiato anche da misure tecniche, di impiegare i dati dell’organizzazione per l’addestramento dei modelli del fornitore, la conservazione protetta dei log di richiesta e risposta, la disciplina dei sub-responsabili che gestiscono i database vettoriali e l’obbligo di cancellare gli embedding contestualmente all’eliminazione del documento originario. L’AI Act aggiunge un ulteriore livello di conformità.

OWASP Top 10 LLM ed AI Act: cibersicurezza, incidenti gravi e la disciplina transitoria

Il Regolamento (UE) 2024/1689 (AI Act), pur non citando espressamente OWASP, adotta la medesima terminologia. L’art. 15, par. 5, stabilisce che i sistemi di IA ad alto rischio siano resilienti ai tentativi di terzi non autorizzati di modificarne l’uso, gli output o le prestazioni sfruttandone le vulnerabilità ed elenca, tra le vulnerabilità specifiche dell’IA, l’avvelenamento dei dati, l’avvelenamento dei modelli, gli esempi antagonistici (adversarial examples) e gli attacchi alla riservatezza. Si tratta, sotto diversa denominazione, delle fattispecie LLM05, LLM04, LLM01 ed LLM02 della graduatoria OWASP.

Per i fornitori di sistemi ad alto rischio la classificazione OWASP offre un riferimento operativo per strutturare il sistema di gestione dei rischi prescritto dall’art. 9. Per i deployer, vale a dire coloro che utilizzano il sistema sotto la propria autorità, l’art. 26 impone di affidare la sorveglianza umana a persone dotate della competenza necessaria e di monitorare il funzionamento del sistema: le voci LLM03 ed LLM07 descrivono le conseguenze che si producono quando tale sorveglianza viene meno. Per gli incidenti gravi trova applicazione l’art. 73, che impone la segnalazione all’autorità di vigilanza del mercato non appena sia accertato il nesso causale con il sistema o la sua ragionevole probabilità. La segnalazione deve comunque avvenire entro 15 giorni, termine che si riduce a 2 giorni in caso di infrazione diffusa o di grave perturbazione di un’infrastruttura critica ed a 10 giorni in caso di decesso. Poiché l’art. 3, punto 49, ricomprende nella nozione di incidente grave anche la violazione degli obblighi previsti dal diritto dell’Unione a tutela dei diritti fondamentali, una divulgazione indebita di dati causata da un sistema ad alto rischio può far sorgere contestualmente l’obbligo di notifica ex art. 33 del GDPR e quello di segnalazione ex art. 73 dell’AI Act, con tempistiche e procedure distinte.

Occorre infine considerare il calendario delle scadenze. Il Regolamento (UE) 2026/1744 dell’8 luglio 2026, pubblicato nella Gazzetta ufficiale dell’Unione europea il 24 luglio 2026, ha sostituito la lett. c) del terzo comma dell’art. 113 dell’AI Act: gli obblighi relativi ai sistemi ad alto rischio si applicano dal 2 dicembre 2027 per quelli elencati nell’Allegato III e dal 2 agosto 2028 per quelli di cui all’Allegato I, in luogo del 2 agosto 2026 originariamente previsto. Il rinvio ha differito l’orizzonte delle sanzioni ma non ha attenuato la concretezza del rischio: i casi richiamati nel documento OWASP si collocano tra il 2022 ed il 2026 e si sono verificati senza attendere alcuna decorrenza formale. Sulla base di questo quadro è possibile definire le verifiche operative.

Sei verifiche prima della messa in produzione di un’applicazione LLM

I controlli che seguono si rivolgono alle organizzazioni che intendono mettere in esercizio un chatbot, un assistente interno od un motore di ricerca semantico sugli archivi documentali ed offrono, al contempo, un punto di riferimento al DPO chiamato ad esprimere il proprio parere preventivo.

Il documento OWASP sconta i limiti propri della sua natura: non costituisce parere legale e trae parte delle proprie fonti da contributi tecnici e studi non ancora sottoposti a revisione paritaria. Le cifre qui riportate rispecchiano quelle del testo originario. Un dato resta tuttavia acquisito: la classificazione del 2026 è la prima fondata sull’esame empirico degli incidenti concretamente verificatisi, oltre che sulle valutazioni della comunità professionale.