L’adozione rapida dell’AI generativa (AIGen) ha introdotto un nuovo canale di esfiltrazione dei dati, spesso difficile da individuare con gli strumenti di controllo tradizionali.

L’AI Data Leakage Prevention consente di governare il rischio di perdita delle informazioni senza rinunciare ai benefici dell’intelligenza artificiale, considerando che l’integrazione dei modelli generativi nei processi aziendali richiede un controllo continuo dei flussi di dati in uscita, integrando le misure DLP (Data Loss Prevention) nella gestione della superficie d’attacco.

Si tratta di prevenire l’esposizione o l’esfiltrazione di dati critici e rafforzare la sicurezza dell’uso dell’AI all’interno dell’organizzazione.

Cos’è la AI Data Leakage Prevention e quali rischi gestisce in azienda

L’AI Data Leakage Prevention è l’insieme di politiche, processi e tecnologie che impediscono a dati sensibili, riservati o regolamentati di essere inviati, in modo consapevole o meno, a strumenti di AI non autorizzati o non adeguatamente protetti.

Inoltre, l’ASM (Attack Surface Management) estende i principi del DLP classico a un contesto in cui il dato lascia l’azienda tramite una “finestra di conversazione” che può comportare la perdita sia di proprietà intellettuale (i.e. codice sorgente, progetti, formule) sia di strategie commerciali che possono finire su servizi esterni, fuori dal controllo dell’impresa.

Senza dimenticare che l’esposizione dei dati personali di clienti, di dipendenti e di fornitori implica sanzioni normative oltre che la possibile violazione degli obblighi contrattuali di riservatezza assunti verso terzi.

Siamo di fronte al fenomeno della shadow AI, cioè degli strumenti adottati dai team senza l’approvazione di IT e sicurezza e che sfuggono a qualsiasi forma di monitoraggio.

Come le interazioni con i modelli generativi espongono i dati aziendali

Ogni interazione con un modello generativo comporta l’invio di informazioni a un servizio esterno. Il punto di esposizione più evidente sono i prompt e gli allegati: testi, documenti, fogli di calcolo e immagini caricati per essere analizzati o riassunti.

Meno visibili, ma altrettanto rilevanti, sono le estensioni del browser che leggono il contenuto delle pagine aziendali e lo trasmettono a servizi AI, e gli assistenti integrati nelle applicazioni SaaS che accedono a email, chat e documenti con gli stessi permessi dell’utente.

È importante evidenziare che anche gli sviluppatori contribuiscono al rischio, quando creano connessioni tramite API che inviano ai modelli dati di produzione, senza adeguati controlli.

Inoltre, non va trascurata la conservazione dei dati da parte del fornitore: cronologie, log e, a seconda delle condizioni contrattuali, l’eventuale impiego dei contenuti per migliorare i modelli possono amplificare il rischio cresce in modo significativo, soprattutto quando si usano account personali gratuiti, che spesso offrono garanzie di riservatezza inferiori rispetto alle versioni enterprise.

Qual è la differenza tra fuga dati involontaria e attacco informatico diretto

Le due minacce hanno origini diverse e richiedono risposte diverse. Ma vediamo di che si tratta.

È doveroso evidenziare che la fuga involontaria è la tipologia di minaccia più diffusa e si contrasta con consapevolezza e controlli preventivi; mentre l’attacco diretto richiede difese tecniche contro tecniche specifiche, quali: la manipolazione dei modelli tramite istruzioni nascoste in documenti o pagine web.

Come strutturare un’architettura DLP per il controllo degli strumenti AI

È importante evidenziare che un’architettura efficace si basa su più livelli complementari, quali: visibilità sugli strumenti in uso; controllo dei canali di uscita; classificazione dei dati; risposta agli incidenti.

Il primo passo consiste nel censire quali servizi AI vengono utilizzati, distinguendo quelli approvati da quelli tollerati e da quelli vietati. Successivamente, si tratta di classificare i dati, dato che nessuna regola DLP funziona se non si sa quali informazioni siano davvero critiche, oltre ad applicare i controlli tecnici nei punti in cui i dati transitano.

