Fine-Tuning mit den eigenen Daten: Warum „Wir hosten es selbst“ die falsche Hälfte des DSGVO-Problems löst

KERNTHESE Das Selbst-Hosting eines KI-Modells kann einen Großteil der Drittlandübermittlungs-Exposition entfernen — abhängig davon, wo Infrastruktur, Support-Zugriff, Telemetrie und Unterauftragsverarbeiter tatsächlich sitzen — aber es lässt das schwierigere Problem bestehen: Training ist keine vorübergehende Nutzung personenbezogener Daten — es ist ihre Einverleibung in die Gewichte des Modells, die derzeit schwer, kostspielig und oft unzuverlässig rückgängig zu machen ist, wobei die Löschung auf Anfrage von unverhältnismäßig teuer bis, in der Praxis, noch nicht verlässlich erreichbar reicht. Berechtigtes Interesse kann eine solche Verarbeitung tragen, aber nur als Schlussfolgerung eines dreistufigen Tests, für den der EDSA bewusst eine hohe Hürde setzt — nie als Voreinstellung. Die Rechtsgrundlage, der Löschpfad und die Folgenabschätzung gehören alle vor den ersten Trainingslauf, nicht danach.

Es gibt eine Frage, die Organisationen selten stellen, bevor sie ein KI-Modell mit ihren eigenen Daten trainieren, und es ist eine andere Frage als die, die sie zu Prompts stellen. Personenbezogene Daten in einen Chatbot einzutippen ist eine vorübergehende Interaktion, die der Anbieter speichern kann oder nicht — und in einem wichtigen Sinne ist sie wiederherstellbar: Ein gespeicherter Prompt kann gelöscht, ein Vertrag neu verhandelt, ein Werkzeug abgeschaltet werden. Ein Modell mit personenbezogenen Daten zu trainieren ist ein Problem ohne Rückgängig-Schaltfläche.

Eine Organisation, die ich berate, hatte die Stufe erreicht, die viele 2026 erreichen. Die Exposition auf der kostenlosen Ebene war geschlossen, ein Enterprise-Vertrag bestand, und das Team war ehrgeizig geworden. Der Vorschlag auf dem Tisch war, ein Open-Weights-Modell — vollständig auf der eigenen Infrastruktur der Organisation gehostet, innerhalb der EU, nie einen US-Anbieter berührend — mit mehreren Jahren interner Aufzeichnungen feinabzustimmen: Support-Tickets, HR-Fallnotizen, Leistungsbeurteilungen, Kundenkorrespondenz. Das Argument war elegant und auf den ersten Blick schwer zu widerlegen. „Alles bleibt im Haus. Keine Daten verlassen unsere Server. Kein amerikanisches Unternehmen kann sie berühren. Dies ist die datenschutzwahrende Option.” Die Foliensammlung nannte es „DSGVO durch Architektur”.

Es war zur Hälfte richtig, und die Hälfte, die es falsch verstand, ist die Hälfte, die mehr zählt. Selbst-Hosting adressiert eine echte und ernste Frage — die gerichtsbarkeitsbezogene, die CLOUD-Act- und FISA-702-Übermittlungsexposition, die mit jedem US-kontrollierten Anbieter einhergeht — auch wenn selbst das nur insoweit gilt, als die Infrastruktur, der Support-Zugriff, die Telemetrie und etwaige Unterauftragsverarbeiter wirklich außerhalb der US-Reichweite liegen. Aber es adressiert diese Frage und nimmt dann stillschweigend an, alle anderen beantwortet zu haben. Es hat die Rechtsgrundlagenfrage nicht berührt — auf welchem rechtmäßigen Grund werden jahrelange personenbezogene Daten von Beschäftigten und Kunden zu einem völlig neuen Zweck verarbeitet? Und es ist direkt in eine Frage hineingelaufen, die das Selbst-Hosting tatsächlich schlimmer macht, nicht besser: Wenn eine dieser Beschäftigten oder Kundinnen später ihr Recht auf Löschung ausübt, kann die Organisation dem nachkommen — oder hat sie ihre personenbezogenen Daten in die Gewichte eines Modells eingebacken, wo sie nun in einer Form leben, die schwer, kostspielig und oft unzuverlässig zu entfernen ist?

