OWASP Top 10 LLM 2026: cosa cambia e come dimostrarlo

L’OWASP Top 10 LLM ha una nuova edizione dal 3 agosto 2026, e mai prima d’ora l’ordine delle voci era cambiato così tanto. Excessive Agency (eccesso di capacità di azione) sale al terzo posto, System Prompt Leakage diventa Hidden Context Exposure e, per la prima volta, la classifica è stata messa alla prova su 7.714 incidenti reali. Quasi tutte le guide si limitano a ripetere le dieci voci. Questa legge l’OWASP Top 10 LLM come farebbe un auditor o un’autorità di vigilanza del mercato: che cosa si è spostato, come è nata la graduatoria, quali obblighi europei tocca ogni voce e quali registrazioni provano che ve ne siete occupati.

In sintesi

• L’edizione 2026 è uscita il 3 agosto 2026: otto voci su dieci hanno cambiato posizione, solo Prompt Injection e Sensitive Information Disclosure restano al loro posto.
• La classifica combina il voto degli esperti (75 per cento) e gli incidenti registrati (25 per cento): è un segnale di consenso, non un punteggio di rischio per il vostro sistema.
• L’Appendice A collega l’OWASP Top 10 LLM a nove framework di sicurezza. Il regolamento sull’IA (AI Act) e la ISO/IEC 42001 non ci sono.
• L’articolo 15, paragrafo 5, dell’AI Act cita avvelenamento di dati e modelli, esempi antagonistici, attacchi alla riservatezza e difetti del modello: tutti e cinque sono nella lista.
• La lista è volontaria. Le evidenze no, quando si applicano AI Act, regolamento sulla ciberresilienza, GDPR, NIS2 o DORA.

Che cos’è l’OWASP Top 10 LLM?

L’OWASP Top 10 LLM, titolo ufficiale OWASP Top 10 for LLM Applications, è un documento di sensibilizzazione scritto dalla comunità: dà un nome ai dieci rischi di sicurezza più critici delle applicazioni costruite su modelli linguistici di grandi dimensioni. Lo cura l’OWASP GenAI Security Project, parte della fondazione la cui Top 10 per le applicazioni web orienta i test di sicurezza dal 2003. Il quadro d’insieme è nella nostra guida alla sicurezza dell’IA.

Le edizioni sono quattro: versione 1.0 del 1° agosto 2023, 1.1 del 16 ottobre 2023, edizione 2025 del 18 novembre 2024 ed edizione 2026 del 3 agosto 2026. Il documento attuale conta 122 pagine, con licenza CC BY-SA 4.0. Ogni voce ha una descrizione, esempi, strategie di prevenzione e mitigazione e scenari di attacco. Secondo il nostro conteggio le strategie di mitigazione numerate sono 96, dalle 3 di Hidden Context Exposure (esposizione del contesto nascosto) alle 19 di Sensitive Information Disclosure (divulgazione di informazioni sensibili).

L’impostazione dell’OWASP Top 10 LLM è dichiarata nella lettera di apertura: smettere di inseguire un modello che non si lasci ingannare e costruirgli intorno un sistema in cui un modello ingannato non rompa nulla di importante. È una tesi architetturale, e per la governance pesa: sposta il punto di controllo dal fornitore del modello al team che mette in esercizio l’applicazione.

Un documento di sensibilizzazione, non uno standard di controllo

Nessuno si certifica rispetto all’OWASP Top 10 LLM: niente requisiti vincolanti, niente schema di conformità, niente auditor accreditati. Il suo valore è il vocabolario condiviso, perché ingegneri della sicurezza, penetration tester, fornitori e auditor usano già quei nomi. Un rilievo etichettato LLM03 si legge allo stesso modo in un rapporto di red teaming dell’IA, in un questionario per i fornitori e in una nota al consiglio di amministrazione.

Quanto al perimetro, l’OWASP Top 10 LLM copre il modello come componente della vostra applicazione. Quando il modello diventa un attore, con strumenti da invocare, memoria persistente ed effetti a valle, OWASP passa la mano alla Top 10 for Agentic Applications, annunciata il 9 dicembre 2025.

La lista OWASP Top 10 LLM 2026: che cosa è cambiato

