DSGVO und KI: wenn das Recht auf Vergessenwerden das Modell erreicht

Das Problem in einem Absatz

Eine Kundin meldet sich bei einem SaaS Produkt an, nutzt es sechs Monate und schreibt dann: "Löscht alle meine Daten. Artikel 17." Das Konto, die Kampagnen, die Berichte und jede Zeile mit ihrer ID zu löschen, ist der leichte Teil. Die unbequeme Frage ist das Modell. Haben ihre Daten geholfen, es zu trainieren, steckt ihr Einfluss in den Parametern des Modells und prägt die Vorhersagen für alle anderen, und das Löschen der Zeilen macht das nicht rückgängig. Das ist das Problem des Machine Unlearning, und genau hier trifft das Recht auf Löschung auf die Art, wie maschinelles Lernen funktioniert.

Es hat mich nachts wach gehalten, als ich GrowCentric.ai gebaut habe, und ich arbeite daran in mehreren Produkten, alle auf Ruby on Rails gebaut und alle dem Datenschutzrecht unterworfen. Dieser Artikel zeigt, was das Gesetz tatsächlich sagt, was die Aufsichtsbehörden über Modelle gesagt haben und was nicht, was die Forschung kann und was nicht, und welche Architektur dich gar nicht erst in das Problem bringt.

Was das Recht auf Löschung sagt

Das Recht steht in Artikel 17 DSGVO. Eine Person kann verlangen, dass ihre personenbezogenen Daten unverzüglich gelöscht werden, wenn einer von mehreren Gründen vorliegt: Die Daten werden für ihren Zweck nicht mehr gebraucht, sie widerruft die Einwilligung, auf der die Verarbeitung beruhte, sie widerspricht und es gibt keine vorrangigen berechtigten Gründe (oder sie widerspricht der Direktwerbung), die Daten wurden unrechtmäßig verarbeitet, eine rechtliche Pflicht verlangt die Löschung, oder sie wurden bei einem Kind für einen Onlinedienst erhoben.¹

Absolut ist das Recht nicht. Die Löschung entfällt, wo die Verarbeitung für die Meinungsfreiheit, eine rechtliche Verpflichtung, die öffentliche Gesundheit, Archiv oder Forschungszwecke oder Rechtsansprüche nötig ist.¹

Die Uhr läuft einen Monat. Der Verantwortliche muss auf den Antrag unverzüglich reagieren, in jedem Fall innerhalb eines Monats nach Eingang. Bei komplexen oder zahlreichen Anträgen kann er um zwei weitere Monate verlängern, muss das der Person aber innerhalb des ersten Monats mitteilen, mit Gründen.²

Modelle erwähnt Artikel 17 nirgends. Er wurde für personenbezogene Daten geschrieben, wo immer sie liegen. Ob ein trainiertes Modell personenbezogene Daten enthält, ist die Frage, an der alles andere hängt.

Rechenbeispiel: der Antrag und die Frist

Ein erfundenes Beispiel. Alstermail ist ein SaaS für E Mail Marketing aus Hamburg, unter alstermail.example. Am 3. März schreibt eine Empfängerin des Newsletters eines Alstermail Kunden und verlangt, dass jede Spur von ihr gelöscht wird. Alstermail verarbeitet die Empfängerdaten im Auftrag seiner Kunden, ist hier also Auftragsverarbeiter: Es leitet den Antrag an den Kunden weiter, den Verantwortlichen, und hilft ihm bei der Antwort, so wie es der Vertrag zur Auftragsverarbeitung vorschreiben muss.³ Die Frist des Kunden endet am 3. April. Betrifft der Antrag Backups, ein Analytics Warehouse und ein Modell, kann der Kunde um zwei Monate verlängern, aber nur, wenn er es der Empfängerin vor dem 3. April mitteilt, mit Gründen.

Spannend ist der letzte Punkt auf dieser Liste: das Modell.

Warum das Löschen der Zeile nicht mehr die ganze Antwort ist

Beim Training verschiebt jedes Beispiel über das Gradientenverfahren Tausende oder Millionen von Parametern um winzige Beträge. Das fertige Modell ist die Summe all dieser Verschiebungen. Es gibt darin keine Spalte mit der Aufschrift "Nutzerin X". Der Einfluss ist über den ganzen Parameterraum verteilt und mit jedem anderen Beispiel verwoben.

Mein Vergleich ist eine Suppe. Die Zutaten kommen nacheinander hinein und köcheln stundenlang. Dann bittet dich jemand, das Salz aus Schritt drei wieder herauszunehmen. Geht nicht. Die einzige Suppe ohne Salz ist eine neue Suppe, die ohne Salz gekocht wurde.