Sul piano tecnologico, l’accesso ai servizi cloud e AI viene governato da Secure Web Gateway e CASB (Cloud Access Security Broker), mentre il DLP di rete e l’endpoint ispeziona e blocca i trasferimenti di dati.

Inoltre, le estensioni di sicurezza del browser controllano ciò che viene digitato o incollato nei siti AI; mentre un gateway AI centralizzato fa da punto unico di accesso ai modelli autorizzati, applicando policy uniformi.

Ancora, gli strumenti di etichettatura dei documenti alimentano le regole DLP con la classificazione, mentre il SIEM (Security Information and Event Management) e i sistemi di monitoraggio correlano gli eventi a supporto della risposta agli incidenti.

Come ispezionare il traffico dati verso le API e i SaaS di intelligenza artificiale

L’ispezione del traffico consente di monitorare quali dati vengono inviati verso API e servizi SaaS di intelligenza artificiale e di intervenire in tempo reale per prevenire esposizioni o perdite di informazioni.

Il primo passo consiste nell’individuare domini, endpoint e servizi AI utilizzati dall’organizzazione, mantenendo un inventario aggiornato delle piattaforme autorizzate e conosciute. Inoltre, quando policy aziendali e normativa applicabile lo consentono, si consiglia di effettuare l’ispezione del traffico TLS (Transport Layer Security) per analizzare il contenuto delle richieste.

È importante, altresì, che l’analisi includa i payload delle richieste web e le chiamate API per verificare la presenza di dati personali, chiavi di accesso, credenziali, segreti e informazioni classificate.

Un ulteriore controllo riguarda la distinzione tra account aziendali e account personali, in modo tale che l’organizzazione possa autorizzare l’utilizzo della versione Enterprise di un servizio AI e, al contempo, limitare o bloccare l’accesso effettuato tramite credenziali personali, riducendo il rischio di Shadow AI e di trasferimento non autorizzato di dati.

Le organizzazioni devono essere consapevoli del fatto che le azioni di sicurezza devono essere proporzionate al livello di rischio. Inoltre, ogni evento dovrebbe essere registrato per supportare le attività di monitoraggio, audit, analisi degli incidenti e progressivo affinamento delle policy.

Ancora, per le integrazioni tramite API, è opportuno utilizzare un API gateway in grado di applicare filtri, policy e limiti alle chiamate.

Di fatto, le chiavi API e le credenziali non dovrebbero essere incorporate direttamente nel codice, ma gestite attraverso meccanismi sicuri di protezione e gestione delle credenziali, diventando parte integrante della strategia di AI security e DLP.

Come definire regole di filtraggio sui prompt per bloccare il codice sorgente

Il codice sorgente è uno degli asset più esposti, considerando che gli sviluppatori sono tra i maggiori utilizzatori di AIGen.

La protezione del codice sorgente avviene tramite l’impiego di più tecniche: il riconoscimento di pattern sintattici individua costrutti tipici dei linguaggi di programmazione, intestazioni di file e blocchi di codice di grandi dimensioni; il rilevamento dei segreti intercetta chiavi API, token, password, stringhe di connessione e certificati inseriti nel codice; il fingerprinting dei repository interni permette di riconoscere porzioni di codice proprietario anche se modificate in parte; i marcatori riservati, come avvisi di copyright, nomi di progetto e riferimenti a sistemi interni, offrono un ulteriore indizio.

A queste tecniche si aggiungono i controlli su dimensione e tipo di file (utili per limitare il caricamento di archivi, file di configurazione e dump di database) e le policy differenziate per ruolo e per progetto, più restrittive per i repository critici e più flessibili per il codice pubblico o open source.

