Article. What i write
LLM, vulnerabilità e responsabilità: la cyber security corre più veloce del diritto
Pubblicato il 25 giugno 2026 su CyberSecurity360.it
La convergenza tra ingegneria della sicurezza, ingegneria del software e disciplina giuridica della responsabilità costituirà il terreno di elaborazione anche per il dominio degli LLM. Le principali vulnerabilità sono note. La loro mappatura su un’architettura di responsabilità giuridicamente sostenibile rimane un compito aperto
A meno di quattro anni dall’ingresso dei Large Language Model (LLM) nel mainstream tecnologico, la comunità scientifica ha sviluppato una tassonomia consolidata delle vulnerabilità che affliggono questi sistemi. L’edizione 2025 dell’OWASP Top 10 for Large Language Model Applications rappresenta un punto di riferimento.
Mentre il piano tecnico evolve rapidamente, il tema della responsabilità giuridica rimane però strutturalmente in ritardo.
Il ritiro formale della AI Liability Directive da parte della Commissione europea nel 2025, l’imminente applicazione dell’AI Act (2 agosto 2026) e l’entrata in vigore della Product Liability Directive rivista (9 dicembre 2026) delineano un quadro frammentato, in cui la distribuzione delle responsabilità lungo la catena del valore (fornitore del modello, fornitore del sistema e deployer) è ancora da definire.
Ecco il divario tra la maturità tecnica delle minacce e quella giuridica delle risposte, e le aree di incertezza che gli esperti di cyber security dovranno affrontare nei prossimi cicli di conformità.
Una superficie di attacco senza precedenti
L’integrazione degli LLM nei flussi operativi critici, come l’assistenza clienti, la generazione di codice, l’elaborazione documentale e i sistemi agentici dotati di capacità di esecuzione, ha prodotto in tempi brevi una superficie di attacco la cui natura è qualitativamente diversa dalle tradizionali vulnerabilità delle applicazioni software. La peculiarità dei modelli linguistici risiede nella loro incapacità strutturale di distinguere, all’interno dello stesso flusso di contesto, le istruzioni legittime dell’operatore dal contenuto fornito in input. Questa caratteristica, lungi dall’essere un difetto di implementazione, rappresenta un tratto architetturale del paradigma generativo. Ciò trasforma elementi normalmente considerati passivi, come documenti, pagine web, voci di calendario e campi di database, in potenziali vettori di esecuzione di istruzioni. L’estensione progressiva degli LLM verso architetture agentiche, dotate di capacità di azione su risorse esterne (invio di e-mail, esecuzione di comandi shell, transazioni finanziarie), amplifica proporzionalmenteì l’impatto di vulnerabilità che, in contesti puramente conversazionali, avrebbero conseguenze limitate. Pertanto, l’impatto di un attacco aumenta proporzionalmente al livello di privilegio assegnato all’agente: un assistente con funzioni di sola sintesi rappresenta un rischio limitato, mentre un agente con capacità di esecuzione diventa un obiettivo ad alto impatto.La tassonomia consolidata
La versione 2025 dell’OWASP Top 10 for LLM Applications rappresenta oggi il principale punto di riferimento tassonomico. Rispetto alle edizioni precedenti, la versione 2025 riflette la transizione del panorama applicativo verso i sistemi di Retrieval-Augmented Generation (RAG) e le architetture Agentiche, introducendo categorie che non erano presenti nelle edizioni precedenti.Prompt Injection
Al primo posto della classifica si conferma la Prompt Injection (LLM01:2025), ridefinita per includere esplicitamente la variante indiretta. L’Injection diretta presuppone un’azione manipolativa da parte dell’utente che interagisce con il sistema, mentre l’Injection indiretta sfrutta l’incapacità del modello di distinguere il contenuto attendibile da quello non attendibile all’interno della stessa finestra di contesto. Questa distinzione è fondamentale dal punto di vista della modellazione delle minacce: l’Injection indiretta non può essere considerata un jailbreak e non può essere risolta con il prompt engineering, in quanto rappresenta una vulnerabilità di livello sistemico causata dalla commistione di input attendibili e non attendibili all’interno dello stesso flusso semantico.Sensitive Information Disclosure
La Sensitive Information Disclosure (LLM02:2025) registra la progressione più marcata, passando dalla sesta alla seconda posizione. Tale ascesa riflette l’aumento documentato di esfiltrazioni di informazioni proprietarie e dati personali attraverso interazioni con assistenti generativi integrati nei flussi aziendali, innescate talvolta da iniezioni indirette, ma anche da configurazioni errate dei meccanismi di recupero.Supply Chain
La supply chain (LLM03:2025) estende al dominio degli LLM con elementi specifici quali la provenienza dei dataset di addestramento, l’integrità dei foundation models distribuiti e la verifica delle componenti di fine-tuning e di embedding.Data and Model Poisoning
Il Data and Model Poisoning (LLM04:2025) amplia il campo d’azione della categoria precedente, relativa all’avvelenamento dei dati di addestramento, includendo le manipolazioni in fase di fine-tuning e di costruzione degli embedding. Le conseguenze di queste manipolazioni vanno dalla riduzione delle prestazioni alla generazione dioutput sistematicamente distorti.Improper Output Handling
L’Improper Output Handling (LLM05:2025) sottolinea la necessità di validare e sanitizzare gli output del modello prima della loro propagazione verso i sistemi a valle, in quanto una negligenza in questo ambito può tradursi in attacchi di cross-site scripting, nell’escalation dei privilegi o nell’esecuzione remota di codice sui sistemi backend.Excessive Agency
L’Excessive Agency (LLM06:2025) ha acquisito importanza con la diffusione delle architetture agentiche, mettendo in luce come l’autonomia del modello nell’invocazione di strumenti esterni e nell’esecuzione di azioni configuri una nuova categoria di rischio, per cui la limitazione dei privilegi e la supervisione umana sono presidi essenziali.System Prompt Leakage ed Vector and Embedding Weaknesses
Tra le novità, segnaliamo il System Prompt Leakage (LLM07:2025), che riguarda l’esposizione di istruzioni di sistema contenenti credenziali, logica operativa interna o regole di filtraggio dei contenuti e le Vector and Embedding Weaknesses (LLM08:2025), dedicate alle vulnerabilità dei sistemi RAG e dei database vettoriali, quali l’avvelenamento degli embedding, gli attacchi di similarità, l’accesso non autorizzato agli archivi vettoriali e l’inversione degli embedding per la ricostruzione del testo sorgente.Misinformation ed Unbounded Consumption
Chiudono la classifica la Misinformation (LLM09:2025), che tratta della generazione di contenuti errati con conseguenze a valle, e l’Unbounded Consumption (LLM10:2025), che amplia la categoria precedente del Denial of Service includendo il fenomeno del Denial of Wallet ovvero l’inflazione mirata dei costi operativi in ambienti cloud con tariffazione a consumo, nonché la replicazione non autorizzata del modello.Dall’analisi teorica all’incidente in produzione
Per molto tempo, la letteratura sulla prompt injection è stata caratterizzata da un’asimmetria netta tra la gravità degli attacchi dimostrati in laboratorio e la limitatezza degli incidenti osservati nell’ambiente reale. Tale asimmetria si è significativamente ridotta negli ultimi tempi. L’analisi condotta da Google sul Common Crawl (un repository open di dati di crawling del Web) ha rilevato un incremento relativo del 32% dei contenuti malevoli destinati all’iniezione indiretta nella categoria dei contenuti malevoli fra novembre 2025 e febbraio 2026. Nel dicembre 2025, Palo Alto Networks ha documentato un caso reale di Injection di Prompt Indiretta (IDPI), progettata per aggirare un sistema di revisione automatica degli annunci pubblicitari basato su LLM. Lakera ha descritto un attacco zero-click che consente l’esecuzione di codice remoto in ambienti di sviluppo integrati basati sul protocollo MCP (Model Context Protocol). L’attacco è stato attivato da un documento Google apparentemente innocuo che ha indotto l’agente a recuperare delle istruzioni da un server controllato dall’attaccante, a eseguire un payload Python e a sottrarre dei segreti, senza che l’utente debba interagire in alcun modo. La vulnerabilità CVE-2025-59944, riguardante l’editor agentico Cursor, ha dimostrato che un banale problema di sensibilità alle maiuscole e minuscole in un percorso di file protetto può essere sfruttato per indirizzare l’agente verso un file di configurazione manipolato e consentire l’esecuzione remota di codice. Il caso noto come “Perplexity Comet leak” ha ulteriormente confermato la fragilità degli assistenti di navigazione integrati. Ciò porta a una considerazione di principio: la prompt injection non è una vulnerabilità risolvibile a livello di modello, ma un vettore le cui conseguenze possono essere contenute solo con un’architettura defense-in-depth che presupponga la fallibilità del componente generativo e che applichi la rigorosa separazione tra istruzioni e dati, l’isolamento dei contesti, la validazione degli output, il controllo del flusso di informazioni e il principio del minimo privilegio.Il quadro normativo
Sul piano normativo, l’Unione europea ha assunto il ruolo di legislatore primario in materia di intelligenza artificiale. Tuttavia, l’architettura normativa risultante è meno coerente di quanto la narrativa pubblica lasci intendere e presenta zone d’ombra significative, soprattutto in relazione all’attribuzione delle responsabilità. Il Regolamento (UE) 2024/1689, noto come AI Act, rappresenta il fulcro del sistema. Adotta un approccio basato sul rischio, suddiviso in quattro classi (rischio inaccettabile, alto, limitato e minimo), e introduce specifici obblighi per i fornitori di General Purpose AI (GPAI), categoria nella quale rientra la maggior parte degli LLM commerciali. Questi obblighi riguardano la trasparenza, la documentazione tecnica, l’informazione agli sviluppatori a valle e la divulgazione delle procedure di addestramento, inclusi i dati utilizzati. Per i modelli che superano una determinata soglia di capacità computazionale e che presentano un rischio sistemico, sono previsti obblighi rafforzati in materia di gestione del rischio e di sicurezza informatica. Gli organismi di regolamentazione, ovvero le autorità nazionali competenti e l’Ufficio per l’intelligenza artificiale presso la Commissione europea, sono operativi dal 2 agosto 2025, mentre la piena applicazione del regolamento è prevista per il 2 agosto 2026. Sono state fissate scadenze specifiche per gli obblighi di watermarking sui contenuti generati artificialmente, che scadranno il 2 dicembre 2026. Le sanzioni previste sono considerevoli: fino a 35 milioni di euro o al 7% del fatturato globale annuo.Le tre figure principali secondo l’AI Act
L’AI Act distingue tre figure principali:- il fornitore del modello GPAI;
- il fornitore del sistema di IA che integra il modello in un’applicazione;
- il deployer, ovvero colui che impiega il sistema nel proprio contesto operativo.
AI Liability Directive: i danni causati dai sistemi di IA
Il gap più rilevante riguarda la responsabilità civile per i danni causati dai sistemi di IA. La proposta di direttiva sull’intelligenza artificiale (AI Liability Directive, AILD), avanzata dalla Commissione nel settembre 2022, mirava a colmare questa lacuna introducendo regole armonizzate tra gli Stati membri, una presunzione relativa di nesso causale e poteri istruttori per l’accesso alle prove. Tuttavia, l’11 febbraio 2025 la Commissione ha ritirato la direttiva dal proprio programma di lavoro, motivando la decisione con l’assenza di un accordo tra i co-legislatori. Il ritiro è stato formalmente confermato nel corso del 2025. Resta dunque affidata al diritto nazionale dei singoli Stati membri la disciplina della responsabilità extracontrattuale per fatto illecito, con il rischio di frammentazione che la direttiva intendeva proprio scongiurare.La nuova Product Liability Directive
A parziale compensazione, opera la nuova Product Liability Directive (Direttiva (UE) 2024/2853), entrata in vigore nel dicembre 2024 e applicabile ai prodotti immessi sul mercato dopo il 9 dicembre 2026. La direttiva estende espressamente il concetto di “prodotto” anche ai software, includendo quindi i sistemi di intelligenza artificiale, e prevede un regime di responsabilità oggettiva del produttore. La direttiva, tuttavia, non definisce di per sé lo standard di sicurezza richiesto: in concreto, la conformità ai requisiti dell’AI Act diverrà il criterio principale di valutazione del difetto, creando un nesso operativo per cui il mancato rispetto delle prescrizioni normative alimenterà la responsabilità per danno da prodotto difettoso. In Italia, la Legge 132/2025, in vigore dal 10 ottobre 2025, ha recepito i principi dell’AI Act nel contesto nazionale introducendo specifiche disposizioni in materia sanitaria.La zona grigia
L’intersezione tra la tassonomia tecnica delle vulnerabilità e l’architettura normativa restituisce un quadro in cui, per ciascuna delle dieci categorie OWASP, è possibile identificare astrattamente un responsabile, ma in cui l’attribuzione concreta resta soggetta a significativi margini interpretativi. Si consideri, ad esempio, il caso paradigmatico della prompt injection indiretta. La vulnerabilità è radicata nell’architettura stessa del foundation models, un’anomalia che l’attuale mondo della ricerca considera privo di una soluzione completamente affidabile durante la fase di addestramento. Il fornitore del GPAI è tenuto a mitigare e rendere trasparente la natura del rischio, conformemente agli articoli dell’AI Act relativi alla gestione dei rischi sistemici. In ragione del proprio controllo sull’architettura, il fornitore del sistema applicativo è tenuto a implementare misure di difesa in profondità quali l’isolamento dei contesti, la validazione degli output e la limitazione dei privilegi degli agenti. Il deployer, infine, ha la responsabilità di definire l’ambito operativo, di monitorare gli incidenti e di garantire la supervisione umana. Quando un’iniezione indiretta determina l’esfiltrazione di dati personali da un assistente integrato in un sistema CRM aziendale, non è possibile dedurre la ripartizione delle responsabilità, ma è necessario un’analisi caso per caso del controllo effettivamente esercitato sui diversi livelli architetturali e del rispetto degli standard tecnici applicabili.Le vulnerabilità della supply chain
Analoghe ambiguità si riscontrano per quanto riguarda le vulnerabilità della supply chain: l’accountability che il deployer deve dimostrare nella verifica della provenienza di un modellodistribuito attraverso un hub pubblico è ancora oggetto di discussione, in assenza di standard normativi cogenti che ne specifichino i termini operativi. Le misure tecniche difensive disponibili sono: spotlighting, gerarchia delle istruzioni, addestramento dell’avversario, controllo del flusso delle informazioni convalida delle chiamate agli strumenti. Il continuous red teaming rappresenta uno stato dell’arte in rapida evoluzione, rispetto al quale il concetto di “diligenza esigibile”, rilevante ai fini della responsabilità giuridica, deve ancora consolidarsi attraverso la prassi applicativa e, presumibilmente, le prime decisioni giurisdizionali.LLM, vulnerabilità e responsabilità: tre implicazioni operative
L’attuale asimmetria tra la maturità delle minacce e quella delle risposte normative non è destinata a risolversi spontaneamente. L’entrata in vigore dell’AI Act nel mese di agosto del 2026 e l’operatività della Product Liability Directive riformata nel mese di dicembre dello stesso anno costituiranno il primo banco di prova reale di un’architettura normativa che è destinata a operare in un regime di responsabilità mista, con il diritto nazionale degli Stati membri chiamato a colmare le lacune. Per gli specialisti di sicurezza informatica si delineano almenotre implicazioni operative. In primo luogo, la documentazione rigorosa dei presidi tecnici adottati lungo l’intera catena del valore non sarà rilevante solo ai fini della conformità normativa, ma anche come elemento probatorio in eventuali contenziosi per responsabilità da prodotto. In secondo luogo, la classificazione delle proprie attività ai sensi dell’AI Act, distinguendo i ruoli di provider e deployer, non potrà ridursi a un mero esercizio formale, ma dovrà riflettere il controllo effettivamente esercitato sui diversi livelli architetturali. Infine, in terzo luogo, l’aggiornamento continuo rispetto allo stato dell’arte delle difese, un perimetro che si modifica con cadenza mensile, come testimoniato dalla letteratura recente, costituirà il parametro implicito in base al quale verrà misurata l’adeguatezza dei presidi adottati. Dunque, in ultima analisi, la convergenza tra ingegneria della sicurezza, ingegneria del software e disciplina giuridica della responsabilità – convergenza che ha caratterizzato l’evoluzione del diritto della cyber sicurezza nell’ultimo ventennio -, è destinata a costituire il terreno fondamentale di elaborazione anche per il dominio degli LLM. Le principali vulnerabilità sono note; la loro mappatura su un’architettura di responsabilità giuridicamente sostenibile rimane il compito aperto del prossimo ciclo regolatorio.Riferimenti bibliografici
Vincenzo Calabro' | Ingegnere informatico specializzato in sicurezza informatica e investigazione digitali. Autore di articoli e saggi. Lecturer, Speaker, Trainer.