Falls das abstrakt klingt, betrachten Sie, was dem weltweit größten Betreiber eines generativen Modells widerfuhr, als die Frage der Löschung aufhörte, theoretisch zu sein. In dem von The New York Times angestrengten Urheberrechtsstreit ordnete eine bundesstaatliche Magistratsrichterin OpenAI am 13. Mai 2025 an, alle ChatGPT-Ausgabeprotokolle, die andernfalls gelöscht worden wären, aufzubewahren und zu separieren — einschließlich der Chats, die Nutzer selbst gelöscht hatten, und Inhalte aus „temporären” Sitzungen, die OpenAIs eigene Richtlinie normalerweise innerhalb von dreißig Tagen löschen würde.¹ OpenAI focht die Anordnung an, die Führung nannte sie einen direkten Konflikt mit den Datenschutzverpflichtungen des Unternehmens und mit der DSGVO; die Anfechtung wurde abgelehnt, und die Aufbewahrungspflicht blieb bis Ende September 2025 in Kraft, woraufhin die Herausgabe von rund 20 Millionen anonymisierten Protokollen an die Kläger angeordnet wurde.² Die Episode ist eine nahezu perfekte Umkehrung des Löschproblems, um das es in diesem Artikel geht — ein Gericht, das die Daten zur Aufbewahrung zwingt, statt einer betroffenen Person, die ihre Entfernung verlangt — aber sie macht denselben zugrunde liegenden Punkt mit ungewöhnlicher Klarheit: Die Frage, was ein KI-System löschen kann und was nicht und wer das tatsächlich kontrolliert, ist keine Fußnote. Um präzise zu sein, was sie zeigt und was nicht: Sie ist kein Beweis dafür, dass die Gewichte des Modells diese Protokolle enthalten — es geht um gespeicherte Interaktionsprotokolle, nicht um die trainierten Parameter. Was sie zeigt, ist, dass KI-Datenlebenszyklen nicht vollständig durch die nutzerseitige „Löschen”-Schaltfläche bestimmt werden — und wenn ein Gericht die Löschung von Protokollen außer Kraft setzen kann, ist die schwierigere Frage der Löschung aus den Gewichten ebenso wenig eine, die eine Organisation als von ihr kontrolliert annehmen sollte. Sie wird nun auf höchster Ebene verhandelt, und die Antworten sind häufig unbequem für die Organisation, die dachte, sie habe die Kontrolle über ihre eigenen Daten.

Ein Detail von OpenAIs Reaktion ist für den Rest dieses Artikels von Bedeutung. OpenAI war sorgfältig zu erklären, dass ChatGPT Enterprise und seine Zero-Data-Retention-API von der Aufbewahrungsanordnung ausgenommen waren und dass es Geschäftsdaten nicht standardmäßig zum Training verwendet.³ Das ist die Enterprise-/Verbraucher-Unterscheidung, die in einem realen Gerichtssaal echte Arbeit leistet: Die vertragliche Oberfläche, die ein Verantwortlicher wählt, bestimmt konkret, ob seine Daten in eine Beweismittelanordnung hineingezogen werden. Aber beachten Sie, was selbst dieser Schutz nicht berührt — das Modell, das bereits trainiert wurde. Eine Aufbewahrungsanordnung betrifft Protokolle; die Löschung aus den Gewichten ist ein anderes und schwierigeres Problem, und es ist dasjenige, das eine selbst-hostende Organisation auf die eigenen Bücher nimmt.

Die Frage, die dieser Artikel beantwortet, ist die, die die elegante Foliensammlung nie erreichte: nicht „Wo läuft das Modell?”, sondern „Können Sie eine Person daraus löschen?” Alles Folgende ist ein Versuch, diese Frage ernst zu nehmen, weil die DSGVO es tut.

Training ist keine Nutzung — es ist eine Einverleibung

Der konzeptionelle Fehler unter „DSGVO durch Architektur” ist, Training so zu behandeln, als wäre es eine Verarbeitung derselben Art wie das Abfragen. Das ist es nicht. Wenn Sie einen Prompt an ein Modell senden, werden die personenbezogenen Daten im Prompt für die Dauer der Anfrage vorübergehend verarbeitet; auf einer ordnungsgemäß vertraglich geregelten Enterprise-Ebene unterliegen sie dann Aufbewahrungsregeln und können im Prinzip gelöscht werden. Wenn Sie ein Modell mit personenbezogenen Daten trainieren oder feinabstimmen, geschieht etwas kategorisch anderes: Die Muster in diesen Daten werden in die Parameter des Modells codiert — Milliarden numerischer Gewichte — und die Daten hören auf, als diskrete, adressierbare Datensätze zu existieren.⁴

Dies ist keine Metapher. Der Europäische Datenschutzausschuss lehnte es in der Stellungnahme 28/2024 ab, trainierte Modelle automatisch als anonym zu behandeln, genau aus diesem Grund: Ein mit personenbezogenen Daten trainiertes KI-Modell kann nicht in allen Fällen als anonym angesehen werden, und es qualifiziert sich nur dann als anonym, wenn der Verantwortliche mit Belegen nachweisen kann, dass die Wahrscheinlichkeit, personenbezogene Daten aus dem Modell zu extrahieren — direkt oder probabilistisch — und die Wahrscheinlichkeit, sie durch Abfragen zu erhalten, beide unbedeutend sind.⁵ Ein feinabgestimmtes Modell, das die Einzelheiten namentlich genannter Support-Tickets und namentlich genannter Leistungsbeurteilungen memoriert hat, nimmt diese Hürde nicht. Es ist, in der Formulierung des EDSA, ein Modell, das immer noch personenbezogene Daten enthält — nur in einer diffusen, verteilten, schwer erreichbaren Form.