<table header-row=”true”> <tr> <td>ID 2026</td> <td>Voce</td> <td>Posizione 2025</td> <td>Che cosa è cambiato</td> </tr> <tr> <td>LLM01</td> <td>Prompt Injection</td> <td>1</td> <td>Resta prima. Copre ora attacchi cross-modali (immagini, audio, video) e iniezioni persistenti in memoria o nel corpus di recupero (RAG)</td> </tr> <tr> <td>LLM02</td> <td>Sensitive Information Disclosure</td> <td>2</td> <td>Resta seconda. Nuove superfici: argomenti delle chiamate agli strumenti, tracce di ragionamento, log, embedding, canali laterali temporali</td> </tr> <tr> <td>LLM03</td> <td>Excessive Agency</td> <td>6</td> <td>Sale di tre. Cause invariate: funzionalità, permessi e autonomia eccessivi</td> </tr> <tr> <td>LLM04</td> <td>Supply Chain</td> <td>3</td> <td>Scende di una. Copre ora artefatti di modello promossi che non sono ciò che dichiarano, adapter e pipeline di conversione</td> </tr> <tr> <td>LLM05</td> <td>Data and Model Poisoning</td> <td>4</td> <td>Scende di una. Assorbe sovversione del fine-tuning e avvelenamento tramite ingestione nel recupero</td> </tr> <tr> <td>LLM06</td> <td>Unbounded Consumption</td> <td>10</td> <td>Sale di quattro. Riletta come asimmetria dei costi: modelli di ragionamento, input multimodali, cicli degli agenti</td> </tr> <tr> <td>LLM07</td> <td>Misinformation</td> <td>9</td> <td>Sale di due, trascinata dagli incidenti registrati</td> </tr> <tr> <td>LLM08</td> <td>Hidden Context Exposure</td> <td>7</td> <td>Ex System Prompt Leakage, estesa a testi di policy recuperati, schemi degli strumenti e ogni contesto nascosto</td> </tr> <tr> <td>LLM09</td> <td>Vector and Embedding Weaknesses</td> <td>8</td> <td>Scende di una. Include ora memoria degli agenti su vettori e cache semantiche</td> </tr> <tr> <td>LLM10</td> <td>Improper Output Handling</td> <td>5</td> <td>Scende di cinque, la caduta più ampia. Aggiunge caratteri di controllo del terminale, renderer con scaricamento automatico, codice generato insicuro</td> </tr> </table>

Dall’OWASP Top 10 LLM 2026 discendono tre osservazioni pratiche.

Il danno si produce dove c’è capacità di agire. Per OWASP la risalita di Excessive Agency è lo spostamento più gravido di conseguenze della lista, perché voto e incidenti concordano. Un assistente che si limita a rispondere può fuorviare; uno che può inviare email, scrivere in un database o disporre un rimborso può eseguire un’istruzione manipolata. Le tre cause alla radice sono una lista di controllo: strumenti di cui l’applicazione non ha bisogno, permessi più ampi del compito, possibilità di agire senza approvazione. L’ultima è una questione di sorveglianza umana.

Gli identificativi hanno cambiato significato. Nel 2025 LLM03 era Supply Chain (catena di fornitura), nel 2026 è Excessive Agency. LLM06 era Excessive Agency, oggi è Unbounded Consumption (consumo illimitato di risorse). Registri dei rischi, piani di test e questionari per i fornitori che citano un identificativo senza anno sono diventati ambigui: va scritto sempre l’anno (LLM03:2026) e i documenti più vecchi vanno riallineati.

Il contesto nascosto va considerato scopribile. LLM08 chiede di progettare come se prompt di sistema, testi di policy recuperati e schemi degli strumenti potessero essere estratti. Quindi nessuna credenziale nel prompt, e le istruzioni nascoste non sono mai l’unico controllo di autorizzazione. La verifica è una domanda: se domani trapelasse l’intera finestra di contesto, che cosa ci guadagnerebbe un attaccante?

Come è stata costruita la classifica 2026: un voto messo alla prova degli incidenti

Le edizioni precedenti dell’OWASP Top 10 LLM poggiavano solo sul giudizio degli esperti. Per il 2026 il gruppo di progetto ha raccolto 7.714 incidenti da database pubblici di vulnerabilità e da un database dei danni causati dall’IA, li ha passati a dei classificatori e ne ha classificati 6.639. Nell’ordine finale il voto pesa per tre quarti, i dati sugli incidenti per un quarto.

Le due fonti divergono in punti istruttivi:

