"Nessuno, neanche chi sviluppa i modelli, sa esattamente quando fa una release, quale sarà il risultato". È questa la premessa con cui Sergio Ajani, Service & Solutions Design Director di Innovaway, inquadra il problema della sicurezza dei Large Language Model. Una premessa che vale quanto una conclusione: nell'era degli LLM, la certezza è un lusso che nessuno può permettersi, e l'onestà intellettuale di chi lavora sul campo inizia dal riconoscerlo.

L'occasione per questa conversazione è arrivata a ridosso della pubblicazione di incidenti legati a Claude Code e a vulnerabilità di ChatGPT, che confermano una dinamica a cui avevamo già assistito in tempo di pandemia con l'adozione frenetica del cloud: “tutti i casi in cui c'è un utilizzo tumultuoso o poco ponderato delle nuove tecnologie portano con sé una serie di malfunzionamenti sistemici nel modello di adozione". La corsa, allora come ora, precede la riflessione. E i conti arrivano dopo.

Il dataset come superficie di attacco

Ajani ricorda che il punto di partenza è che l'efficacia di un LLM dipende dai dati usati in fase di addestramento: "banalizzando, il dataset stesso è una superficie di attacco estremamente critica perché contiene i dati usati per le elaborazioni, e come tale espone a rischi sistemici tutte le organizzazioni che vi inseriscono le proprie informazioni". In quest’ottica, data governance e data protection sono il prerequisito necessario per chi usa o costruisce sistemi AI.

Sergio Ajani, Service & Solutions Design Director di Innovaway

Più nello specifico, Ajani identifica tre grandi famiglie di vulnerabilità legate alla gestione dei dati di training. La prima è il data poisoning: "che nasce quando qualcuno, in modo scientifico, voluto, non casuale, inserisce campioni manipolati che alterano il comportamento del modello, creando vulnerabilità paragonabili a uno zero-day all'interno di un sistema LLM". È un rischio amplificato dal fatto che molti modelli ampiamente utilizzati sono open source: chiunque può studiarli, trovare le falle e costruire exploit per sfruttarle.

La seconda famiglia riguarda il privacy leakage: informazioni sensibili inserite nei dataset di training si possono estrarre anche semplicemente attraverso le chat. "Questa vulnerabilità è principalmente è legata a una mancanza di governance nella fase di caricamento dei dataset, ma potrebbe essere anche intenzionale quando il training viene affidato a una terza parte". La terza vulnerabilità è quella della supply chain: l'utilizzo di dataset provenienti dall'esterno, acquisiti via web scraping o da fonti terze senza controlli di integrità, può introdurre codice malevolo o informazioni non corrette all'interno del sistema.

Quest'ultimo punto porta Ajani a un parallelismo illuminante con il vibe coding: così come chi genera codice con l'AI tende ad accettarlo senza analizzarlo riga per riga, altrettanto accade con le fonti dei dataset. "Tuttora si tende a riporre un’eccessiva fiducia in ciò che genera e seleziona l’AI", e il rischio non è solo di sicurezza, è di accuratezza. In questo contesto c’è però un rovescio della medaglia che Ajani segnala con lucidità: "Se sono obbligato ad analizzare i dati per essere sicuro che non ci siano informazioni sensibili o altri elementi che possano rappresentare un rischio per la sicurezza, quello è anche l’occasione in cui posso chiedermi se quel dato è buono, se mi serve davvero, se posso migliorare la catena di gestione. Come sempre in ambito security, un problema diventa anche un'opportunità".

Tre livelli di responsabilità

La superficie di attacco è uno dei problemi. Un altro, enorme, problema è il tema della responsabilità, con un modello che dovrebbe essere chiaro e percepito da tutte le parti in causa, come quello di shared responsability del cloud. In realtà, del panorama LLM attuale è tra le questioni più complesse e meno chiarite.

Anche qui Ajani individua tre livelli distinti. Il primo riguarda chi fornisce il modello: "dovrebbe garantire – sottolinea Ajani- che il modello non sia facilmente inducibile ad azioni che mettono a rischio la sicurezza delle informazioni", il che non è un requisito banale, perché i modelli pre-addestrati possono contenere algoritmi e funzionalità che, in determinate condizioni, diventano vettori di rischio.

Il secondo livello è quello del system integrator: "questi sistemi non sono clic-and-buy. C'è una responsabilità precisa sulla progettazione della pipeline, sulla cifratura, sulla configurazione dei security model, sulla gestione degli ambienti di calcolo" spiega Ajani. Chi realizza la soluzione porta con sé responsabilità tecniche e attuative che non possono essere scaricate su altri tramite un contratto.

Il terzo livello, non meno importante, è il cliente, che nella visione di Ajani "ha due ruoli. Come data controller è responsabile dei propri dati e della classificazione che assegna loro: se dice che un dato è protetto, viene protetto; se non lo classifica come tale, non viene protetto. E poi è responsabile della governance complessiva, che deve tenere sotto controllo tutta la pipeline e tutta la catena". Questa governance non può essere delegata a strumenti AI, perché "il controllore non può operare all’interno dello stesso dominio in cui risiede la criticità”.

RAG, accessi e il problema della compiacenza

Definito il perimetro delle responsabilità, il passo successivo è capire dove le aziende italiane si trovano concretamente ad operare oggi e su quali scenari Innovaway viene chiamata a intervenire, dato che il suo portafoglio di servizi include Cyber Resilience, gestione della compliance NIS2 e DORA, e Threat & Vulnerability Assessment.

