Machine Unlearning: Ein praktischer Workflow zur Entfernung von AI-Daten

Wenn jemand Sie auffordert, seine Daten aus einem AI-System zu löschen, ist das Entfernen einer einzelnen Zeile aus einer Datenbank nicht die gesamte Aufgabe. Machine Unlearning kann die Reaktion eines Modells auf bestimmte Trainingsbeispiele reduzieren oder umlenken, bereinigt aber nicht automatisch den restlichen Stack: Vektorindizes, Fine-Tuning-Adapter, gecachte Prompts, Checkpoints, Replikate, Backups und Exporte. NIST definiert Machine Unlearning als selektives Entfernen des Einflusses bestimmter Trainingspunkte aus einem trainierten Modell und weist ausdrücklich darauf hin, dass effiziente approximative Techniken ein vollständiges Neutraining von Grund auf vermeiden können. Das ist enger gefasst als „das gesamte System hat die Daten vergessen.“ NIST

Für die meisten Teams ist die praktische Antwort mehrschichtig. Verfolgen Sie zunächst, wohin die Daten gelangt sind. Stoppen Sie anschließend ihre weitere Verwendung. Löschen oder beschränken Sie danach abgeleitete Artefakte. Erst dann entscheiden Sie, ob die Modellgewichte neu trainiert oder einem approximativen Unlearning unterzogen werden müssen. Googles Machine Unlearning Challenge von 2023 verwendete genau diese modellzentrierte Perspektive: Ein unlearned Modell sollte schwer von einem Modell zu unterscheiden sein, das ohne das Forget-Set neu trainiert wurde, und gleichzeitig die Leistung auf dem Retain-Set bewahren. Google Research

Inhaltsverzeichnis

Was Machine Unlearning tatsächlich bedeutet

Machine Unlearning ist eine Operation auf Modellebene. Es geht darum, den Einfluss ausgewählter Daten auf das Verhalten eines trainierten Modells zu reduzieren. Das kann ein exaktes Neutraining auf dem Retain-Set oder eine approximative Methode bedeuten, die ohne die vollständigen Kosten eines Neutrainings ausreichend nahe an dieses Ergebnis herankommt. NIST verwendet beide Ideen in seinem Glossareintrag, und Googles Challenge-Seite beschreibt den Goldstandard als Ähnlichkeit mit einem Modell, das ohne die vergessenen Beispiele von Grund auf neu trainiert wurde. NIST Google Research

Diese Definition ist wichtig, weil AI-Systeme selten bei den Modellgewichten enden. Ein Produktions-Stack umfasst normalerweise:

Das Löschen nur einer dieser Ebenen kann dazu führen, dass die Daten an anderer Stelle weiterhin erreichbar sind. In der Praxis ist „diese Daten aus AI entfernen“ zunächst ein Lineage-Problem, bevor es zu einem Problem der Modellbearbeitung wird.

Warum ein normaler Lösch-Workflow nicht ausreicht

Viele AI-Produkte haben die Daten, deren Löschung verlangt wird, nie zum Trainieren verwendet. Sie haben sie nur zur Inferenzzeit abgerufen. In diesem Fall besteht die Aufgabe darin, Quelldatensätze, abgeleitete Embeddings, Caches und Zugriffspfade zu entfernen. Machine Unlearning ist irrelevant, weil die Modellgewichte nie verändert wurden.

Die schwierigeren Fälle beginnen, wenn die Daten Gewichte, Adapter oder persistente Memories beeinflusst haben. Dann müssen Sie vier Situationen unterscheiden, statt jede Löschanfrage gleich zu behandeln.

Diese Tabelle zeigt, warum ein „Lösch-Button“ das falsche mentale Modell ist. Das richtige Modell lautet: Entfernung nach Umfang plus Nachweise.

Ein praktischer Workflow in sieben Schritten

1. Anfrage eingrenzen und weitere Verwendung einfrieren

Beginnen Sie mit den exakten Identifikatoren: User-ID, Datei-Hash, Dokument-IDs, Namen von Vektorsammlungen, IDs von Trainings-Batches oder Ticket-Referenzen. Stoppen Sie anschließend die weitere Verwendung. Pausieren Sie Ingestion, Neutraining, Export-Jobs oder Synchronisierungen, die dieselben Daten während der Bereinigung erneut erzeugen würden.

