KI-Fine-Tuning und Kundendaten: Was Datenschutzgesetze wirklich vorschreiben

Das Feinabstimmen von KI-Modellen mit vertraulichen Kundendaten ist einer der überzeugendsten Anwendungsfälle für KI im Unternehmensumfeld – ein Modell, das auf Ihren eigenen Kundeninteraktionen und Transaktionshistorien trainiert wurde, liefert Ergebnisse, die ein generisches Modell nicht erreichen kann. Das geschäftliche Potenzial ist eindeutig. Die rechtlichen und Governance-Anforderungen sind jedoch deutlich weniger klar.

Die entscheidende Frage ist nicht, ob Sie dürfen, Kundendaten für das Feinabstimmen eines KI-Modells verwenden. In den meisten Fällen dürfen Sie das. Die eigentliche Frage ist, ob Sie dies rechtmäßig tun können – und ob Sie diese Rechtmäßigkeit nachweisen können, wenn eine Aufsichtsbehörde, eine betroffene Person oder das Rechtsteam eines Kunden danach fragt.

Dieser Beitrag erläutert, welche Anforderungen das Datenschutzrecht tatsächlich stellt, bevor Kundendaten in eine Trainingspipeline gelangen, wo die häufigsten Governance-Fehler auftreten und wie Sie eine Compliance-Infrastruktur aufbauen, die das Feinabstimmen rechtlich absichert.

Executive Summary

Kernaussage: Das Feinabstimmen eines KI-Modells mit Kundendaten ist nicht grundsätzlich verboten – es löst jedoch Datenschutzpflichten nach DSGVO, CCPA, HIPAA und anderen Regelwerken aus, die die meisten Unternehmen vor Beginn der Verarbeitung nicht adressiert haben.

Warum das wichtig ist: Wenn Sie Kundendaten ohne die richtige Rechtsgrundlage, ohne Maßnahmen zur Datenminimierung und ohne Audit-Infrastruktur für das Training von KI verwenden, setzen Sie Ihr Unternehmen dem Risiko von behördlichen Maßnahmen, Ansprüchen betroffener Personen und möglichen Vertragsverletzungen aus. Das Risiko steigt mit dem Umfang: Jeder für das Training genutzte Datensatz ist ein Datensatz, den Sie möglicherweise nicht mehr löschen können, falls ein Löschantrag eingeht.

Wichtige Erkenntnisse

1. Feinabstimmung mit Kundendaten ist nach DSGVO, CCPA und HIPAA zulässig – aber nur mit dokumentierter Rechtsgrundlage, einer Bewertung der Zweckkompatibilität und Maßnahmen zur Datenminimierung, die vor Trainingsbeginn umgesetzt werden.
2. Das Recht auf Löschung ist das größte Problem: Sobald Kundendaten in den Modellgewichten eingebettet sind, erfordert das Löschen ein erneutes Training – Ihr Löschkonzept muss vor dem ersten Trainingslauf feststehen.
3. De-Identifizierung reduziert Risiken, beseitigt sie aber nicht – Feinabgestimmte Modelle können Trainingsdaten speichern und reproduzieren, sodass nach üblicher Anonymisierung eine Re-Identifizierung möglich bleibt.
4. Trainingspipelines, die Ihre üblichen Zugriffskontrollen umgehen, erzeugen unüberwachte Datenflüsse außerhalb Ihres Governance-Perimeters – jeder Datenexport muss authentifiziert, richtliniengesteuert und protokolliert werden.
5. Vertragliche Nutzungsbeschränkungen in Kundenverträgen verbieten häufig die Weiterverwendung von Daten für das Modelltraining – selbst wenn das Datenschutzrecht dies erlauben würde – eine rechtliche Prüfung der Kundenverträge ist zwingend erforderlich.

Was Feinabstimmung mit Kundendaten tatsächlich bedeutet – und warum das für den Datenschutz relevant ist

Nicht jedes KI-Training mit Kundendaten birgt dasselbe Datenschutzrisiko. Die gewählte Methode bestimmt sowohl die ausgelösten rechtlichen Pflichten als auch die Schwierigkeit, Betroffenenrechte nachträglich zu erfüllen.

