L’adozione di sistemi di intelligenza artificiale all’interno comporta l’utilizzo di grandi quantità di dati, spesso personali o aziendali. Tali dati sono necessari per: addestrare modelli, condurre ricerche, sviluppare nuove applicazioni, preparare rapporti, ecc.
Il trattamento di tali dati nei contesti di AI presenta rischi specifici come: la possibilità di re-identificazione degli interessati, la memorizzazione involontaria di informazioni riservate da parte dei modelli (il cosiddetto leakage) e il riutilizzo dei dataset per finalità diverse da quelle originarie.
Per questo motivo, accanto alle misure tecniche di mascheramento ed anonimizzazione dei dati, è necessario costruire un impianto organizzativo che ne governi l’applicazione, la verifica e l’aggiornamento nel tempo.
Il quadro si complica considerando anche il contesto normativo cogente e volontario rappresentato da norme quali: AI Act, CRA, ISO/IEC 42001:2023, ISO/IEC 27001:202e, ecc.
Indice degli argomenti
Anonimizzazione dati AI tra norme, rischi e obiettivi
Questo articolo presenta alcune delle principali misure disponibili per la anonimizzazione e mascheratura dati, siano essi personali che aziendali, nei progetti di AI, illustrandone vantaggi, limiti e ambiti di applicazione più idonei. L’obiettivo è quello di fornire un primo quadro utile a chi deve scegliere, presidiare o validare le misure all’interno della propria organizzazione, fermo restando che sono necessari successivi approfondimenti in relazione al contesto specifico.
Anonimizzazione, pseudonimizzazione e mascheramento nei progetti AI
Prima di esaminare le singole tecniche, è opportuno richiamare una distinzione che il GDPR (art. 4 e Considerando 26) e gli orientamenti del WP29/EDPB pongono al centro del quadro normativo. I termini anonimizzazione, pseudonimizzazione e mascheramento non sono sinonimi e producono conseguenze giuridiche sostanzialmente diverse.
Anonimizzazione
L’anonimizzazione, in senso tecnico e giuridico, rende impossibile — in modo irreversibile — la re-identificazione dell’interessato, anche qualora il dataset venisse incrociato con altre informazioni esterne disponibili. Un dato “genuinamente” anonimizzato fuoriesce dall’ambito di applicazione del GDPR, infatti non è più un dato personale e il suo trattamento non è soggetto agli obblighi del Regolamento.
Esempio. Un ospedale conduce una ricerca epidemiologica sui ricoveri per infarto nel 2025. Prima di elaborare il dataset, rimuove nome, cognome, codice fiscale, data di nascita esatta e indirizzo, e aggrega i dati per fasce di età quinquennali e per macroaree geografiche (es. “Nord-Ovest”). Il risultato è una tabella del tipo: “fascia 65-69 anni – macro area geografica Nord-Ovest: 456 ricoveri”. Nessun individuo è più identificabile, neppure incrociando il dataset con registri pubblici o banche dati demografiche.
Pseudonimizzazione
La pseudonimizzazione, invece, sostituisce gli identificativi diretti (nome, codice fiscale, e-mail) con codici o token generati artificialmente, conservando tuttavia la possibilità tecnica di risalire al dato originario attraverso una chiave crittografica o una tabella di corrispondenza custodita separatamente e con accesso controllato. Il dato pseudonimizzato resta a tutti gli effetti un dato personale e rimane pienamente soggetto al GDPR. La pseudonimizzazione è una misura di sicurezza ma non un’uscita dal perimetro del Regolamento.
Esempio. Uno studio clinico raccoglie dati sanitari dei partecipanti. Anziché trattare i dati con il nome reale dei pazienti, ogni partecipante viene identificato con un codice alfanumerico (es. PT-2025-00123). La tabella di corrispondenza tra codice e identità reale è conservata dal responsabile della privacy del centro coordinatore, in un sistema separato, con accesso limitato a pochi soggetti identificati ed autorizzati. I ricercatori lavorano esclusivamente con i codici. Se qualcuno ottenesse accesso alla tabella di corrispondenza, la re-identificazione sarebbe immediata; per questo motivo il dataset rimane un dato personale pseudonimizzato, non anonimizzato.
Mascheramento
Il mascheramento (data masking) è una tecnica che oscura o sostituisce parzialmente le informazioni sensibili all’interno di un dato, rendendolo illeggibile o inutilizzabile in parte, ma preservando la struttura o il formato originario. A differenza della pseudonimizzazione — che sostituisce l’intero identificativo con un codice — il mascheramento interviene solo su una porzione del dato o su una porzione di dati di un dataset, spesso per consentirne un uso limitato in contesti specifici (ambienti di test, supporto clienti, log applicativi) senza esporre l’informazione completa.
Il grado di protezione offerto dipende fortemente dal contesto. In alcuni casi il dato mascherato consente ancora l’identificazione (ad esempio, se si conosce il titolare di quella carta di credito), in altri no. Il dato mascherato è generalmente considerato ancora un dato personale ai fini del GDPR, salvo che il mascheramento raggiunga un livello di irreversibilità tale da soddisfare i criteri dell’anonimizzazione autentica — circostanza rara nella pratica.
Esempio. Un operatore di call center deve verificare l’identità di un cliente. Il sistema CRM mostra il numero di carta di credito dell’utente in forma mascherata: **** **** **** 1234. L’operatore può confermare gli ultimi quattro cifre con il cliente senza mai vedere il numero completo. Il dato originario è conservato integralmente nel sistema, ma viene esposto solo in forma parziale. Il dato personale esiste, è protetto nella sua visualizzazione, ma non è eliminato né reso irriconoscibile in assoluto.
Questa distinzione è particolarmente rilevante nei progetti di AI. Un dataset apparentemente “anonimizzato” tramite semplice rimozione dei nomi può restare comunque re-identificabile attraverso tecniche di linkability o inference, soprattutto quando contiene variabili quasi identificative (età, codice postale, professione) o quando viene combinato con altre fonti.
La valutazione del rischio di re-identificazione – secondo i tre criteri classici di singling out, linkability e inference indicati dal WP29 nell’Opinion 05/2014 – deve quindi precedere la scelta della tecnica e accompagnarne la verifica nel tempo, anche per i dataset di training di modelli AI, dove il rischio di memorizzazione introduce una variabile ulteriore rispetto ai contesti di trattamento tradizionali.
La minimizzazione, infine, è un principio più ampio che impone di trattare solo i dati strettamente necessari alla finalità perseguita, indipendentemente dalla tecnica di mascheramento adottata.
Le misure tecniche per l’anonimizzazione dati AI
Non esiste una tecnica di mascheramento “migliore in assoluto”. La scelta dipende dal tipo di dato (testo libero, dati strutturati, immagini, audio), dalla finalità della ricerca AI, dal livello di rischio accettabile e dalla eventuale necessità di poter risalire al dato originario. Di seguito sono presentate le principali famiglie di tecniche, con i relativi vantaggi e limiti.
Generalizzazione e soppressione nei dataset strutturati
Queste tecniche riducono la precisione di alcuni attributi (ad esempio sostituendo un’età esatta con una fascia decennale, o un CAP con la sola provincia) fino a garantire che ogni combinazione di valori sia condivisa da un numero minimo di record (k-anonymity), evitando al contempo che i valori sensibili associati siano troppo omogenei (l-diversity) o troppo simili alla distribuzione complessiva (t-closeness).
| Vantaggi | Svantaggi / limiti |
|---|---|
| Approccio concettualmente semplice e ben documentato in letteratura, con strumenti di calcolo consolidati.Mantiene una buona leggibilità e utilità statistica del dataset per analisi aggregate.Adatto a dataset strutturati con attributi quasi identificativi noti (età, area geografica, professione). | Il livello di protezione dipende fortemente dalla scelta dei parametri (k, l, t) e dalla conoscenza ausiliaria disponibile a un potenziale attaccante.Poco efficace su testo libero o dati non strutturati, tipici di molti progetti di AI.Una generalizzazione eccessiva può compromettere l’utilità del dataset per l’addestramento dei modelli. |
Perturbazione e rumore statistico nei dati per l’AI
Le tecniche di perturbazione modificano i valori originali introducendo rumore statistico (noise addition), scambiando valori tra record simili (data swapping) o sostituendo gruppi di record con valori medi (microaggregazione), in modo da preservare le proprietà statistiche del dataset senza conservare i valori esatti dei singoli individui.
| Vantaggi | Svantaggi / limiti |
|---|---|
| Mantiene utili proprietà statistiche aggregate, vantaggioso per modelli che apprendono da pattern distribuzionali.Più resistente a tecniche di linkability rispetto alla sola generalizzazione, perché i valori sono alterati e non solo troncati.Applicabile in modo automatizzato e scalabile su grandi dataset. | L’introduzione di rumore può degradare la qualità del dato e, di conseguenza, le prestazioni del modello AI addestrato.Inapplicabile in contesti in cui i dati disponibili sono limitati.Richiede competenze statistiche per calibrare correttamente l’intensità della perturbazione.Non garantisce da sola un livello di anonimizzazione formale se non combinata con una valutazione del rischio residuo. |
Differential privacy nelle pipeline di training
La differential privacy introduce un parametro matematico (epsilon) che quantifica e limita la quantità di informazione che un singolo record può influenzare nell’output di un’analisi o nell’addestramento di un modello, garantendo che la presenza o l’assenza di un singolo individuo nel dataset non sia, in pratica, distinguibile dall’esterno.
| Vantaggi | Svantaggi / limiti |
|---|---|
| Offre una garanzia matematica formale di protezione, a differenza di molte tecniche euristiche.Il parametro epsilon è configurabile e consente di adattare il compromesso tra privacy e utilità alla finalità della ricerca.Particolarmente indicata per pipeline di training di modelli AI su larga scala, dove è già adottata da diversi framework di machine learning. | Il compromesso tra utilità del dato e livello di protezione richiede competenze tecniche specifiche. Un epsilon troppo permissivo riduce la protezione, uno troppo restrittivo degrada il modello.Complessità implementativa superiore rispetto ad altre tecniche, soprattutto per team senza esperienza specifica.Comunicare e documentare il significato del parametro epsilon a soggetti non tecnici, ai fini dell’accountability, può risultare difficile. |
Mascheramento, hashing e tokenizzazione
Il masking sostituisce parte di un valore con caratteri fissi (ad esempio mostrando solo le ultime quattro cifre di un codice), l’hashing trasforma un valore in un’impronta univoca tramite funzione matematica (con o senza salt), mentre la tokenizzazione sostituisce il dato con un token che può essere reversibile, tramite tabella di corrispondenza protetta, o irreversibile.
| Vantaggi | Svantaggi / limiti |
|---|---|
| Tecniche relativamente semplici da implementare anche con strumenti diffusi (Excel, script Python, Microsoft Presidio).La tokenizzazione reversibile consente di mantenere la possibilità di ricollegare il dato quando strettamente necessario e autorizzato, utile in contesti di ricerca che richiedono follow-up.L’hashing con salt riduce il rischio di attacchi a dizionario rispetto al semplice hashing. | L’hashing senza salt è vulnerabile ad attacchi a dizionario o rainbow table se il set di valori possibili è limitato (es. codici fiscali, numeri di telefono).La tokenizzazione reversibile mantiene lo status di dato personale – è pseudonimizzazione, non anonimizzazione – e richiede comunque misure di sicurezza sulla tabella di corrispondenza.Il semplice masking di superficie non protegge da attacchi di inferenza se altri campi del dataset permettono comunque la re-identificazione. |
Dati sintetici come alternativa o complemento
I dati sintetici sono generati algoritmicamente per riprodurre le proprietà statistiche di un dataset reale senza contenere record originali, e possono essere usati come alternativa o complemento alle tecniche di anonimizzazione classiche.
| Vantaggi | Svantaggi / limiti |
|---|---|
| Possono eliminare quasi del tutto il legame diretto con i dati reali, riducendo in modo significativo il rischio di re-identificazione.Utili per condividere dataset di test o di sviluppo con team interni o esterni senza esporre dati reali.Permettono di generare volumi di dati aggiuntivi quando il dataset originale è limitato. | Il generatore può “memorizzare” pattern troppo specifici del dataset originale (overfitting), reintroducendo un rischio di leakage se non adeguatamente testato.La fedeltà statistica dei dati sintetici rispetto ai dati reali deve essere validata, altrimenti il modello addestrato può avere prestazioni inferiori o bias non rilevati.Richiede competenze e strumenti specifici (es. librerie specifiche per dati semplici, modelli generativi più sofisticati per dataset complessi) e una validazione del rischio residuo comunque necessaria. |
Modelli AI in locale per rilevare e mascherare i dati
Un’alternativa, o un complemento, alle tecniche precedenti consiste nell’utilizzare modelli di intelligenza artificiale – in particolare modelli linguistici (LLM) per il riconoscimento di entità in testo libero – installati ed eseguiti all’interno del perimetro dell’organizzazione, invece di affidarsi a servizi cloud di terze parti per la fase di rilevamento e mascheramento dei dati. Il modello, ospitato su infrastruttura on-premise o in un ambiente cloud privato controllato dall’organizzazione, individua le entità sensibili nel testo e applica la strategia di anonimizzazione prevista (sostituzione, mascheramento, generalizzazione) senza che i dati grezzi transitino verso l’esterno nemmeno durante questa fase di pre-elaborazione.
| Vantaggi | Svantaggi / limiti |
|---|---|
| I dati non lasciano il perimetro organizzativo nemmeno durante la fase di rilevamento e mascheramento, riducendo il rischio di esposizione a terze parti già nella fase preparatoria del progetto AI.I modelli linguistici colgono meglio il contesto rispetto ai soli recognizer basati su regole o espressioni regolari, con un potenziale beneficio sui falsi negativi nel testo libero e nei documenti non strutturati.Controllo pieno su versioni, aggiornamenti e personalizzazione del modello (es. riconoscimento di codici interni, terminologia di settore), senza dipendere dalle politiche di un fornitore esterno.Nessuna dipendenza dalle condizioni contrattuali di un servizio cloud terzo in materia di conservazione o eventuale riuso dei dati trasmessi per l’elaborazione. | Richiede un investimento infrastrutturale (capacità di calcolo, eventuali GPU) e competenze di AI engineering per l’implementazione, l’aggiornamento; l’affinamento e la manutenzione del modello, spesso superiori a quelle necessarie per strumenti come Presidio.I modelli eseguibili in locale, specie se di dimensioni contenute per ragioni di costo computazionale, possono avere un’accuratezza inferiore rispetto ai grandi modelli cloud, con necessità di un impegno rilevante per la validazione umana dei risultati.Il modello stesso, se sottoposto a fine-tuning su dati interni, può incorporare un rischio residuo di memorizzazione (leakage) dei dati di addestramento, da gestire con le medesime cautele previste per altri modelli AI.Introduce un ulteriore oggetto di governance; infatti le decisioni di anonimizzazione del modello vanno documentate, validate e tenute sotto controllo nel tempo, anche a fronte di aggiornamenti del modello che possono modificarne il comportamento (model drift). |
Strumenti operativi per anonimizzare dati AI
Le tecniche descritte sopra devono essere tradotte in strumenti operativi concretamente utilizzabili dai team. Alcuni strumenti ricorrono con maggiore frequenza nei progetti aziendali, tra questi se ne citano alcuni tra i più diffusi.
Microsoft Presidio
Framework open source organizzato in due moduli principali:
- l’Analyzer, che rileva entità sensibili in testo, documenti o dataset strutturati – anche tramite recognizer personalizzati per identificativi specifici del proprio dominio, come codici interni o identificativi di progetto;
- l’Anonymizer, che applica strategie di trasformazione (redact, replace, mask, hash, encrypt) in base alla necessità o meno di reversibilità.
È disponibile inoltre un modulo Image Redactor per i contenuti visivi.
| Vantaggi | Svantaggi / limiti |
|---|---|
| Framework flessibile, integrabile in pipeline dati per elaborazione batch o in tempo reale.Consente di costruire recognizer ad hoc per entità specifiche del proprio contesto di ricerca.Copre più tipi di contenuto (testo, documenti, dataset strutturati, immagini). | Il supporto linguistico e il tasso di falsi positivi/negativi variano in base alla lingua e al dominio, rendendo necessaria una validazione umana periodica.Richiede manutenzione costante delle regole e dei recognizer personalizzati.Il livello di protezione resta legato alla qualità della configurazione e non garantisce da solo l’anonimizzazione “formale” del dataset. |
A titolo illustrativo, l’esempio seguente – estratto ed adattato al contesto italiano a partire dalla demo pubblica di Presidio – mostra come l’Analyzer riconosca le diverse categorie di dati personali in un testo libero e come l’Anonymizer le sostituisca con il relativo tag, prima ancora di qualunque utilizzo del testo per addestramento o ricerca AI.
| Testo originale (input) | Testo dopo l’anonimizzazione (output) |
|---|---|
| Salve; sono Marco Rossi e risiedo a Bologna.Il numero della mia carta di credito è 1234-1234-1234-1234 | Salve, sono <PERSON> e risiedo a <LOCATION>.Il numero della mia carta di credito è <CREDIT_CARD>. |
Presidio include recognizer dedicati al contesto italiano – IT_FISCAL_CODE per il codice fiscale, IT_VAT_CODE per la partita IVA, IT_IDENTITY_CARD per la carta d’identità, IT_DRIVER_LICENSE per la patente di guida e IT_PASSPORT per il passaporto – particolarmente utili nei dataset di ricerca e nei documenti aziendali italiani.
Come per ogni recognizer basato su pattern ed espressioni regolari, restano comunque necessari controlli periodici del tasso di falsi positivi/negativi e un aggiornamento delle regole a fronte di nuovi formati documentali.
Excel
Resta lo strumento più diffuso tra il personale non tecnico, utilizzato tramite formule di troncamento o sostituzione di testo, funzioni di hashing tramite Power Query, e la stessa Power Query per la generalizzazione di campi (es. età vs fascia di età, CAP vs area geografica).
| Vantaggi | Svantaggi / limiti |
|---|---|
| Accessibilità immediata, nessuna specifica competenza di programmazione richiesta.Adatto a interventi puntuali su dataset di ridotte dimensioni.Permette di coinvolgere rapidamente un team ampio e con competenze diversificate. | Assenza di controlli di qualità automatici ed elevato rischio di errore umano (es. formule non applicate a tutte le righe).Scarsa tracciabilità delle trasformazioni effettuate.Non dovrebbe costituire l’unica misura di anonimizzazione su dataset di ricerca sensibili, ma può accompagnare strumenti più strutturati. |
Python
Tramite librerie per la manipolazione dei dataset e per la generazione di dati sintetici di test e hashlib per le funzioni di hashing, Python consente di costruire pipeline di anonimizzazione automatizzate, ripetibili e versionabili.
| Vantaggi | Svantaggi / limiti |
|---|---|
| Scalabilità su grandi volumi di dati.Possibilità di integrare controlli di qualità automatici nella pipeline.Tracciabilità delle trasformazioni tramite repository, changelog e revisione del codice. | Richiede competenze di programmazione all’interno del team o personale dedicato al presidio degli script.Il rischio di errori nella logica degli script resta presente e deve essere mitigato con test e revisione tra pari.Maggiore complessità iniziale di set-up rispetto a strumenti pronti all’uso. |
Misure organizzative per governare l’anonimizzazione dati AI
Le misure tecniche, per quanto accuratamente scelte, non sono sufficienti se non sono accompagnate da un sistema organizzativo di regole, ruoli e controlli applicato in modo coerente da tutta l’organizzazione. Anche in questo caso, ogni misura, appartenente a questa famiglia, presenta vantaggi e limiti operativi.
Regolamento per l’uso dell’AI
Un regolamento interno definisce l’ambito di applicazione, i dati ammessi e non ammessi nei progetti e più in generale nell’applicazione di soluzioni di AI, l’obbligo di anonimizzazione preventiva, i divieti e le sanzioni interne, individuando anche le responsabilità di redazione e aggiornamento del documento.
| Vantaggi | Svantaggi / limiti |
|---|---|
| Fornisce un riferimento unico, vincolante e verificabile per tutta l’organizzazione, utile anche in sede di accountability verso le autorità di controllo. | Un regolamento troppo generico rischia di restare inapplicato nella pratica quotidiana, mentre uno troppo rigido può ostacolare l’innovazione; richiede aggiornamenti periodici per restare aderente all’evoluzione normativa (AI Act, schemi di decreto legislativo, norme ISO, ecc.) e tecnologica. |
Ruoli e responsabilità nella matrice RACI
Definire chi tra le varie funzioni aziendali preposti alla gestione dei progetti (es. PM, referenti di funzione) ed ai controlli (es. CISO, CAIO, DPO) è responsabile, consultato o informato in ciascuna fase del processo di anonimizzazione – e chi autorizza l’uso di un dataset per la ricerca AI – riduce ambiguità e tempi morti.
| Vantaggi | Svantaggi / limiti |
|---|---|
| Chiarezza su chi decide e chi risponde, elemento centrale ai fini dell’accountability richiesta dal GDPR, AI ACT e altre normative; facilita la gestione di situazioni critiche o non conformità. | Richiede un disegno organizzativo accurato e un aggiornamento costante al variare di strutture, progetti e personale, altrimenti rischia di diventare un documento formale scollegato dalla prassi operativa. |
Procedure operative e registro delle anonimizzazioni
Per le aziende che sviluppano sistemi di AI o forniscono dati a soggetti terzi, devono predisporre checklist per l’anonimizzazione pre-rilascio dei dataset, processi formalizzati di richiesta e approvazione dei dati (anche per le ricerche) e un registro delle anonimizzazioni effettuate costituiscono il livello procedurale che traduce regole e ruoli in pratica quotidiana verificabile.
| Vantaggi | Svantaggi / limiti |
|---|---|
| Garantiscono ripetibilità e tracciabilità, utili sia in fase di audit interno sia in caso di richieste da parte di autorità di controllo; riducono la dipendenza da conoscenza individuale non documentata. | Procedure troppo onerose possono generare resistenza da parte dei team, con il rischio che vengano percepite come un ostacolo burocratico e quindi eluse nella pratica se non accompagnate da formazione volta a rafforzare la consapevolezza e strumenti adeguati. |
Piani di formazione del personale
Piani di formazione differenziati per profilo (ricercatori, analisti, IT), con periodicità definita, modalità di verifica dell’apprendimento e gestione dei nuovi assunti, volti ad assicurare la comprensione e consapevolezza delle ragioni alla base delle misure implementate da parte di chi ne fa un uso quotidiano.
| Vantaggi | Svantaggi / limiti |
|---|---|
| Riduce il rischio di errore umano, una delle cause più frequenti di mascheramento inefficace anche in presenza di strumenti tecnici adeguati; rafforza una cultura organizzativa della protezione dei dati. | Richiede un investimento continuo di tempo e risorse, con il rischio che diventi un adempimento formale se non accompagnata da esercitazioni pratiche e verifica sul campo. |
Indicatori, audit, DPIA e FRIA
Indicatori di monitoraggio, audit periodici sulle pipeline di anonimizzazione, gestione delle non conformità e, dove necessario, valutazione d’impatto (DPIA) o valutazione d’impatto sui diritti fondamentali (FRIA) per i trattamenti ad alto rischio completano il presidio organizzativo.
| Vantaggi | Svantaggi / limiti |
|---|---|
| Permettono di rilevare derive o degradi delle misure nel tempo – ad esempio nuove fonti di dati che reintroducono rischi di re-identificazione – prima che si traducano in incidenti; costituiscono evidenza di accountability. | Richiedono competenze di audit specifiche e risorse dedicate, spesso scarse nelle organizzazioni di dimensioni minori; il valore degli audit dipende dalla qualità degli indicatori scelti, da definire con cura per evitare controlli puramente formali. |
Gestione di fornitori e terze parti
Clausole contrattuali specifiche sull’anonimizzazione e sull’uso dei dati per il training di modelli AI, insieme a una valutazione dei sub-fornitori, estendono il presidio organizzativo anche alla catena di fornitura, spesso punto debole nei progetti di AI che si appoggiano a piattaforme o modelli di terze parti.
| Vantaggi | Svantaggi / limiti |
|---|---|
| Riduce il rischio che dati personali o aziendali vengano trattati o riutilizzati per finalità non autorizzate da fornitori esterni (es. training di modelli general-purpose); rafforza la responsabilità contrattuale in caso di violazioni. | La verifica effettiva del rispetto delle clausole da parte dei fornitori è spesso difficile per non dire impossibile, soprattutto quando si tratta di grandi piattaforme con scarsa trasparenza sui propri processi interni di trattamento dei dati. |
In relazione a questo aspetto si vedano, per quanto solo parzialmente pertinenti al tema in esame, anche i due recenti provvedimenti del Garante:
- garanteprivacy.it/web/guest/home/docweb/-/docweb-display/docweb/10262367
- garanteprivacy.it/web/guest/home/docweb/-/docweb-display/docweb/10262105
Anonimizzazione dati AI: perché serve un approccio combinato
Nessuna misura tecnica, da sola, garantisce un livello di protezione adeguato nei progetti di AI. La generalizzazione può risultare insufficiente su testo libero, la perturbazione e la differential privacy richiedono competenze statistiche specifiche, la tokenizzazione reversibile mantiene lo status di dato personale, i dati sintetici introducono un rischio residuo di leakage del generatore, e l’uso di modelli di AI in locale, se da un lato evita l’esposizione dei dati a servizi cloud esterni, dall’altro richiede investimenti infrastrutturali e una governance dedicata sul comportamento del modello. Analogamente, le misure organizzative – regolamento, ruoli, procedure, formazione, audit, gestione dei fornitori – restano efficaci solo se concretamente applicate e periodicamente verificate. Le misure non si traducono automaticamente in protezione se non supportate da strumenti tecnici adeguati.
L’approccio più solido resta quindi quello combinato:
accompagnarla con un impianto organizzativo che definisca responsabilità, formi il personale e verifichi nel tempo l’adeguatezza delle misure adottate rispetto al rischio di re-identificazione, anche alla luce dell’evoluzione del quadro normativo (AI Act, CRA, ISO/IEC 42001:2023, ISO/IEC 27001:2022) e delle tecniche di attacco.
selezionare la tecnica di mascheramento più adatta al tipo di dato e alla finalità della ricerca/sviluppo AI, presidiarne l’implementazione tramite strumenti verificabili – da Microsoft Presidio a script Python tracciati, fino a eventuali modelli di AI in locale dove il contesto lo richieda;
Partecipa alla community