Zwei Dinge machen daraus eine Rechtsfrage und nicht nur eine technische. Modelle können auswendig lernen. Carlini und Kollegen haben aus GPT 2 Hunderte wörtliche Trainingssequenzen extrahiert, darunter Namen, Telefonnummern und E Mail Adressen, manche davon aus nur einem einzigen Dokument der Trainingsdaten.⁴ Und Membership Inference Angriffe können allein aus den Antworten eines Modells erkennen, ob ein bestimmter Datensatz in seinem Trainingsset war.⁵ Ein Modell, das so viel preisgibt, enthält personenbezogene Daten in jedem Sinn, auf den es ankommt.

So sieht das in den Produktarten aus, an denen ich arbeite, an vier erfundenen Unternehmen:

• Ein SaaS zur Marketingoptimierung lernt aus Kampagnenergebnissen. Zeigen die Daten eines Kunden, dass eine bestimmte Zielgruppe donnerstagabends am besten konvertiert, kann dieses Muster die Empfehlungen für einen anderen Kunden prägen. Wird das Konto des ersten Kunden gelöscht, bleibt das Muster im Modell.
• Eine E Mail Plattform wie Alstermail lernt, welche Versandzeiten und Betreffzeilen geöffnet werden. Die Öffnungen und Klicks jeder Empfängerin sind in dieses Lernen eingeflossen. Löscht man eine Empfängerin, bleibt die Erkenntnis.
• Ein regionales Branchenverzeichnis in Leipzig, unter stadtteilsuche.example, reiht lokale Betriebe nach dem Verhalten der Besucher. Das Rankingmodell behält die Muster, wenn ein Besucher geht.
• Ein Gebrauchtwagenmarkt in München auf Solidus, unter isarmotors.example, empfiehlt Autos nach dem Surfverhalten. Hat er von einem Besucher gelernt, dass Leute, die sich einen bestimmten Kompaktwagen für Familien ansehen, auch den eines Konkurrenten ansehen, verlernt er diese Verbindung nicht, wenn der Besucher gelöscht wird.

In jedem Fall ist das Löschen in der Datenbank leicht und das Modell nicht.

Was die Aufsichtsbehörden tatsächlich gesagt haben

In der ersten Fassung dieses Artikels stand, die Aufsichtsbehörden hätten Unlearning zur Pflicht gemacht. Das haben sie nicht, und ich habe diesen Abschnitt so umgeschrieben, dass er nur sagt, was in den veröffentlichten Dokumenten steht.

Die Stellungnahme des EDSA zu KI Modellen

In der Stellungnahme 28/2024, angenommen am 17. Dezember 2024, hat sich der Europäische Datenschutzausschuss (EDSA) mit personenbezogenen Daten in KI Modellen befasst. Seine zentrale Feststellung: KI Modelle, die mit personenbezogenen Daten trainiert wurden, können nicht in allen Fällen als anonym gelten, und die Anonymität ist im Einzelfall zu prüfen. Damit ein Modell als anonym gilt, müssen sowohl die Wahrscheinlichkeit, personenbezogene Daten über die Menschen in den Trainingsdaten zu extrahieren, als auch die Wahrscheinlichkeit, solche Daten über Abfragen herauszubekommen, unerheblich sein, unter Berücksichtigung aller Mittel, die vernünftigerweise eingesetzt werden könnten.⁶

Die Folge ist logisch, auch wenn sie nicht ausbuchstabiert wird: Ein Modell, das nicht anonym ist, enthält personenbezogene Daten, und die DSGVO gilt dafür, die Betroffenenrechte eingeschlossen.

Die Stellungnahme zählt auch auf, was eine Aufsichtsbehörde tun kann, wenn ein Modell mit unrechtmäßig verarbeiteten Daten entwickelt wurde: ein Bußgeld, eine vorübergehende Beschränkung der Verarbeitung, die Löschung des unrechtmäßig verarbeiteten Teils des Datensatzes oder, wo das nicht möglich ist und je nach Sachlage unter Wahrung der Verhältnismäßigkeit, die Anordnung, den ganzen Datensatz zur Entwicklung des Modells und oder das Modell selbst zu löschen.⁶ Das ist der schlimmste Fall, und er betrifft eine unrechtmäßige Entwicklung, keinen gewöhnlichen Löschantrag.

Zwei weitere Punkte zählen für alle, die bauen. Unter den Maßnahmen, die einem Verantwortlichen bei der Abwägung für das berechtigte Interesse helfen können, nennt die Stellungnahme, Menschen die Löschung auch dort zu ermöglichen, wo die Gründe aus Artikel 17 nicht greifen, und Techniken nach dem Training, die versuchen, personenbezogene Daten zu entfernen oder zu unterdrücken.⁶ Das sind Angebote zur Risikominderung, keine Pflichten. Und wer das Modell eines anderen einsetzt, soll angemessen geprüft haben, dass es nicht durch unrechtmäßige Verarbeitung personenbezogener Daten entwickelt wurde.⁶ Baust du auf einem Modell eines Dritten, ist diese Prüfung deine.

