DSGVO und KI: Das "Recht auf Vergessenwerden" bedeutet jetzt "Unlearning"
Lass mich dir von einem Problem erzählen, das mich beim Bauen von [GrowCentric.ai](https://growcentric.ai) nicht schlafen ließ. Ein Nutzer meldet sich an. Er nutzt die Plattform sechs Monate. Seine Kampagnendaten, Zielgruppen-Verhaltensmuster, Conversion-Metriken und Engagement-Signale fließen alle ins System. Manche dieser Daten trainieren die ML-Modelle. Dann schickt der Nutzer eine E-Mail: "Ich will alle meine Daten gelöscht haben. Artikel 17, DSGVO." Kein Problem. Ich lösche den Account. Die Kampagnen. Die Reports. Jeden Datenbankeintrag. Aber hier kommt die Frage, die jeden KI-Entwickler nervös macht: Was ist mit den Modellen? Die Daten des Nutzers haben die Modellgewichte beeinflusst. Sie haben die gelernten Muster geformt. Sie beeinflussen Vorhersagen für andere Nutzer in diesem Moment. Das Löschen der Datenbankzeilen macht das gelernte Wissen nicht rückgängig. Das ist das "Machine Unlearning"-Problem. Und es ist der Kollisionspunkt zwischen dem DSGVO-Recht auf Löschung und der fundamentalen Funktionsweise maschinellen Lernens. Ich arbeite an diesem Problem über mehrere Produkte hinweg. [GrowCentric.ai](https://growcentric.ai) nutzt ML-Modelle für Marketing-Optimierung. [Stint.co](https://stint.co), wo ich ein Marketing-Dashboard mit Echtzeit-Reporting, Insight-Generierung und E-Mail-Kampagnen für große Zielgruppen gebaut habe, verarbeitet erhebliche Mengen an Nutzerdaten. [Regios.at](https://regios.at), eine regionale österreichische Plattform, handhabt Community- und lokale Geschäftsdaten. Und [Auto-Prammer.at](https://auto-prammer.at), mein Automotive-Marktplatz auf Solidus, nutzt KI für Empfehlungen und Preisgestaltung. Alles auf Ruby on Rails. Alles DSGVO-pflichtig. Alles nutzt KI auf Weisen, die Artikel 17 wirklich kompliziert machen.
Warum "Zeile löschen" nicht mehr reicht
Konkret an jedem Produkt das ich baue:
GrowCentric.ai: Die Marketing-Optimierung lernt aus Kampagnendaten. Wenn Conversion-Raten, Engagement-Muster und saisonale Trends in prädiktive Modelle fließen und Client A gelöscht wird, bleiben die gelernten Muster im Modell.
Stint.co: Das Marketing-Dashboard generiert Echtzeit-Reporting und Insights für digitale Kampagnen. Wenn das System lernt, dass E-Mails am Dienstag um 10 Uhr 23% höhere Öffnungsraten haben, basiert dieser Insight auf dem Engagement-Verhalten realer Menschen. Lösche eine Person, der Insight bleibt.
Regios.at: Die regionale Plattform handhabt lokale Geschäftseinträge und Nutzerinteraktionen. Wenn KI-Features (Suchranking, Content-Empfehlungen) auf Nutzerverhalten trainiert wurden, bestehen die Muster im Modell fort.
Auto-Prammer.at: Der Automotive-Marktplatz nutzt KI für Fahrzeugempfehlungen und Preisvorhersagen. Wenn die Empfehlungsengine von Nutzer X gelernt hat, dass BMW-3er-Interessenten auch Audi-A4-Angebote ansehen, löscht das Entfernen von Nutzer X diese Assoziation nicht.
In jedem Fall: Datenbanklöschung ist einfach. Modell-Enttrainierung ist es nicht.
Was die Regulierer tatsächlich sagen
Das ist keine theoretische Sorge.
Im März 2025 startete der EDPB seine koordinierte Durchsetzungsaktion speziell zum Recht auf Löschung. 30 Datenschutzbehörden in ganz Europa ermitteln aktiv, wie Organisationen Löschungsanfragen behandeln.
Die EDPB-Stellungnahme 28/2024 vom Dezember 2024 ist entscheidend:
KI-Modelle sind nicht automatisch anonym. Der EDPB hat die Position der Hamburger Datenschutzbehörde abgelehnt, dass LLMs keine personenbezogenen Daten speichern. Ob ein Modell anonym ist, erfordert eine Einzelfallbewertung.
Recht auf Löschung gilt für Modelle, nicht nur für Datensätze. Wenn Daten eines Betroffenen ein Modell beeinflusst haben, geht die Pflicht über das Löschen des Trainingsdatensatzes hinaus.
Schlimmster Fall: Löschung des gesamten Modells. Die EDPB-Stellungnahme erwähnt ausdrücklich, dass eine DSB die Löschung des gesamten Datensatzes und/oder des KI-Modells selbst anordnen könnte.
Unrechtmäßiges Training kontaminiert nachgelagerte Nutzung. Selbst ein anderer Controller, der ein unrechtmäßig trainiertes Modell einsetzt, kann Compliance-Probleme haben.
Und der Präzedenzfall: Im Dezember 2024 verhängte die italienische DSB eine Strafe von 15 Millionen Euro gegen OpenAI wegen DSGVO-Verstößen einschließlich der Verarbeitung von Trainingsdaten.
Das Informatik-Problem: Warum Machine Unlearning so schwer ist
Beim Training fließen Daten durch das System und passen interne Parameter an. Jedes Trainingsbeispiel verschiebt tausende Parameter um winzige Beträge. Nach Millionen Beispielen ist das Verhalten das kumulative Ergebnis aller Verschiebungen.
Es gibt keinen Rückgängig-Knopf. Man kann ein trainiertes Modell nicht ansehen und sagen "diese Gewichte wurden von Nutzer X beeinflusst."
Analogie: Stell dir vor, du machst eine Suppe und fügst Zutaten einzeln hinzu. Nach Stunden Köcheln bittet jemand, das Salz von Schritt drei zu entfernen. Das geht nicht. Es hat sich verteilt.
Forschungsansätze: Vollständiges Neutraining (genau aber teuer), approximatives Unlearning (schneller, keine Garantien), SISA-Training (geschärfte Daten für partielles Neutraining), Einflussfunktionen (gut in der Theorie, teuer in der Praxis).
Keiner löst das fundamentale Problem.
Die praktische Lösung: Gar nicht erst auf personenbezogenen Daten trainieren
Die beste Lösung für Machine Unlearning ist, es nie zu brauchen.
Mein Ansatz über alle Rails-Anwendungen:
Schicht 1: Daten-Provenienz-Tracking. Jeder Trainingslauf zeichnet genau auf, welche Daten verwendet wurden, auf welcher Aggregationsebene, und ob personenbezogene Daten beteiligt waren. Implementiert in GrowCentric.ai, Stint.co Dashboard und Auto-Prammer.at.
Schicht 2: Anonymisierungs-Pipeline. Die entscheidende Architekturentscheidung: Personenbezogene Daten werden anonymisiert oder aggregiert, BEVOR sie eine Trainingspipeline erreichen. Rohe Nutzerdaten bleiben in der Anwendungsdatenbank (wo DSGVO-Löschung einfach ist). Abgeleitete, anonymisierte Features fließen zum Trainingssystem.
Für GrowCentric.ai: Kampagnendaten auf Kampagnenebene aggregiert, mindestens 50 Nutzer pro Kohorte. Für Stint.co: Engagement-Metriken auf Segment/Zeitbucket-Ebene, mindestens 100 Empfänger pro Segment. Für Auto-Prammer.at und Regios.at: k-Anonymität mit k=10 Minimum.
Wenn ein Nutzer Löschung nach Artikel 17 verlangt, lösche ich seine personenbezogenen Daten aus der Anwendungsdatenbank. Die Trainingsdaten waren nie personenbezogen, sie wurden vor dem Eintritt in die Trainingspipeline aggregiert und anonymisiert. Es gibt nichts zu "unlearnen", weil keine individuellen Daten je "gelernt" wurden.
Schicht 3: Löschungs-Handler. Ein systematischer GDPRErasureHandler der: alle personenbezogenen Daten aus Anwendungsdatenbanken löscht, den Modell-Impact bewertet, eventuelle Modell-Remediation plant, an Drittverarbeiter weiterleitet und vollständige Compliance-Dokumentation generiert.
Schicht 4: Design für Retrainierbarkeit. SISA-inspiriertes geschärdetes Training, das partielles Neutraining ermöglicht falls nötig. Vollständige Versionierung und Provenienz für jeden Trainingslauf.
Wie das über verschiedene Produkte aussieht
GrowCentric.ai: Höchstes Risiko wegen Multi-Client-Kampagnendaten. Alle Daten auf Kampagnenebene aggregiert. Modelle lernen "Automotive-Kampagnen im DACH-Raum performen am besten Donnerstag/Freitag abends" nicht "Nutzer 47832 konvertiert donnerstags."
Stint.co: Großvolumiger E-Mail-Versand und Insight-Generierung. Engagement-Metriken auf Segment/Zeitbucket-Ebene aggregiert. Dashboard zeigt individuelle Reports dem Account-Inhaber, aber Lernsysteme sehen nur aggregierte Raten.
Regios.at: Lokale Geschäftseinträge und Community-Interaktionen. Browsing-Muster auf Sitzungsebene mit k-Anonymität anonymisiert.
Auto-Prammer.at: Fahrzeugempfehlungen auf Solidus. Collaborative-Filtering-Features aus anonymisierten Interaktionsmatrizen berechnet. Preisvorhersagemodelle nutzen nur Marktmerkmale (Marke, Modell, Jahr, Kilometerstand, Region, Saison), keine individuellen Käufer-/Verkäuferdaten.
Der Artikel-17-Antwort-Spielplan
- Innerhalb von 72 Stunden bestätigen
- Daten kartieren (Provenienz-Tracking)
- Modell-Impact bewerten
- Personenbezogene Daten löschen (innerhalb eines Monats)
- Bei Bedarf Modell-Remediation planen
- An Drittverarbeiter weiterleiten
- Alles dokumentieren
- Dem Nutzer bestätigen
Wie das ins regulatorische Gesamtbild passt
Die EU-KI-Verordnung verlangt technische Dokumentation einschließlich Trainingsdaten-Informationen. Die DSGVO verlangt Antworten auf Löschungsanfragen. Zusammen bedeuten sie: du musst genau wissen, welche Daten deine Modelle trainiert haben.
Der Cyber Resilience Act fügt Sicherheitsanforderungen für die Datenpipelines hinzu. Die NIS2-Richtlinie fügt Meldepflichten bei Datenpannen hinzu.
Der Digital Omnibus vom November 2025 schlägt "berechtigtes Interesse" als Rechtsgrundlage für KI-Trainingsdaten vor und würde die Verarbeitung besonderer Datenkategorien (Artikel 9 DSGVO) zur Entverzerrung von KI-Systemen erlauben. Aber das Recht auf Löschung würde bestehen bleiben.
Das Fazit für Entwickler
Das Recht auf Vergessenwerden ist nicht mehr nur das Löschen von Datenbankzeilen. Im KI-Zeitalter erstreckt es sich auf die Modelle, die diese Zeilen trainiert haben. Der EDPB hat es gesagt. Die italienische DSB hat es durchgesetzt. 30 europäische Datenschutzbehörden ermitteln aktiv.
Aber: Wenn du deine Systeme von Anfang an richtig architektierst, löst sich das Problem weitgehend von selbst.
Personenbezogene Daten von Trainingsdaten durch Aggregation und Anonymisierung trennen. Vollständige Datenprovenienz pflegen. Trainingspipelines für Retrainierbarkeit designen. Umfassende Löschungsbehandlung bauen die Modell-Impact bewertet. Und alles dokumentieren.
Das mache ich in jeder Rails-Anwendung, ob GrowCentric.ai, Stint.co, Regios.at oder Auto-Prammer.at.
Die Frage ist nicht ob ein Regulierer fragt, wie du Löschungsanfragen für KI-Trainingsdaten behandelst. Die Frage ist wann.