Wenn die Anfrage datenschutzbezogen ist, halten Sie die rechtliche Einordnung eng. Artikel 17 der DSGVO begründet unter bestimmten Umständen ein Recht auf Löschung, sagt Ihnen aber nicht, welche technische Ebene zuerst bearbeitet werden muss. Die Stellungnahme des Europäischen Datenschutzausschusses vom 18. Dezember 2024 zu AI-Modellen besagt außerdem, dass mit personenbezogenen Daten trainierte Modelle nicht in allen Fällen als anonym behandelt werden können. Bewahren Sie einen expliziten Lösch-Workflow auf, statt anzunehmen, dass das Modell außerhalb des Geltungsbereichs liegt. EUR-Lex EDPB

2. Lineage verfolgen, bevor Sie etwas löschen

Kartieren Sie den vollständigen Pfad:

3. Quell- und abgeleitete Artefakte löschen oder beschränken

Entfernen Sie nun deterministisch, was Sie entfernen können:

Ein öffentliches AnythingLLM-Issue berichtete, dass Embeddings gelöschter Dokumente in einem Weaviate-basierten Setup angeblich weiterhin abrufbar waren. Ein einzelnes Issue ist anekdotische Evidenz und keine plattformweite Feststellung. Es zeigt dennoch, warum jeder Lösch-Workflow einen negativen Retrieval-Test für Dokument-IDs, charakteristische Formulierungen und Paraphrasen benötigt.

4. Entscheiden, ob sich die Modellgewichte überhaupt verändert haben

Dies ist der Verzweigungspunkt, den Teams häufig überspringen.

Googles Challenge definiert das Ziel auf Modellebene: Das unlearned Modell sollte einem Modell ähneln, das ohne die vergessenen Beispiele neu trainiert wurde, und zugleich das nützliche Verhalten bewahren, das aus den übrigen Daten gelernt wurde. Google Research

5. Evaluationsdatensätze erstellen, bevor Sie Gewichte ändern

Sie benötigen mindestens drei Bereiche:

*Bildunterschrift: Die Löscharbeit beginnt mit Daten-Lineage und abgeleiteten Artefakten. Machine Unlearning auf Modellebene beginnt erst, nachdem Sie nachgewiesen haben, ob die Gewichte betroffen waren.*

6. Vergessen und erhaltene Nutzbarkeit gemeinsam testen

Aktuelle Forschung macht den Zielkonflikt deutlich.

Das Paper *Behavioral Audit of Machine Unlearning Has a Privacy Cost* argumentiert, dass ein Black-Box-Verhaltensaudit bei konvexen Modellen nicht gleichzeitig unzureichendes Unlearning erkennen und vermeiden kann, Informationen über die Zugehörigkeit zum Retain-Set an einen ehrlich-neugierigen Auditor zu leaken. Die Autoren zeigen außerdem empirische Hinweise darauf, dass dieser Konflikt in nichtkonvexen Umgebungen fortbesteht. Das bedeutet: Ein einzelner sauberer Audit-Score ist nicht dasselbe wie ein universeller Beweis für sicheres Vergessen. arXiv

Das Audit-Framework von Google Research vom 10. Juni 2026 nähert sich dem Problem aus einer anderen Richtung. Es schlägt Regularized f-Divergence Kernel Tests vor, um Audits empfindlicher zu machen und False Positives über verschiedene Stichprobengrößen hinweg zuverlässiger zu kontrollieren. Das Ergebnis ist ein statistischer Test, kein Beweis für vollständige Löschung. Google Research

PrivUn unterscheidet drei Ebenen der Wiederherstellung: direkte Abfrage, In-Context-Wiederherstellung und Wiederherstellung durch Fine-Tuning. Verwenden Sie die Ebenen, die zu Ihrem Zugriff auf das Modell passen. Eine Verweigerung beim ursprünglichen Prompt kann die erste Prüfung bestehen, während ein stärkerer Wiederherstellungspfad das Ziel weiterhin offenlegt.

7. Veraltete Artefakte ausmustern und Nachweise aufbewahren

Entfernen oder isolieren Sie nach der Arbeit auf Modellebene veraltete Replikate, Checkpoints, Adapter und Caches. Bewahren Sie anschließend ein Nachweispaket auf:

Diese Nachweise machen aus einem Lösch-Workflow etwas, das Support, Security, Legal und Engineering gemeinsam überprüfen können.

Was die aktuelle Unlearning-Forschung tatsächlich unterstützt

Drei aktuelle Papers sind hier nützlich, unterstützen aber unterschiedliche Aussagen.

Verhaltensaudits sind nicht kostenlos