Feinabstimmung aktualisiert die Gewichte eines bestehenden Modells durch Training mit einem neuen Datensatz – Ihren Kundendaten. Das Modell lernt Muster und Zusammenhänge aus diesen Daten. Kritisch ist: Trainingsdaten können vom Modell gespeichert und in Ausgaben reproduziert werden und werden so in den Modellgewichten verankert, dass sie ohne erneutes Training nicht mehr entfernt werden können.

RAG (Retrieval-Augmented Generation) verändert die Modellgewichte nicht. Es ruft relevante Dokumente aus einem gesteuerten Datenspeicher zur Laufzeit ab. Da die Daten im gesteuerten Repository verbleiben, ist das Löschen technisch einfach – das Entfernen aus dem Retrieval-Index erfüllt Löschanfragen ohne erneutes Modelltraining.

In-Context Learning stellt Daten zur Laufzeit im Prompt bereit, ohne das Modell zu verändern oder einen persistenten Speicher zu erzeugen. Dies birgt das geringste Datenschutzrisiko der drei Ansätze, da keine Trainingsdaten über die jeweilige Sitzung hinaus gespeichert werden.

Feinabstimmung ist der risikoreichste Ansatz, weil Trainingsdaten nicht mehr nur gespeichert, sondern irreversibel verarbeitet werden, auf Löschanfragen nicht mehr entfernt werden können und über Modellausgaben an Dritte gelangen können, die sonst keinen Zugriff hätten.

Die rechtliche Lage: Welche Datenschutzgesetze gelten und was sie verlangen

Das Feinabstimmen mit Kundendaten löst nicht nur ein einzelnes Datenschutzregime aus – in der Regel greifen mehrere parallel, abhängig davon, wer Ihre Kunden sind, welche Daten Sie verarbeiten und in welcher Branche Sie tätig sind. Die Anforderungen sind nicht einheitlich, aber die grundlegenden Governance-Pflichten sind konsistent: Rechtsgrundlage, Datenminimierung, Zweckbindung und Audit-Trail.

DSGVO. Für alle personenbezogenen Daten von EU-Bürgern verlangt die DSGVO eine dokumentierte Rechtsgrundlage gemäß Artikel 6, bevor das Training beginnt. Am wahrscheinlichsten sind Einwilligung und berechtigtes Interesse, jeweils mit erheblichen Bedingungen: Die Einwilligung muss freiwillig, spezifisch und widerrufbar sein; das berechtigte Interesse erfordert eine Interessenabwägung, die bei sensiblen Daten schwerer zu erfüllen ist.

Die Zweckbindung nach Artikel 5 bedeutet, dass Daten, die für die Leistungserbringung erhoben wurden, nicht ohne dokumentierte Kompatibilitätsprüfung für das Modelltraining weiterverwendet werden dürfen. Das Recht auf Löschung nach Artikel 17 stellt das größte praktische Problem dar: Fordert ein Kunde die Löschung, nachdem seine Daten für die Feinabstimmung genutzt wurden, ist das Entfernen aus den Modellgewichten technisch nur durch erneutes Training möglich. Eine DSFA ist vor risikoreicher Verarbeitung erforderlich und für jedes Feinabstimmungsprojekt mit personenbezogenen Daten in großem Umfang dringend zu empfehlen.

CCPA / CPRA. Verbraucher in Kalifornien haben das Recht, dem „Verkauf“ oder „Teilen“ ihrer personenbezogenen Daten nach CCPA und dessen Nachfolger CPRA zu widersprechen. Die Nutzung von Kundendaten zum Trainieren oder Verbessern eines KI-Modells kann als „Teilen“ im Sinne der weit gefassten CPRA-Definition gelten, insbesondere wenn ein Drittanbieter-KI-Anbieter beteiligt ist. Unternehmen müssen die Zweitnutzung – einschließlich KI-Training – in ihren Datenschutzhinweisen offenlegen und Opt-out-Anfragen vor der Nutzung dieser Daten in Trainingspipelines beachten.

HIPAA. Geschützte Gesundheitsinformationen dürfen nur mit Patientenautorisierung oder De-Identifizierung nach den Safe-Harbor- oder Expert-Determination-Standards von HIPAA für das Training von KI-Modellen verwendet werden. Die HIPAA-Minimum-Necessary-Regel gilt für alle für das Training extrahierten PHI – es dürfen nur die für das konkrete Ziel erforderlichen Daten genutzt werden. Die De-Identifizierung für LLM-Training ist technisch anspruchsvoll: Die Kontextfülle, die klinische Notizen für das Training wertvoll macht, erhöht auch das Risiko der Re-Identifizierung trotz Entfernung der Standardkennzeichen.

