PII vor AI-Ingestion stoppen
Verhindern, dass personenbezogene Daten und Secrets in Indexe, Feature Stores, Notebooks und Vendor-Fine-Tune-Uploads gelangen — scannen, maskieren, Nebenkopien steuern.
Begriffe vor dem Lesen
- Datenmüll — Daten, Dokumente oder Assets ohne belastbaren Zweck, verantwortliche Person, Aktualität, Herkunft oder Qualitätsnachweis.
- KI-Suche — Retrieval-Augmented Generation: ein Modell ruft Inhalte
- Datenschutz-Folgenabschätzung / DSFA — Datenschutz-Folgenabschätzung: Prüfung für Verarbeitungen, die ein hohes Risiko für betroffene Personen haben können.
zur Laufzeit ab, statt nur aus Training zu antworten.
- Training — Nutzung von Daten, um Modellverhalten oder Features zu lernen.
- Imputation / Schätzung — Ersetzen fehlender Werte durch abgeleitete Annahmen. Das muss sichtbar bleiben.
- KI-Fitness — Eignung eines Assets für Retrieval, Training oder Agentennutzung mit Zweck, Qualität, Rechten und Nachweis.
Qualität, Quellkorrektur und AI-Nutzung
Datenqualität muss sichtbar machen, wo ein Problem behoben wurde. Wenn der Fehler im Quellsystem entsteht, ist die beste Behebung eine Korrektur an der Quelle oder mindestens ein dokumentierter Quellbefund mit Owner. Wenn ETL oder ELT Werte nachgelagert bereinigt, schätzt, mappt oder filtert, braucht diese Änderung Evidence: Regel, Grund, betroffene Felder, Version und erlaubte Nutzung.
Das ist besonders wichtig für AI. Retrieval, Training, Features und Agenten sehen oft nur das nachgelagerte Ergebnis. Ohne Kennzeichnung wissen sie nicht, ob ein Wert beobachtet, korrigiert, geschätzt, defaulted oder ausgeschlossen wurde. Governance muss Unsicherheit und Herkunft erhalten, statt sie hinter einem sauber wirkenden Datensatz zu verstecken.
Personenbezogene Daten aus dem HR-Mailbox-Export verschwinden nicht in Embeddings, Prompt-Caches oder Vendor-Uploads des Policy-Bots. Prävention vor Ingest ist billiger als Remediation in Teil 5 — und für die meisten DSDR-Uhren die einzige ehrliche Story.
Privacy-Pillars bleiben normativ: PII & Privacy Governance, DSDR Governance. Dieser Teil ist die präventive Betriebskontrolle auf dem Prep-Pfad.
Vorher: DQ-Gates für AI-Fitness. Weiter: Machine Unlearning und AI-Remediation.
Entscheidung
Bevor ein Pfad Retrieval oder Training speist:
- Klassifizieren vor dem Move — keine Quelle ohne Sensitivitäts-Tag und rechtmäßigen AI-Zweck;
- Scan + Mask/Strip im Scrub (Teil 2) mit Hit-Rates; PII-Rate-Gate aus Teil 3 bei Bruch failen;
- Getrennte Stores — Prod-Indexe und Training-Snapshots teilen keine unmanaged Raw-Landings;
- Vendor- und Notebook-Pfade im Scope — Uploads und lokale Exports brauchen dieselbe Purpose Card und Scan-Evidence;
- Nebenkopien listen — Caches, Eval-Sets, Logs, Embedding-Metadata; Refresh und Restore triggern Re-Scan;
- Owner für Zweck, Steward für die Control Card, Privacy für Sign-off, Custodian für den Block.
Retrieval mit minimierten Feldern ≠ Training auf voller Conversation History. Training auf Personenbezug ist DPIA, kein Crawl-Default.
Präventions-Workflow
1. Pfade mappen
Steward listet Crawl, Export, Feature-Job, Vendor und Notebook. Owner setzt Sensitivität plus AI-Zweck vor Enablement. Ein ungemappter POC-Upload ist der DSDR-Blindspot.
2. Scrub mit Evidence
Custodian fährt PII/Secret-Scan im Scrub und speichert nur aggregierte Hit-Rates. Steward failt das Teil-3-Gate bei Bruch. Einmal Regex ohne Log hält Namen weiter in Chunk-Text und Metadata.
3. Vendor und Notebook blocken
Privacy und Owner geben Uploads nur mit Purpose Card und Scan-Evidence frei. Custodian blockt unmanaged Vendor-Pfade. „Für einen POC“ außerhalb des Scopes ist eine zweite Kopie ohne DSDR.
4. Nebenkopien inventarisieren
Steward listet Caches, Eval-Sets und Log-Retention wie Deletion-Side-Copies — Nonprod, Exports…. Custodian hängt Source-Refresh an Corpus-Re-Scan. Wer Caches auslässt, erzählt DSDR eine halbe Wahrheit.
5. Dirty Ingest belegen
Custodian stoppt, wenn ein dirty Ingest mit klarem Fail-Reason fällt. Owner hängt die Control Card an das DSDR-Runbook (was zu purgen ist, wenn Prävention scheitert → Teil 5). Ohne Fail-Beweis bleibt das Gate Folie.
Handoffs
| Von | An | Artefakt |
|---|---|---|
| Path-Owner | Steward | Ingest-Pfade + AI PII Control Card |
| Steward | Custodian | Scan-Tool, Schwelle, Masking-Policy |
| Privacy | Owner | Vendor/Notebook-Sign-off oder Block |
| Steward | Deletion Ops | Side-Copy-Klassen + Retention |
| Custodian | DSDR-Lead | Fail-Reason + Purge-Hooks (Teil 5) |
Anti-Patterns
- personenbezogene Daten „kurz“ in Prompt oder Dokumentbestand lassen
- Dienstleister-Fine-Tune mit Raw-CSV außerhalb Auskunfts- und Löschrechte-Umfang
- Feature Store und Notebook am Warehouse-Masking vorbeiführen
- Eval-Sets mit subjektbezogenen Texten behalten
- Nicht-Produktion-Refresh ohne Re-Scan nach Scrub
Umsetzung im Alltag
Dieser Einstieg ist kein Kalenderzwang und keine Leseliste. Nimm einen echten Fall, an dem sich die Entscheidung prüfen lässt.
Arbeitsweise: Nutze den verlinkten Plan als Arbeitsfläche für Owner, Termine und offene Punkte. Die fachliche Entscheidung muss trotzdem in der Story verständlich bleiben.
Starte mit dem kleinsten Fall, der fachlich wichtig genug ist. Prüfe danach, ob die Entscheidung wirklich auffindbar, umsetzbar und auditierbar ist. Rollenklärung: Wer hilft wem an der Quelle.
- Jeden Ingest-Pfad (Crawl, Export, Vendor, Notebook) mappen.
- Sensitivität und AI-Zweck vor Path-Enablement verlangen.
- PII-Scan im Scrub fahren; nur aggregierte Evidence speichern.
- Einen unmanaged Path blocken und den Fail-Reason loggen.
Tools und Quellen
Data Junk Before AI
Part 4 of 6
View series