Il know-how aziendale non esce più soltanto da un allegato inviato al destinatario sbagliato, da un repository mal protetto o da una violazione di rete. Può lasciare l’organizzazione attraverso un gesto molto più ordinario: incollare un contratto in un chatbot, chiedere a un modello di ottimizzare una funzione proprietaria, far riassumere una roadmap di prodotto, trasformare in una presentazione il verbale di una riunione tecnica. La promessa è comprensibile. L’IA generativa accelera compiti che prima richiedevano ore. Il rischio è meno visibile, perché il trasferimento di informazione avviene dentro un’interfaccia conversazionale che sembra innocua.
Il data leakage legato ai modelli esterni non coincide con la sola possibilità che un provider usi i prompt per addestrare nuovi sistemi. Quella domanda resta importante, ma restringe troppo il problema. In gioco ci sono anche log, retention, permessi, strumenti collegati, connettori, agenti, cache, sistemi di audit e servizi terzi richiamati lungo la catena applicativa. Un modello, in azienda, raramente è soltanto un modello. È un punto di passaggio dentro un’infrastruttura più ampia, dove ogni frammento di contesto può diventare informazione esportata.
Indice degli argomenti
Il know-how aziendale è spesso meno etichettato dei dati personali
Le imprese hanno imparato a riconoscere i dati personali, anche grazie a un quadro normativo ormai maturo. Il know-how, invece, circola in forme più sfuggenti. Si trova nei commenti del codice sorgente, nei dataset di test, nelle specifiche non ancora brevettate, nelle condizioni negoziali con un cliente, nei risultati intermedi di un laboratorio, nei prompt usati per interrogare basi documentali interne. Non sempre reca un’etichetta di riservatezza, ma può contenere ciò che rende competitiva un’organizzazione.
I grandi modelli linguistici accentuano questa fragilità perché premiano il contesto. Per ottenere una risposta utile, l’utente tende a fornire il problema nella sua interezza, non una versione depurata. È qui che la produttività può entrare in tensione con la sicurezza. OWASP colloca la disclosure di informazioni sensibili tra i rischi principali delle applicazioni basate su LLM, includendo dati aziendali confidenziali, credenziali, documenti legali, algoritmi proprietari e codice sorgente. La perdita può avvenire all’ingresso, quando l’informazione viene inviata al servizio, oppure all’uscita, quando un’applicazione mal progettata restituisce dati che l’utente non avrebbe dovuto vedere.
Data leakage IA generativa: il rischio non finisce con il training
I principali fornitori cloud e AI distinguono ormai tra prodotti consumer, servizi business e API. Nelle offerte enterprise o commerciali, OpenAI, Microsoft, Google Cloud, Anthropic e AWS dichiarano in forme diverse che i dati dei clienti non vengono usati di default per addestrare o migliorare i modelli di base, salvo consenso o configurazioni specifiche. È un elemento rilevante e va riconosciuto, perché separa gli ambienti governati da molti strumenti di uso personale.
La sicurezza, però, non si esaurisce nella clausola sul training. OpenAI, per esempio, indica che i dati inviati alle API non sono usati per addestrare i modelli, ma descrive anche log di abuse monitoring che possono contenere prompt e risposte e che, di default, sono conservati fino a trenta giorni, salvo eccezioni o controlli come Zero Data Retention e Modified Abuse Monitoring. Altri provider applicano logiche diverse, legate al tipo di prodotto, alla regione, al contratto e alla configurazione scelta. Per un’impresa, la domanda corretta non è soltanto se il dato finisca nel training. Bisogna sapere dove viene processato, per quanto tempo resta disponibile, chi può accedervi, quali subfornitori intervengono e quali funzioni accessorie possono ricevere contenuti.
La letteratura scientifica aggiunge un ulteriore motivo di prudenza. Gli studi sull’estrazione di dati di training hanno mostrato che modelli linguistici di grandi dimensioni possono memorizzare e restituire porzioni dei dati su cui sono stati addestrati, soprattutto quando il materiale è raro, duplicato o particolarmente riconoscibile. Questo non implica che un prompt aziendale inviato oggi a un servizio esterno riemerga automaticamente domani in una risposta pubblica. Implica, più concretamente, che il ciclo di vita del dato dentro l’IA va trattato come una superficie di rischio, non come un dettaglio tecnico secondario.
Shadow AI, il varco più probabile per la perdita di dati
Nella pratica quotidiana, la minaccia più frequente non è l’attacco sofisticato. È l’adozione spontanea. Un commerciale usa un assistente pubblico per rifinire una proposta. Un tecnico carica un log applicativo per farsi aiutare nel debug. Un consulente sintetizza un documento del cliente con uno strumento gratuito. Nessuno sta tentando di sottrarre informazioni, ma l’effetto può essere simile a una micro-esfiltrazione distribuita, difficile da vedere e ancora più difficile da ricostruire.
Un divieto assoluto raramente funziona. Se l’azienda blocca gli strumenti generativi senza offrire alternative solide, i dipendenti cercheranno scorciatoie meno controllabili. La risposta più efficace è costruire una via sicura e semplice. Servono strumenti approvati, policy leggibili, formazione concreta e regole di classificazione che non restino confinate nei documenti del reparto compliance. L’utente deve capire quando può usare un assistente generico, quando deve ricorrere a un ambiente enterprise, quando va anonimizzato il contenuto e quando l’informazione non deve uscire dal perimetro aziendale.
Le difese contro il data leakage stanno nell’architettura
La prima difesa è la minimizzazione. Un modello esterno dovrebbe ricevere soltanto il contesto necessario al compito, non l’intero documento o l’intero repository. Sistemi di anonimizzazione e oscuramento automatico possono rimuovere chiavi API, dati cliente, riferimenti contrattuali, segreti tecnici e identificativi prima che il prompt venga inviato. Tokenizzazione e mascheramento aiutano se sono inseriti in un processo verificabile, non se diventano un gesto manuale affidato alla buona volontà del singolo.
Il secondo livello riguarda i permessi. Un assistente collegato ai documenti aziendali deve rispettare la stessa segregazione prevista negli strumenti originari. Non può diventare, per via semantica, un motore capace di aggirare cartelle, ruoli e autorizzazioni. Il principio del least privilege resta essenziale, soprattutto quando entrano in gioco agenti che possono interrogare archivi, chiamare API, aprire ticket o produrre azioni su sistemi interni.
Il terzo livello è contrattuale. Prima di adottare un modello esterno, procurement, legale, sicurezza e data protection dovrebbero verificare clausole su uso per training, retention, localizzazione, cancellazione, accessi umani, subfornitori, auditabilità e gestione degli incidenti. Le opzioni di retention ridotta o nulla, quando disponibili, vanno valutate in base al caso d’uso. Per attività a bassa criticità può bastare un servizio enterprise configurato correttamente. Per proprietà intellettuale strategica, ricerca riservata o segreti industriali può essere preferibile un’architettura privata, un modello self-hosted o un sistema RAG che mantenga gli archivi sotto controllo aziendale e invii al modello solo frammenti filtrati.
Regole e standard alzano il livello di responsabilità
Il quadro europeo rende il tema sempre meno opzionale. L’AI Act attribuisce rilievo alla sicurezza, alla trasparenza e alla protezione delle informazioni riservate. In particolare, l’articolo 78 disciplina gli obblighi di riservatezza nell’applicazione del regolamento e richiama espressamente la tutela della proprietà intellettuale, delle informazioni commerciali confidenziali, dei segreti industriali e del codice sorgente. Il Codice di condotta europeo per i modelli di IA a uso generale, pubblicato nel luglio 2025 come strumento volontario di supporto alla conformità, si inserisce nello stesso movimento, con capitoli dedicati a trasparenza, copyright, safety e security.
Anche gli standard stanno andando nella stessa direzione. ISO/IEC 42001 definisce un sistema di gestione per l’intelligenza artificiale. Il profilo NIST AI 600-1 adatta il Risk Management Framework alla generative AI. La Cloud Security Alliance ha pubblicato una matrice di controlli per l’IA e linee guida Zero Trust per ambienti LLM, segnalando che la sicurezza dei sistemi generativi non è più un tema sperimentale, ma una disciplina da integrare nei processi ordinari di governance.
La conclusione è meno spettacolare di molte narrazioni sull’IA, ma più utile per chi deve gestirla. Proteggere il know-how non significa rinunciare ai modelli esterni. Significa trattare ogni prompt come un trasferimento di informazione, con una finalità, un limite, una destinazione e una responsabilità. La produttività dell’IA generativa è reale. Lo è anche il rischio di consegnare fuori dall’impresa, un frammento alla volta, ciò che l’impresa sa fare meglio.