Das Paper vom Juni 2026 über Verhaltensaudits ist die stärkste Warnung vor überzogenen Behauptungen. Sein Kernergebnis lautet nicht „Unlearning ist unmöglich“. Das Ergebnis ist enger und nützlicher: Unter einem unehrlichen Betreiber und einem ehrlich-neugierigen Auditor kann ein Verhaltensaudit einen Zielkonflikt zwischen Datenschutz und Audit erzeugen. Wenn Ihre Compliance-Erzählung allein auf Black-Box-Probing beruht, können Sie beim Versuch, das Vergessen zu überprüfen, Informationen über die behaltenen Daten offenlegen. arXiv

Gezielte Bearbeitung kann bei ausgewählten Benchmarks funktionieren

*ZeroUnlearn* ist ein optimistischeres Ergebnis. Es formuliert Machine Unlearning als Model-Editing-Problem neu, berichtet starke Benchmark-Ergebnisse auf Llama-3.2, Llama-3.1 und Qwen-3 und gibt an, dass sein Closed-Form-Few-Shot-Update den SVD-Schritt auf MCF und ZsRE unter 0,3 Sekunden hält, während das End-to-End-Editing bei 10 Samples von etwa 0,04 Stunden auf 3,35 bis 3,82 Stunden bei 1000 Samples anwächst, bei einem Gesamtspeicher von etwa 14,9 bis 17,4 GB. Diese Zahlen sind relevant, weil sie zeigen, dass approximatives Unlearning nicht automatisch zu teuer zum Testen ist. arXiv

Die Einschränkungen sind jedoch wichtiger als die Schlagzeile. Das Paper evaluiert ausgewählte offene Modelle und Benchmark-Datensätze wie MCF, ZsRE und eine angepasste Single-Hop-Version von MQUAKE. Außerdem verwendet es eine gezielte Layer-Auswahl, um eine Beeinträchtigung allgemeiner Fähigkeiten zu vermeiden. Das ist ein Beleg für vielversprechende faktenbezogene Entfernung im Benchmark-Maßstab, aber kein Beweis dafür, dass ein Produktionssystem jede Kopie sensibler Informationen vollständig gelöscht hat. arXiv

Kontinuierliches Löschen ist in multimodalen Systemen weiterhin schwach

*ICU-Bench* bildet den ernüchternden Gegenpol. Der Benchmark enthält 1.000 datenschutzsensible Profile aus medizinischen Berichten und Arbeitsverträgen, 9.500 Bilder, 16.000 Frage-Antwort-Paare und 100 sequenzielle Forget-Aufgaben. Die Schlussfolgerung ist einfach: Aktuelle multimodale Unlearning-Methoden haben in kontinuierlichen Szenarien Schwierigkeiten und bewahren nicht gleichzeitig Vergessensqualität, erhaltene Nutzbarkeit und Stabilität über lange Sequenzen. Wenn Ihr Produkt im Laufe der Zeit wiederholt Löschanfragen erhält, sollten Sie dieses Paper lesen, bevor Sie eine saubere Automatisierung versprechen. arXiv

Zusammengenommen unterstützen die Papers eine praktische Position:

Was Sie Nutzern und Stakeholdern versprechen sollten

Versprechen Sie weniger. Überprüfen Sie mehr.

Gute Formulierungen klingen so:

Schlechte Formulierungen klingen so:

Wenn Sie eine kurze Regel benötigen, verwenden Sie diese: Machine Unlearning ist eine Ebene innerhalb eines umfassenderen Workflows zur Entfernung von AI-Daten.

FAQ

Lässt das Löschen einer Zeile aus einer Vektordatenbank das LLM vergessen?

Nein. Es kann verhindern, dass ein Retrieval-Pfad die Daten erneut einführt, was bei RAG-Systemen häufig die richtige erste Maßnahme ist. Wenn derselbe Inhalt jedoch für Fine-Tuning, kontinuierliches Training oder persistente Model-Memory verwendet wurde, verändert das alleinige Löschen der Vektorzeile die Gewichte nicht.

Kann Machine Unlearning beweisen, dass meine Daten aus jeder Modellkopie verschwunden sind?

Nicht allein. Aktuelle Forschung zu Audits zeigt, dass Black-Box-Audits Grenzen haben, und Produktionssysteme enthalten häufig Caches, Adapter, Checkpoints, Replikate und Backups außerhalb der geprüften Modelloberfläche. Sie benötigen Nachweise auf Systemebene, nicht nur einen Score auf Modellebene. arXiv Google Research

Prüfung der Aussagen

Quellen