Per tre decenni, proteggere i dati personali ha significato controllare dove i dati erano archiviati e chi poteva raggiungere il database. Gli strumenti di IA hanno smontato quel modello in circa diciotto mesi.
Non è una critica all'IA. È la descrizione di un cambiamento strutturale — e comprenderlo è la differenza tra una protezione dei dati che funziona davvero e una protezione che fa bella figura in un audit di conformità ma crolla nella pratica nell'istante in cui un professionista apre una finestra di chat.
Il vecchio modello — e perché funzionava
La protezione classica dei dati personali era pensata per dati strutturati: schede CRM, sistemi di cartelle cliniche, database HR, registri contabili. La minaccia era l'accesso non autorizzato — un attaccante o un dipendente non abilitato che raggiungeva dati che non avrebbe dovuto raggiungere.
La risposta era altrettanto strutturata:
- Tokenizzazione e cifratura a livello di campo nei database: si sostituiscono codici di previdenza sociale e numeri di conto con token opachi a riposo. Solo i servizi abilitati possono risalire dal token al valore originale.
- Controlli di accesso basati sui ruoli: si limita quali dipendenti possono interrogare quali tabelle. Ogni lettura viene registrata.
- DLP di rete (prevenzione della perdita di dati): si analizza il traffico in uscita alla ricerca di pattern di dati personali strutturati — formato del codice di previdenza sociale, numeri di carta di credito, pattern di IBAN — e si blocca l'esfiltrazione prima che lasci il perimetro aziendale.
- Mascheramento dei dati negli ambienti non di produzione: si testa con dati dall'aspetto realistico ma generati in modo sintetico, che non contengono alcuna identità reale.
Questo funzionava perché i dati vivevano in posizioni delimitate e note. Si potevano elencare i sistemi che contenevano dati personali, cingere gli strati di archiviazione e di rete di controlli, e quei controlli tenevano di fronte al modello di minaccia per cui erano stati costruiti.
Cosa hanno cambiato gli strumenti di IA
La superficie di minaccia si è spostata — non perché gli strumenti di IA siano insicuri, ma perché hanno introdotto un percorso nuovo e senza attrito dall'archiviazione controllata al trattamento esterno.
Considerate il flusso di lavoro: un professionista apre SharePoint, scarica un contratto in PDF, apre ChatGPT e ne incolla il contenuto. Era autorizzato ad accedere al documento — nessun controllo di accesso è stato violato. Non ha esfiltrato dati in senso tecnico — ha usato un dispositivo approvato sulla rete aziendale. Ma il documento, con ogni nome, indirizzo e cifra finanziaria che contiene, è appena transitato verso un'infrastruttura cloud commerciale di cui l'organizzazione non ha alcuna visibilità, che nessun contratto disciplina, e di cui non esiste alcuna traccia di audit.
Gli strumenti di un tempo non hanno alcuna presa su questo:
- Il DLP di rete rileva pattern strutturati nei caricamenti di file e nei flussi in uscita, ma la maggior parte delle interazioni con l'IA avviene come richieste HTTPS POST verso un'interfaccia web — il proxy vede il dominio di destinazione, non il contenuto del corpo del messaggio.
- La tokenizzazione nel database protegge i dati personali a riposo. Quando l'utente ha scaricato un PDF e lo sta leggendo, i dati sono già stati estratti dal deposito dei token, ricostruiti e visualizzati. Il sistema di token ha fatto esattamente ciò che doveva — semplicemente non era progettato per il passaggio successivo.
- I controlli di accesso sono stati soddisfatti nell'istante in cui l'utente abilitato ha aperto il file. Ciò che accade a valle di quell'accesso è fuori dal loro perimetro, per progettazione.
Il vecchio modello partiva dal presupposto che controllare l'accesso ai dati equivalesse a controllare ciò che ne accadeva. Gli strumenti di IA hanno rotto quel presupposto di netto. Accesso autorizzato più una finestra di chat: ecco dei dati che lasciano l'organizzazione — in silenzio, legalmente (dal punto di vista del controllo di accesso), e in volume.
Perché il filtraggio lato cloud non basta
Una risposta a questa falla consiste nel far transitare tutto il traffico di IA attraverso un proxy aziendale che intercetta le richieste, cerca i dati personali, li oscura e inoltra la versione ripulita. Questo approccio esiste ed è meglio di niente. Ma ha limiti strutturali:
- Richiede l'ispezione SSL del traffico HTTPS — tecnicamente invasiva, costosa da gestire, e sempre più contestata dai modelli di sicurezza dei browser e dalla resistenza dei dipendenti in nome della riservatezza.
- Richiede una configurazione per ogni strumento di IA. Man mano che la proliferazione degli strumenti di IA accelera, la superficie da configurare cresce più in fretta di quanto qualsiasi team di sicurezza possa tenere il passo. Un nuovo strumento di IA diventa una falla nell'istante in cui un utente lo scopre.
- Intercetta i pattern di dati personali strutturati (formato del codice di previdenza sociale, IBAN) ma fatica con nomi in chiaro, indirizzi e identificatori dipendenti dal contesto — che costituiscono la maggior parte dei dati personali nei documenti professionali.
- Non può fare nulla contro il copia-incolla da applicazioni fuori dal perimetro del proxy — dispositivi mobili, macchine personali, flussi «offline e poi incollato».
Il filtraggio lato cloud tratta l'IA come un canale da sorvegliare anziché come un comportamento da ristrutturare. L'azione di fondo — un utente che estrae contenuto sensibile da un sistema controllato e lo consegna a un servizio esterno — accade comunque. Il filtraggio aggiunge un dosso a metà strada. Non affronta la radice.
Il confronto in termini chiari
Dimensione DLP tradizionale Anonimizzazione lato clientIl confine giusto: prima dell'IA, sul dispositivo
L'intervento deve avvenire prima che i dati lascino il dispositivo dell'utente — non al perimetro della rete, non dentro l'infrastruttura del fornitore di IA a cose fatte.
Questo richiede un diverso modello mentale. Invece di chiedersi «come sorvegliamo ciò che gli utenti inviano agli strumenti di IA?», la domanda diventa: «come diamo agli utenti una versione dei loro documenti che sia, per progettazione, sicura da inviare a qualsiasi strumento di IA?»
L'intuizione chiave è che all'IA non servono le identità per fare il suo lavoro. Le serve struttura, lingua e contesto. «Alice Martin, nata il 14 marzo 1987, residente in 14 rue des Acacias, Lione, riferimento cliente A-2091» non dice nulla di più a un grande modello linguistico sulla clausola contrattuale che gli si chiede di analizzare. Rimuovete l'identità, tenete la clausola. Il risultato dell'IA è ugualmente utile — e i dati originali non hanno mai lasciato il dispositivo.
Come promptShield mette in pratica tutto questo
promptShield gira interamente offline sul dispositivo dell'utente — nessuna inferenza nel cloud, nessuna chiamata di rete durante l'anonimizzazione. Il flusso di rilevamento applica tre livelli a ciascun documento:
- Regex — pattern strutturati ad alta precisione: IBAN, codice di previdenza sociale, email, telefono, numero di passaporto e altri formati di identificativi documentali in 7 lingue europee. Si attivano per primi, con alta precisione, e non richiedono il caricamento di un modello.
- Riconoscimento delle entità nominate — modelli spaCy e transformer eseguiti in locale, che rilevano nomi, indirizzi, organizzazioni e date in contesto. La stessa entità che ricorre tra le pagine viene collegata, così anonimizzare a pagina 1 la sopprime automaticamente a pagina 4.
- Passaggio LLM opzionale — per i casi ambigui, un modello GGUF eseguito localmente dirime le rilevazioni limite senza inviare alcun dato da nessuna parte.
Ogni entità rilevata viene sostituita con un token tipizzato e stabile: [PERSON_1], [ADDRESS_2], [IBAN_1]. La corrispondenza tra token e valore originale è conservata in un database SQLite locale — il registro dei token — che non lascia mai il dispositivo.
L'utente incolla il documento anonimizzato in qualsiasi strumento di IA. L'IA produce la sua analisi a partire dai token. Quando l'utente vuole riportare il risultato dell'IA sul documento originale, promptShield ripristina i valori reali. Il flusso analitico è invariato. L'esposizione, invece, è eliminata per progettazione.
Cosa cambia, e cosa no
L'anonimizzazione lato client affronta una falla precisa: il percorso senza attrito da un documento controllato a un servizio di IA esterno. Non sostituisce i controlli di accesso, non sostituisce la registrazione degli audit, e non elimina la necessità di formare i dipendenti a un uso appropriato dell'IA.
Ciò che cambia, invece, è il modello di rischio per questo specifico caso d'uso. Una volta che anonimizzate prima di incollare, la domanda «cosa succede se un dipendente usa ChatGPT su un documento di un cliente?» ha una risposta diversa. L'IA riceve contenuto strutturato — logica delle clausole, indici finanziari, architettura del contratto — senza alcun identificatore associato. Non c'è nulla da esporre.
Il vecchio perimetro era l'archivio dei documenti. Il nuovo perimetro deve essere il documento stesso — precisamente l'istante in cui passa da un sistema delimitato a testo libero nelle mani di un utente.
Quel confine è quello che il DLP tradizionale non è mai stato progettato per tenere. È quello che conta adesso.