Das Jahr der koordinierten Prüfung zur Löschung

2025 war das Recht auf Löschung Thema des Coordinated Enforcement Framework des EDSA. 32 Datenschutzbehörden haben teilgenommen: 9 haben förmliche Untersuchungen eröffnet oder fortgeführt, 23 haben Sachstandserhebungen durchgeführt, und 764 Verantwortliche haben geantwortet. Der Bericht wurde am 10. Februar 2026 angenommen.⁷

Er fand sieben wiederkehrende Probleme, darunter schwache interne Verfahren, zu wenig Information für die Betroffenen, unklare Aufbewahrungsfristen und die Löschung aus Backups.⁷ KI Modelle hebt er nicht eigens hervor. Die Feststellung, die für diesen Artikel am meisten zählt, betrifft die Anonymisierung: Viele Verantwortliche anonymisieren statt zu löschen, manche nutzen dabei nur eine einfache Pseudonymisierung oder teilweise Maskierung, was die Anforderungen der DSGVO an eine Löschung nicht erfüllen würde, und der EDSA arbeitet an Leitlinien zur Anonymisierung.⁸ Merk dir das für die Architektur weiter unten.

Die deutschen Aufsichtsbehörden

Private Unternehmen beaufsichtigen in Deutschland die Datenschutzbehörden der Länder.⁹ Gemeinsam sprechen sie in der Datenschutzkonferenz (DSK), der Konferenz der unabhängigen Datenschutzaufsichtsbehörden des Bundes und der Länder. Deren Orientierungshilfe "Künstliche Intelligenz und Datenschutz" vom 6. Mai 2024 ist das Deutlichste, was es hierzulande zu Löschung und KI gibt. Verantwortliche müssen gewährleisten, dass Betroffene ihre Rechte auf Berichtigung und Löschung ausüben können, und dafür technische und organisatorische Verfahren so konzipieren, dass diese Rechte wirksam ausgeübt werden können. Eine Berichtigung muss in einer KI Anwendung umsetzbar sein, etwa durch Korrektur von Daten oder durch Nachtraining oder Fine Tuning. Bei der Löschung ist darauf zu achten, dass eine Wiederherstellung des Personenbezugs dauerhaft unmöglich ist. Und unerwünschte Ausgaben mit nachgeschalteten Filtern zu unterdrücken, ist nicht generell eine Löschung im Sinne von Artikel 17, weil die Daten für das Modell weiter personenbeziehbar verfügbar sein könnten. Filter können aber helfen, bestimmte Ausgaben zu vermeiden.¹⁰

Eine deutsche Behörde hat die Frage auch andersherum beantwortet. Der Hamburgische Beauftragte für Datenschutz und Informationsfreiheit vertrat 2024 in einem Diskussionspapier die These, in Large Language Models würden keine personenbezogenen Daten gespeichert. Die Betroffenenrechte könnten sich daher nicht auf das Modell selbst richten, wohl aber auf Eingabe und Ausgabe des KI Systems, und das Training mit personenbezogenen Daten müsse trotzdem datenschutzkonform sein.¹¹ Die Stellungnahme des EDSA vom Dezember 2024 verlangt dagegen eine Prüfung im Einzelfall.⁶ In der ersten Fassung stand, der EDSA habe die Hamburger Position "verworfen". Das sagt die Stellungnahme nicht, deshalb habe ich es gestrichen. Für dich zählt: Wer sich auf "im Modell steckt nichts" verlässt, verlässt sich auf eine These, die der EDSA so nicht teilt.

Das ist die ehrliche Lage. Keine Aufsichtsbehörde, die ich gefunden habe, schreibt Machine Unlearning als Technik vor. Die DSK sagt, dass die Rechte in einer KI Anwendung wirksam umsetzbar sein müssen, nennt Nachtraining als einen Weg und lässt Filter allein nicht als Löschung gelten.

Der Fall, den alle zitieren

Im Dezember 2024 verhängte die italienische Datenschutzbehörde, der Garante, gegen OpenAI ein Bußgeld von 15 Millionen € und stellte unter anderem fest, dass OpenAI personenbezogene Daten von Nutzern zum Training von ChatGPT verarbeitet hatte, ohne zuvor eine geeignete Rechtsgrundlage festzulegen.¹² Die erste Fassung dieses Artikels hörte dort auf. Seitdem hat ein Urteil des Gerichts in Rom, veröffentlicht am 18. März 2026, der Klage von OpenAI gegen diese Entscheidung stattgegeben, und der Garante hat die Entscheidung von seiner Website genommen.¹² Der Fall zeigt, dass die Fragen offen sind. Gefestigtes Recht zeigt er nicht.

Was die Forschung zum Machine Unlearning kann