Die Forschungsliteratur ist eindeutig darüber, was das für die Löschung bedeutet. Große Sprachmodelle memorieren nachweislich personenbezogene Daten aus ihrem Trainingskorpus und können sie wiedergeben — Namen, Adressen, Kontaktdaten, klinische Notizen — wörtlich oder annähernd.⁶ Und die Entfernung der Daten einer bestimmten Einzelperson, sobald sie in den Gewichten sind, ist im aktuellen Stand der Technik ein ungelöstes Problem, in optimistisches Vokabular gekleidet. Die verfügbaren Wege sind: vollständiges Neutraining von Grund auf mit ausgeschlossenen Daten der Einzelperson (definitiv, aber teuer und in jeder Kadenz unpraktisch); Machine-Unlearning-Techniken (aktive Forschung, noch nicht zuverlässig und schwer zu verifizieren); oder Ausgabefilterung, die die Erzeugung der Daten der gelöschten Person unterdrückt, ohne sie tatsächlich aus dem Modell zu entfernen.⁷ Kommentatoren haben die Konsequenz unverblümt formuliert: Das Löschen personenbezogener Daten aus dem Trainingssatz hat keine Wirkung auf ein bereits trainiertes Modell, weil es bisher keinen verlässlichen Weg gibt, ein trainiertes Modell vergessen zu lassen.⁸

Dies ist die Asymmetrie, die „DSGVO durch Architektur” gänzlich verfehlt. Die Daten im Haus zu behalten verbessert Ihre Kontrolle darüber, wo sie sind. Es tut nichts, um Ihre Fähigkeit zu verbessern, eine bestimmte Person daraus zu entfernen, sobald das Training stattgefunden hat. Ein selbst-gehostetes Modell ist kein datenschutzwahrendes Modell, weil es selbst-gehostet ist; es ist ein Modell, dessen Löschproblem nun auf Ihrer eigenen Bilanz sitzt statt auf der eines Anbieters.

Berechtigtes Interesse ist ein Test, kein Kontrollkästchen

Lassen Sie das Löschproblem einen Moment beiseite und stellen Sie die vorgelagerte Frage: Auf welcher Rechtsgrundlage verarbeitet die Organisation jahrelange personenbezogene Daten zum neuen Zweck des Modelltrainings? Nach Art. 6 DSGVO benötigt jede Verarbeitung eine Grundlage, und die Verarbeitung von Daten, die zu einem Zweck erhoben wurden (Betrieb eines Support-Desks, Verwaltung eines Beschäftigungsverhältnisses), zu einem wesentlich anderen Zweck (Training eines Modells) ist selbst eine Verarbeitung, die ihre eigene Rechtfertigung erfordert.

Für die meisten internen Trainingsszenarien ist die Einwilligung das falsche Werkzeug. Die Einwilligung von Beschäftigten ist wegen des Machtungleichgewichts im Beschäftigungsverhältnis vermutlich nicht freiwillig; rückwirkende Einwilligung von Tausenden früherer Kunden ist unpraktisch zu erlangen und, wo unter Druck erlangt, brüchig. Das drängt Verantwortliche zu Art. 6 Abs. 1 lit. f — berechtigtes Interesse. Der EDSA bestätigte in der Stellungnahme 28/2024, dass berechtigtes Interesse eine gültige Grundlage für die Verarbeitung sowohl bei der Entwicklung als auch beim Einsatz von KI-Modellen sein kann.⁹ Aber er bestätigte dies im selben Atemzug damit, klarzustellen, dass berechtigtes Interesse ausdrücklich keine Standardgrundlage ist und nur dann akzeptabel ist, wenn der Verantwortliche den strukturierten dreistufigen Test besteht, den der EDSA auf seinen Leitlinien 1/2024 aufbaute.¹⁰

Die drei Schritte sind es wert, präzise genannt zu werden, weil Organisationen in der Praxis den ersten durchführen und die anderen beiden überspringen.

Schritt eins — das Interesse muss legitim sein. Es muss rechtmäßig, klar und präzise artikuliert sowie real und gegenwärtig statt spekulativ sein.¹¹ „Wir könnten einige Effizienzgewinne finden” ist spekulativ; „wir werden die durchschnittliche Ticket-Bearbeitungszeit durch Routing auf historischen Mustern verringern” ist artikulierbar. Vagheit scheitert in Schritt eins.