Sul fronte degli scenari più richiesti, Ajani è netto: per un utilizzo enterprise, il modello fine-tuned su dati aziendali è quello con il profilo di utilizzo più concreto. “Lo stiamo implementando su vari clienti, con use case diversi che non sempre trattano dati riservati o critici: talvolta sono solo dati informativi o knowledge base. Ma il principio di rischio è lo stesso". Questi sistemi si appoggiano quasi invariabilmente a un'architettura RAG (Retrieval-Augmented Generation), che introduce vulnerabilità proprie: c'è sempre un rischio legato a questo elemento che allarga e stira la superficie d'attacco.

I due temi su cui si concentra la maggior parte degli interventi sono la protezione dei dati e il controllo degli accessi. Sul primo, Ajani porta un esempio concreto: "un'azienda di moda che usa modelli cloud per progettare i bozzetti di una sfilata gioca il proprio vantaggio competitivo sulla riservatezza: se quei contenuti trapelano, la sfilata perde valore prima ancora di esistere. Il segreto industriale riguarda tutti i settori e, in Italia, significa inoltre e soprattutto proteggere il valore del Made in Italy". Siamo davanti a un'estensione del concetto di DLP (Data Loss Prevention), nel dominio dell'AI.

Sul controllo degli accessi, "si passa da un modello di controllo su database, ormai consolidato, a un paradigma in cui si implementano ruoli all'interno di un sistema che non ragiona per ruoli in modo analitico, ma solo in modo ipotetico" piega Ajani. Un modello linguistico, se interpellato da qualcuno che si dichiara direttore generale e chiede accesso illimitato, potrebbe compiacere per natura per il famoso "concetto di compiacenza del modello". Inoltre, l'architettura RAG pone un problema di data governance temporale, perché "non è banale mantenerla allineata, aggiornarla, essere sicuri che contenga tutte e solo le informazioni necessarie. Bisogna garantire sia l'accesso al dato sia che il dato obsoleto venga cancellato: è come una finestra che si sposta sulle mie informazioni, non può contenere tutto".

Il problema degli accessi diretti ai prompt è altrettanto critico: "se un dipendente può caricare un documento riservato in un prompt, dubito che esista in questo momento la possibilità di fare un fencing efficace. Si può farlo sui dati acquisiti in back office come system integration, ma se un agente AI è collegato a SharePoint o a un Google Drive aziendale, ha accesso a tutto" riflette Ajani. Per questo motivo, la soluzione adottata internamente da Innovaway per i propri operatori di help desk è paradigmatica: una RAG verificata, con prompt costruiti ad hoc che filtrano sia le richieste che gli output, e che non consentono il caricamento di file arbitrari. "Si va verso un'AI più di scopo, più filtrata. Meno spettacolare, ma più sicura" sintetizza Ajani.

Nonostante quanto detto finora, restano le criticità emerse con le ultime notizie relative ai modelli AI, e che fanno venire il dubbio che l'industria stia privilegiando la velocità a dispetto della sicurezza. Ajani ribatte con una riflessione pragmatica su base storica: "quando hanno messo in produzione le macchine a vapore, non erano molto sicure. In generale, quando si perseguono fini tangibili, si intraprende una corsa che non lascia inevitabilmente spazio per fermarsi a ragionare. La mia sensazione è che non si possa mettere un freno allo sviluppo tecnologico senza bloccare del tutto l’innovazione, almeno in questa fase”. Pensando a un paradigma esclusivamente di cybersecurity, non dovrebbe quindi essere consentito quanto meno l’uso di agenti che prendono possesso dello schermo del pc, ma c’è fior di servizi in abbonamento mensile che lo fanno.

Uno sguardo al futuro

Fermarsi ad analizzare la situazione attuale sarebbe limitante, perché è mandatorio avere un occhio sul futuro quando c’è un ballo la produttività aziendale. Per questo la parte finale della conversazione con Ajani sugli agenti AI ha aperto all’orizzonte di ricerca che Innovaway sta esplorando con alcune università italiane e che riguarda le architetture neurosimboliche. Ajani spiega che "si stanno fondendo due filoni che erano paralleli: quello basato su ragionamenti simbolici, deterministici, e quello delle reti neurali. Questa disciplina unisce l'aspetto simbolico con quello neuronale", con l'obiettivo pratico di costruire un agente supervisore che non ragioni con la stessa logica statistica del sistema che deve controllare, perché "chi deve essere determinista non può essere fatto della stessa materia di chi sbaglia".

L'applicazione può essere anche in ambito security, come spiega Ajani: "pensiamo che questa evoluzione possa essere importante per implementare un layer di supervisione che analizzi tutti i prompt e gli output e verifichi che siano compliant, non in modo statistico, ma alla base di un ragionamento. Un'architettura in cui agenti LLM eseguono i task e agenti neurosimbolici verificano ogni stato prima che l'output passi alla fase successiva”. Non sostituzione delle persone, ma utilizzo della augmented intelligence per la supervisione, consentendo di fare cose con più affidabilità rispetto all’intelligenza artificiale che conosciamo oggi. È uno dei tasselli del piano industriale 2026-2028 dell’azienda, un percorso di crescita basato su uno sviluppo organico e acquisizioni mirate, potenziato dall'integrazione tecnologica derivante dalla partnership con vendor leader di mercato come HCLSoftware.

L’ipotesi è intrigante e sicuramente richiederà formazione, che è un po’ il fil rouge di tutta la conversazione, perché a parte lo sguardo sul futuro, la realtà che già stiamo vivendo evidenzia che "tutto il tema degli LLM apre a possibilità che prima non esistevano, sia per i progettisti che per gli utenti, e per questo obbliga a un cambio di approccio nella valutazione del modello di rischio. Occorre un’attività di awareness a tappeto per diffondere il nuovo paradigma con tutte le sue stratificazioni" che deve coinvolgere non solo le competenze tecniche, ma anche e soprattutto il management, a cui oggi non è chiaro cosa sia l'AI, cosa possa fare e quali rischi comporta.