Gelöscht ist nicht vergessen. Jedenfalls nicht, wenn die Daten vorher zum Training eines KI-Modells genutzt wurden. Die geplante KI-Nutzung echter Steuerdaten durch Finanzbehörden zeigt ein Grundproblem fast jedes professionellen KI-Projekts: Was bedeutet Löschen, wenn Daten ins Modell eingelernt wurden?
Ein Modell enthält keine Tabelle der Trainingsdaten. Es enthält keine Akte, die man entfernen kann. Stattdessen kondensiert das Training statistische Zusammenhänge in Millionen von Parametern. Die klassische Frage der Datenhaltung, wie lange darf ein Datensatz im System bleiben, ist damit beantwortet. Die eigentliche KI-Frage nicht: ob und in welcher Form Informationen aus diesen Daten bereits in das trainierte Modell eingeflossen sind.
Genau hier beginnt die eigentliche Debatte.
Der aktuelle Anlass: KI-Training mit echten Steuerdaten
Das Jahressteuergesetz 2026 enthält einen bemerkenswerten Baustein: Die Finanzverwaltung soll personenbezogene Daten künftig ausdrücklich für die Entwicklung, Überprüfung oder Änderung automatisierter Verfahren verwenden dürfen. Der Entwurf bezieht dabei auch KI-Systeme der Finanzbehörden ein. Vorgesehen ist dies unter anderem dann, wenn unveränderte Daten benötigt werden oder eine Anonymisierung beziehungsweise Pseudonymisierung nicht oder nur mit unverhältnismäßigem Aufwand möglich ist. In diesen Fällen sollen personenbezogene Daten innerhalb eines Jahres nach Beendigung der jeweiligen Maßnahmen gelöscht werden. Siehe dazu den Referentenentwurf des Bundesministeriums der Finanzen zum Jahressteuergesetz 2026.
Heise hat diesen Punkt unter der Überschrift „Finanzamt 2.0” aufgegriffen und zugespitzt: Steuerbehörden sollen KI mit echten Bürgerdaten trainieren dürfen. Die vorgesehene Schutzmaßnahme: eine Löschfrist nach einem Jahr. Siehe dazu den Beitrag „Finanzamt 2.0: Steuerbehörden sollen KI mit echten Bürgerdaten trainieren”.
Diese Löschfrist ist wichtig. Sie setzt eine zeitliche Grenze für die Nutzung personenbezogener Daten in Entwicklungs-, Prüf- oder Änderungsprozessen. Sie adressiert aber vor allem ein klassisches Datenhaltungsproblem: Wie lange dürfen personenbezogene Daten in Systemen gespeichert werden?
Die eigentliche KI-Frage liegt eine Ebene tiefer:
Was bedeutet Löschen, wenn Daten nicht nur gespeichert, sondern zum Lernen verwendet wurden?
Ein KI-Modell ist keine normale Datenbank
Bei klassischen IT-Systemen ist das Grundprinzip vergleichsweise klar. Ein Datensatz liegt in einer Datenbank, einem Dokumentenarchiv oder einem Dateisystem. Wird er gelöscht, ist er technisch sauber umgesetzt aus diesem System entfernt.
Bei KI-Modellen ist die Lage komplizierter. Ein trainiertes Modell enthält den ursprünglichen Trainingsdatensatz nicht einfach als Tabelle. Es speichert keine Excel-Liste mit Steuerfällen, Kundennamen oder Gehaltsdaten. Stattdessen werden während des Trainings statistische Zusammenhänge in Modellparametern abgebildet.
Das klingt zunächst beruhigend. Ist es aber nur teilweise.
Denn je nach Modelltyp, Trainingsverfahren, Datenqualität, Wiederholungen im Trainingsbestand, Einzigartigkeit einzelner Fälle und späterem Zugriff auf das Modell können Informationen aus Trainingsdaten im Modell fortwirken. Nicht unbedingt als vollständig rekonstruierbarer Datensatz, aber als Muster, Fragment, Wahrscheinlichkeit oder im ungünstigen Fall als nahezu wortgetreue Wiedergabe.
Das Risiko lautet also nicht: „Jedes KI-Modell speichert automatisch personenbezogene Daten.”
Die präzisere Aussage lautet: „Ein KI-Modell kann unter bestimmten Bedingungen personenbezogene Informationen oder charakteristische Muster aus Trainingsdaten so aufnehmen, dass sie später ableitbar, testbar oder extrahierbar werden.”
An dieser Stelle reicht die Frage „Wann löschen wir die Originaldaten?” nicht aus. Vorab muss geklärt werden: Was darf das Modell überhaupt lernen?
Zwar wird unter dem Begriff „Machine Unlearning” daran geforscht, den Einfluss einzelner Trainingsdaten nachträglich aus Modellen zu entfernen. In der Praxis ist das aber nicht mit dem Löschen eines Datenbankeintrags vergleichbar. Je nach Modelltyp kann Unlearning rechenaufwändig, nur approximativ, schwer überprüfbar oder wirtschaftlich kaum darstellbar sein. Häufig bleibt als verlässliche Referenz das erneute Training eines Modells ohne die betroffenen Daten. Genau deshalb sollte Datenschutz beim KI-Training nicht erst beim nachträglichen Entfernen beginnen.
Von persistentem Gedächtnis zur Modellwirkung
Das KI-Syndikat hat am Beispiel persistenter KI-Assistenten gezeigt, dass KI-Gedächtnis eine Frage von Kontrolle, Eigentum und Governance ist, weit jenseits einer reinen Komfortfunktion. Unternehmenswissen kann in Assistenten-Memory, Nutzerkontexten oder Anbieterumgebungen entstehen und sich damit klassischen Unternehmenssystemen entziehen. Siehe dazu den Beitrag „Wenn die KI sich erinnert, gehört das Wissen plötzlich nicht mehr dem Unternehmen” von Prof. Dr. Daniel Sonnet.
Beim Training mit personenbezogenen Daten stellt sich eine verwandte, aber noch grundsätzlichere Frage: Was passiert mit Informationen, wenn sie tief in ein Modell eingelernt werden, statt nur in einem Assistenten zwischengespeichert zu sein?
Memory betrifft das, was eine KI über Nutzungskontexte behält. Training betrifft das, was eine KI aus Daten lernt.
Beides verlangt Kontrolle. Aber beim Training ist die Kontrolle schwieriger, weil sich der Einfluss einzelner Datenpunkte nicht mehr so einfach isolieren lässt wie ein Eintrag in einer Datenbank.
Drei Risiken, die Löschfristen allein nicht lösen
Drei technische Risikoklassen zeigen, warum Löschfristen zu kurz greifen: Memorization, Membership Inference und Model-Inversion-Angriffe.
Wichtig ist dabei die Grenzziehung: Die anschaulichsten Beispiele für extrahierte Trainingsdaten stammen häufig aus Large Language Models, weil dort memorisierte Textpassagen sichtbar ausgegeben werden können. Der Steuerdaten-Kontext betrifft eher strukturierte Daten, Klassifikation und Anomalieerkennung. Die Risiken verschwinden dadurch nicht, sie zeigen sich nur anders: weniger als wortgetreue Textausgabe, stärker als Rückschluss auf Zugehörigkeit zum Trainingsbestand oder Modellreaktionen auf gezielte Abfragen.
1. Memorization: Wenn Modelle mehr behalten als gewünscht
Memorization bedeutet: Ein Modell lernt keine allgemeinen Muster mehr, sondern übernimmt einzelne Trainingsbeispiele oder Fragmente davon ungewöhnlich stark.
Das kann besonders dann passieren, wenn Daten mehrfach vorkommen, selten sind, stark herausstechen oder für das Modell besonders prägnant wirken. In Sprachmodellen können das ungewöhnliche Textpassagen, personenbezogene Kontaktdaten, Codefragmente, UUIDs oder andere eindeutige Sequenzen sein. In strukturierten Daten können es seltene Fallkonstellationen, Ausreißer oder ungewöhnliche Merkmalskombinationen sein.
Carlini et al. zeigten bereits bei GPT-2, dass sich einzelne Trainingsbeispiele durch Modellabfragen extrahieren ließen. Darunter waren auch personenbezogene Informationen wie Namen, Telefonnummern und E-Mail-Adressen. Siehe „Extracting Training Data from Large Language Models”.
Spätere Forschung zu produktionsnahen Sprachmodellen zeigte, dass solche Risiken nicht nur theoretisch ältere Modelle betreffen. Nasr et al. untersuchten extrahierbare Memorization auch bei offenen, halb-offenen und geschlossenen Modellen und beschrieben unter anderem Angriffe, bei denen Modelle aus ihrem normalen Antwortverhalten herausgebracht wurden. Die Autoren kamen zu dem Ergebnis, dass Alignment Memorization nicht automatisch beseitigt. Siehe „Scalable Extraction of Training Data from (Production) Language Models”.
Auch Code-Modelle sind betroffen: Niu et al. untersuchten Privacy-Leaks aus Code-Generierungsmodellen im Umfeld früher GitHub-Copilot-Versionen und zeigten, dass sensible personenbezogene Informationen aus Code-Kontexten eine eigene Risikoklasse darstellen können. Siehe „CodexLeaks: Privacy Leaks from Code Generation Language Models in GitHub Copilot”.
Für Steuerdaten, Gesundheitsdaten, HR-Daten oder Compliance-Daten ist dieser Punkt zentral. Gerade seltene, eindeutige oder wirtschaftlich auffällige Fälle können besonders sensibel sein. Ein außergewöhnlicher Steuerfall, eine seltene Unternehmensstruktur oder eine ungewöhnliche Einkommenskonstellation ist nicht nur ein Datenpunkt. Er kann ein identifizierbares Muster sein.
2. Membership Inference: War dieser Fall im Trainingsbestand?
Membership Inference verfolgt ein anderes Ziel. Hier versucht ein Angreifer nicht zwingend, den ursprünglichen Datensatz vollständig zu rekonstruieren. Es reicht die Frage:
War diese Person, dieser Fall oder dieser Datensatz Teil des Trainingsbestands?
Schon diese Information kann sensibel sein.
Bei medizinischen Daten kann die Zugehörigkeit zu einem Trainingsdatensatz Rückschlüsse auf eine Erkrankung ermöglichen. Bei HR-Daten kann sie Rückschlüsse auf interne Konflikte, Bewerbungen oder Leistungsbewertungen erlauben. Bei Steuerdaten kann bereits die Frage, ob ein bestimmter Fall in einem Prüf-, Trainings- oder Risikodatensatz enthalten war, eine vertrauliche Information darstellen.
Shokri et al. haben Membership-Inference-Angriffe gegen Machine-Learning-Modelle untersucht. Im Grundmodell erhält ein Angreifer Black-Box-Zugriff auf ein Modell und versucht anhand der Modellantworten zu erkennen, ob ein bestimmter Datensatz im Training enthalten war. Siehe „Membership Inference Attacks against Machine Learning Models”.
Das ist für Unternehmen besonders wichtig, weil viele KI-Systeme über Schnittstellen oder interne Anwendungen zugänglich gemacht werden. Der Schutzbedarf endet nicht bei der Datenbank. Er reicht bis zur Frage, welche Rückschlüsse das fertige System durch seine Antworten ermöglicht.
3. Rekonstruktion und Model Inversion: Wenn Antworten Merkmale verraten
Bei Rekonstruktions- oder Model-Inversion-Angriffen leitet der Angreifer aus Modellantworten, Wahrscheinlichkeiten, Confidence Scores oder wiederholten Abfragen Informationen über Trainingsdaten oder sensible Merkmale ab.
Das kann je nach System sehr unterschiedlich aussehen. Bei Klassifikationsmodellen können Confidence-Werte ausgenutzt werden. Bei generativen Modellen können wiederholte oder gezielt gestaltete Prompts dazu führen, dass memorisierte Fragmente ausgegeben werden. Bei Modellen auf Personen-, Bild- oder Profildaten kann das Ziel sein, erkennbare Merkmale oder Repräsentationen zu rekonstruieren.
Fredrikson et al. zeigten, dass sich aus Modellzugriff und Confidence-Ausgaben sensible Merkmale ableiten lassen. Siehe „Model Inversion Attacks that Exploit Confidence Information”.
Der entscheidende Punkt: Der Angriff erfolgt nicht auf die ursprüngliche Datenbank, sondern auf das Modell.
Damit verschiebt sich der Datenschutzfokus. Es genügt nicht mehr, nur Datenspeicher, Backups und Zugriffskonten abzusichern. Auch Modellverhalten, Schnittstellen, Antwortformate, Protokollierung und Missbrauchserkennung werden Teil des Datenschutzkonzepts.
Was diese Beispiele gemeinsam zeigen
Die genannten Arbeiten stammen aus unterschiedlichen Modellwelten. Sie zeigen nicht, dass jedes KI-Modell automatisch personenbezogene Daten preisgibt. Sie zeigen aber, dass Datenschutzrisiken im trainierten Modell und im späteren Antwortverhalten entstehen, genauso wie in der ursprünglichen Datenbank.
Für die Praxis reicht diese Erkenntnis aus: Datenschutz beim KI-Training darf nicht erst bei der Löschung der Quelldaten beginnen. Er muss bereits vor dem Training ansetzen.
Warum die Löschfrist notwendig, aber nicht ausreichend ist
Die vorgesehene Löschfrist im Steuerdaten-Kontext ist ein sinnvoller Baustein. Sie setzt eine zeitliche Grenze für die Nutzung personenbezogener Daten im Entwicklungs-, Prüf- oder Änderungsprozess. Der Referentenentwurf macht zugleich deutlich, dass KI-Systeme der Finanzbehörden unter bestimmten Voraussetzungen auch im fortlaufenden Betrieb auf personenbezogene Daten angewiesen sein können, wenn sie sonst ihre Funktionsfähigkeit verlieren oder geeignete Testfälle nicht mit verhältnismäßigem Aufwand geschaffen werden können.
Das ist rechtlich relevant. Es beantwortet aber nicht die technische Modellfrage.
Wenn ein Modell während des Trainings personenbezogene Muster oder einzelne Fragmente übernommen hat, verschwinden diese Effekte nicht dadurch, dass die Quelldaten nachträglich gelöscht werden. Das Modell ist kein Archivordner, aus dem man eine Akte entfernt.
Damit wird auch die datenschutzrechtliche Bewertung anspruchsvoller. Der Europäische Datenschutzausschuss hat in seiner Opinion 28/2024 klargestellt, dass KI-Modelle, die mit personenbezogenen Daten trainiert wurden, nicht pauschal als anonym gelten können. Entscheidend ist vielmehr eine Einzelfallprüfung, insbesondere ob personenbezogene Informationen mit realistisch einsetzbaren Mitteln aus dem Modell gewonnen werden können. Siehe EDPB Opinion 28/2024.
Die praktische Konsequenz lautet: Löschung ist ein notwendiges Element. Aber Datenschutz beim KI-Training beginnt vor der Löschung: bei Datenauswahl, Trainingsdesign, Schutzmaßnahmen, Tests und Governance.
Was vor dem Training geklärt werden muss
Aus den technischen Risiken ergeben sich konkrete Schutzmaßnahmen. Kein nachträgliches Compliance-Häkchen, sondern Bestandteil der Systemarchitektur.
Datenminimierung und Trainingsdatenhygiene
Der erste Schutz ist banal, aber wirksam: Nicht jede verfügbare Information gehört in einen Trainingsdatensatz. Vor dem Training muss das Team klären, welche Daten wirklich benötigt werden, welche Identifikatoren entfernbar sind und welche Ausreißer fachlich notwendig, aber datenschutzrechtlich sensibel sind.
Datenminimierung ist im KI-Kontext kein formaler DSGVO-Grundsatz am Rand. Sie ist ein technischer Schutz gegen Memorization.
Synthetische Daten: hilfreich, aber kein Freifahrtschein
Synthetische Daten können ein sinnvoller Baustein sein. Die Idee: Ein Verfahren erzeugt künstliche Datensätze, die statistische Eigenschaften echter Daten nachbilden, ohne reale Personen direkt abzubilden.
Das kann Datenschutzrisiken deutlich reduzieren. Aber synthetische Daten sind nicht automatisch anonym und nicht automatisch risikofrei.
Der EDPS beschreibt synthetische Daten als künstlich erzeugte Datensätze, die statistische Eigenschaften der Originaldaten nachbilden. Zugleich weist der EDPS darauf hin, dass eine Privacy-Assurance-Bewertung erforderlich ist, um zu prüfen, ob Personen in synthetischen Daten identifiziert werden können. Siehe EDPS TechSonar: Synthetic Data.
Für Steuerdaten ist das besonders relevant. Komplexe, seltene oder wirtschaftlich auffällige Fälle sind für die Qualität eines KI-Systems möglicherweise wichtig. Gleichzeitig sind genau diese Fälle besonders identifizierbar. Synthetische Daten können also helfen, müssen aber selbst auf Qualität, Verzerrungen, Nähe zu Originaldaten und Re-Identifikationsrisiken geprüft werden.
Differential Privacy: Mathematischer Schutz mit Zielkonflikt
Differential Privacy ist einer der stärksten technischen Ansätze, um den Einfluss einzelner Personen oder Datensätze auf ein Modell zu begrenzen.
Vereinfacht gesagt wird während des Trainings mathematisches Rauschen eingebaut. Bei DP-SGD werden Gradienten begrenzt und verrauscht, bevor Modellparameter aktualisiert werden. Dadurch soll verhindert werden, dass ein einzelner Trainingsdatensatz einen zu starken, später erkennbaren Einfluss auf das Modell erhält. Siehe NIST: „How to deploy machine learning with differential privacy”.
Differential Privacy ist allerdings kein Zauberstab. Je stärker der Privatsphärenschutz, desto größer kann der Verlust an Modellgenauigkeit sein. An diesem Punkt gehört Differential Privacy in die Governance eines KI-Projekts, nicht nur in die technische Debatte. Das Projektteam muss entscheiden und dokumentieren: Welches Schutzniveau ist angemessen, und welche fachlichen Einbußen sind akzeptabel?
Zugriffskonzepte und Betriebsüberwachung
Selbst wenn ein Modell sauber trainiert wurde, bleibt der Betrieb kritisch.
Relevante Fragen: Wer darf das Modell abfragen? Welche Antworten gibt das System aus? Werden Confidence Scores angezeigt? Gibt es Rate Limits? Werden ungewöhnliche Abfragemuster erkannt?
Bei klassischen Anwendungen denkt man bei Zugriffsschutz an Login und Rollenkonzepte. Bei KI-Systemen kommt eine zusätzliche Ebene hinzu: Auch scheinbar berechtigte Nutzer können durch systematische Abfragen Informationen extrahieren, die nicht für sie bestimmt sind. Deshalb gehören Red-Teaming, Missbrauchserkennung und Protokollierung zum Datenschutzkonzept.
Datenschutz-Folgenabschätzung und Dokumentation
Wenn personenbezogene Daten in großem Umfang, mit sensiblen Inhalten oder für KI-Training verarbeitet werden, ist eine Datenschutz-Folgenabschätzung in vielen Konstellationen erforderlich. Die französische Datenschutzaufsicht CNIL beschreibt die Datenschutz-Folgenabschätzung als Instrument, um Risiken für Rechte und Freiheiten natürlicher Personen zu bewerten und geeignete Maßnahmen vorzusehen. Siehe CNIL: Carrying out a data protection impact assessment if necessary.
Eine solche Bewertung muss den gesamten Modelllebenszyklus betrachten: Zweck und Rechtsgrundlage, Datenauswahl, Trainingsverfahren, Tests auf Memorization und Extraktion, Zugriffskonzepte, Löschfristen und Umgang mit Betroffenenrechten.
Warum das nicht nur ein Behördenproblem ist
Der Fall der Steuerbehörden ist prominent, aber kein Sonderfall. In der Beratung mittelständischer Unternehmen kenne ich das Muster: Der Wunsch nach KI entsteht dort, wo über Jahre gewachsene Datenbestände plötzlich nutzbar werden sollen: Supporttickets, CRM-Einträge, Rechnungen, Vertragsdaten.
Bei der Finanzverwaltung geht es um Steuerdaten und staatliche Verarbeitung. Im Unternehmen geht es vielleicht um Kundenkommunikation, Gesundheitsdaten im Beschäftigtenkontext oder Geschäftsgeheimnisse.
Die Grundfrage bleibt dieselbe: Welche Daten dürfen in ein KI-System fließen, und was passiert mit ihrem Einfluss auf das Modell?
Hier verläuft die Grenze zwischen experimenteller und professioneller KI-Nutzung. Letztere basiert auf einer systematischen Vorab-Klärung: Welche Aufgabe soll das System lösen? Welche Daten sind dafür wirklich erforderlich? Welche Schutzmaßnahmen greifen vor dem Training?
Fazit: KI braucht nicht nur Daten, sondern Ordnung
Die geplante Löschfrist im Steuerdaten-Kontext ist ein wichtiger Schutzmechanismus, aber sie beantwortet nicht die gesamte Frage.
Bei KI-Systemen reicht der alleinige Blick auf Speicherorte und Löschfristen nicht aus. Entscheidend ist auch, wie Daten in Modelle einfließen, ob einzelne Informationen memorisiert werden können, welche Rückschlüsse das Modell später erlaubt und wie der Betrieb kontrolliert wird.
Eine Löschfrist allein reicht nicht. Es braucht eine Vorab-Entscheidung: welche Daten ein Modell lernen darf, wie stark einzelne Datenpunkte wirken dürfen und wie sich das fertige System später prüfen lässt.
Das bedeutet: Datenschutz, Technik und Governance gehören an den Anfang des Projekts, nicht ans Ende. Bei der Datenauswahl, beim Trainingsdesign, bei den Zugriffskonzepten.
Gelöscht ist nicht vergessen. Ein Modell, das mit sensiblen Daten lernt, muss von Anfang an so gebaut werden, dass es nicht mehr preisgibt, als es soll. Vertrauen ist nicht der Gegenpol zur digitalen Transformation. Vertrauen ist ihre Voraussetzung.