• Prompt Injection. Prima per il voto, fuori dalle prime dieci stando al solo dato grezzo degli incidenti. OWASP vi legge un effetto delle difese: i team la contrastano così tanto che pochi exploit arrivano in un database pubblico. L’esposizione resta reale, come mostra CVE-2025-32711, falla zero-click in un assistente in produzione.
• Misinformation (informazioni errate). In basso nel voto, in alto negli incidenti: lo scarto più ampio della lista. Risultato: settimo posto.
• Sensitive Information Disclosure. L’unico punto, nella parte alta, in cui convinzione ed evidenza coincidono.

Per un registro dei rischi, tre conseguenze contano più della classifica.

1. La posizione non misura la gravità per il vostro sistema. Un assistente per i clienti senza strumenti è poco esposto a LLM03; un agente interno con accesso in scrittura lo è moltissimo. Ogni voce va pesata sulla propria architettura.
2. I conteggi pubblici sottostimano i rischi ben presidiati. La nota di ricerca della Cloud Security Alliance del 15 agosto 2026 lo dice chiaramente: l’assenza di incidenti non dimostra l’assenza di rischio.
3. Misinformation è ormai una voce di sicurezza, non solo un tema di qualità. Una risposta sbagliata che guida una chiamata a uno strumento diventa un’azione sbagliata. Qui l’OWASP Top 10 LLM incontra gli obblighi di accuratezza, tema del nostro articolo sulle allucinazioni come rischio principale dell’IA generativa.

Ciò che l’OWASP Top 10 LLM non mappa: l’AI Act e la ISO/IEC 42001

L’Appendice A dell’OWASP Top 10 LLM 2026 raccoglie le corrispondenze con nove framework esterni, ciascuno con la sua versione: la OWASP Top 10 for Agentic Applications, OWASP GenAI Data Security 2026, MITRE ATLAS, MITRE ATT&CK, CWE, NIST AI 600-1, il NIST AI RMF, la CSA AI Controls Matrix e l’OWASP AI Vulnerability Scoring System. Nessuno dei nove è l’AI Act, nessuno è la ISO/IEC 42001. L’AI Act viene nominato tre volte in 122 pagine, sempre intorno a LLM02, e una menzione colloca ancora gli obblighi per l’alto rischio ad agosto 2026, data che il Digital Omnibus, regolamento (UE) 2026/1744, ha spostato al 2 dicembre 2027 per i sistemi dell’allegato III.

Per un documento di sicurezza non è un difetto. È un vuoto per chi deve dimostrare a un’autorità come il lavoro di sicurezza risponde a un obbligo di legge. L’articolo 15, paragrafo 5, dell’AI Act impone 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, ed elenca le vulnerabilità specifiche dell’IA: avvelenamento dei dati, avvelenamento dei modelli, esempi antagonistici o evasione dal modello, attacchi alla riservatezza, difetti del modello. Ciascuna trova posto in una voce dell’OWASP Top 10 LLM.

La tavola di raccordo è una nostra lettura, non una mappatura di OWASP né della Commissione. <table header-row=”true”> <tr> <td>Voce</td> <td>Aggancio nell’AI Act</td> <td>Evidenza che un auditor chiede</td> </tr> <tr> <td>LLM01 Prompt Injection</td> <td>Art. 15(5), input antagonistici; art. 55(1)(a), test contraddittorio</td> <td>Rapporto di test per rilascio contro attaccanti che conoscono la difesa; inventario dei canali di input non attendibili</td> </tr> <tr> <td>LLM02 Sensitive Information Disclosure</td> <td>Art. 15(5), attacchi alla riservatezza; art. 10; GDPR art. 32</td> <td>Classificazione dei dati di ogni fonte di contesto; test di oscuramento; procedura per incidenti di divulgazione</td> </tr> <tr> <td>LLM03 Excessive Agency</td> <td>Art. 14, sorveglianza umana; art. 26, obblighi dei deployer</td> <td>Registro di strumenti e permessi per applicazione; regola di approvazione delle azioni ad alto impatto; log delle chiamate</td> </tr> <tr> <td>LLM04 Supply Chain</td> <td>Art. 25, catena del valore; art. 15(5), componenti preaddestrati</td> <td>Provenienza di modelli e dataset; inventario dei componenti firmati; valutazioni dei fornitori</td> </tr> <tr> <td>LLM05 Data and Model Poisoning</td> <td>Art. 10, governance dei dati; art. 15(5), avvelenamento di dati e modelli</td> <td>Tracciabilità dei dataset; validazione di fine-tuning e ingestione nel recupero; approvazione del riaddestramento</td> </tr> <tr> <td>LLM06 Unbounded Consumption</td> <td>Art. 15(4), resilienza a errori e guasti</td> <td>Tetti di spesa; limiti di frequenza; test degli interruttori automatici; allarmi sui costi</td> </tr> <tr> <td>LLM07 Misinformation</td> <td>Art. 15(1) e (3), accuratezza dichiarata; art. 14(4)(b), distorsione dell’automazione</td> <td>Metriche di accuratezza e ancoraggio alle fonti; risultati delle valutazioni; istruzioni agli utenti sull’eccesso di affidamento</td> </tr> <tr> <td>LLM08 Hidden Context Exposure</td> <td>Art. 15(5), attacchi alla riservatezza</td> <td>Scansione dei segreti in prompt e schemi degli strumenti; prova che l’autorizzazione è applicata fuori dal modello</td> </tr> <tr> <td>LLM09 Vector and Embedding Weaknesses</td> <td>Art. 10; art. 15(5); GDPR art. 32</td> <td>Test di isolamento tra tenant nel recupero; registro di provenienza dell’ingestione; procedura di cancellazione degli embedding</td> </tr> <tr> <td>LLM10 Improper Output Handling</td> <td>Art. 15(5), difetti del modello; regolamento sulla ciberresilienza, allegato I</td> <td>Test di codifica dell’output; inventario delle destinazioni a valle; registrazioni di sviluppo sicuro</td> </tr> </table>

