Machine Unlearning und AI-Remediation

Begriffe vor dem Lesen

• Datenmüll — Daten, Dokumente oder Assets ohne belastbaren Zweck, zuständige Fachrolle, 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 Verantwortung. Wenn ETL oder ELT Werte nachgelagert bereinigt, schätzt, mappt oder filtert, braucht diese Änderung Nachweis: 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, falsche oder veraltete Daten haben bereits KI-Suche, Caches, Trainingsdaten, Dienstleisterkopien oder Modellartefakte erreicht. Eine Warehouse-Zeile zu löschen reicht dann nicht mehr. Dieser Teil ist das Incident-Playbook: Umfang klären, weitere Nutzung stoppen, passende Bereinigung je Speicherort wählen und nachweisen, was getan wurde. Er verspricht ausdrücklich nicht, dass ein Sprachmodell mit mathematischer Sicherheit „vergisst“.

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

Ausgangspunkt

Teams behandeln AI-Incidents oft wie einfache BI-Löschungen:

• Quelltabelle löschen und Ticket schließen;
• Chunks, Prompt-Caches und Evaluationssets unberührt lassen;
• Fine-Tune-Checkpoints und Dienstleisterkopien bleiben online;
• „wir unlearnen“ behaupten, ohne Methode, Umfang oder Prüfung zu benennen;
• Wiederauftreten nach Restore oder Re-Crawl nicht kontrollieren.

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ühre jeden AI-Datenvorfall als Umfang klären → Eindämmen → Bereinigen → Nachweisen → Wiederauftreten verhindern. Für jede Speicherklasse muss klar sein, was betroffen ist und welche Bereinigung gilt.

1. Umfangsmatrix als erstes Pflichtartefakt

Baue eine Umfangsmatrix, bevor ungezielt aus Indizes und Caches gelöscht wird:

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;
• Datenschutz und die zuständige Stelle für Auskunfts- oder Löschrechte benachrichtigen, wenn personenbezogene Daten betroffen sind.

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

3. Remediate nach Klasse (Entscheidungstabelle)

Wähle 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-Nachweis und Recurrence-Controls. Erfinden Sie keine Garantie, die die Wissenschaft nicht hergibt.

4. Nachweispaket für AI

Erweitere den Lösch-Nachweis 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ühre das Playbook an einem Pilot-Incident (Tabletop oder real):

• Umfang-Matrix öffnen; jede Klasse in/out mit verantwortlicher 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.

Arbeitsartefakt

AI Remediation Case File:

1. AI Contamination Scope Matrix;
2. Containment-Log;
3. Remediation Decision Record (je Klasse);
4. Nachweispaket (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: AI Product Owner, Steward, Datenschutz bei personenbezogenen Daten und Plattform 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-Nachweis…, Backups, Snapshots…, GDPR für Analytics- und AI-Teams. Glossary: Machine Unlearning.

Tools und Quellen