Scelte di progetto
Ogni scelta di Pseudomania nasce da un vincolo concreto: il servizio da proteggere, le regole sul lavoro, la necessità di non affidare a una sola persona le chiavi dei dati. Qui trovi le ragioni, una per una.
Architettura
Perché un'estensione del browser e non un proxy di rete?
Il servizio da proteggere è claude.ai con l'abbonamento Claude Team: si usa dall'interfaccia web e non offre un'API su cui interporre un filtro. Un proxy di rete vedrebbe solo traffico cifrato (TLS). Per leggerlo dovrebbe intercettare la connessione con un certificato dell'ente installato su ogni PC (TLS inspection): una tecnica invasiva, fragile ai cambi del sito e dei protocolli, e non prevista dai termini del fornitore, che vietano l'uso di proxy non autorizzati.
Il browser è l'unico punto in cui il testo esiste in chiaro prima di partire e in cui la risposta può essere ripristinata davanti all'utente. Un'estensione può intercettare l'invio, sostituire il testo e rilanciarlo, senza toccare la cifratura della connessione. Come rete di sicurezza, l'estensione esamina anche le richieste che la pagina invia a claude.ai: ciò che non è già stato pseudonimizzato viene trattato o bloccato.
Perché l'abbonamento Claude Team e non l'API?
Gli utenti dell'ente usano già Claude Team: costo prevedibile per postazione, interfaccia completa (Progetti, allegati, artifact), nessuno sviluppo di un'applicazione di chat da mantenere. Con l'API si pagherebbe a consumo e servirebbe un'interfaccia propria. Pseudomania si adatta allo strumento che le persone usano davvero, invece di chiedere loro di cambiarlo.
Il piano Team offre inoltre console di amministrazione, SSO, disattivazione centralizzata di funzioni (memoria, connettori, feedback) e l'esclusione dei dati dall'addestramento dei modelli secondo le condizioni commerciali del fornitore.
Perché Chrome e le policy gestite?
Chrome è il browser standard dell'ente pilota e supporta la gestione centralizzata: le policy di Chrome Enterprise (Google Admin, criteri di gruppo di Windows, Intune) permettono di installare l'estensione in modo forzato, impedirne la disattivazione e passarle la configurazione (indirizzo del server, identity provider, comportamento fail-closed). In questo modo la protezione non dipende dalla buona volontà del singolo.
Chrome e claude.ai sono anche gli strumenti che usa chi ha scritto Pseudomania. Tutto ciò che dipende dal sito è isolato nel modulo extension/src/sites/claude.js (registrato in registry.js): altri chatbot o altri browser Chromium si possono aggiungere scrivendo un adattatore, secondo la licenza AGPL e con contributi benvenuti; Firefox richiederebbe adattamenti (dettagli).
Perché la misura sia efficace, l'ente consente claude.ai solo dal Chrome gestito (proxy aziendale e accesso condizionato dell'SSO) e blocca l'app desktop e l'app mobile di Claude.
Perché Rizzo-PII e Privacy Guardrail come basi?
Rizzo-PII è un modello di riconoscimento dei dati personali addestrato sull'italiano, con etichette pensate per i documenti italiani (codice fiscale, partita IVA, dati catastali, targhe). Il codice e i pesi sono rilasciati con licenza MIT e gira su CPU, senza GPU e senza inviare dati all'esterno. Esiste anche come app desktop, che rende possibile la Personal edition senza server.
Privacy Guardrail del DFKI (Apache-2.0) è un'estensione già pensata per intercettare i chatbot nel browser: da lì vengono le tecniche di inserimento del testo nella casella di claude.ai, di intercettazione degli appunti e di osservazione delle risposte. Partire da progetti aperti e documentati riduce il codice nuovo da scrivere e verificare.
Cosa si pseudonimizza
Perché nella Personal edition la protezione si attiva per conversazione?
Un professionista non usa Claude solo con dati di clienti: per una ricerca generica la pseudonimizzazione è superflua. Un interruttore globale verrebbe spento e dimenticato; uno per conversazione limita l'effetto alla chat in cui serve. Per ridurre gli errori: lo stato è sempre visibile, una nuova conversazione eredita l'ultima scelta solo se era «attiva» (altrimenti chiede), finché il banner aspetta i messaggi sono protetti, e lo spegnimento riguarda solo l'uscita, mai il ripristino. Nella Enterprise edition non c'è scelta: la protezione è sempre attiva.
Che cosa viene pseudonimizzato e che cosa no?
Sì: messaggi, modifiche e rigenerazioni; istruzioni e documenti dei Progetti; allegati PDF, DOCX, XLSX, TXT, Markdown, CSV e i loro nomi; testo lungo incollato che claude.ai trasforma in allegato.
No: immagini e altri formati (bloccati); preferenze personali del profilo Claude (il regolamento vieta di inserirvi dati personali); dati che il modello non riconosce; quasi-identificatori; tutto ciò che passa da altri browser o app. La dettatura vocale è disattivata perché il suo testo non passerebbe dall'estensione.
Perché Claude riceve un'istruzione fissa sui segnaposto?
Il ripristino funziona solo se nella risposta i segnaposto compaiono esattamente come sono stati inviati. Un modello linguistico tende a «migliorare» il testo: potrebbe tradurre [FULLNAME_1], declinarlo, spiegarlo o inventare [FULLNAME_7]. Per questo l'estensione antepone al primo messaggio di ogni conversazione, e alle istruzioni di progetto, questa istruzione:
I testi contengono segnaposto tra parentesi quadre come [FULLNAME_n] o [CF_n] (n = numero). Riportali esattamente come sono, senza modificarli, tradurli, declinarli o spiegarli, e non crearne di nuovi.
I segnaposto che l'estensione non riconosce restano evidenziati in rosso e vengono contati, per misurare il fenomeno nel pilota.
Perché i dati sanitari e giudiziari sono bloccati e non pseudonimizzati?
Per le categorie particolari (art. 9 GDPR: salute, opinioni politiche, appartenenza sindacale, convinzioni religiose…) e per i dati giudiziari (art. 10) il contesto stesso è il dato sensibile: «[FULLNAME_1] è in cura per una malattia oncologica» rivela comunque un'informazione sanitaria su una persona che altri elementi del testo possono identificare. Il rischio residuo sarebbe troppo alto per l'uso previsto, quindi l'invio si ferma. Il regolamento d'uso vieta comunque questi contenuti, perché anche il blocco automatico può fallire.
Impostazioni di Claude
Perché la memoria di Claude è spenta?
I segnaposto sono numerati per conversazione o progetto: [FULLNAME_1] in una chat è Mario Rossi, in un'altra è Anna Bianchi. Se la memoria riportasse un segnaposto da una chat all'altra, l'estensione lo ripristinerebbe con il nome della chat corrente, cioè con la persona sbagliata. Un segnaposto globale per utente avrebbe evitato la collisione, ma avrebbe creato un profilo di lunga durata di tutte le persone citate.
L'ente ha scelto di spegnere la memoria dalla console Team: il rischio di ripristino errato tra conversazioni è così mitigato alla radice. Le preferenze personali del profilo non passano dall'estensione: il regolamento vieta di inserirvi dati personali.
Perché la ricerca web resta attiva, e con quali cautele?
La ricerca web è utile per norme, scadenze e notizie aggiornate, e gli utenti la userebbero comunque altrove. Claude compone le ricerche dal testo pseudonimizzato, quindi di norma contengono solo segnaposto; un dato sfuggito al rilevamento, però, potrebbe finire nella richiesta inviata al motore di ricerca, che è un sub-fornitore di Anthropic.
Cautele adottate: verifica del sub-fornitore di ricerca e del suo inquadramento; menzione nell'informativa; regola d'uso (niente dati personali nelle richieste che comportano una ricerca); misura, nel pilota, di quante ricerche contengono dati sfuggiti, per decidere se mantenerla.
Come sono gestiti i Progetti di Claude?
I Progetti restano disponibili (sul piano Team non si possono disattivare) e sono supportati: istruzioni e documenti della conoscenza sono pseudonimizzati e le chat del progetto condividono un unico dizionario, così lo stesso nome ha lo stesso segnaposto in tutto il progetto. La condivisione dei progetti è disattivata: il dizionario è cifrato con la chiave del singolo utente e un collega non potrebbe ripristinare i valori.
Il dizionario di un progetto dura quanto il progetto, più 30 giorni dall'ultimo uso, e scade se l'utente non lo conferma una volta l'anno dal pannello.
Cifratura e chiavi
Perché il dizionario è cifrato nel browser e non sul server?
Il dizionario è la tabella che collega ogni segnaposto al valore reale: è il dato più delicato del sistema. Se fosse cifrato con una chiave del server, chi amministra il server (o chi ne ottiene i privilegi) potrebbe decifrarlo in blocco. Per questo ogni valore è cifrato dall'estensione con una chiave AES-GCM a 256 bit dell'utente; il server conserva solo il testo cifrato e un'impronta (HMAC) che gli serve a dare lo stesso segnaposto allo stesso valore.
Risultato: un amministratore con pieni poteri sulla VM non può decifrare i dizionari passati. Restano i rischi descritti nei rischi residui.
Perché la chiave è automatica e non protetta da una password?
Una frase segreta scelta dall'utente avrebbe aumentato la protezione teorica, ma avrebbe scaricato sull'IT il lavoro di gestire password dimenticate, reset e dizionari persi. L'ente ha scelto il minimo lavoro per l'IT e nessuna azione per l'utente: al primo avvio l'estensione genera la chiave e la importa nel browser come chiave non estraibile (nemmeno l'estensione può più leggerla in chiaro). Prima di scartare la copia grezza, ne invia al server una copia di custodia cifrata con la chiave pubblica dei custodi, che il server non può aprire.
Che cosa succede se cambio PC o reinstallo il browser?
La chiave è legata al profilo del browser: su un nuovo PC l'estensione genera una chiave nuova. I segnaposto delle chat precedenti diventano «non ripristinabili» e sono mostrati come tali: le chat hanno vita breve e il recupero non è previsto. Per i progetti, su richiesta motivata, due custodi possono recuperare la vecchia chiave dalla copia di custodia e ricifrarla per il nuovo dispositivo, senza che la chiave compaia mai in chiaro fuori da una postazione offline. Ogni recupero è verbalizzato.
E se una chiave viene esposta?
La chiave non è estraibile dal browser con le normali API, ma un PC compromesso resta un PC compromesso. In caso di sospetto l'amministratore attiva la rotazione forzata per quell'utente: l'estensione genera una nuova chiave, ricifra le voci e la vecchia copia di custodia viene distrutta. L'operazione è registrata e non richiede i custodi. Se a essere compromessa è una quota della chiave dei custodi, si ridistribuiscono le quote o si genera una nuova coppia di custodia con rotazione di tutte le chiavi utente.
Come funziona la rotazione delle chiavi?
Ogni 90 giorni, senza alcuna azione dell'utente, l'estensione genera una nuova chiave e la relativa copia di custodia, scarica le proprie voci cifrate, le ricifra e le ricarica. Quando la vecchia chiave non ha più voci, il server ne distrugge la copia di custodia (salvo blocco dell'autorità giudiziaria). La rotazione limita il danno di un'eventuale esposizione e rende effettiva la cancellazione crittografica dei vecchi backup.
Controllo e accessi
Chi sono i custodi e quando intervengono?
I custodi sono almeno tre persone designate dal titolare, distinte dagli amministratori di sistema. La chiave privata di custodia viene generata offline con lo strumento del repository e divisa con lo schema di Shamir: servono 2 quote su 3 per ricomporla, e non è mai presente sul server. Lo stesso modello è già usato dall'ente per le immagini della videosorveglianza.
I custodi intervengono solo in due casi: richiesta scritta dell'autorità giudiziaria (aprono la copia di custodia dell'utente indicato e decifrano le sole voci richieste) e recupero dei progetti dopo un cambio di PC, su richiesta motivata. Ogni operazione richiede due custodi presenti e si chiude con un verbale. È esclusa ogni altra richiesta, comprese quelle del dirigente o dell'ufficio disciplinare.
Perché i contenuti si recuperano dall'esportazione di Claude Team e il server tiene solo un registro minimo?
Le conversazioni (pseudonimizzate) sono già conservate da Claude Team, e il Primary Owner dell'organizzazione può esportarle tutte. Duplicarle sul server dell'ente avrebbe creato un secondo archivio di testi, con più rischi e più obblighi. Si è scelto invece di governare l'esportazione: il ruolo di Primary Owner è affidato a un account di servizio con password custodita da un custode e secondo fattore da un altro; l'esportazione si fa solo su richiesta dell'autorità giudiziaria, si estrae solo la parte richiesta, il resto viene distrutto e tutto è verbalizzato.
Sul server resta un registro minimo, senza testi: per ogni messaggio inviato registra pseudonimo dell'utente, tipo di azione, conteggi delle entità e l'impronta SHA-256 del testo pseudonimizzato. L'impronta permette di verificare che un'esportazione sia autentica e che una cancellazione sia avvenuta, senza conservare il contenuto.
Conservazione
Durate dell'Enterprise edition, con le motivazioni. Dettagli e rinvii nella DPIA (§ 2.5) e nel regolamento d'uso (art. 11).
| Dato | Durata | Motivazione e fonti |
|---|---|---|
| Dizionario delle chat | 30 giorni dall'ultimo uso; nessun recupero dopo cambio PC | Minimizzazione e limitazione della conservazione (art. 5, par. 1, lett. c ed e, GDPR) |
| Dizionario dei progetti | Durata del progetto + 30 giorni dall'ultimo uso; scade senza conferma annuale; recupero via custodi su richiesta motivata | Come sopra; la conferma evita dizionari dimenticati |
Voci in attesa (pending:) | 24 ore | Tecnica |
| Registro minimo | 90 giorni in forma pseudonima, poi solo aggregati anonimi (giorno, ufficio, azione, conteggi) | Garante, documento di indirizzo del 6/6/2024 (doc. web 10026277): metadati conservati oltre 21 giorni solo con le garanzie dell'art. 4, c. 1, L. 300/1970. Garante, provv. Regione Lombardia del 29/4/2025 (doc. web 10134221): log limitati a 90 giorni e poi anonimizzati. I 90 giorni sono subordinati all'accordo sindacale o all'autorizzazione dell'Ispettorato |
| Tracce Langfuse | 30 giorni nel pilota, poi 7 | Minimizzazione; servono solo a misurare il rilevamento. Per analogia, EDPB, Linee guida 3/2019 sui dispositivi video (tempi brevi e cancellazione automatica) |
| Backup del database applicativo | ≤ 35 giorni (7 giornalieri + 4 settimanali), una copia offline | Continuità; EDPB, azione coordinata (CEF) 2025 sul diritto alla cancellazione: difficoltà di cancellare dai backup, quindi durata breve e riapplicazione delle cancellazioni |
| Key store e suoi backup | Backup separati, rotazione 14 giorni | Separazione tra chiavi e dati |
| Copie di custodia delle chiavi | Stessa vita della chiave (rotazione ogni 90 giorni), distrutte con la chiave | Cancellazione crittografica: NIST SP 800-88 Rev. 2 (cryptographic erase come tecnica di purge) |
| Registri di accesso di amministratori e custodi, registro delle cancellazioni | 24 mesi, sola aggiunta, catena di hash | Garante, provv. 27/11/2008 sugli amministratori di sistema (log inalterabili, almeno 6 mesi); ACN, linee guida sulle banche dati (almeno 24 mesi) |
| Verbali dei custodi e richieste dell'autorità | Protocollati, secondo il massimario dell'ente | Regole sulla gestione documentale |
| Blocco per l'autorità giudiziaria | Sospende la cancellazione dei soli dati indicati, fino a revoca, registrato | Obblighi di legge |
Riferimento di principio: Garante, Linee guida per posta elettronica e Internet del 1/3/2007 (doc. web 1387522), sull'aspettativa di riservatezza dei lavoratori. Alcune fonti sono indicate nella DPIA come da verificare sul testo ufficiale.
Come si cancellano i dati anche dai backup?
Cancellare un dato da ogni backup è difficile: l'EDPB lo ha segnalato nell'azione coordinata 2025 sul diritto alla cancellazione. Pseudomania usa la cancellazione crittografica (crypto-shredding): i valori del dizionario sono cifrati con chiavi che il server non possiede in chiaro; quando una chiave non ha più voci vive, si distrugge la sua copia di custodia. Le voci rimaste nei backup del database diventano indecifrabili, perché la chiave non esiste più nel browser e la sua copia di custodia è stata distrutta (il key store ha backup propri, separati e brevi, a 14 giorni).
Ogni cancellazione è scritta in un registro in sola aggiunta, esportato fuori dal database e riapplicato dopo ogni ripristino da backup, prima di rimettere in servizio il sistema.
Che cosa c'entra l'art. 4 dello Statuto dei lavoratori?
Il registro minimo e le tracce non servono a controllare i dipendenti, ma consentono in astratto di ricostruirne l'attività. L'art. 4, comma 1, della L. 300/1970 richiede per questi strumenti un accordo con le rappresentanze sindacali o, in mancanza, l'autorizzazione dell'Ispettorato nazionale del lavoro; il comma 3 richiede un'informativa adeguata. Le misure di progetto (pseudonimo invece dell'identità, nessun testo nel registro, 90 giorni e poi aggregati anonimi, accesso solo tramite custodi su richiesta dell'autorità giudiziaria) servono a rendere l'accordo possibile e il controllo indiretto il più limitato possibile. L'esportazione di Claude Team va inclusa nell'accordo.
Edizioni e licenza
Perché due edizioni, e perché la Personal non ha server né Langfuse?
Un ente ha bisogno di garanzie che un singolo professionista non ha (installazione forzata, SSO, custodi, registro per gli obblighi verso i lavoratori e l'autorità). Un professionista ha bisogno del contrario: niente da amministrare. La Personal edition è quindi solo l'estensione più l'app desktop di Rizzo-PII: rilevamento, dizionario e registro restano sul PC, cifrati con una chiave locale, senza Docker, server o Langfuse. Non servono custodi né registri centrali perché non ci sono altri utenti da tutelare né un'organizzazione che possa accedere ai dati.
Perché la licenza AGPL?
Il Codice dell'amministrazione digitale chiede alle PA di rendere riusabile il software che commissionano. La AGPL-3.0-or-later garantisce che chiunque lo usi, anche offrendolo come servizio in rete, debba rendere disponibili le proprie modifiche: i miglioramenti fatti da un ente tornano a tutti gli altri. È compatibile con le licenze dei componenti (Apache-2.0, MIT) e con l'AGPL di PyMuPDF usato per i PDF. Vedi Licenza e crediti.
Limiti e rischi residui
Quali rischi restano, dichiarati senza giri di parole?
- Il server vede il testo in chiaro durante la singola richiesta, per riconoscere i dati. Chi ha i privilegi di root sulla VM può modificare il servizio e intercettare le richieste future; non può decifrare i dizionari passati. Può però verificare se un valore che già conosce è presente (tramite l'impronta HMAC). Contromisure: amministratori designati, registri inalterabili, verifica annuale.
- Quasi-identificatori: il contesto può identificare una persona anche senza nome.
- Falsi negativi del riconoscimento: un dato non riconosciuto arriva a Claude e, con la ricerca web attiva, può arrivare al motore di ricerca.
- Cambi dell'interfaccia di claude.ai: selettori e richieste interne del sito possono cambiare senza preavviso; l'estensione se ne accorge e, nella Enterprise edition, blocca l'invio, con un disservizio fino all'aggiornamento.
- Elusione: altri browser, dispositivi personali, app non gestite. Si contrasta con SSO, accesso condizionato, proxy e regolamento, non con l'estensione.
- Voci non caricate in tempo: se l'estensione non riesce a salvare una nuova voce entro 10 minuti, quel valore non sarà ripristinabile (verrà riproposto alla prossima occorrenza).
- Termini del fornitore: in attesa di conferma scritta da Anthropic sull'uso dell'estensione.