Vertragliche Verpflichtungen. Über das Datenschutzrecht hinaus unterliegen Kundendaten häufig vertraglichen Nutzungsbeschränkungen, die unabhängig von – und oft strenger als – die geltenden gesetzlichen Vorgaben sind. Enterprise-SaaS-Verträge, Datenverarbeitungszusätze und Verträge im Finanzdienstleistungsbereich beschränken die Datennutzung meist auf den Hauptzweck der Dienstleistung. Die Verwendung dieser Daten für das Modelltraining ohne ausdrückliche vertragliche Erlaubnis birgt ein Vertragsverletzungsrisiko, unabhängig davon, ob das Datenschutzrecht dies erlauben würde. Eine rechtliche Prüfung der Kundenverträge ist Voraussetzung für jedes Feinabstimmungsprogramm.

Die vier Fragen, die Sie vor der Feinabstimmung beantworten müssen

Bevor Kundendaten für eine Trainingspipeline extrahiert werden, müssen vier Governance-Fragen dokumentiert beantwortet sein. Das sind keine bloßen Formalitäten – sie sind Voraussetzung dafür, dass das Feinabstimmen rechtmäßig ist und Ihr Unternehmen es im Nachhinein verteidigen kann.

1. Haben Sie eine Rechtsgrundlage? Nach DSGVO bedeutet das eine dokumentierte Rechtsgrundlage nach Artikel 6, die vor der Verarbeitung vorliegt – keine nachträgliche Rechtfertigung nach einer Beschwerde. Nach CCPA und CPRA bedeutet das, dass Opt-out-Mechanismen bestehen und Ihr Datenschutzhinweis die KI-Trainingsnutzung offenlegt. Nach HIPAA liegt eine Patientenautorisierung oder eine formell verifizierte De-Identifizierung vor der Extraktion vor. Die Rechtsgrundlage muss dokumentiert und vor dem Einbringen von Daten in die Trainingspipeline vorhanden sein.

2. Ist der Zweck mit dem ursprünglichen Erhebungszweck kompatibel? Datenminimierung und Zweckbindung sind nicht allein durch eine Rechtsgrundlage erfüllt. Daten, die für die Leistungserbringung erhoben wurden, dürfen nicht automatisch für das Modelltraining weiterverwendet werden. Die DSGVO verlangt eine dokumentierte Kompatibilitätsprüfung – dabei werden der Zusammenhang zwischen ursprünglichem und neuem Zweck, die Art der Daten und die Folgen für Betroffene bewertet. Die CCPA verlangt die Offenlegung des Zweitzwecks im Datenschutzhinweis. War der ursprüngliche Zweck sehr eng gefasst, kann eine erneute Einwilligung erforderlich sein.

3. Können Sie Löschanfragen erfüllen? Sind Kundendaten einmal in Modellgewichten eingebettet, können sie nur durch erneutes Training entfernt werden. Vor dem ersten Trainingslauf muss Ihr Unternehmen eine von drei Positionen festlegen: (a) Es gilt eine dokumentierte Ausnahme vom Recht auf Löschung; (b) eine konkrete Zusage zum Retraining wird innerhalb eines definierten Zeitrahmens bei validierten Löschanfragen eingehalten; oder (c) Ihr Trainingsansatz unterstützt Machine Unlearning, das gezielte Datenentfernung ermöglicht. Diese Entscheidung muss vor Trainingsbeginn getroffen werden – wenn eine Löschanfrage eingeht, sind Ihre Optionen begrenzt.

4. Können Sie nachweisen, welche Daten wie verarbeitet wurden? DSGVO Artikel 30 verlangt ein Verzeichnis der Verarbeitungstätigkeiten. Für die Feinabstimmung bedeutet das: Dokumentation, welche Kundendaten extrahiert wurden, aus welchen Systemen, auf welcher Rechtsgrundlage, welche Transformationen angewendet wurden und welche Modellversion damit trainiert wurde. Diese Dokumentation ist Ihre Verteidigung bei regulatorischen Anfragen oder Betroffenenanfragen – und sie muss zeitnah erfolgen, nicht erst im Nachhinein rekonstruiert werden.