Forscher arbeiten daran mindestens seit 2015, und ein Überblick von 2022 fasst den Stand so zusammen: Die jüngeren Arbeiten hätten das Problem nicht vollständig lösen können.¹³ Die wichtigsten Familien:

Vollständiges Neutraining. Noch einmal von vorn trainieren, ohne die gelöschten Daten. Das ist exakt und der Maßstab, an dem alles andere gemessen wird. Für ein großes Modell ist es langsam und teuer. Für ein kleines Fachmodell kann es gut bezahlbar sein.

SISA Training. Bourtoule und Kollegen teilen die Trainingsdaten in Shards, trainieren auf jedem ein eigenes Modell und kombinieren deren Ausgaben. Kommt eine Löschung, wird nur der Shard neu trainiert, der den Datensatz enthielt.¹⁴ Der Name steht für sharded, isolated, sliced and aggregated. Das senkt die Kosten des Vergessens, um den Preis, dass du deine ganze Trainingspipeline darum herum baust.

Entfernen über Einflussfunktionen. Koh und Liang haben gezeigt, wie Einflussfunktionen eine Vorhersage auf die Trainingspunkte zurückführen, die am meisten dafür verantwortlich sind.¹⁵ Guo und Kollegen haben daraus "certified removal" gemacht, eine formale Garantie, dass sich ein Modell nach dem Entfernen von Daten nicht von einem unterscheiden lässt, das sie nie gesehen hat, für lineare Klassifikatoren.¹⁶ Stark bei einfachen Modellen, viel schwerer bei tiefen Netzen.

Umetikettieren und Fine Tuning. Graves und Kollegen haben "amnesiac" Unlearning vorgeschlagen: die Updates jedes Batches aufzeichnen und rückgängig machen, oder die zu vergessenden Daten umetikettieren und nachtrainieren, dann gegen Membership Inference und Model Inversion Angriffe prüfen.¹⁷ Schnell, aber nur näherungsweise.

Der Test ist für alle derselbe Angriff, der sie überhaupt nötig macht: Kann ein Angreifer noch erkennen, dass der Datensatz im Trainingsset war?⁵

Rechenbeispiel: was Sharding spart

Isar Motors trainiert sein Empfehlungsmodell jede Nacht neu. Ein vollständiger Trainingslauf dauert acht Stunden (die Annahme des Beispiels). Sind die Daten in gleich große Shards geteilt, trainiert eine Löschung nur einen Shard neu, die Kosten sind also ungefähr die vollen Kosten geteilt durch die Zahl der Shards:

$$C_{\text{shard}} \approx \frac{C_{\text{full}}}{S}$$

Dabei ist $C_{\text{shard}}$ die Zeit für das Neutraining nach einer Löschung, $C_{\text{full}}$ die Zeit für einen vollständigen Trainingslauf und $S$ die Zahl der gleich großen Shards. Das ist ein einfaches Verhältnis, erklärt in Grundlagen: Verhältnisse und Raten.

Mit 16 Shards:

$$\frac{8}{16} = 0{,}5$$

Dabei ist $8$ der volle Lauf in Stunden, $16$ die Zahl der Shards und $0{,}5$ die Stunden pro Löschung. Dreißig Löschungen im Monat kosten 15 Stunden Training statt 240. Der Haken: 16 Modelle, die jeweils auf einem Sechzehntel der Daten trainiert sind, sagen womöglich schlechter vorher als ein Modell auf allen Daten, und Bourtoule und Kollegen haben diesen Zielkonflikt für ihre Datensätze gemessen.¹⁴ Schnelles Vergessen bezahlst du mit etwas Genauigkeit.

Die praktische Antwort: personenbezogene Daten aus dem Training heraushalten

Hier höre ich auf, das Problem zu beschreiben, und beschreibe, was ich dagegen tue.

Die beste Antwort auf Machine Unlearning ist, es nie zu brauchen. Erreichen personenbezogene Daten ein Modell nie in identifizierbarer Form, gibt es nichts zu verlernen. Das heißt nicht, dass du nicht von deinen Nutzern lernen darfst. Es heißt, eine Architektur zu bauen, die personenbezogene Daten von Trainingsdaten trennt, durch Aggregation, Anonymisierung und sorgfältige Governance.

Lies es von oben. Die Rohdaten bleiben dort, wo Löschen leicht ist. Die Prüfung der Kohortengröße ist das Tor. Der Herkunftsnachweis unten ist das, womit du einen Antrag mit Belegen beantwortest statt mit einem Schulterzucken.

Schicht 1: Herkunft der Daten

Zuerst musst du genau wissen, welche Daten in welches Modell gegangen sind. Kannst du die Frage "Wurden die Daten dieser Person für das Training dieses Modells genutzt?" nicht beantworten, kannst du auch einen Löschantrag nicht richtig beantworten.

