Zum Hauptinhalt springen
Kern•6–10 Stunden

Privacy- und Lineage-Gate für Analytics

Baue eine privacy-aware KI-Analytics-Pipeline mit Datenminimierung, Berechtigungsprüfungen, Lineage, Egress-Kontrollen, Retention und Negativtests, bevor sensibler Kontext ein Modell erreicht.

DatenminimierungPII-KlassifizierungZugriffskontrolleLineageEgress-GovernancePrivacy-Tests

Szenario

Aufgabe

Ein Analyst soll Kundenverhalten untersuchen, doch das Source Dataset enthält Identifikatoren, Kontaktdaten, interne Notizen und Felder, die für die Aufgabe nicht nötig sind. Ein KI-Tool kann die Analyse beschleunigen, aber „wir haben das Modell nicht gebeten, PII anzuzeigen“ ist keine Kontrolle. Weise nach, dass sensible Felder nicht ohne Notwendigkeit in den Modell- oder Tool-Kontext gelangen, Berechtigungen zur Aufgabe passen und jedes veröffentlichte Insight eine Lineage zu einem erlaubten Source Slice besitzt.

Schrittweise Umsetzung

1. Daten nach Zweck statt Bequemlichkeit klassifizieren

Ergebnis: Nur für den konkreten Analytics-Job erforderliche Felder gelangen in die Pipeline.

Aufgaben

  • →Columns und abgeleitete Felder inventarisieren
  • →Direkte und indirekte Identifikatoren sowie sensitive Kategorien markieren
  • →Jedes Feld an einen expliziten Zweck binden
  • →Felder ohne Task Necessity entfernen oder aggregieren

Prüfungen

  • ✓„Könnte nützlich sein“ ist kein Zweck
  • ✓Abgeleitete Felder erben die Privacy-Klassifizierung ihrer Source Inputs
  • ✓Die minimierte View ist aus einer versionierten Transformation reproduzierbar

2. Identity- und Permission-Plane vom Model Reasoning trennen

Ergebnis: Das LLM entscheidet nicht, welche Daten ein Nutzer sehen darf.

Aufgaben

  • →User- oder Service-Identity vor Retrieval oder Query prüfen
  • →Row-, Column- und Tenant-Filter vor dem Modellkontext anwenden
  • →Externe Prozessoren und Tools als eigene Egress Boundaries behandeln
  • →Read-only als Default für Analytics Tools setzen

Prüfungen

  • ✓Unzulässige Daten erscheinen selbst bei direkter Anfrage nicht im Prompt
  • ✓Das Tool Schema erweitert keine Business Authority
  • ✓Ein Cross-Tenant-Negativtest endet in deterministic deny

3. End-to-End-Lineage aufbauen

Ergebnis: Jeder Claim und jedes Artifact lässt sich auf eine konkrete Version erlaubter Daten zurückführen.

Aufgaben

  • →Source Snapshot und Version protokollieren
  • →Transformationen und Query Hash speichern
  • →Output Claims mit Source Slices verknüpfen
  • →Modell/Tool-Konfiguration und Timestamp festhalten

Prüfungen

  • ✓Lineage endet nicht bei „AI generated“
  • ✓Stale Source- oder Permission-Version ist im Trace sichtbar
  • ✓Ein veröffentlichtes Artifact hat einen reproduzierbaren Evidence Path

4. Privacy Failures injizieren

Ergebnis: Schutz wird durch Negativtests statt durch Policy-Folien belegt.

Aufgaben

  • →Excluded PII über den Prompt anfordern
  • →Stale Group Membership simulieren
  • →Tool/Result Leakage und Logs prüfen
  • →Deletion- und Retention-Propagation testen

Prüfungen

  • ✓Kritisches Leakage blockiert den Rollout
  • ✓Logs speichern keine rohen sensitiven Payloads ohne explizite Policy
  • ✓Deletion oder Access Revocation propagiert durch Analytics Cache, Index und Context Path

Akzeptanzkriterien

  • Jedes Feld im KI-sichtbaren Dataset hat expliziten Zweck und Klassifizierung
  • Permission Filtering erfolgt vor Modell/Tool-Kontext und besitzt Negativtests
  • End-to-End-Lineage reicht vom Source Snapshot bis zum veröffentlichten Claim oder Artifact
  • Externer Egress, Logs, Retention und Deletion Propagation sind dokumentiert und geprüft
  • Cross-Tenant- oder Unauthorized-Field-Leakage ist unabhängig vom aggregierten Quality Score ein Hard Blocker