Per la ISO/IEC 42001 gli stessi artefatti trovano posto nel sistema di gestione: nei controlli dell’Allegato A sul ciclo di vita del sistema di IA (verifica e validazione, esercizio e monitoraggio, registri degli eventi), sui dati per i sistemi di IA (qualità e provenienza), sui rapporti con terze parti e clienti e sull’uso dei sistemi di IA. Un auditor di certificazione chiederà come avete individuato i rischi di sicurezza dell’IA e che cosa avete deciso per ciascuno: una registrazione della decisione, voce per voce, è la risposta.

Quale norma rende esigibili queste evidenze

L’OWASP Top 10 LLM è volontaria. Ciò che descrive non lo è più quando si applica uno di questi regimi.

• AI Act, articolo 15. Vincola i sistemi di IA ad alto rischio. Dopo il Digital Omnibus, i sistemi dell’allegato III devono essere conformi dal 2 dicembre 2027, i prodotti dell’allegato I dal 2 agosto 2028. Primo passo: capire quando un sistema di IA è ad alto rischio.
• AI Act, articolo 55. I fornitori di modelli di IA per finalità generali con rischio sistemico devono svolgere e documentare il test contraddittorio e garantire un’adeguata protezione della cibersicurezza per il modello e la sua infrastruttura fisica (articolo 55). Gli obblighi valgono dal 2 agosto 2025, i poteri di esecuzione della Commissione dal 2 agosto 2026.
• Regolamento sulla ciberresilienza. Il regolamento (UE) 2024/2847 riguarda i prodotti con elementi digitali, cioè anche la maggior parte del software commerciale che incorpora un modello linguistico. Dall’11 settembre 2026 i fabbricanti segnalano vulnerabilità attivamente sfruttate e incidenti gravi, tramite la piattaforma unica di segnalazione, al CSIRT coordinatore e all’ENISA: preallarme entro 24 ore, notifica entro 72 ore (sintesi di Jones Day). I requisiti essenziali si applicano per intero dall’11 dicembre 2027. Secondo il suo articolo 12, un sistema di IA ad alto rischio che li soddisfa si considera conforme al requisito di cibersicurezza dell’articolo 15 dell’AI Act.
• GDPR, articolo 32. La sicurezza del trattamento vale per qualunque applicazione che tocchi dati personali. LLM02 e LLM09 descrivono violazioni di dati personali prima che accadano.
• NIS2 e DORA. Soggetti essenziali e importanti ed entità finanziarie devono già gestione dei rischi e segnalazione degli incidenti per i propri sistemi ICT. DORA si applica dal 17 gennaio 2025.

Due date vanno nel piano di progetto: il 2 dicembre 2027 e l’11 dicembre 2027, a nove giorni di distanza. Un unico fascicolo di sicurezza, strutturato sulle voci dell’OWASP Top 10 LLM e con rinvii incrociati ai due regolamenti, prepara a entrambe le scadenze. A metà 2026 la norma armonizzata sulla cibersicurezza dell’IA era ancora in preparazione presso il CEN-CENELEC: una tassonomia pubblica e riconosciuta resta, per ora, la struttura più difendibile.