class DataProvenanceTracker
  def record_training_usage(model_version:, data_sources:)
    data_sources.each do |source|
      TrainingDataRecord.create!(
        model_name: model_version.model_name,
        model_version: model_version.version_string,
        data_source_type: source[:type],
        data_source_id: source[:id],
        contains_personal_data: source[:personal_data],
        anonymisation_method: source[:anonymisation_method],
        aggregation_level: source[:aggregation_level],
        included_at: Time.current,
        data_hash: compute_data_hash(source)
      )
    end
  end

  def find_models_using_data_from(user:)
    TrainingDataRecord.where(
      data_source_type: "user_derived",
      data_source_id: user.id,
      contains_personal_data: true
    ).includes(:model_version)
  end

  def erasure_impact_assessment(user:)
    affected = find_models_using_data_from(user: user)
    {
      user_id: user.id,
      affected_model_count: affected.size,
      models: affected.map do |record|
        {
          model: record.model_name,
          version: record.model_version,
          anonymisation_method: record.anonymisation_method,
          aggregation_level: record.aggregation_level,
          retraining_required: record.contains_personal_data &&
                               record.aggregation_level == "individual"
        }
      end,
      assessed_at: Time.current
    }
  end
end

Das habe ich in GrowCentric.ai und in den Kundenprodukten, an denen ich arbeite, als Erstes umgesetzt. Jeder Trainingslauf hält fest, welche Daten verwendet wurden, auf welcher Aggregationsstufe und ob personenbezogene Daten beteiligt waren.

Schicht 2: die Anonymisierungspipeline

Die entscheidende Festlegung: Personenbezogene Daten werden aggregiert oder anonymisiert, bevor sie eine Trainingspipeline erreichen. Die Rohdaten bleiben in der Datenbank der Anwendung, wo das Löschen einfach ist. Nur abgeleitete, aggregierte Merkmale fließen ins Training.

class TrainingDataAnonymiser
  def prepare_training_features(user_data, purpose:)
    case purpose
    when :campaign_optimisation then aggregate_campaigns(user_data)
    when :email_engagement      then aggregate_engagement(user_data)
    when :recommendation_engine then generalise_browsing(user_data)
    end
  end

  private

  def aggregate_campaigns(data) # Keine Kennungen, nur Kohorten, mindestens 50 pro Kohorte
    data.group_by { |d| cohort_key(d) }
        .select { |_key, members| members.size >= 50 }
        .transform_values { |members| aggregate_metrics(members) }
  end

  def aggregate_engagement(data) # Nur Segment und Zeitfenster, mindestens 100 Empfänger pro Gruppe
    data.group_by { |d| [d[:segment], time_bucket(d[:timestamp])] }
        .select { |_key, members| members.size >= 100 }
        .transform_values do |members|
          {
            open_rate: members.count { |m| m[:opened] }.to_f / members.size,
            click_rate: members.count { |m| m[:clicked] }.to_f / members.size,
            segment_size: members.size
          }
        end
  end

  def generalise_browsing(data) # Merkmale verallgemeinern, nur Gruppen mit mindestens k = 10 behalten
    data.map { |d| strip_identity(d) }
        .group_by { |d| generalise_attributes(d) }
        .select { |_key, group| group.size >= 10 }
  end

  def cohort_key(datum)
    [datum[:region_code], datum[:industry_vertical],
     time_bucket(datum[:timestamp]), device_category(datum[:device])].join(":")
  end
end

Das Prinzip sind Mindestgrößen für Kohorten. Für Kampagnendaten in GrowCentric.ai keine Trainingskohorte unter 50. Für das E Mail Engagement in den Kundenprodukten kein Segment unter 100 Empfängern. Für Surfdaten Gruppen von mindestens zehn. Das Letzte ist k Anonymität, das Modell von Latanya Sweeney: Eine Veröffentlichung schützt jede Person, wenn sich ihr Datensatz darin von mindestens $k-1$ anderen nicht unterscheiden lässt.¹⁸

Jetzt der ehrliche Vorbehalt, den die erste Fassung weggelassen hat. Gruppieren ist nicht automatisch Anonymisieren. Sweeneys eigener Aufsatz zeigt, wie k anonyme Veröffentlichungen trotzdem reidentifiziert werden können, wenn die begleitenden Regeln nicht eingehalten werden.¹⁸ Und der EDSA hat Verantwortliche gefunden, die eine einfache Pseudonymisierung oder Maskierung als Löschung behandeln, obwohl sie den Maßstab der DSGVO nicht erfüllt.⁸ Anonym heißt rechtlich, dass sich die Daten nicht mehr auf eine identifizierbare Person beziehen.¹ Die Kohortenprüfung ist also notwendig, aber nicht hinreichend: seltene Kombinationen verwerfen, Zeitstempel und Orte vergröbern, nie auf Kennungen trainieren und testen, was ein Angreifer ableiten könnte.