Schritt zwei — Erforderlichkeit. Die Verarbeitung muss unbedingt erforderlich sein, das heißt, kein weniger eingriffsintensives Mittel würde dasselbe Interesse erreichen. Der EDSA setzt hier bewusst eine hohe Hürde in Bezug auf das Volumen der beteiligten personenbezogenen Daten.¹² Wenn das Trainingsziel mit einem kleineren, anonymisierten oder synthetischen Datensatz erreicht werden kann, dann ist die Verarbeitung des gesamten Korpus namentlich genannter Datensätze nicht erforderlich, und die Grundlage scheitert — unabhängig davon, wie legitim das zugrunde liegende Interesse ist. Hier brechen die meisten internen Trainingsvorschläge leise zusammen: „mit allem trainieren, was wir haben” ist selten das am wenigsten eingriffsintensive Mittel.

Schritt drei — Abwägung. Das Interesse des Verantwortlichen darf nicht von den Rechten, Freiheiten und vernünftigen Erwartungen der betroffenen Personen überwogen werden.¹³ Eine Beschäftigte, die eine Beschwerde einreichte, oder eine Kundin, die eine Reklamation mailte, erwartete vernünftigerweise nicht, dass dieser Text Jahre später zu Trainingsmaterial für ein Modell wird. Je weiter der neue Zweck von der ursprünglichen Erwartung entfernt sitzt, desto schwerer neigt sich die Abwägung gegen den Verantwortlichen — und wo berechtigtes Interesse herangezogen wird, muss das Widerspruchsrecht der betroffenen Person nach Art. 21 durchgehend verfügbar sein.¹⁴

Die eigenen Beispiele des EDSA für Interessen, die diesen Test überstehen können, sind in ihrer Enge aufschlussreich: ein Konversationsagent zur Unterstützung von Nutzern, ein KI-System zur Betrugserkennung, die Verbesserung der Bedrohungserkennung in einem Informationssystem.¹⁵ Diese teilen ein Merkmal — eine enge, nachweisbare Erforderlichkeitsverbindung zwischen den Daten und dem Zweck. „Ein allgemeines Modell mit all unseren historischen HR-Notizen feinabstimmen” hat keine solche enge Verbindung, und eine Abwägung des berechtigten Interesses, die etwas anderes vorgibt, ist eine Abwägung, geschrieben, um zu einer vorbestimmten Antwort zu gelangen.

Was Selbst-Hosting wirklich behebt — und was nicht

Nichts davon ist ein Argument gegen Selbst-Hosting. Selbst-Hosting ist für den richtigen Anwendungsfall die stärkste verfügbare Antwort auf das Drittlandübermittlungsproblem. Ein Modell, das auf von der Organisation kontrollierter Infrastruktur innerhalb der EU läuft, auf Hardware, die kein in den USA eingetragener Anbieter erreichen kann, entfernt die CLOUD-Act- und FISA-702-Exposition an der Wurzel. Das ist eine echte und wertvolle Eigenschaft, und für sensible Verarbeitung kann sie entscheidend sein.

Der Fehler liegt allein in der Substitution — darin, die gerichtsbarkeitsbezogene Behebung so zu behandeln, als hätte sie die anderen Pflichten erfüllt. Klar dargelegt sind die beiden Achsen unabhängig:

Frage	Was Selbst-Hosting ändert	Was Ihr Problem bleibt
Kann eine US-Behörde die Offenlegung der Daten erzwingen?	Entfernt die Exposition — sofern es wirklich keine US-kontrollierte Stelle oder Infrastruktur irgendwo in der Kette gibt	Nichts, wenn die Kette wirklich frei von US-erreichbaren Parteien ist
Gibt es eine Rechtsgrundlage für das Training mit diesen Daten?	Nichts — der Test nach Art. 6 / berechtigtem Interesse ist davon unberührt, wo das Modell läuft	Die vollständige dreistufige Abwägung, genau wie zuvor
Können wir ein Löschersuchen nach dem Training erfüllen?	Nichts — und die Last wächst wohl, weil die Pflicht nun bei Ihnen liegt, nicht bei einem Anbieter	Ein verifizierbarer Löschpfad, den Sie selbst bauen müssen
Ist eine DSFA erforderlich?	Nichts — Verarbeitung mit hohem Risiko löst Art. 35 unabhängig vom Hosting aus	Die DSFA, vollständig