In Italia l’interlocutore è già individuato. La legge n. 132/2025 affida la vigilanza del mercato ai sensi dell’AI Act all’Agenzia per la Cybersicurezza Nazionale (ACN), che è anche l’autorità nazionale per la cybersicurezza, mentre l’AgID è l’autorità di notifica. Sicurezza e conformità finiscono sullo stesso tavolo: meglio un solo fascicolo.

Dall’OWASP Top 10 LLM alle evidenze: un metodo in sei passaggi

1. Censire ogni applicazione basata su un modello linguistico. Per ciascuna si registrano modello, fonti di contesto, strumenti, archivi di memoria e destinazioni a valle. Senza un inventario dei sistemi di IA nessuno può dire quali voci siano nel perimetro. L’AI Registry di AI Sigil conserva questa scheda per ogni sistema.
2. Decidere l’applicabilità voce per voce. Si scrive “si applica” oppure “non si applica”, con la motivazione. OWASP osserva che un sistema di recupero senza vettori non ha superficie di attacco per LLM09. Un’esclusione registrata è un’evidenza. Il silenzio è una lacuna.
3. Scegliere le mitigazioni e nominare un responsabile. Si attinge alle 96 strategie dell’OWASP Top 10 LLM, si collega ciascuna a un controllo già in esercizio quando esiste e si indica l’artefatto che ne dà prova.
4. Testare prima del rilascio e dopo ogni modifica. Ogni nuova versione del modello, prompt di sistema, strumento o corpus di recupero riapre LLM01, LLM03 e LLM08. L’OWASP Top 10 LLM chiede test contro attaccanti adattivi, che hanno letto la difesa in esercizio: è il terreno del red teaming dell’IA.
5. Portare la catena di fornitura nel contratto. LLM04 e LLM05 non si chiudono con i soli test. Provenienza, firma, avviso sulle vulnerabilità e notifica delle modifiche vanno nella due diligence dei fornitori di IA e nel contratto.
6. Fissare in anticipo soglie e scadenze per gli incidenti. Si decide prima che cosa è un incidente grave ai sensi dell’articolo 73 dell’AI Act, una vulnerabilità attivamente sfruttata per il regolamento sulla ciberresilienza e una violazione di dati personali per il GDPR, e chi trasmette la segnalazione degli incidenti di IA entro 24 o 72 ore.

Ogni passaggio lascia una registrazione. Insieme formano una dichiarazione di applicabilità per il rischio dei modelli linguistici: dieci voci, una decisione per ciascuna, un controllo, un responsabile e un risultato di test. È quel fascicolo a trasformare l’OWASP Top 10 LLM da poster in sala riunioni a evidenza di audit.

Top 10 LLM o Top 10 Agentic: quale lista si applica

OWASP traccia il confine in base al ruolo. Se il modello è un componente che restituisce testo al vostro codice, vale l’OWASP Top 10 LLM. Se è un attore che invoca strumenti, conserva memoria e innesca effetti a valle, si applica anche la OWASP Top 10 for Agentic Applications. L’Appendice A dell’OWASP Top 10 LLM collega ogni voce alle corrispondenti voci agentiche: Excessive Agency vi compare come ASI02 Tool Misuse and Exploitation, ASI03 Identity and Privilege Abuse e ASI08 Cascading Failures.

In azienda quasi tutte le implementazioni stanno sul confine: un assistente riceve un connettore, poi un secondo, poi l’accesso in scrittura, e nessuno rivede il perimetro dell’analisi dei rischi. Due verifiche aiutano.

• Registrare nell’inventario tre attributi per applicazione: strumenti, memoria persistente, capacità di agire senza approvazione. Quando uno dei tre cambia, si applicano entrambe le liste.
• Usare prima del rilascio la “lethal trifecta” (la triade letale) che OWASP riprende da Simon Willison. Un agente che accede a dati privati, elabora contenuti non attendibili e comunica verso l’esterno riunisce le condizioni per uno sfruttamento ad alto impatto. Tolto uno dei tre lati, vengono meno.

L’approvazione umana è il controllo a cui OWASP ritorna più spesso, ed è anche quello di cui si fida meno quando i volumi crescono: la stanchezza da approvazione (approval fatigue) logora il giudizio di chi convalida. È un problema di progettazione della sorveglianza umana, non una casella da spuntare. Per la governance degli agenti si vedano le guide sugli agenti di IA autonomi e su IA agentica e IA generativa. Sullo stesso terreno si muove il documento congiunto di ANSSI e BSI sui principi di progettazione Zero Trust per i sistemi basati su LLM.