Rechenbeispiel: das Tor der Kohortengröße

Die Stadtteilsuche gruppiert Besuchersitzungen nach Stadtteil, Kategorie und Woche, bevor sie ihr Rankingmodell trainiert. In einer Woche haben die Gruppen für "Gohlis, Hochzeitsfotografie" diese Sitzungszahlen: 41, 12 und 7.

Mit $k = 10$ behält das Tor Gruppen ab 10:

• 41: behalten
• 12: behalten
• 7: verworfen

Die Gruppe mit sieben fällt nicht heraus, weil sieben eine magische Zahl wäre, sondern weil in einer kleinen, spezifischen Gruppe das Verhalten eines Einzelnen hervorsticht. Verlangt einer dieser sieben Besucher später die Löschung, löscht die Stadtteilsuche seine Rohsitzungen, und der Herkunftsnachweis zeigt, dass seine Woche in einer verworfenen Gruppe lag oder in einer behaltenen mit mindestens zehn, nie als Einzelner in einem Modell.

Schicht 3: die Bearbeitung des Löschantrags

Kommt ein Antrag herein, bearbeitet das System ihn von Anfang bis Ende:

class GDPRErasureHandler
  def process_erasure_request(user:, requested_at: Time.current)
    request = ErasureRequest.create!(user: user, requested_at: requested_at,
                                     status: "processing")

    ActiveRecord::Base.transaction do
      delete_personal_data(user)

      impact = DataProvenanceTracker.new.erasure_impact_assessment(user: user)
      impact[:models].each do |model_info|
        if model_info[:retraining_required]
          schedule_model_remediation(model_info, user)
        else
          log_no_action_required(model_info, reason: "training_data_aggregated")
        end
      end

      propagate_to_processors(user)

      request.update!(
        status: "completed",
        completed_at: Time.current,
        impact_assessment: impact,
        model_remediation_required: impact[:models].any? { |m| m[:retraining_required] },
        documentation: generate_erasure_documentation(user, impact)
      )
    end

    ErasureConfirmationMailer.send_confirmation(user, request).deliver_later # Frist: ein Monat ab Eingang, Verlängerung nur mit Mitteilung
    request
  end

  private

  def delete_personal_data(user)
    [UserProfileService, CampaignDataService, EmailEngagementService,
     BrowsingHistoryService, SupportTicketService,
     AuditLogService] # Protokoll anonymisieren, wo das Gesetz die Aufbewahrung verlangt
      .each { |service| service.erase_for(user) }
  end

  def schedule_model_remediation(model_info, user)
    ModelRetrainingJob.perform_later(model_name: model_info[:model],
                                     exclude_user_id: user.id,
                                     reason: "erasure_request", priority: "high")
  end

  def propagate_to_processors(user)
    DataProcessorRegistry.all.each do |processor|
      processor.request_erasure(user_identifier: user.anonymised_id)
    end
  end
end

Funktioniert die Pipeline aus Schicht 2, sollte der Zweig mit dem Neutraining fast nie laufen. Er ist für den Tag da, an dem er es doch tut.

Schicht 4: auf Neutraining auslegen

Halte auch bei guter Aggregation das Neutraining machbar. Genau das meint die DSK, wenn sie wirksame technische Verfahren für die Betroffenenrechte verlangt und das Nachtraining als einen Weg nennt:¹⁰

class RetrainableModelPipeline
  def train(model_config:, training_data:, excluded_users: [])
    dataset = prepare_versioned_dataset(training_data: training_data,
                                        excluded_users: excluded_users)
    model = ModelTrainer.train(config: model_config, data: dataset[:features])

    ModelVersion.create!(
      model_name: model_config[:name],
      version: next_version(model_config[:name]),
      trained_at: Time.current,
      training_data_hash: dataset[:hash],
      excluded_users: excluded_users,
      data_provenance: dataset[:provenance]
    )
    model
  end

  def prepare_versioned_dataset(training_data:, excluded_users: []) # Nach SISA: Daten in Shards halten, damit ein Teilneutraining möglich ist
    shards = training_data.each_slice(shard_size).map do |shard|
      { data: shard.reject { |d| excluded_users.include?(d[:source_user_id]) },
        hash: Digest::SHA256.hexdigest(shard.to_json) }
    end
    { features: shards.flat_map { |s| s[:data] },
      hash: Digest::SHA256.hexdigest(shards.map { |s| s[:hash] }.join),
      provenance: shards.map { |s| s[:hash] } }
  end
end

Der Ablauf bei einem Löschantrag, Schritt für Schritt

Wenn jemand das Recht auf Löschung ausübt:

Schritt 1: schnell bestätigen. Keine gesetzliche Pflicht, aber eine Antwort innerhalb weniger Tage sagt der Person, dass ein Mensch den Antrag gesehen hat.

Schritt 2: die Daten finden. Nutze die Herkunftsnachweise, um jede Stelle zu finden, an der ihre personenbezogenen Daten liegen: Anwendungsdatenbanken, Analytics, Backups, Auftragsverarbeiter und Trainingssets. Die Löschung aus Backups gehörte zu den Schwachstellen, die der EDSA immer wieder fand.⁷ Sag der Person klar, was mit der Kopie im Backup passiert, bis sie überschrieben wird.

Schritt 3: die Modelle bewerten. Funktioniert die Architektur, zeigt die Bewertung, dass ihre Daten das Training nur aggregiert erreicht haben. Schreib das auf.

Schritt 4: löschen. Entferne die personenbezogenen Daten überall, innerhalb eines Monats nach Eingang, oder verlängere bei einem komplexen Fall mit Mitteilung.²

Schritt 5: wenn nötig neu trainieren. Hat ein Modell personenbezogene Daten in identifizierbarer Form erreicht, plane ein Neutraining ohne sie und halte den Zeitplan fest.

Schritt 6: deine Auftragsverarbeiter informieren. Gib den Antrag an jeden Auftragsverarbeiter weiter, der die Daten hält.

Schritt 7: alles dokumentieren. Schwache Verfahren und schlechte Information gehörten zu den wichtigsten Befunden des EDSA.⁷ Deine Aufzeichnungen sind dein Beleg.

Schritt 8: der Person bestätigen. Sag, was gelöscht wurde, was in Backups liegt und wie lange, und ob noch ein Neutraining läuft.

Wie das ins größere Bild passt

Die KI Verordnung verlangt von Anbietern von Hochrisikosystemen eine technische Dokumentation, die ihre Trainingsdaten einschließt, für die meisten ab dem 2. Dezember 2027,¹⁹ und ihr Digital Omnibus erlaubt Anbietern jetzt, besondere Kategorien personenbezogener Daten ausschließlich zur Erkennung von Verzerrungen zu verarbeiten, mit Löschung, sobald die Verzerrung korrigiert ist.²⁰ Die Termine behandle ich in der EU KI Verordnung für SaaS Entwickler, die DACH Perspektive in KI Compliance für den DACH Markt. Zusammen mit der DSGVO heißt das: wissen, womit deine Modelle trainiert wurden, und es zeigen können.

In der ersten Fassung dieses Artikels stand auch ein Vorschlag, das berechtigte Interesse als Rechtsgrundlage für KI Training nach der DSGVO zuzulassen. Das war ein eigener Vorschlag, seinen Stand konnte ich nicht bestätigen, und ich habe ihn gestrichen. Egal auf welcher Rechtsgrundlage, das Recht auf Löschung bleibt.

Der Cyber Resilience Act bringt Sicherheitspflichten für die Pipelines selbst, und die NIS2 Richtlinie Meldepflichten, wenn in sie eingebrochen wird.

Unterm Strich für Entwickler

Beim Recht auf Vergessenwerden ging es nie nur um Zeilen. Es geht um personenbezogene Daten, wo immer sie liegen, und ein Modell kann einer dieser Orte sein. Der EDSA sagt, ein mit personenbezogenen Daten trainiertes Modell ist nicht automatisch anonym. Die DSK sagt, die Rechte müssen in einer KI Anwendung wirksam umsetzbar sein, und ein Filter allein ist keine Löschung. Keiner von beiden verlangt, dass du Machine Unlearning beherrschst.

Also bau das System von Anfang an richtig. Halte personenbezogene Daten durch Aggregation mit Mindestgrößen für Kohorten aus dem Training heraus, und verwechsle Maskierung nicht mit Anonymisierung. Halte fest, was in jedes Modell gegangen ist. Halte das Neutraining machbar. Bearbeite Anträge von Anfang bis Ende, die Modelle eingeschlossen, und schreib alles auf.

Die Muster sind in jeder Rails Anwendung, die ich baue, dieselben: Herkunftsnachweis, Aggregation, Mindestkohorten, Training in Shards, wo es sich lohnt, eine vollständige Bearbeitung von Löschanträgen und ein Protokoll. Bau sie einmal und setz sie überall ein, denn früher oder später fragt jemand, was mit seinen Daten in deinem Modell passiert ist.

Footnotes

1. Europäisches Parlament und Rat, Verordnung (EU) 2016/679 (Datenschutz Grundverordnung), Artikel 17 und Erwägungsgrund 26, EUR Lex, https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32016R0679

2. Europäisches Parlament und Rat, Verordnung (EU) 2016/679 (Datenschutz Grundverordnung), Artikel 12 Absatz 3, EUR Lex, https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32016R0679

