The document DLP pipeline: masks that hold

Il documento entra una volta; il segnaposto resta

La knowledge base di un workspace AI ingerisce documenti veri - contratti, lettere HR, fatture. Alcuni contengono dati che nessuno dovrebbe leggere con noncuranza, e un LLM non dovrebbe mai citarli. La risposta di Simmetric Chat per i workspace abilitati: una pipeline di scansione documentale che trasforma le entità sensibili in segnaposto numerati estesi a tutto il documento e conserva l'unica copia pulita cifrata. Il punto del progetto è l'ultima frase - il segnaposto resta: il mascheramento è unilatero per costruzione, così "il documento" e "il corpus ricercabile" diventano oggetti diversi dal design.

Questo articolo percorre la pipeline come la incontra l'operatore: la scansione asincrona, i tre livelli di rilevamento, ciò che un segnaposto garantisce, cosa accade al ri-embedding, come vengono conservati gli originali, e le due gate di unmask (ri-composizione nel chat, unmask dell'anteprima) che rendono la copia pulita raggiungibile solo di proposito.

Funzione opzionale dell'edizione Enterprise, abilitabile per workspace e spenta di default (l'interruttore del workspace + la gate di valutazione). Fatti da FACT-CENSUS.md F-DLP-1.

La scansione: asincrona, in coda, dopo l'ingest

Quando la scansione documentale è attiva per un workspace, ogni documento caricato attraversa una scansione asincrona via pg-boss dopo che l'ingest è completo - la via del caricamento resta reattiva, e la scansione si comporta come ogni altro job di sfondo della piattaforma: in coda, con i tentativi ripetuti, osservabile. Un corpus legacy ha il proprio backfill (gated sulla valutazione e confermato esplicitamente nell'interfaccia), limitato sotto la coda live e ripristinabile: una colonna di marcatura (dlpScannedAt) cinge ogni ri-esecuzione ai documenti mai scannerizzati.

Rileva: tre livelli

Il rilevamento è una pipeline a 3 livelli, ognuno per ciò che è:

1. Pattern regex configurabili dagli amministratori - il servizio di pattern che l'admin cura (attiva/disattiva ogni pattern, anteprime di prova).
2. La validazione a checksum per gli identificatori italiani/europei a formato fisso - Codice Fiscale (comprese le validazioni di omocodia), P.IVA, IBAN: queste classi sono deterministiche; una stringa che fallisce il proprio checksum non è un identificatore, così i numeri ordinari non le inescano mai.
3. Il rilevamento contestuale via LLM per nomi e indirizzi - le classi contestuali passano dal modello; il loro recall è un valore misurato e documentato, non una promessa.

Due classi nominate sono deterministiche (i checksum) e due sono contestuali (le classi LLM) - e la gate di valutazione misura esattamente questa spaccatura: la barra di qualità per l'abilitazione = zero falsi positivi soppressi sulle classi deterministiche, con il recall delle classi contestuali documentato a ogni esecuzione.

Il numero che questo post non stamperà mai: un conteggio di "quanti tipi di PII esistano". Il contract del census è esplicito - i numeri non tracciabili non partono; le classi vengono nominate, il codice dice ciò che rileva.

Maschera: segnaposto numerati che non possono ri-abbinarsi

Le entità rilevate diventano segnaposto numerati estesi a tutto il documento ([PERSON_1], [GOV_ID_2], ...). Tre proprietà rendono ciò significativo:

• Coerenza su tutto il documento - la stessa entità è lo stesso segnaposto sull'intero documento; l'LLM continua a leggere un documento coerente.
• Idempotenza - il mascheramento è il proprio punto fisso: la sintassi del segnaposto non può mai ri-abbinarsi, quindi una ri-scansione non produce mai artefatti della classe [PERSON_1_1].
• La riscrittura è totale - i chunk vengono riscritti con il testo mascherato, i vettori FTS ricalcolati, e gli embedding ri-generati sul testo mascherato. Nessun vettore non censurato resta ricercabile.

Cifra: l'unica copia pulita è AES-256-GCM

Il testo originale e ogni valore di entità atterrano cifrati (AES-256-GCM sotto il contract di chiave della piattaforma). È ciò che rende onesta la pipeline: il mascheramento non è una "messa in ombra a livello di vista" - i byte non mascherati semplicemente non esistono senza cifratura nello store. Gli originali cifrati sono l'unica copia pulita.

Le due gate di unmask

La copia pulita è raggiungibile attraverso esattamente due gate, entrambe esplicite:

1. Ri-composizione nel chat - a fine flusso, esattamente una volta, il server ri-compone i segnaposto nel messaggio terminale solo per gli utenti con il permesso dlp:unmask nel workspace del documento citato. Il testo ri-composto viaggia nel payload done dell'SSE; i visitatori del widget non ricevano mai testo ri-composto (applicato lato server, non nascondendo un controllo).
2. Unmask dell'anteprima - l'endpoint del testo documentale serve il testo mascherato per default; un parametro di unmask vale solo attraverso la scala della gate (il parametro presente, l'interruttore del workspace attivo, il ruolo che risolve il permesso). Ogni braccio mancante restituisce comunque testo mascherato con un 200 - l'endpoint non è mai un oracolo dei diritti.

La matrice di audit

Ogni percorso di lettura piantato da un test comportamentale (la vista del testo, l'anteprima OCR, la sintesi, le citazioni, il widget, i tool MCP, la ricerca full-text, gli export, il ri-embedd dell'amministrazione). I tre pioli più duri sono i bracci del "mai": i visitatori del widget, le superfici di citazione, e i tool MCP ricevono testo mascherato e mai una ri-composizione. La classe del log di audit (il registro immutabile della piattaforma, F-AUDIT-1) registra le operazioni che toccano la superficie.

Per continuare

• Richiedi una demo

La guida porta il walkthrough operativo completo - l'interruttore, il corridore di valutazione, il backfill, ogni endpoint - su /it/docs/document-dlp-pipeline:

• Document DLP pipeline - la guida
• La versione in linguaggio semplice
• Fatti in questo post: righe FACT-CENSUS.md F-DLP-1 (la pipeline), F-DLP-2 (la decisione del conteggio non tracciato), F-AUDIT-1 (il registro degli eventi)

Provenance: Simmetric Chat docs/DLP_DOCUMENT_PIPELINE.md (v0.28.1, Phase 192 DLP-01..06), packages/server/src/services/ (dlpPatternService/dlpChecksum/quota services), encryptionService - allo stato documentale fissato dal census (SHA aca5b8ff).