De-Identifizierung: Löst sie das Problem?

De-Identifizierung wird am häufigsten als Lösung für das Rechtsgrundlagenproblem vorgeschlagen – wenn Daten keine personenbezogenen Daten mehr sind, gilt die DSGVO, HIPAA und die meisten Datenschutzgesetze nicht mehr. Die Logik ist korrekt. Die Umsetzung ist jedoch schwieriger als viele Unternehmen erwarten.

Nach DSGVO müssen Daten wirklich anonym – nicht nur pseudonymisiert – sein, um außerhalb des Anwendungsbereichs zu liegen. Pseudonymisierte Daten bleiben nach DSGVO personenbezogene Daten, unabhängig von den vorgenommenen Transformationen. Echte Anonymisierung erfordert, dass eine Re-Identifizierung vernünftigerweise unmöglich ist. Für LLM-Feinabstimmungsdatensätze ist dieser Standard schwer zu erreichen: Seltene Merkmale, ungewöhnliche Attributkombinationen oder charakteristische Schreibstile können auch nach Entfernung von Namen und direkten Identifikatoren eine Re-Identifizierung ermöglichen.

Nach HIPAA verlangt Safe Harbor die Entfernung von 18 spezifischen Identifikator-Kategorien. Expert Determination erfordert eine statistische Bestätigung, dass das Re-Identifizierungsrisiko sehr gering ist. LLM-Trainingsdaten scheitern häufig an beiden Standards – nicht weil Identifikatoren übersehen wurden, sondern weil die Kontextfülle, die klinische Notizen für das Training wertvoll macht, sie im Aggregat re-identifizierbar macht.

Das Memorierungsproblem ist das am meisten unterschätzte Risiko. Feinabgestimmte Modelle können Passagen aus Trainingsdaten wortwörtlich speichern und auf gezielte Prompts hin wiedergeben. De-Identifizierung beim Input garantiert keinen Datenschutz beim Output – ein Modell, das auf de-identifizierten Datensätzen trainiert wurde, kann Passagen reproduzieren, die eine Re-Identifizierung im Kontext ermöglichen. Dieses Risiko wurde in der Forschung mehrfach nachgewiesen und kann nicht allein durch vorgelagerte Anonymisierung ausgeschlossen werden.

De-Identifizierung reduziert KI-Risiken und kann die regulatorische Last mindern, ist aber eine Risikominderungsmaßnahme, keine Compliance-Lösung. Sie löst das Löschproblem nicht, wenn eine Re-Identifizierung weiterhin möglich ist, und schützt nicht vor Memorierungs-basierten Offenlegungen beim Inferenzzeitpunkt.

Wie Sie Kundendaten für KI-Feinabstimmung compliant nutzen

Compliance für Feinabstimmung ist erreichbar – aber sie erfordert eine Governance-Infrastruktur, die vor der Datenextraktion geschaffen wird, nicht erst nach dem Deployment des Modells. Die gleiche Governance auf Datenebene, die den KI-Agenten-Zugriff compliant macht, gilt direkt für Trainingsdatenpipelines: Jede Extraktion muss authentifiziert, richtliniengesteuert, verschlüsselt und protokolliert werden, bevor Kundendaten die geschützte Umgebung verlassen.

Rechtsgrundlage vor der Extraktion festlegen und dokumentieren. Das Verarbeitungsprotokoll muss der Verarbeitung vorausgehen. Die Rechtsgrundlage nach Artikel 6 ist dokumentiert, die Kompatibilitätsprüfung abgeschlossen und der Datenschutzhinweis aktualisiert, bevor Daten aus Produktivsystemen extrahiert werden. Für HIPAA-Daten liegt die Autorisierung vor oder die De-Identifizierung ist vor Extraktion verifiziert.

Datenminimierung vor dem Training anwenden. Extrahieren Sie nur die Datenfelder und Datensätze, die für das konkrete Feinabstimmungsziel erforderlich sind. ABAC-Durchsetzung auf der Extraktionsebene verhindert, dass Trainingspipelines auf Daten außerhalb des definierten Umfangs zugreifen – das gleiche Prinzip, das den KI-Agenten-Zugriff auf regulierte Daten in der Produktion steuert, gilt auch für die Trainingsdatenpipeline. Das erfüllt Artikel 5 der DSGVO und ist unabhängig von der Rechtsordnung Best Practice.

