Zurück zur Dokumentation
Guide 00

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:

3 Min. Lesezeit

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.md F-DLP-1, F-DLP-2, F-AUDIT-1.
  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).
  2. 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.
  3. Maskiertes Re-embed — document_chunks.chunkText wird mit dem maskierten Text neu geschrieben, searchVector/searchVectorMulti (FTS) neu berechnet, und die Vektoren via dem Collector-Endpoint /api/ingest/reembed neu eingebettet. Kein geschwärzter Vektor bleibt durchsuchbar.
  4. 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 SystemConfig DLP_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 stub vs live).

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)

KlasseWas sie erkennt
GOV_IDCodice Fiscale (inkl. der Omocodia-Verifikation)
FINANCIALP.IVA, IBAN (mit Checksummen-Validierung)
PERSONPersonennamen (kontextuelle LLM-NER)
ADDRESSAdressen (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

AbschnittQuelle
Die 4-Stufen-Pipeline / detect / mask / reembed / encryptdocs/DLP_DOCUMENT_PIPELINE.md (Overview — Phase 192 DLP-01..06) — F-DLP-1
Admin-Kontrolle / Toggle / Eval / Backfilldocs/DLP_DOCUMENT_PIPELINE.md (§ Admin controls)
Chat re-composition / Unmask-Preview / Auditdocs/DLP_DOCUMENT_PIPELINE.md (§ DLP-03/04, SC-4) — F-AUDIT-1 für die Audit-Klasse
Der "10 PII"-Zählernicht 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`).