Wissensraum · Deep Dive 16 von 22
KI-Training und das Recht an Daten
Trainingsdaten, Data Lineage, GPAI-Regime — und wie vier Rechtsordnungen unterschiedlich antworten
Trainingsprozesse technisch · Data Governance (Art. 10) · DSGVO-Spannungsfeld · GPAI-Regime · Rechtsvergleich EU/CH/USA/China
Was dieser Deep Dive Ihnen zeigt
Was KI-Training technisch bedeutet, welche Datenrechte dabei berührt werden – und warum die Antwort in der EU, der Schweiz, den USA und China jeweils anders ausfällt.
1. Was KI-Training technisch bedeutet
Training = statistisches Lernen aus Daten. Das Modell extrahiert Muster, Korrelationen, Wahrscheinlichkeitsverteilungen aus einem Datensatz (Trainingsdaten). Die Qualität eines KI-Systems wird durch die Qualität seiner Trainingsdaten bestimmt – aber «Qualität» hat nicht nur eine technische, sondern auch eine rechtliche Dimension: Herkunft, Rechtsgrundlage, Bias, Aktualität.
Supervised Learning: Das Modell wird mit gelabelten Daten trainiert (Eingabe + richtige Antwort). Unsupervised Learning: Das Modell erkennt Muster ohne Labels. Reinforcement Learning: Das Modell lernt durch Belohnung und Bestrafung. Self-Supervised Learning: Das Modell erzeugt eigene Labels aus Rohdaten – dies ist die Grundlage der meisten modernen Large Language Models (LLMs).
Foundation Models / Large Language Models: Training auf riesigen Textkorpora (Common Crawl, Books3, Wikipedia, Code-Repositories). Milliarden Parameter, trainiert über Wochen auf tausenden GPUs. Die Rechenlast ist immens: Externe Schätzungen gehen für GPT-4 von einer Trainingsrechenleistung in der Größenordnung von 1025 FLOPs aus; offiziell bestätigt sind Architektur und Rechenmenge nicht (GPT-3 nach Schätzungen rund 1023 FLOPs).
Fine-Tuning: Anpassung eines vortrainierten Modells an spezifische Aufgaben mit kleineren, domänenspezifischen Datensätzen. RLHF (Reinforcement Learning from Human Feedback): Menschliche Bewertung von Modellantworten zur Verhaltenssteuerung – dies macht ein Modell «sicherer». Es ändert den ursprünglichen Pretraining-Datensatz nicht, ergänzt den Trainingsprozess jedoch um weitere Bewertungs- und Präferenzdaten.
Data Lineage = Nachverfolgbarkeit: Woher stammen die Trainingsdaten? Wie wurden sie gesammelt, gefiltert, annotiert? Welche Rechte bestehen an ihnen? Für Hochrisiko-Systeme verlangt der AI Act (Art. 10) eine Daten-Governance und -Dokumentation; unter der DSGVO folgt die Nachweisbarkeit der Herkunft mittelbar aus Rechenschaftspflicht (Art. 5 Abs. 2) und Rechtsgrundlagen-Erfordernis. Eine allgemeine, verordnungsübergreifende „Data-Lineage-Pflicht" für jedes KI-System gibt es in dieser Pauschalität allerdings nicht.
Einordnung
Die Qualität eines KI-Systems wird durch die Qualität seiner Trainingsdaten bestimmt. Aber «Qualität» hat nicht nur eine technische, sondern auch eine rechtliche Dimension: Herkunft, Rechtsgrundlage, Bias, Aktualität. Ein Modell, das mit unrechtmäßig beschafften Daten trainiert wurde, ist nicht nur ethisch fragwürdig – es ist auch regulatorisch fehlerhaft und haftet den Betreibern zurück.
2. AI Act Art. 10: Daten-Governance für Hochrisiko-KI
Art. 10 EU AI Act verlangt für Hochrisiko-Systeme: Trainings-, Validierungs- und Testdaten müssen relevant, hinreichend repräsentativ und – soweit möglich – fehlerfrei und vollständig sein. Der Maßstab ist „to the best extent possible", nicht absolute Fehlerfreiheit. Das klingt abstrakt, hat aber konkrete Konsequenzen:
Bias-Prüfung: Datensets müssen auf Verzerrungen geprüft werden (Geschlecht, Ethnie, Alter, Behinderung). Ein Kreditscoring-Modell, das überproportional Männer bevorzugt oder Ältere benachteiligt, scheitert an der Art. 10-Prüfung, egal wie akkurat die Vorhersagen sind.
Dokumentationspflicht: Data Lineage muss nachweisbar sein – welche Daten, welche Quellen, welche Verarbeitungsschritte. Adressat der Daten-Governance nach Art. 10 ist primär der Provider des Hochrisiko-Systems (nicht pauschal jeder Deployer); er muss zeigen können: «Hier ist die Quelle. Hier ist die Verarbeitung. Hier ist die Bias-Analyse.» Für Foundation Models ist vollständige Data Lineage kaum möglich. Common Crawl enthält Milliarden von Webseiten – die Herkunft jedes einzelnen Datenpunkts zu dokumentieren ist technisch und wirtschaftlich unrealistisch.
Das ist das strukturelle Problem des GPAI-Regimes (siehe unten): Art. 10 wurde für spezialisierte Hochrisiko-Systeme geschrieben (Kreditscoring, Einstellungsentscheidungen). Foundation Models sind per Definition nicht spezialisiert. Sie sind «general-purpose». Die Art. 10-Anforderungen sind auf sie gar nicht zugeschnitten – für GPAI-Modelle gelten stattdessen die spezifischen Pflichten des Art. 53 (u.a. technische Dokumentation und Trainingsdaten-Zusammenfassung).
3. DSGVO und Trainingsdaten – das ungeloste Spannungsfeld
Art. 6 DSGVO: Jede Verarbeitung personenbezogener Daten braucht eine Rechtsgrundlage. Einwilligung? Berechtigtes Interesse? Vertragserfuellung? Gesetzliche Pflicht? Das Problem: Web-Scraping für Trainingsdaten erfasst massenhaft personenbezogene Daten – ohne Einwilligung der Betroffenen. Kann man sich auf «berechtigtes Interesse» berufen? Die Rechtsprechung ist skeptisch. Im US-Verfahren «New York Times v. OpenAI» (Southern District of New York) – ein Urheberrechtsstreit, kein Datenschutzverfahren – argumentieren die Kläger, dass es keine «faire Balance» zwischen dem Interesse des Trainierens und dem Interesse der Urheber gibt. (Der bekannteste britische Trainingsdaten-Fall ist demgegenüber Getty Images v. Stability AI.)
Art. 9 DSGVO: Besondere Kategorien (Gesundheit, Ethnie, politische Überzeugung, Religion) – noch strengerer Schutz. Foundation Models enthalten unweigerlich solche Daten. Wenn ein LLM auf Millionen von Wikipedia-Artikeln trainiert wurde, enthält es auch Informationen über Gesundheit, Ethnie und Religion von realen Menschen – ohne dass diese Daten pseudonymisiert sind. Diese Frage ist rechtlich noch nicht abschließend geklärt. Die Text-and-Data-Mining-Ausnahme der DSM-Richtlinie (Art. 4) und die Frage, ob Modellgewichte selbst eine «Verarbeitung» im Sinne der DSGVO darstellen, sind Gegenstand laufender Diskussion.
Art. 22 DSGVO: Recht, nicht einer ausschließlich automatisierten Entscheidung mit rechtlicher oder ähnlich erheblicher Wirkung unterworfen zu werden. Er betrifft die spätere Nutzung solcher Entscheidungen (Kredit, Bewerbung, Versicherung), nicht unmittelbar die Rechtmäßigkeit des Trainings. Aber: Wenn das Trainingsdatenmaterial selbst aus diskriminierenden Entscheidungen bestand, ist das Problem tiefer als die Entscheidungslogik.
Recht auf Erklärung: DSGVO Art. 13–15, Erwägungsgrund 71 – Betroffene haben ein Recht auf «aussagekräftige Informationen über die involvierte Logik». Bei neuronalen Netzen mit Milliarden Parametern ist «Erklärbarkeit» ein ungelöstes technisches und rechtliches Problem. Man kann nicht sagen, warum GPT-4 diesen Satz geschrieben hat – die innere Struktur ist nicht transparent.
Die DSGVO wurde für eine Welt geschrieben, in der Daten gezielt erhoben und zweckgebunden verarbeitet werden. KI-Training funktioniert umgekehrt: erst sammeln, dann Zweck definieren.
4. GPAI-Regime: Foundation Models unter dem AI Act
Art. 51–56 AI Act: General-Purpose AI Models (GPAI) – Modelle, die für eine Vielzahl von Aufgaben eingesetzt werden können (GPT, Claude, Gemini, Mistral, Llama). Provider von GPAI-Modellen müssen:
Technische Dokumentation erstellen
Trainingsdaten-Zusammenfassung veröffentlichen (Transparenzbericht)
Copyright-Policy einhalten (EU Copyright Directive Art. 4)
Mit Downstream-Providern kooperieren (z.B. wenn eine Firma Claude in ein Produkt integriert)
Systemische Risiken (Art. 51 Abs. 2): GPAI-Modelle mit «high-impact capabilities» unterliegen zusätzlichen Pflichten – Adversarial Testing, Incident Monitoring, Cybersicherheit. Schwelle: >10²5; FLOPs Trainingsrechenleistung = Vermutung systemischen Risikos. Das trifft die größten Modelle (etwa GPT-4-Klasse). Kleinere Modelle wie Mistral 7B liegen mit ihren 7 Mrd. Parametern klar unter der Schwelle und lösen die Vermutung gerade nicht aus – anders als ggf. sehr große Flaggschiff-Modelle. (Mistral 7B und Mistral Large sind unterschiedliche Modelle und nicht zu verwechseln.)
Relevanz für Unternehmen: Wer GPT-4, Claude oder Mistral via API in eigene Produkte integriert, ist «Deployer» – und muss sicherstellen, dass der Provider seine GPAI-Pflichten erfüllt. Die Verantwortungskette ist vertraglich, nicht nur regulatorisch. Die meisten API-Terms of Service regeln das nicht explizit.
Einordnung
Das GPAI-Regime versucht, die Verantwortung entlang der Wertschöpfungskette aufzuteilen: Provider dokumentiert, Deployer prüft. In der Praxis funktioniert das nur, wenn die Verträge diese Aufteilung abbilden – was bei den meisten API-Terms of Service nicht der Fall ist. Die Verantwortungslücke ist eine Schwachstelle.
5. Rechtsvergleich: Vier Antworten auf dieselbe Frage
Wie regulieren vier verschiedene Rechtsordnungen KI-Training und Trainingsdaten?
| Dimension | EU | Schweiz | USA | China |
|---|---|---|---|---|
| KI-Gesetz | AI Act (2024) | Kein horizontales KI-Gesetz | Kein Bundesgesetz, sektorale Ansätze | Interim Measures for Generative AI (2023), Deep Synthesis Provisions (2023) |
| Trainingsdaten | Art. 10 AI Act: Qualität, Bias, Dokumentation | nDSG: Allgemeine Datenschutzpflichten | Fair Use Doctrine (§107 Copyright Act) | Wahrheitspflicht, keine «Subversion der Staatsmacht» |
| Datenschutz | DSGVO: Einwilligung/berechtigtes Interesse | nDSG: Ähnlich DSGVO, aber weniger Sanktionen | Kein Bundes-Datenschutzgesetz, State Laws (CCPA) | PIPL (2021): Einwilligung, aber staatlicher Zugriff |
| Copyright | Text & Data Mining nur mit Opt-out (Art. 4 Copyright Directive) | Keine TDM-Ausnahme im URG | Fair Use: Umstritten (NYT v. OpenAI) | Staatliche Kontrolle über Trainingsinhalte |
| GPAI/Foundation Models | Art. 51–56: Dokumentation, Transparenz, systemische Risiken | Keine Regulierung | Kein umfassendes Bundes-KI-Gesetz; Executive Order 14110 (2023) am 20. Jan. 2025 vollständig aufgehoben | Registrierungs- und Genehmigungspflicht vor Markteinführung |
| Philosophie | Risikobasierte Regulierung ex ante | Sektorale Selbstregulierung | Innovationsfreiheit, Haftung ex post | Staatliche Kontrolle, Zensurkomponente |
Analyse: Die EU reguliert ex ante (vor dem Schaden) – bevor ein Modell trainiert wird, müssen Dokumentation und Bias-Prüfung vorliegen. Die USA regulieren ex post (nach dem Schaden, über Haftung und Litigation) – Fair Use ist eine Verteidigungslinie, keine Voraberlaubnis. China reguliert ex ante mit ideologischer Komponente – Trainingsdaten dürfen nicht gegen die Staatsmacht vorgehen, und alle Modelle müssen genehmigt werden. Die Schweiz wartet ab und wird über den Markt erfasst (Unternehmen können nach EU-Standard kompatibel sein, um den Markt zu behalten).
6. Fallstudie
Ausgangssituation
Ein europaüisches FinTech entwickelt eine Kreditscoring-KI. Trainiert auf historischen Kreditdaten aus 20 Jahren – Kreditvergabe, Ausfallquoten, Kundenmerkmale. Das System wird als Hochrisiko-KI klassifiziert (Annex III, Kreditwürdigkeitsprüfung).
Was sich zeigt
Ein AI-Act-Audit deckt auf: Keine Bias-Analyse, keine Data Lineage, keine Dokumentation der Datenquellen. Die Trainingsdaten stammten von Partnerkreditinstituten, die ihrerseits Datenschutzrichtlinien hatten – aber niemand hat je geprüft, ob das Trainingsmaterial die DSGVO einhielt. Das Modell benachteiligt systematisch Antragsteller aus bestimmten Postleitzahlgebieten. War das Absicht? Nein. War es Diskriminierung? Technisch ja, rechtlich auch.
Die Konsequenz
Doppelte regulatorische Exposition: (1) möglicher AI-Act-Verstoß, (2) DSGVO-Beschwerde eines abgelehnten Antragstellers. Der Antragsteller kann Auskunft über die Logik der automatisierten Entscheidung verlangen (DSGVO Art. 15 Abs. 1 lit. h). Das Unternehmen kann nicht erklären, warum das Modell so funktioniert – die Trainingsdaten sind nicht dokumentiert. Mögliche Folgen – je nach nationaler Umsetzung, Aufsichtspraxis und Einzelfall – reichen von Anordnungen und Auflagen über Marktrücknahme bis zu Bußgeldern; automatisch tritt keine dieser Folgen ein.
Warum das typisch ist
Viele Unternehmen bauen KI-Systeme, indem sie historische Daten nehmen und sie trainieren. Sie dokumentieren nicht, ob diese Daten rechtmäßig beschafft wurden, ob sie alle Datenschutzverpflichtungen erfüllen, ob sie Bias enthalten. Der Fehler liegt nicht im Modell – er liegt in der Datengrundlage. Und die Datengrundlage ist unter dem AI Act nicht optional.
7. Was das für Unternehmen bedeutet
Praxis-Impuls: Drei Fragen an Ihr Data-Team
(1) Können Sie für Ihre Trainingsdaten dokumentieren, woher sie stammen und unter welcher Rechtsgrundlage sie verarbeitet werden? Das ist nicht optional. Wenn Sie ein Modell trainieren, brauchen Sie einen Nachweis, dass die Daten rechtmäßig beschafft wurden. Web-Scraping ohne Einwilligung funktioniert in der EU nicht auf Dauer, es sei denn, Sie haben einen Text-&-Data-Mining-Opt-out.
(2) Haben Sie eine Bias-Analyse durchgeführt, die den Anforderungen von Art. 10 AI Act standhält? Für Hochrisiko-Systeme ist das Pflicht. Für General-Purpose-Modelle ist es zu komplex. Aber wenn Sie ein Hochrisiko-System deployen (z.B. Kreditentscheidung), müssen Sie zeigen können: «Hier ist unsere Bias-Analyse.»
(3) Wenn Sie Foundation Models via API nutzen: Haben Sie vertraglich sichergestellt, dass der Provider seine GPAI-Pflichten erfüllt – und dass Sie Zugang zu den Informationen haben, die Sie für Ihre eigene Compliance brauchen? Die meisten Standard-Verträge regeln das nicht. Das ist ein Verhandlungspunkt.
Was bleibt
KI-Training ist keine rein technische Frage. Es berührt Datenschutz (DSGVO), Urheberrecht (Copyright Directive), Produktsicherheit (AI Act) und Vertragsrecht (GPAI-Verantwortungskette) gleichzeitig. Jede dieser Dimensionen hat eigene Anforderungen und Sanktionen.
Data Lineage ist die zentrale Compliance-Anforderung. Wer nicht nachweisen kann, woher seine Trainingsdaten stammen und wie sie verarbeitet wurden, hat unter dem AI Act ein fundamentales Dokumentationsproblem. Das ist nicht technisches Detail – das ist regulatorische Grundvoraussetzung.
Die Rechtsordnungen divergieren fundamental. EU reguliert ex ante, USA ex post, China ideologisch, Schweiz wartet. Für multinationale Unternehmen bedeutet das: vier verschiedene Compliance-Logiken für dasselbe Modell. Ein Modell, das in der EU zertifizierbar ist, kann in China nicht trainiert werden, und in den USA ist die Rechtslage unklar.
GPAI-Verträge sind die neue Frontlinie. Wer Foundation Models nutzt, ohne die Verantwortungsteilung vertraglich zu klären, erbt die Compliance-Last des Providers – ohne dessen Ressourcen. Die Standardverträge adressieren das nicht. Das ist ein Verhandlungsthema.