Dati: i rischi nascosti dell’AI generativa e come mitigarli

L’intelligenza artificiale generativa è un potente acceleratore di business, ma le aziende non sempre sanno dove finiscono le loro informazioni sensibili quando interrogano un Large Language Model (LLM). Per questo è importante sfatare il mito della natura effimera dei dati nell’AI ed evidenziare tre rischi concreti, e spesso sottovalutati, che possono portare a data leak catastrofici.

Il problema nasce da un’errata percezione comune. Molti credono che, essendo i modelli LLM stateless (ossia modelli che trattano ogni richiesta e interazione come una transazione indipendente non correlata a nessuna precedente richiesta), sia sufficiente chiudere una sessione di chat per far sparire i dati.

La realtà, come dimostrano gli incidenti di sicurezza che hanno coinvolto grandi aziende e piattaforme, è molto più complessa. Sebbene il nucleo del modello non memorizzi le conversazioni, l’infrastruttura che lo circonda è tutt’altro che priva di memoria. Infatti, i dati, spesso a nostra insaputa, persistono in cache, log, embedding store e dump di sistema.

Anatomia di un flusso dati e i suoi punti deboli

Per capire dove si annida il rischio, è necessario analizzare il percorso di una query in un’architettura comune come la RAG (Retrieval-Augmented Generation). L’informazione viaggia dall’utente a un controller, passa per un retriever che interroga una knowledge base e arriva a un prompt builder, prima di essere inviata all’LLM. La risposta segue un percorso inverso, spesso passando per un redactor che dovrebbe censurare le informazioni sensibili. Questo flusso, composto da almeno otto passaggi, nasconde tre zone rosse critiche:

1. Retention “accidentale” in cache e log. Ogni framework di sviluppo, per sua natura, traccia richieste e risposte per poter analizzare e risolvere i bug. Questi dati finiscono su disco, in cache di servizio e file di log. Il problema è che chi scrive questi logger raramente si pone il problema della sicurezza dei dati contenuti. Poche aziende implementano di default la cifratura dei log prima della scrittura su disco o processi automatici per l’eliminazione periodica delle cache e dei log più vecchi. Di conseguenza, informazioni sensibili come password, dati personali o segreti aziendali possono rimanere archiviate per mesi, se non anni, in file di testo facilmente accessibili.
2. Prompt injection e prompt leak. Questa vulnerabilità, evidenziata anche nella Top 10 per le applicazioni LLM redatta da Open Worldwide Application Security Project (OWASP) – un’iniziativa open-source internazionale no-profit nata nel 2001 con lo scopo di formulare linee guida, strumenti e metodologie per migliorare la sicurezza delle applicazioni informatiche – permette a un utente malintenzionato di manipolare l’LLM per fargli rivelare il suo prompt di sistema originale. Questo prompt di sistema spesso contiene informazioni critiche, come token di accesso, istruzioni riservate o chiavi API. Nel 2025, l’OWASP ha dimostrato che, in alcuni casi, è sufficiente iniziare una chat con la parola “sure” per convincere un agente a esporre l’intero prompt.
3. Fine-tuning involontario. Questo è forse il rischio più insidioso perché trasforma il dato da un’entità discreta a una caratteristica intrinseca del modello stesso. Il contenuto sensibile viene codificato nei pesi del modello e, a quel punto, non esiste un comando per cancellarlo. Questo può accadere attraverso tre pipeline principali:

• Learning loop automatico: processi che, a intervalli regolari, prendono i log delle conversazioni per generare dataset e ri-addestrare il modello (fine-tuning). Se i log non vengono prima depurati, dati personali e segreti aziendali finiscono direttamente nel dataset di addestramento.
• Feedback-based tuning (RLHF/RLAIF): molti sistemi raccolgono il feedback degli utenti per migliorare le performance del modello. Gli utenti, nel tentativo di fornire un contesto utile, possono incollare dati riservati direttamente nelle finestre di feedback, fornendo involontariamente materiale sensibile per il ri-addestramento.
• Opt-in di terze parti: alcuni vendor SaaS utilizzano i prompt dei loro clienti per migliorare i loro modelli pubblici. Anche se dichiarano di conservare i dati solo per un periodo limitato di 30 giorni e in forma cifrata, il modello base può comunque imparare e memorizzare l’essenza di tali informazioni.

Una strategia in tre mosse per la sicurezza

Mitigare questi rischi è possibile, ma richiede un approccio proattivo basato su tre azioni fondamentali:

1. Pre-prompt sanitation e Data Loss Prevention (DLP), ossia implementare sistemi che analizzino e depurino le richieste degli utenti prima che vengano inviate all’LLM, rimuovendo o mascherando dati sensibili al fine di prevenire la trasmissione di informazioni riservate;
2. Policy di accesso e auditing, che significa definire policy chiare su chi può accedere a quali dati e sistemi e implementare un sistema di auditing per tracciare ogni interazione;
3. AI Sec-Ops e monitoraggio continuo; cioè adottare un approccio di Security Operation specifico per l’AI, con un monitoraggio costante dei flussi di dati e dei log per individuare anomalie e potenziali leak in tempo reale.

Il miglior firewall? Le policy aziendali

L’AI non è il nemico, ma un acceleratore che amplifica ogni cosa, inclusi gli errori di governance dei dati. Per questo, la responsabilità della sicurezza non può essere delegata interamente al vendor di AI. Il vero firewall risiede piuttosto nelle policy aziendali e nel monitoraggio continuo. Solo con questa consapevolezza si può iniziare a lavorare per far sì che i dati restino davvero dove devono stare.