Das Recht auf Löschung nach Art. 17 verdient hier eine besondere Anmerkung, weil das Selbst-Hosting-Team angenommen hatte, es sei seine Stärke. Die Begründung war: „Wir halten die Daten, also können wir sie löschen.” Das gilt für die Quelldatensätze und ist falsch für das Modell. Das Löschen des ursprünglichen Support-Tickets entfernt nicht, was das Modell daraus gelernt hat. EU-Leitlinien erkennen unter Art. 17 eine Dimension der technischen Unmöglichkeit und des unverhältnismäßigen Aufwands an — aber sie geben Verantwortlichen keine pauschale Ausrede. Die Erwartung ist, dass eine Organisation nachweisen können muss, dass sie vernünftige technische Alternativen (Unlearning, Neutraining, robuste Ausgabefilterung mit Verifizierung) geprüft hat, bevor sie behauptet, die Löschung aus dem Modell sei undurchführbar.¹⁶ „Wir können nicht, weil neuronale Netze so funktionieren” ist für sich genommen keine konforme Antwort; es ist der Anfang einer Bewertung, die der Verantwortliche im Voraus durchgeführt haben sollte.

Ein Belastungstest: das Löschersuchen, das nach dem Training eintrifft

Setzen Sie die Abstraktion unter Last. Achtzehn Monate, nachdem das Fine-Tuning ausgeliefert wurde, sendet ein ehemaliger Beschäftigter — derjenige, der eine Beschwerde einreichte, die in den HR-Fallnotizen lag — ein schriftliches Löschersuchen nach Art. 17. Er möchte jede Spur seiner personenbezogenen Daten entfernt haben. Die Organisation löscht das Quell-Ticket binnen Minuten aus ihrer Datenbank; dieser Teil ist wirklich einfach. Dann stellt die Datenschutzbeauftragte die schwierigere Frage: Sind die Daten dieser Person noch im Modell?

Hier gehen die bequemen Antworten eine nach der anderen aus. Das Team kann nicht einfach behaupten, das Modell sei anonym — unter der Stellungnahme 28/2024 erfordert das den Nachweis mit Belegen, dass Extraktions- und Abfrage-Leckage-Wahrscheinlichkeiten beide unbedeutend sind, und ein Fine-Tuning, das namentlich genannte HR-Notizen memorierte, wird Mühe haben, das zu zeigen. Sie können sich nicht stillschweigend auf einen Ausgabefilter verlassen, der den Namen unterdrückt, weil Unterdrückung keine Entfernung ist und eine Aufsichtsbehörde, die die Angelegenheit prüft, das sagen wird. Sie können nicht glaubhaft die „technische Unmöglichkeit” nach Art. 17 Abs. 3 anrufen, sofern sie nicht zeigen können, dass sie Unlearning, Neutraining und Verifizierung vor dem Eintreffen dieses Ersuchens geprüft haben — und das haben sie nicht, weil die Foliensammlung bei „DSGVO durch Architektur” aufhörte. Das einzige vollständig verteidigungsfähige Mittel, das bleibt, ist, das Modell ohne die Daten dieser Einzelperson von Grund auf neu zu trainieren, zu den Kosten und Ausfallzeiten, die das impliziert, jedes Mal, wenn ein solches Ersuchen eintrifft.

Dies ist der Moment, in dem die Schwierigkeit aufhört, eine theoretische Eigenschaft zu sein, und eine operative und finanzielle wird. Beachten Sie auch, dass das Selbst-Hosting dies schlimmer gemacht hat, nicht besser: Es gibt keinen Anbieter, der die Last teilt, keinen Auftragsverarbeiter, dessen Vertrag einen Teil der Pflicht absorbiert. Die Organisation, die sagte „alles bleibt im Haus”, besitzt nun auch das Löschproblem im Haus. Der Belastungstest ist der Beweis der These — der Zeitpunkt, „können wir eine Person aus diesem Modell löschen?” zu beantworten, war, bevor die Daten je in die Gewichte gelangten, weil danach die verbleibenden Antworten dazu neigen, eine Kombination aus teuer, schwer zu verifizieren oder rechtlich exponiert zu sein.

Die Reihenfolge der Schritte ist die ganze Disziplin

Alles Obige reduziert sich auf eine Abfolge, und die Abfolge ist der Punkt. Der Fehlermodus ist nie, dass eine Organisation am Ende zur falschen Schlussfolgerung gelangt — es ist, dass sie zuerst trainiert und danach argumentiert, an welchem Punkt die Schwierigkeit, das vom Training Bewirkte rückgängig zu machen, bereits die meisten Optionen verschlossen hat.

Die korrekte Reihenfolge, vor einem einzigen Trainingslauf:

Erstens: Bestimmen Sie den Zweck präzise. Nicht „Abläufe verbessern”, sondern das spezifische, artikulierbare Interesse, das Schritt eins des Tests des berechtigten Interesses überstehen muss.

Zweitens: Minimieren Sie auf diesen Zweck. Bestimmen Sie den kleinsten, am wenigsten identifizierenden Datensatz, der das Ziel erfüllt — anonymisiert, wo möglich, synthetisch, wo machbar, pseudonymisiert mindestens, auf das Erforderliche zugeschnitten. Dies ist Schritt zwei des Tests, ausgeführt als Engineering, nicht als Papierkram. Es ist auch die wirksamste einzelne Intervention, weil Daten, die nie in die Gewichte gelangen, später kein Löschproblem schaffen.

