Sicurezza degli LLM: chi risponde dei rischi nelle imprese

L’adozione dell’AI generativa nelle imprese italiane corre più veloce della capacità di governarne i rischi. Secondo l’ultimo rapporto ISTAT “Imprese e ICT”, nel 2025 il 16,4% delle imprese con almeno 10 addetti ha integrato soluzioni basate su Large Language Model in processi decisionali, operativi e di gestione dei dati: più del triplo rispetto al 2023.

Una crescita che, nel dibattito pubblico sulla trasformazione digitale, tende a essere raccontata quasi esclusivamente come opportunità. Eppure ogni LLM in produzione è anche una superficie di attacco, e le vulnerabilità che lo caratterizzano non sono difetti da correggere con una patch, piuttosto sono il prodotto di scelte architetturali, organizzative e contrattuali distribuite lungo tutta la catena di adozione.

Le vulnerabilità degli LLM lungo il ciclo di vita

Prima di affrontare il nodo della responsabilità, è utile tracciare rapidamente il perimetro tecnico del problema. Le vulnerabilità degli LLM si distribuiscono lungo l’intero ciclo di vita del sistema.

Nella fase di addestramento, il rischio principale è il Data Poisoning: inserire nel dataset fonti non verificate o contenuti manipolati significa alterare il comportamento del modello alla radice, prima ancora che entri in produzione. In sistemi con architetture RAG si aggiunge il problema della governance temporale: la knowledge base deve essere mantenuta aggiornata e presidiata continuamente. Non è un’attività automatica, e non è una responsabilità del modello.

Una volta in uso, la vulnerabilità più diffusa è la prompt injection: un input costruito per aggirare le istruzioni del sistema, inducendo il modello a produrre output non previsti o a rivelare informazioni riservate. La criticità di questa minaccia emergeva anche dalla Top 10 per la sicurezza delle applicazioni AI della fondazione OWASP (Open Worldwide Application Security Project) che anche nell’aggiornamento del 2025 confermava la Prompt Injection al primo posto assoluto. Inoltre, diversi studi di settore e attività di “red teaming” hanno evidenziato come tecniche avanzate di prompt injection, a partire dagli attacchi basati su roleplay, istruzioni indirette e manipolazioni logiche, possano compromettere con elevata probabilità sistemi LLM privi di adeguate difese multilivello.

Va aggiunto che con l’introduzione degli agenti AI, queste minacce cambiano natura, se un sistema conversazionale produce una risposta sbagliata, in un sistema agentivo connesso a strumenti operativi, ciò si traduce in un’azione sbagliata, ovvero il danno da informativo diventa operativo.

Nessuna di queste vulnerabilità dipende esclusivamente da un difetto implementativo, piuttosto sono il risultato di “negligenze”, come già evidenziato, lungo tutta la catena di adozione: progettazione, integrazione, aggiornamento nel tempo. Ed è proprio da questa distribuzione che nasce il problema più sottovalutato.

Sicurezza degli LLM e dispersione di responsabilità

Quando si verifica un incidente di sicurezza legato a un LLM, la prima domanda che emerge non è tecnica, ma chi risponde. E la risposta, oggi, non è chiara.

Le vulnerabilità descritte sono il risultato di decisioni prese in momenti e attori diversi, con livelli di consapevolezza anche molto differenti. Il vendor che ha pre-addestrato il modello, il system integrator che ha progettato l’architettura, il cliente che ha deciso quali dati far confluire nel sistema: ciascuno ha contribuito a costruire il perimetro di rischio. Ma quando quel perimetro viene violato, ogni attore tende a considerare la sicurezza come un tema delegato agli altri.

Questo schema non è nuovo nel settore tecnologico, ma negli LLM si manifesta con una forza particolare per due ragioni. La prima è l’opacità dei modelli: a differenza di un’applicazione tradizionale, un LLM produce output probabilistici che nessun attore della catena può prevedere o garantire completamente. La seconda è la velocità di adozione: le organizzazioni hanno integrato questi sistemi in processi critici prima che esistesse un framework condiviso per gestirne i rischi. Il risultato è che la responsabilità si è frammentata prima ancora di essere definita.

Tre livelli di responsabilità non delegabili

Per uscire dall’ambiguità occorre distinguere con precisione i livelli su cui questa responsabilità si articola. Ne identifico almeno tre, con obblighi che non possono essere scaricati sugli altri.

Il vendor del modello

Il vendor del modello è responsabile di garantire che il sistema non sia inducibile, tramite prompt injection o jailbreak, a comportamenti che compromettono la sicurezza delle informazioni. I modelli pre-addestrati possono contenere funzionalità che, in determinate condizioni operative, diventano vettori di rischio. Si tratta di garanzie che la pressione competitiva relega spesso in secondo piano, anche per l’assenza di un’attenzione diffusa delle organizzazioni su questo tema. Ma la responsabilità esiste indipendentemente dal fatto che venga richiesta.

Il system integrator

Il system integrator ha responsabilità tecniche sulla progettazione dell’intera pipeline: cifratura, configurazione dei modelli di sicurezza, architettura RAG, gestione degli ambienti e dei perimetri di accesso. Queste responsabilità esistono indipendentemente da come viene strutturato il contratto. Chi progetta l’architettura decide strutturalmente anche quanto il sistema può essere esposto.

Il cliente

Il cliente ha una responsabilità nel suo doppio ruolo. Come data controller è responsabile della classificazione dei propri dati e delle decisioni su quali informazioni entrano nel sistema. Come committente è responsabile della governance della pipeline nel tempo. Questa governance non può essere delegata all’AI stessa, perché un sistema linguistico non può essere il garante della propria affidabilità. E non può essere delegata interamente al fornitore, perché nessun fornitore conosce il contesto operativo dell’organizzazione meglio dell’organizzazione stessa.

Il modello di Shared Responsibility che manca agli LLM

Chi ha vissuto la transizione verso il cloud riconosce questo schema. Anche lì la responsabilità sulla sicurezza era rimasta a lungo ambigua, frammentata tra provider e clienti. La svolta è arrivata con il modello di Shared Responsibility che ha definito una mappa esplicita di chi è responsabile di cosa, a quale livello dello stack tecnologico. Una mappa che non ha eliminato i rischi, ma ha reso certamente possibile presidiarli con maggiore consapevolezza.

Per gli LLM, quel modello non esiste ancora. E la sua assenza non è un problema tecnico, è un problema di governance del settore. Costruirlo richiede che vendor, integratori e clienti smettano di considerare la sicurezza degli LLM un problema altrui, e che il management, non solo i team tecnici, comprenda concretamente cosa implica introdurre questi sistemi nei processi aziendali e le conseguenze dello Shadow AI per essere in grado di valutare i rischi che si stanno “accettando”.

La priorità emergente è adottare gli LLM con un modello di responsabilità chiaro, riconoscendo anche che la velocità d’innovazione non può giustificare compromessi sulla sicurezza da parte di nessun attore della catena. Non farlo significherà farlo al primo incidente, e a quel punto il costo non sarà solo tecnico.