Machine Unlearning und AI-Remediation

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 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.

Prävention ist gescheitert: sensible oder Müll-Daten sitzen schon im Gedächtnis des Policy-Bots (RAG-Chunks und optional Fine-Tune). Eine Warehouse-Zeile zu löschen reicht nicht. Dieser Teil ist das Incident-Playbook — jede Kopie scopen, Exposition containen, Remediation wählen die zum Speicherort passt, und nachweisen was getan wurde. Es verspricht nicht, dass ein Sprachmodell mit mathematischer Sicherheit „vergisst“.

Diese Serie endet hier. Nachbarn behalten ihre Tiefe: Löschung die hält, Lösch-Evidence…, AI Governance, DSDR Governance, Pfad Deletion Ops.

Problem

Teams behandeln AI-Incidents wie BI-Deletes:

• Quelltabelle purgen und Ticket schließen;
• Vector-Chunks, Prompt-Caches und Eval-Sets unberührt lassen;
• Fine-Tune-Checkpoints und Dienstleister-Kopien bleiben online;
• „wir unlearnen“ wird behauptet ohne Methode, Umfang oder Verify;
• Recurrence nach Restore oder Re-Crawl ist niemandes Kontrolle.

Zwei Gedächtnisarten kollidieren:

Signatur falscher Schließung:

Beispiel (Lehrfall, keine Kundendaten): Typisches Muster aus Governance-Projekten — im eigenen Umfeld durch Catalog-/BI-/Ticket-/Prozessquellen ersetzen.

Quelle:     Subject-Zeile in CRM + Warehouse gelöscht
Index:      120 Chunks weiter retrievebar
Cache:      Prompt-Store-Hits 14 Tage
Checkpoint: ft-customer-notes-v3 weiter served
Vendor:     Upload laut Vertrag „90 Tage“ behalten
Ticket:     closed — „AI informiert“

Ticket zu schließen, während Chunks, Cache und Fine-Tune-Checkpoint weiter antworten, ist keine Remediation — „Unlearning“ ohne Scope und Verify bleibt eine Behauptung.

Entscheidung

Führen Sie jeden AI-Daten-Incident als Scope → Contain → Remediate → Evidence → Recurrence, mit expliziter Entscheidung je Gedächtnisklasse.

1. Scope-Matrix (pflichtiges erstes Artefakt)

Bauen Sie eine AI Contamination Scope Matrix, bevor Sie ungezielt aus Indizes und Caches löschen:

Regeln: leere „unknown“-Zeilen sind offene Risiken, nicht optional. Shadow- und Nonprod-Kopien zählen — Nonprod, Exports…. Verknüpfen Sie Subject- oder Müll-Asset-IDs wo möglich mit Chunk-/Document-IDs.

2. Contain

Bis Remediation fertig ist:

• Serving auf last-known-clean Model-/Index-Version disable oder pinnen;
• Crawls und Fine-Tune-Jobs pausieren, die die schlechte Quelle neu ingestieren;
• Dienstleister-Zugriff widerrufen oder weitere Uploads einfrieren;
• Prompt-Cache-Reads einschränken, die Content resurfacen können;
• Privacy / Auskunfts- und Löschrechte-verantwortliche Person benachrichtigen, wenn personenbezogene Daten betroffen sind.

Containment ist nicht Remediation. Es stoppt den Blast-Radius.

3. Remediate nach Klasse (Entscheidungstabelle)

Wählen Sie einen Primärpfad je kontaminierter Klasse. Mischen nur mit dokumentierter Begründung.

Machine Unlearning heißt hier: Techniken, die den Einfluss bestimmter Trainingspunkte auf parametrische Modelle (manchmal auch Influence-Scores) entfernen oder reduzieren sollen. Enterprise-Einsatz bleibt approximativ. Jeden Unlearning-Lauf koppeln mit:

• dokumentierter Methode und Parametern;
• Membership-/Influence-ähnlichen Checks wo machbar;
• Fallback-Plan (Retrain), wenn Verify scheitert;
• ehrlicher Sprache in Nachweis: versuchter parametrischer Remediation, nicht zertifizierte Weight-Erasure.

Für DSDR zählen Prozess, Scope-Abdeckung und Restrisiko — Spiegel zu Lösch-Evidence und Recurrence-Controls. Erfinden Sie keine Garantie, die die Wissenschaft nicht hergibt.

