Ogni giorno migliaia di aziende italiane affidano a un Large Language Model decisioni, processi e dati critici. Lo fanno convinte di adottare una tecnologia straordinariamente potente, spesso senza considerare che rappresenta anche una superficie di attacco in continua evoluzione. Secondo l’ultimo rapporto ISTAT “Imprese e ICT”, nel 2025 il 16,4% delle imprese con almeno 10 addetti ha adottato soluzioni di AI generativa, oltre al triplo rispetto al 2023. Una crescita guidata molto spesso più dall’urgenza di innovare che da una riflessione matura sui rischi.
Le vulnerabilità degli LLM, una veloce review
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.
Una 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 è 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 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 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 che manca
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.
di Sergio Ajani, Service & Solutions Design Director, Innovaway