Vollständiges, manipulationssicheres Verarbeitungsprotokoll führen. Dokumentieren Sie, welche Daten extrahiert wurden, aus welchen Systemen, auf welcher Rechtsgrundlage, welche Transformationen angewendet wurden und welche Modellversion damit trainiert wurde. Dies ist Ihr Artikel-30-Verzeichnis und Ihre Beweisführung bei regulatorischen Anfragen. Es muss so lange gepflegt werden, wie das damit trainierte Modell produktiv eingesetzt wird. Audit-Logs über die Extraktionspipeline, Transformationen und das Modell-Deployment liefern zeitnahe Dokumentation, die nachträglich nicht rekonstruiert werden kann.

Die Datenextraktion durch Ihren Standard-Zugriffsperimeter steuern. Trainingspipelines, die die normalen Zugriffskontrollen umgehen, erzeugen unüberwachte Datenflüsse außerhalb Ihres KI-Governance-Perimeters. Jede Kundendatenextraktion für die Feinabstimmung sollte die gleichen Identitätsprüfungen, Richtliniendurchsetzung, FIPS 140-3 Level 1-validierte Verschlüsselung und Audit-Logging durchlaufen wie jeder andere Zugriff auf regulierte Daten. Die Datenrichtlinien-Engine, die den KI-Agenten-Zugriff in der Produktion steuert, sollte auch steuern, was Trainingspipelines extrahieren dürfen.

Ein Löschkonzept vor dem ersten Trainingslauf erstellen. Legen Sie Ihre dokumentierte Position zum Recht auf Löschung fest: Welche Ausnahme gilt, wie sieht Ihr Zeitplan für das Retraining aus oder welche Machine-Unlearning-Fähigkeiten Ihre Infrastruktur unterstützt. Dieser Plan kann nicht reaktiv entwickelt werden – wenn eine Löschanfrage eingeht, ist das Modell produktiv und Ihre Optionen sind begrenzt.

Kiteworks Compliant AI: Governance der Datenebene vom Training bis zur Inferenz

Die meisten Unternehmen behandeln KI-Trainingsdaten als separates Problem von KI-Produktivdaten – gesteuert von unterschiedlichen Teams, über verschiedene Pipelines, mit unterschiedlichen Kontrollen. Genau an dieser Trennung entstehen Compliance-Lücken. Die gleichen Vorschriften, die den KI-Agenten-Zugriff in der Produktion regeln, regeln auch, was Trainingspipelines aus Ihrer Kundendatenumgebung extrahieren dürfen. Und die gleiche Governance-Infrastruktur, die produktive KI absichert, macht auch Feinabstimmung rechtssicher.

Kiteworks Compliant AI steuert die Datenebene in beiden Kontexten – innerhalb des Private Data Network – und erzwingt authentifizierte Identität, ABAC-Richtlinien auf Operationsebene, FIPS 140-3 Level 1-validierte Verschlüsselung und manipulationssichere Audit-Logs für jede Dateninteraktion, egal ob ein KI-Agent auf Produktivdaten zugreift oder eine Trainingspipeline Datensätze für die Feinabstimmung extrahiert.

Jede Extraktion wird zugeordnet, eingegrenzt, verschlüsselt und protokolliert, bevor Daten bewegt werden. Wenn Ihr DSB, Ihr Rechtsteam oder eine Aufsichtsbehörde fragt, welche Kundendaten Ihr Modell trainiert haben und mit welcher Autorisierung, liefern Sie ein strukturiertes Evidenzpaket – keine nachträgliche Recherche. 

Kontaktieren Sie uns, um zu erfahren, wie Kiteworks KI-Feinabstimmung für regulierte Unternehmen compliant macht.

Weitere Ressourcen

• Blog Post
  Zero‑Trust-Strategien für kosteneffizienten KI-Datenschutz
• Blog Post
  Wie 77 % der Unternehmen beim KI-Datenschutz versagen
• eBook
  AI Governance Gap: Warum 91 % der kleinen Unternehmen 2025 russisches Roulette mit Datensicherheit spielen
• Blog Post
  Für Ihre Daten gibt es kein „–dangerously-skip-permissions“
• Blog Post
  Regulierungsbehörden wollen keine KI-Policy mehr – sie verlangen den Nachweis der Wirksamkeit.