È doveroso evidenziare che il blocco totale può spingere gli utenti verso alternative non controllate. Pertanto, si consiglia di affiancare ai filtri strumenti approvati e sicuri, con avvisi chiari che spieghino il motivo del blocco e indichino l’alternativa corretta.

Come integrare la sicurezza dell’AI con la compliance e il GDPR

La protezione dei dati nell’uso dell’AI non è solo una questione tecnica, ma un obbligo normativo. Il GDPR si applica ogni volta che nei prompt, nei documenti caricati o negli output sono presenti dati personali.

Inoltre, AI Act e, per molti settori, la direttiva NIS2 richiedono di integrare i controlli DLP con il programma di compliance per gestire i requisiti in modo coerente, evitando duplicazioni e lacune.

Quali requisiti di protezione dati impone l’adozione dell’AI generativa (AIGen)

L’uso di strumenti di AIGen richiede, innanzitutto, una base giuridica e finalità definite per il trattamento dei dati personali, oltre che l’applicazione del principio di minimizzazione, inviando ai modelli solo i dati strettamente necessari, oltre a ricorrere, quando possibile, ad anonimizzazione o pseudonimizzazione.

Sul piano contrattuale, il fornitore del servizio AI è di norma responsabile del trattamento e richiede un accordo ai sensi dell’art. 28 del GDPR.

Inoltre, se i dati raggiungono server fuori dallo spazio economico europeo servono garanzie adeguate per i trasferimenti. Ancora, quando il trattamento presenta rischi elevati per i diritti e per le libertà delle persone è necessaria una valutazione d’impatto (DPIA), e restano fermi gli obblighi di sicurezza e di notifica tempestiva dei data breach all’autorità.

Si tratta di implementare un approccio secondo i principi di privacy by design e by default, richiedendo che ogni strumento AI sia sottoposto a una valutazione preliminare che verifichi condizioni contrattuali, uso dei dati per l’addestramento, tempi di conservazione e certificazioni del fornitore.

Come dimostrare la tutela delle informazioni riservate durante gli audit

Il principio di responsabilizzazione (accountability) impone di essere in grado di dimostrare, e non solo di applicare, le misure adottate. Pertanto, in sede di audit, conviene presentare una policy sull’uso accettabile dell’AI, approvata dalla direzione e comunicata a tutto il personale, insieme a un inventario degli strumenti autorizzati con l’esito delle valutazioni sui fornitori.

Inoltre, il registro dei trattamenti deve risultare aggiornato con i trattamenti che coinvolgono l’AI e le relative DPIA.

È necessario, altresì, documentare le strategie di DLP mediante: prove di test; aggiornamenti; verifiche periodiche; log e report degli eventi, che mostrano tentativi bloccati, avvisi generati, incidenti gestiti e azioni correttive.

Completano il quadro le prove di formazione del personale, i contratti con i fornitori contenenti clausole su riservatezza, conservazione e uso dei dati e alcuni indicatori di performance, quali: il numero di violazioni della policy, i tempi di risposta e la copertura dei controlli.

Conclusione

L’AIGen è ormai parte del lavoro quotidiano e vietarla del tutto non costituisce una valida soluzione, considerando che gli utenti trovano, comunque, il modo di usarla, spesso fuori dal controllo dell’organizzazione.

Pertanto, la strada più efficace è governarla. Ciò comporta: conoscere quali strumenti sono in uso; classificare i dati; ispezionare i flussi verso i servizi AI; filtrare ciò che non deve uscire, a partire dal codice sorgente e dalle informazioni personali.

È importante evidenziare che i controlli tecnici acquistano pieno valore quando sono collegati alla compliance: un’architettura DLP ben documentata, unita a policy chiare, formazione e contratti solidi con i fornitori, consente di rispettare il GDPR, NIS2 e DORA e di affrontare gli audit con evidenze concrete.

L’AI Data Leakage Preventionsi converte, quindi, in una leva strategica che consente alle organizzazioni di sfruttare l’innovazione, senza mettere a rischio il proprio patrimonio informativo, oltre a garantire la compliance.