Osserva come un avvocato, un commercialista o un medico si serve davvero di un'IA su un fascicolo concreto, e noterai qualcosa che gli strumenti di anonimizzazione sembrano aver tutti mancato: nessuno lavora in un solo passaggio. Si pone una domanda, si legge la risposta, si rilancia con un approfondimento più mirato, si incolla un secondo documento, si torna al primo. Il lavoro è la conversazione. E quasi ogni modo di nascondere i dati personali si rompe in silenzio nel momento in cui quella conversazione prende il via.
Questa osservazione è l'intera ragione per cui promptShield ha la forma che ha. Nominiamo dunque l'idea con chiarezza, perché per quanto ne sappiamo nessun altro l'ha posta al centro: l'anonimizzazione stabile in conversazione — una stessa entità mantiene uno stesso codice, dall'inizio alla fine della conversazione e attraverso ogni file collegato, così che l'IA ragioni sul documento protetto esattamente come farebbe su quello reale, e tu possa ripristinare fedelmente i valori reali alla fine.
Il lavoro è a più turni — quindi anche la protezione deve esserlo
Immagina la versione realistica del compito. Hai un contratto e i suoi tre addendi. Incolli il contratto, anonimizzato, e chiedi al modello di riassumere gli obblighi. Lo fa. Poi incolli un addendum e chiedi: «questo modifica le condizioni di pagamento dell'acquirente rispetto all'originale?» Quindi: «redigi una clausola che risolva il conflitto tra l'articolo 4 qui e l'articolo 7 là.»
Perché ciò produca qualcosa di utile, il modello deve sapere che l'«acquirente» del contratto e l'«acquirente» dell'addendum sono la stessa persona giuridica, che l'indirizzo della clausola 4 è lo stesso indirizzo citato tre turni prima, che «il convenuto» e «la signora Laurent» sono una sola parte, non due. La coreferenza — il filo dell'identità che attraversa l'intero scambio — non è un optional gradito. È la sostanza stessa del ragionamento professionale. Spezzala, e la risposta dell'IA è sbagliata con sicumera, in un modo che è persino difficile da notare.
Un'anonimizzazione che vede un documento come «una cosa da ripulire una volta sola» non coglie mai questo. Pulisce il file e lo restituisce. Ma il professionista non ha un file; ha un caso, una pratica, un cliente — un insieme di materiale collegato su cui ragiona nel suo complesso, in dialogo, nel tempo. L'unità di lavoro non è il documento. È la conversazione.
Perché gli approcci ovvi crollano
Una volta che inquadri il compito come «mantenere l'identità coerente su un'intera conversazione», le tecniche comuni si rivelano lo strumento sbagliato:
| Approccio | Che cosa fa | Perché la conversazione lo smonta |
|---|---|---|
| Le barre di oscuramento | Copre il testo sulla pagina | Il modello non può ragionare su ciò che non vede: nessun «acquirente» successivo rimanda più a qualcosa |
| Cancellare i nomi | Rimuove l'entità senza sostituirla | Persone distinte confluiscono nello stesso vuoto, e il modello inventa in silenzio qualcuno che lo riempia |
| Un'etichetta nuova a ogni passaggio | Genera uno pseudonimo diverso a ogni esecuzione | Il secondo turno rinomina tutti: una persona ne diventa due, e nulla segnala la contraddizione |
| Cerca-e-sostituisci | Fa corrispondere una grafia a una stringa | Manca le forme flesse, le iniziali e gli alias — e non sa nulla del secondo documento che incollate |
| Tokenizzazione documento per documento | Codici stabili, ma solo dentro un singolo file | Un contratto e la sua appendice danno alla stessa parte codici diversi: il ragionamento incrociato fallisce in silenzio |
Lo schema è lo stesso in ogni riga: ogni approccio va bene per «disinfettare questo singolo blocco di testo», e ciascuno fallisce nel momento in cui il lavoro diventa una conversazione. Sono stati costruiti per un'unità di lavoro diversa da quella che i professionisti hanno realmente.
Che cosa richiede l'anonimizzazione stabile in conversazione
Nominare la lacuna è facile; colmarla comporta requisiti concreti, e sono proprio quelli che fanno di questo un prodotto e non una macro di cerca-e-sostituisci.
Un'identità stabile. La stessa entità deve corrispondere allo stesso codice ogni volta che compare — non solo all'interno di un documento, ma su tutta la conversazione e in ogni file collegato. In promptShield, «John Smith» riceve lo stesso codice (diciamo [P0ABCD]) sia che compaia nel contratto, nella fattura o nell'allegato dell'email, perché i file collegati condividono un unico registro di codici. Deponili nella stessa cartella e il collegamento è automatico — senza configurazione.
Codici tipizzati e leggibili. Un codice è [P0ABCD], [A1WXYZ], [B2KLMN] — la prima lettera indica il tipo (P per persona, A per indirizzo, B per IBAN), così che il modello sappia ancora che sta ragionando su una persona, un indirizzo, un conto, e possa produrre una risposta davvero utile invece di soffocare in un rumore opaco. Un'istruzione accompagna il download e chiede all'IA di restituire i codici esattamente come sono. La struttura che aiuta l'IA è preservata; solo l'identità è nascosta.
Un ciclo di andata e ritorno fedele. Nascondere l'identità è solo metà del lavoro. La corrispondenza dal codice al valore originale è custodita localmente, così che, quando la risposta dell'IA torna piena di [P0ABCD] e [B2KLMN], la decodifichi in un solo passaggio e ottieni un risultato che si legge come se non avessi mai anonimizzato nulla. Sono i codici stabili a rendere questa decodifica priva di ambiguità: un codice, un originale, ogni volta.
Metti tutto questo insieme e ottieni la proprietà che conta: l'IA lavora sul documento protetto esattamente come farebbe su quello reale. Stesso ragionamento, stessi rimandi incrociati, stessa coerenza su più turni — senza che alcuna identità reale sia mai presente nella conversazione, e con un ripristino pulito alla fine.
Il ciclo, dall'inizio alla fine
In pratica è un unico ciclo continuo, e segue il ritmo del lavoro reale invece di interromperlo:
- Codifica. Ogni entità è sostituita da un codice stabile e tipizzato; i file collegati condividono il registro; un umano rivede i rilevamenti prima che qualcosa venga fissato. (Sui documenti ad alto rischio, quella revisione umana è tutto il senso — vedi perché un umano resta nel circuito.)
- Conversa. Incolla la versione protetta in ChatGPT, Claude o qualsiasi modello. Poni domande di approfondimento. Incolla altri documenti della stessa pratica. Torna indietro. Le identità restano coerenti per tutta la durata della conversazione, perché i codici non derivano.
- Decodifica. Riporta l'output dell'IA e ripristina ogni codice al suo valore reale in un solo passaggio — un documento finale che si legge come se i veri nomi ci fossero stati fin dall'inizio.
E poiché l'intero ciclo si esegue sulla tua macchina, nessuna parte della pratica — né gli originali, né la tabella dei codici, né un solo turno del testo protetto della conversazione — lascia mai il tuo perimetro.
La categoria che rivendichiamo
Moltissimi strumenti sanno nascondere un nome. Alcuni sanno persino nasconderlo in modo coerente, se li configuri per farlo. Ciò che manca sul mercato non è la capacità presa isolatamente — è un prodotto costruito attorno al modo in cui i professionisti lavorano davvero con l'IA: in modo iterativo, di turno in turno, attraverso file collegati, con un umano che garantisce il risultato e un ciclo di andata e ritorno pulito alla fine. È il flusso di lavoro per cui promptShield è progettato da cima a fondo, ed è l'idea a cui vorremmo dare un nome.
Chiamala anonimizzazione stabile in conversazione. Un'entità, un codice, dall'inizio alla fine — così che tu possa finalmente usare l'IA sui documenti che contano nel modo in cui già li pensi: non come file da ripulire, ma come un caso da trattare.
Domande frequenti
Perché lo stesso nome deve avere sempre lo stesso codice?
Perché i professionisti non anonimizzano in un colpo solo. Fanno una domanda di seguito, incollano un secondo documento e ragionano su entrambi. Se la stessa persona riceve un codice diverso a ogni turno, l'IA legge di due persone diverse.
Che cosa si rompe se i codici cambiano tra documenti?
Il ragionamento incrociato. Un contratto e la sua appendice smettono di indicare la stessa parte, e ogni conclusione tratta dai due è sbagliata. Per questo l'oscuramento reversibile mantiene un codice stabile per entità invece di un'etichetta nuova a ogni esecuzione.
La mappa è conservata online da qualche parte?
No. Il registro codice-valore resta sulla macchina che lo ha creato, la stessa scelta di progetto che sta dietro al motore che abbiamo scritto proprio per questo.