Drittens: Führen Sie die DSFA durch. Der Einsatz eines mit personenbezogenen Daten trainierten Modells im großen Maßstab erreicht fast sicher die Hochrisiko-Schwelle des Art. 35, und die DSK ist eindeutig, dass ein Verantwortlicher, der nicht zugleich der Anbieter des Systems ist, dennoch seine eigene Risikobewertung schuldet.¹⁷ Die DSFA ist der Ort, an dem die Abwägung, der Löschpfad und die Restrisiken niedergeschrieben werden — vorher, nicht nachher.

Viertens: Entwerfen Sie den Löschpfad im Voraus. Entscheiden Sie jetzt, auf Papier, wie ein künftiges Art.-17-Ersuchen erfüllt wird: welche Kombination aus Quelldatensatz-Löschung, Neutrainings-Kadenz, Unlearning und Ausgabefilterung gilt und wie die Konformität verifiziert wird. Ein ohne Löschplan trainiertes Modell ist ein Modell, das früher oder später ein Ersuchen erhält, das es nicht erfüllen kann.

Fünftens — und erst dann — trainieren. Mit festgelegtem Zweck, minimierten Daten, bewertetem Risiko und entworfenem Ausgang.

Selbst-Hosting gehört zu dieser Disziplin als eine starke Kontrolle unter mehreren. Es ist kein Ersatz für die Disziplin.

Das Fazit

ZUSAMMENFASSUNG FÜR ENTSCHEIDUNGSTRÄGER Selbst-Hosting kann die Übermittlungsexposition verringern oder entfernen — abhängig davon, wo Infrastruktur, Support-Zugriff, Telemetrie und Unterauftragsverarbeiter sitzen — tut aber wenig sonst: Die Rechtsgrundlagenfrage und die Löschfrage sind unberührt, und die Löschfrage wird wohl schlimmer, weil die Pflicht nun Ihre ist. Training verleibt personenbezogene Daten in einer Weise in die Gewichte ein, die derzeit schwer, kostspielig und oft unzuverlässig rückgängig zu machen ist — sind sie einmal dort, kann die Löschung auf Anfrage nicht verlässlich verifiziert werden ohne kostspieliges Neutraining oder Unlearning ungewisser Zuverlässigkeit — sodass die Rechtsgrundlage (ein dreistufiger Test des berechtigten Interesses, für den der EDSA eine hohe Hürde setzt), die Datenminimierung, die DSFA und der Löschpfad alle vor den ersten Trainingslauf gehören. Die richtige Frage ist nicht „Wo läuft das Modell?”, sondern „Können wir eine Person daraus löschen?” — und wenn die Antwort Nein lautet, hätte das Modell gar nicht erst mit ihnen trainiert werden dürfen.

Training ist keine Nutzung personenbezogener Daten — es ist ihre Einverleibung. Ein Prompt kann gelöscht werden; ein Gewicht kann nicht mit annähernd derselben Zuversicht ent-lernt werden. Diese eine Asymmetrie ist der Grund, warum die Verarbeitung von Daten durch ein Modell und das Training eines Modells mit Daten verschiedene Probleme sind, nicht zwei Versionen eines einzigen.

Selbst-Hosting ist eine echte Antwort auf die Übermittlungsfrage und eine Nicht-Antwort auf die Rechtsgrundlagen- und Löschfragen. „Alles bleibt im Haus” beschreibt, wo die Daten sind; es sagt nichts darüber, ob Sie sie trainieren durften oder ob Sie nachkommen können, wenn jemand verlangt, entfernt zu werden.

Die Disziplin ist die Reihenfolge der Schritte: Zweck, Minimierung, DSFA, Löschplan — dann Training. Kehren Sie diese Reihenfolge um, und die Schwierigkeit, das vom Training Bewirkte rückgängig zu machen, hat die Entscheidung bereits für Sie getroffen.

Glossar der Abkürzungen

Begriff	Definition
Fine-Tuning	Weiteres Training eines vortrainierten Modells auf einem engeren Datensatz zur Spezialisierung
Gewichte / Parameter	Die Milliarden numerischer Werte, in die ein Modell Muster aus Trainingsdaten codiert
Berechtigtes Interesse	Rechtsgrundlage nach Art. 6 Abs. 1 lit. f DSGVO, die eine dreistufige Abwägung erfordert
LIA	Legitimate Interest Assessment — der dokumentierte dreistufige Test
Machine Unlearning	Forschungstechniken, die darauf abzielen, bestimmte Daten aus einem trainierten Modell ohne vollständiges Neutraining zu entfernen
Recht auf Löschung	Das Recht der betroffenen Person nach Art. 17 DSGVO, personenbezogene Daten löschen zu lassen
DSFA	Datenschutz-Folgenabschätzung (Art. 35 DSGVO), erforderlich bei Verarbeitung mit hohem Risiko
Selbst-gehostet	Ein Modell, das auf von der Organisation kontrollierter Infrastruktur läuft statt der eines Anbieters
EDPB Opinion 28/2024	Die Stellungnahme des EDSA vom Dezember 2024 zu personenbezogenen Daten in KI-Modellen
DSK	Datenschutzkonferenz — die deutsche Versammlung der Datenschutzaufsichtsbehörden