4. Evidence Pack (AI-Erweiterung)

Erweitern Sie die Deletion-Evidence-Idee um AI-Felder:

• Contamination Umfang Matrix (versioniert);
• Containment-Aktionen und Zeitstempel;
• Remediation-Wahl je Klasse (Tabelle oben);
• Index-Rebuild-Job-IDs, Document/Chunk-Delete-Counts, Hash des clean Snapshots;
• Model/Adapter-Registry: alte Version retired, neue live;
• Dienstleister-Delete-Request-ID und Confirmation;
• Verify: Retrieval-Tests auf Subject-/Müll-Marker; Sample-Prompts die zuvor trafen; parametrische Checks falls behauptet;
• Restrisiko-Statement (was nicht bewiesen werden konnte);
• Recurrence-Kontrollregeln: Re-Crawl-Block, Prüfpunkt-Re-Enable, Restore→Re-Delete für KI-Stores.

Referenzen und Aggregate speichern — keinen zweiten PII-Lake im Ticket-System.

5. Recurrence

Events verdrahten, die Kontamination wieder einführen:

• Source-Restore / Nicht-Produktion-Refresh → KI-Umfang re-verifizieren;
• Dokumentbestand-Rebuild ohne Part-3-Gates → Incident reopen;
• versehentliches Re-Enable retired Checkpoint → Change-Kontrollregel-Fail;
• Dienstleister-Re-Upload alter Datei → Path-Kontrollregel-Fail (Teil 4).

KPIs (Starter): Scope-Completeness, Time-to-Contain, Residual-Retrieval-Hit-Rate nach Purge, Retired-Checkpoint-Re-Serve-Rate, Vendor-Confirm-Latenz.

Checkliste

Führen Sie das Playbook an einem Pilot-Incident (Tabletop oder real):

• Umfang-Matrix öffnen; jede Klasse in/out mit verantwortliche Person markieren;
• Serving und Ingest innerhalb vereinbarter SLA containen;
• Remediation je Klasse über Entscheidungstabelle wählen;
• Index-Rebuild und/oder Model-Pfad ausführen; IDs festhalten;
• KI Nachweispaket vervollständigen; Restrisiko explizit;
• Recurrence-Checks nach Restore/Refresh planen;
• Lessons in Teile 2–4 Gates und Hygiene-Register speisen;
• stoppen, wenn „done“ Pack + Verify heißt, nicht eine Chat-Nachricht.

Artefakt

AI Remediation Case File:

1. AI Contamination Scope Matrix;
2. Containment-Log;
3. Remediation Decision Record (je Klasse);
4. Evidence Pack (AI-erweitert);
5. Restrisiko und Recurrence-Plan;
6. Links zu DSDR-Case / Hygiene-Disposition / Prep-Pack-Versionen.

Betriebsnotizen

• Index-Delete ≠ Modell-Vergessen. In jedem Status-Update sagen.
• Unlearning ohne Verify bleibt Behauptung. Bei hohem Risiko oder Regulierung Retrain bevorzugen.
• Müll-Incidents brauchen dieselbe Umfang-Disziplin; Remediation ist oft Rebuild + Prüfpunkt-Fix, nicht parametrisches Unlearning.
• Verantwortung: KI-Product-verantwortliche Person + Steward + Privacy (bei personenbezogene Daten) + Platform für Index/Registry — Entscheidungsrechte, kein Crowd-Chat.
• Tiefe zu Plattform-Löschung und Backups bleibt in der Deletion-Serie; dieses Playbook ergänzt nur KI-Gedächtnisklassen.

Tools

Model Registry und Vector-Admin für Version-Pin und Purge. PII/DSDR-Tooling für Subject-IDs. Observability für Prompt-Traces. Katalog für Corpus und Sensitivität. Architecture Fit bei Multi-Vendor-Pfaden. Lernen: Deletion Ops, PII in 5 Schritten, AI Foundations.

Ressourcen

Teile 1–4 von Datenmüll vor AI. AI Governance, AI Failures, Lösch-Evidence…, Backups, Snapshots…, GDPR für Analytics- und AI-Teams. Glossary: Machine Unlearning.

Tools und Quellen