Domande frequenti

Che cos’è l’OWASP Top 10 LLM, in parole semplici? L’OWASP Top 10 LLM è la classifica dei dieci rischi di sicurezza più critici nelle applicazioni costruite su modelli linguistici di grandi dimensioni, redatta dall’OWASP GenAI Security Project. Ogni voce spiega come nasce il problema, fornisce esempi e propone difese. I team di sicurezza la usano per delimitare i test, i fornitori per descrivere la propria copertura, gli auditor come vocabolario di riferimento.

Che cosa è cambiato nell’OWASP Top 10 LLM nel 2026? Otto voci su dieci hanno cambiato posizione. Excessive Agency è salita dal sesto al terzo posto, Unbounded Consumption dal decimo al sesto, Misinformation dal nono al settimo. Improper Output Handling è scesa dal quinto al decimo. System Prompt Leakage ora si chiama Hidden Context Exposure. Nuovo anche il metodo: il voto degli esperti pesa per il 75 per cento, un archivio di 7.714 incidenti reali per il 25 per cento.

L’OWASP Top 10 LLM è obbligatoria? No. È un documento di sensibilizzazione volontario, senza schema di certificazione. I rischi che nomina sono però coperti da norme vincolanti: l’articolo 15 dell’AI Act per i sistemi ad alto rischio, l’articolo 55 per i modelli per finalità generali con rischio sistemico, il regolamento sulla ciberresilienza per i prodotti con elementi digitali, l’articolo 32 del GDPR per i dati personali. Usare l’OWASP Top 10 LLM per strutturare le evidenze è una scelta. Avere le evidenze non lo è.

Che rapporto c’è tra l’OWASP Top 10 LLM e l’AI Act? L’OWASP Top 10 LLM non contiene alcuna mappatura verso l’AI Act. L’aggancio più vicino è l’articolo 15, paragrafo 5, che elenca avvelenamento dei dati e dei modelli, esempi antagonistici, attacchi alla riservatezza e difetti del modello. Corrispondono, nell’ordine, a LLM05, LLM04, LLM01, LLM02 insieme a LLM08 e LLM09, e LLM10. Excessive Agency si collega alla sorveglianza umana dell’articolo 14, Misinformation ai livelli di accuratezza che l’articolo 15 impone ai fornitori di dichiarare.

La prompt injection è ancora il rischio numero uno? Sì. Nell’OWASP Top 10 LLM 2026 resta al primo posto grazie al voto degli esperti. Stando ai soli dati pubblici sugli incidenti uscirebbe dalle prime dieci: secondo OWASP, i team più maturi contengono i tentativi prima che diventino casi da segnalare. L’NCSC britannico lo spiega nella nota la prompt injection non è una SQL injection: i modelli non separano le istruzioni dai dati, quindi la superficie di attacco non si può chiudere, soltanto contenere.

Qual è la differenza tra la Top 10 LLM e la Top 10 Agentic? L’OWASP Top 10 LLM riguarda il modello come componente all’interno di un’applicazione. La lista Agentic, annunciata il 9 dicembre 2025, riguarda il modello come attore autonomo, con strumenti, memoria ed effetti a valle. Sono pensate per essere usate insieme. Se la vostra applicazione può invocare strumenti o agire senza che una persona approvi ogni passaggio, vanno lette entrambe, e la scelta va rivista a ogni nuovo connettore.

Conclusione

L’OWASP Top 10 LLM è il vocabolario più condiviso per la sicurezza dei modelli linguistici, e l’edizione 2026 lo ha reso più onesto mettendo le convinzioni alla prova di un archivio di incidenti. Resta un documento di sicurezza: non dice quale norma si applica, da quando, né che cosa un’autorità chiederà di vedere. Quella parte è vostra: un inventario, una decisione per ogni voce, un controllo e un responsabile nominati, un risultato di test dopo ogni modifica, scadenze per gli incidenti concordate in anticipo. Le segnalazioni del regolamento sulla ciberresilienza sono già operative e dicembre 2027 porta sia gli obblighi per l’alto rischio sia i requisiti di prodotto completi. AI Sigil collega ogni applicazione basata su un modello linguistico presente nel registro alle voci applicabili, ai controlli scelti, ai risultati dei test e alle decisioni sugli incidenti, così che la risposta a un auditor sia un report, non una ricostruzione.