DLP-Pipline für Dokumente — Betreiber-Anleitung
Wenn die DLP-Untersuchung für einen Workspace aktiviert ist, durchläuft jedes hochgeladene Dokument nach der Ingestion eine asynchrone pg-boss-Untersuchung:
Wenn die DLP-Untersuchung für einen Workspace aktiviert ist, durchläuft jedes hochgeladene Dokument nach der Ingestion eine asynchrone pg-boss-Untersuchung:
Optionale Enterprise-Funktion, pro Workspace aktivierbar (workspaces.dlpDocumentScanEnabled, Standard aus; die Aktivierung erfordert das Bestehen der eval gate). Quelle:docs/DLP_DOCUMENT_PIPELINE.md(Phase 192, DLP-01..06 — v0.28.1). Provenienz-Zeilen:FACT-CENSUS.mdF-DLP-1, F-DLP-2, F-AUDIT-1.
- Detect — eine 3-Ebenen-Pipeline: vom Admin konfigurierbare Regex-Muster (
dlpPatternService), Checksummen-Validierung für die italienischen Identifikatoren mit festem Format (Codice Fiscale inkl. Omocodia, P.IVA, IBAN —dlpChecksum) und kontextuelle NER via LLM für Namen/Adressen (der bestehende Ollama-Client). - Mask — die erkannten Entitäten werden zu durchnummerierten Platzhaltern auf Dokumentebene (
[PERSON_1],[GOV_ID_2], …). Die Maskierung ist idempotent (mask∘mask = mask) — die Platzhalter-Syntax kann sich nie selbst wieder anbinden. - Maskiertes Re-embed —
document_chunks.chunkTextwird mit dem maskierten Text neu geschrieben,searchVector/searchVectorMulti(FTS) neu berechnet, und die Vektoren via dem Collector-Endpoint/api/ingest/reembedneu eingebettet. Kein geschwärzter Vektor bleibt durchsuchbar. - Originalverschlüsselung — der Originaltext und jeder Entitätswert werden AES-256-GCM-verschlüsselt gespeichert (
encryptionService, der ENCRYPTION_KEY-Vertrag). Die Maskierung ist one-way: die verschlüsselten Originale sind die einzige saubere Kopie.
Admin-Kontrolle
Der Workspace-Toggle (DLP-01)
Settings → Workspaces → der Schalter DLP document scan (die Spalte workspaces.dlpDocumentScanEnabled, Standard aus).
- Der Schalter bleibt deaktiviert, bis die eval gate (unten) bestanden ist — das DEAKTIVIEREN ist nie blockiert.
- Der Zustand flippt optimistisch und fällt bei einem Speicherfehler zurück.
Die eval gate (DLP-05)
Die Qualitätsbewertung der Erkennung muss vor der Aktivierung bestehen:
- POST /api/system/dlp/eval/run (admin) — führt den wiederholbaren Läufer über das committed Fixture-Corpus italienischer PII (
packages/server/src/__tests__/fixtures/dlp-eval/). Persistiert das Ergebnis in SystemConfigDLP_EVAL_LAST_RUN(admin-nicht-editierbar). - GET /api/system/dlp/eval/result (admin) — liest den letzten Lauf; nie ausgeführt liefert
{ passed: false, noRun: true }— nie ein stiller Pass. - Die Gate-Metrik: null falsch Positive aus unterdrückten Checksummen auf den Klassen GOV_ID/FINANCIAL. Die PERSON/ADDRESS-Recall ist nur dokumentiert (nerMode markiert
stubvslive).
Das Legacy-Corpus-Backfill (DLP-06)
POST /api/system/dlp/backfill (admin, mit AlertDialog-Bestätigung in der UI):
- Eval-gated: weist mit
409 { error, gate: "eval-not-passed" }zurück, wenn der letzte Eval fehlt oder gefallen ist. - Idempotent + wiederaufnehmbar: der Marker
dlpScannedAt— ein Neu-Lauf nimmt nur Dokumente ohne den Marker in die Warteschlange. - Rate-limited: Warteschlangen-Konkurrenz 1 (unter der Live-Untersuchungswarteschlange).
- Die Konvergenz ist gepinnt vom Integration-Twin (echtes Postgres): maskierte Chunks persistiert, tsvector neu berechnet, der reembed-Payload byte-gleich dem maskierten Text, Audit-Abfragen = null verbleibende PII.
Die vier Muster-Klassen (europäische/italienische Identifikatoren)
| Klasse | Was sie erkennt |
|---|---|
| GOV_ID | Codice Fiscale (inkl. der Omocodia-Verifikation) |
| FINANCIAL | P.IVA, IBAN (mit Checksummen-Validierung) |
| PERSON | Personennamen (kontextuelle LLM-NER) |
| ADDRESS | Adressen (kontextuelle LLM-NER) |
Die Checksummen-Klassen (GOV_ID/FINANCIAL) sind deterministisch; die kontextuellen (PERSON/ADDRESS) laufen über die LLM-NER — ihre Recall ist im Eval-Ergebnis dokumentiert.
Chat re-composition (DLP-03)
Die maskierten Platzhalter erreichen die LLM; am Ende des Streams, genau einmal, stellt der Server die Platzhalter in der Terminalnachricht wieder her — für Benutzer, die dlp:unmask auf dem Workspace des zitierten Dokuments besitzen. Das additive Feld content im done-SSE-Payload trägt den wiederaufgesetzten Text; Widget-Besucher erhalten NIE wiederaufgesetzten Text (server-seitig erzwungen; für die UI ist es nur eine Steuerung verbergen).
Die Unmask-Vorschau (DLP-04)
GET /api/documents/:documentId/text liefert standardmäßig den maskierten Text. ?unmask=true setzt nur über die Gate-Leiter wieder zusammen: das gültige param → der Workspace-Toggle an → resolveWorkspaceRole + die dlp:unmask-Berechtigung. Jeder Verfehl-Arm liefert maskierten Text (200) — der Endpunkt ist nie ein Anspruchs-Orakel. Der UI-Toggle zeichnet sich nur für berechtigte Benutzer an Dokumenten mit Entitäten (DOM-Abwesenheit), ist pro-Ansicht und wird nie persistiert.
Die Audit-Matrix (SC-4)
Jeder Lesepfad ist von einem Verhaltenstest gepinnt (18 Zeilen: Textansicht, OCR-Preview, synthesis, citations, widget RAG, MCP tools, FTS, export, KB-Kopie, reembed admin). Widget/citations/MCP tragen harte negative Pins (maskiert, nie wiederaufgesetzt).
Diese Anleitung behandelt die Betriebsoberfläche der DLP-Pipeline für Dokumente; die technische Tiefe steckt im Zwillingsbeitrag:
Provenance
| Abschnitt | Quelle |
|---|---|
| Die 4-Stufen-Pipeline / detect / mask / reembed / encrypt | docs/DLP_DOCUMENT_PIPELINE.md (Overview — Phase 192 DLP-01..06) — F-DLP-1 |
| Admin-Kontrolle / Toggle / Eval / Backfill | docs/DLP_DOCUMENT_PIPELINE.md (§ Admin controls) |
| Chat re-composition / Unmask-Preview / Audit | docs/DLP_DOCUMENT_PIPELINE.md (§ DLP-03/04, SC-4) — F-AUDIT-1 für die Audit-Klasse |
| Der "10 PII"-Zähler | nicht zitiert: der Zähler ist in dieser Durchlauf nicht rückverfolgbar (F-DLP-2 = UNTRACED-IN-THIS-PASS) — die Seite benennt die tatsächlichen Klassen, nie eine nicht rückverfolgte Zahl |
---
Betreiber-Referenz — Simmetric Chat v0.28.1 (Dokumente aktualisiert am 2026-10-02, Census-SHA `aca5b8ff`).