Rechtlicher Hinweis: Dieser Artikel dient allgemeinen Informationszwecken und stellt keine Rechtsberatung dar. Für eine rechtssichere Beurteilung im konkreten Einzelfall wird die Konsultation einer auf Datenschutz spezialisierten Anwältin oder eines Anwalts empfohlen. Stand: Juni 2026.

1. In dem konsolidierten Urheberrechtsstreit unter Führung von The New York Times (S.D.N.Y.) ordnete Magistratsrichterin Ona T. Wang OpenAI am 13. Mai 2025 an, alle ChatGPT-Ausgabeprotokolldaten, die andernfalls gelöscht würden, aufzubewahren und zu separieren — einschließlich nutzergelöschter und „temporärer” Chats, die normalerweise innerhalb von ~30 Tagen gelöscht werden. Siehe OpenAI, „How we’re responding to The New York Times’ data demands” https://openai.com/index/response-to-nyt-data-demands/ und Berichterstattung unter https://www.thurrott.com/a-i/openai-a-i/330404/openai-must-turn-over-chatgpt-logs-in-new-york-times-case (abgerufen Juni 2026). ↩

2. OpenAI widersprach der Anordnung und unterlag; die Pflicht zur unbefristeten Aufbewahrung lief, bis sie mit Wirkung zum 26. September 2025 aufgehoben wurde, und im November 2025 ordnete das Gericht die Herausgabe von ~20 Millionen anonymisierten ChatGPT-Protokollen (Dez. 2022–Nov. 2024) an die Kläger an. Siehe Bloomberg Law, „OpenAI Must Turn Over 20 Million ChatGPT Logs, Judge Affirms”, 12. Nov. 2025 https://news.bloomberglaw.com/ip-law/openai-must-turn-over-20-million-chatgpt-logs-judge-affirms (abgerufen Juni 2026). ↩

3. OpenAI, „How we’re responding to The New York Times’ data demands” — ChatGPT Enterprise wurde als von der Aufbewahrungsanordnung ausgenommen klargestellt; Zero-Data-Retention-API-Inhalte werden nicht gespeichert und sind nicht betroffen; und „we don’t train our models on business data by default.” Verfügbar unter: https://openai.com/index/response-to-nyt-data-demands/ (abgerufen Juni 2026). ↩

4. Duality Technologies, „LLMs and Data Privacy: How to Protect Sensitive Information”, 2026 — während des Trainings codiert ein LLM Muster aus seinem Korpus in Milliarden von Parametern; für ein Modell, dessen Gewichte die Daten einer Einzelperson codiert haben, ist die Löschung nach Art. 17 technisch herausfordernd. Verfügbar unter: https://dualitytech.com/blog/llm-data-privacy/ (abgerufen Juni 2026). ↩

5. 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 — ein Modell ist nur dann anonym, wenn die Wahrscheinlichkeit, personenbezogene Daten zu extrahieren (direkt oder probabilistisch), und die Wahrscheinlichkeit, sie über Abfragen zu erhalten, beide unbedeutend sind, im Einzelfall beurteilt. Verfügbar unter: https://www.edpb.europa.eu/system/files/2024-12/edpb_opinion_202428_ai-models_en.pdf (abgerufen Juni 2026). ↩

6. „What Should LLMs Forget? Quantifying Personal Data in LLMs for Right-to-Be-Forgotten Requests”, arXiv 2507.11128 (XKDD 2025 / ECML PKDD 2025) — LLMs memorieren und können PII wörtlich oder annähernd leaken; nachgelagerte Filter und RAG entfernen memorierte Inhalte nicht aus dem Modell selbst. Verfügbar unter: https://arxiv.org/pdf/2507.11128 (abgerufen Juni 2026). ↩

7. GDPR Local, „Large Language Models (LLM) GDPR Compliance”, 9. Dezember 2025 — Löschoptionen: Machine Unlearning, vollständiges Neutraining (kann die Genauigkeit verschlechtern) oder Ausgabefilterung; die Ausnahmen der technischen Unmöglichkeit nach Art. 17 Abs. 3 erfordern den Nachweis, dass vernünftige Alternativen geprüft wurden. Verfügbar unter: https://gdprlocal.com/large-language-models-llm-gdpr/ (abgerufen Juni 2026). ↩