3. Europäisches Parlament und Rat, Verordnung (EU) 2016/679 (Datenschutz Grundverordnung), Artikel 28 Absatz 3 Buchstabe e, Unterstützung bei den Rechten der betroffenen Person, EUR Lex, https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32016R0679

4. Nicholas Carlini, Florian Tramer, Eric Wallace, Matthew Jagielski und andere, Extracting Training Data from Large Language Models, arXiv, 2020, https://arxiv.org/abs/2012.07805

5. Reza Shokri, Marco Stronati, Congzheng Song und Vitaly Shmatikov, Membership Inference Attacks against Machine Learning Models, arXiv, 2016, https://arxiv.org/abs/1610.05820

6. Europäischer Datenschutzausschuss, Opinion 28/2024 on certain data protection aspects related to the processing of personal data in the context of AI models, angenommen am 17. Dezember 2024, https://www.edpb.europa.eu/system/files/2024-12/edpb_opinion_202428_ai-models_en.pdf

7. Europäischer Datenschutzausschuss, EDPB identifies challenges hindering the full implementation of the right to erasure, 18. Februar 2026, https://www.edpb.europa.eu/news/edpb-identifies-challenges-hindering-the-full-implementation-of-the-right-to-erasure_en

8. Europäischer Datenschutzausschuss, 2025 Coordinated Enforcement Action: Implementation of the right to erasure by controllers, angenommen am 10. Februar 2026, Abschnitt 4.2.7, https://www.edpb.europa.eu/system/files/2026-02/edpb_cef-report_2025_right-to-erasure_en.pdf

9. Bundesministerium der Justiz und für Verbraucherschutz, Bundesdatenschutzgesetz (BDSG), § 40 Aufsichtsbehörden der Länder, Gesetze im Internet, https://www.gesetze-im-internet.de/bdsg_2018/__40.html

10. Konferenz der unabhängigen Datenschutzaufsichtsbehörden des Bundes und der Länder (DSK), Orientierungshilfe Künstliche Intelligenz und Datenschutz, Version 1.0, 6. Mai 2024, Randnummern 26 bis 29, https://www.datenschutzkonferenz-online.de/media/oh/20240506_DSK_Orientierungshilfe_KI_und_Datenschutz.pdf

11. Der Hamburgische Beauftragte für Datenschutz und Informationsfreiheit, Diskussionspapier: Large Language Models und personenbezogene Daten, 2024, https://datenschutz-hamburg.de/fileadmin/user_upload/HmbBfDI/Datenschutz/Informationen/240715_Diskussionspapier_HmbBfDI_KI_Modelle.pdf

12. Garante per la protezione dei dati personali, ChatGPT, il Garante privacy chiude l'istruttoria, 20. Dezember 2024, mit dem Hinweis auf das Urteil des Gerichts in Rom Nr. 4153/2026, veröffentlicht am 18. März 2026, https://www.garanteprivacy.it/home/docweb/-/docweb-display/docweb/10085432

13. Thanh Tam Nguyen, Thanh Trung Huynh, Zhao Ren, Phi Le Nguyen und andere, A Survey of Machine Unlearning, arXiv, 2022, https://arxiv.org/abs/2209.02299

14. Lucas Bourtoule, Varun Chandrasekaran, Christopher A. Choquette-Choo, Hengrui Jia und andere, Machine Unlearning, arXiv, 2019, https://arxiv.org/abs/1912.03817

15. Pang Wei Koh und Percy Liang, Understanding Black-box Predictions via Influence Functions, arXiv, 2017, https://arxiv.org/abs/1703.04730

16. Chuan Guo, Tom Goldstein, Awni Hannun und Laurens van der Maaten, Certified Data Removal from Machine Learning Models, arXiv, 2019, https://arxiv.org/abs/1911.03030

17. Laura Graves, Vineel Nagisetty und Vijay Ganesh, Amnesiac Machine Learning, arXiv, 2020, https://arxiv.org/abs/2010.10981

18. Latanya Sweeney, k-anonymity: a model for protecting privacy, International Journal on Uncertainty, Fuzziness and Knowledge-based Systems, 10(5), 2002, https://dataprivacylab.org/dataprivacy/projects/kanonymity/kanonymity.pdf

19. Europäisches Parlament und Rat, Verordnung (EU) 2024/1689 (Verordnung über künstliche Intelligenz), Artikel 11 und Anhang IV Nummer 2 Buchstabe d, Amtsblatt der Europäischen Union, 12. Juli 2024, EUR Lex, https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=OJ:L_202401689

20. Europäisches Parlament und Rat, Verordnung (EU) 2026/1744 (Digital Omnibus zur KI), Artikel 1 Nummern 6 und 40, zur Änderung der Verordnung (EU) 2024/1689, Amtsblatt der Europäischen Union, 24. Juli 2026, EUR Lex, https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=OJ:L_202601744