8. IAPP, „Perspective: Why data subjects’ rights to LLM training data are not relevant”, 17. Februar 2026 — das Löschen personenbezogener Daten aus den Trainingsdaten hat keine Auswirkung auf ein bereits trainiertes LLM; „Machine Unlearning” eines bereits trainierten Modells ist im gegenwärtigen Stand der Technik noch nicht möglich. Verfügbar unter: https://iapp.org/news/a/perspective-why-data-subjects-rights-to-llm-training-data-are-not-relevant (abgerufen Juni 2026). Siehe auch TechPolicy.Press, „The Right to Be Forgotten Is Dead”, 20. Mai 2025. ↩

9. Europäischer Datenschutzausschuss, Pressemitteilung „EDPB opinion on AI models: GDPR principles support responsible AI”, 18. Dezember 2024 — berechtigtes Interesse kann eine Rechtsgrundlage für Entwicklung und Einsatz sein, aber nur, wo die Verarbeitung als unbedingt erforderlich nachgewiesen wird und die Abwägung der Rechte gewahrt ist. Verfügbar unter: https://www.edpb.europa.eu/news/news/2024/edpb-opinion-ai-models-gdpr-principles-support-responsible-ai_en (abgerufen Juni 2026). ↩

10. CMS, „EDPB Opinion 28/2024: key takeaways”, 20. März 2026 — der EDSA stellt fest, dass Art. 6 Abs. 1 lit. f nicht die „standardmäßige” Rechtsgrundlage für Training und Nutzung von KI-Modellen sein kann; sie ist nur auf Grundlage einer nachgewiesenen dreistufigen Abwägung des berechtigten Interesses akzeptabel, aufbauend auf den Leitlinien 1/2024. Verfügbar unter: https://cms.law/en/deu/legal-updates/edpb-opinion-28-2024-key-takeaways-on-processing-personal-data-in-the-context-of-ai-models (abgerufen Juni 2026). ↩

11. EDPB Opinion 28/2024, zum ersten Schritt — ein Interesse ist legitim, wo es (1) rechtmäßig, (2) klar und präzise artikuliert und (3) real und gegenwärtig (nicht spekulativ) ist. Siehe auch Debevoise Data Blog, 14. April 2025. Verfügbar unter: https://www.debevoisedatablog.com/2025/04/14/gdpr-considerations-when-developing-and-deploying-ai-models-the-edpbs-opinion-on-compliance/ (abgerufen Juni 2026). ↩

12. IAPP, „EDPB weighs in on key questions on personal data in AI models”, 17. Februar 2026 — der EDSA setzt eine hohe Hürde für die Erforderlichkeit in Bezug auf das Volumen der im Modell beteiligten personenbezogenen Daten. Verfügbar unter: https://iapp.org/news/a/edpb-weighs-in-on-key-questions-on-personal-data-in-ai-models (abgerufen Juni 2026). ↩

13. European Papers, „Processing Personal Data in the Context of AI Models: EDPB’s Opinion 28/2024”, 27. Februar 2025 — der dritte Schritt wägt das berechtigte Interesse gegen die Grundrechte der betroffenen Personen, die Auswirkung der Verarbeitung und ihre vernünftigen Erwartungen ab. Verfügbar unter: https://www.europeanpapers.eu/europeanforum/protecting-personal-data-in-context-of-ai-models (abgerufen Juni 2026). ↩

14. EDPB Opinion 28/2024 — wo immer berechtigtes Interesse herangezogen wird, gilt das Widerspruchsrecht nach Art. 21 und muss gewährleistet sein. ↩

15. EDSA-Pressemitteilung, 18. Dezember 2024 (a. a. O.) — Beispiele für Interessen, die sich auf berechtigtes Interesse stützen können: ein Konversationsagent zur Unterstützung von Nutzern; ein KI-System zur Erkennung betrügerischer Inhalte oder Verhaltensweisen; die Verbesserung der Bedrohungserkennung in einem Informationssystem. ↩

16. GDPR Local (a. a. O.) — EU-Leitlinien erkennen Ausnahmen der technischen Unmöglichkeit nach Art. 17 Abs. 3 an, aber Organisationen müssen nachweisen, dass sie vernünftige technische Alternativen geprüft haben, bevor sie solche Ausnahmen für KI-Systeme geltend machen. ↩

17. Datenschutzkonferenz (DSK), „Orientierungshilfe Künstliche Intelligenz und Datenschutz” — eine DSFA ist bei KI-Verarbeitung häufig erforderlich, und wo der Verantwortliche nicht zugleich der Anbieter des KI-Systems ist, bleibt der Verantwortliche verpflichtet, seine eigene Risikobewertung durchzuführen. Verfügbar unter: https://www.datenschutzkonferenz-online.de/orientierungshilfen.html (abgerufen Juni 2026). ↩