Wissensraum · Deep Dive 21 von 27
Trainingsdaten, Data Lineage, GPAI-Regime – und wie vier Rechtsordnungen unterschiedlich antworten
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.
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, Einwilligung, 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: GPT-4 wurde mit ca. 1,76 × 10²5; FLOPs trainiert (zum Vergleich: GPT-3 mit 3,1 × 10²3; 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», ändert aber nichts an der Datengrundlage.
Data Lineage = Nachverfolgbarkeit: Woher stammen die Trainingsdaten? Wie wurden sie gesammelt, gefiltert, annotiert? Welche Rechte bestehen an ihnen? Data Lineage ist nicht optional – sie ist unter dem AI Act eine Compliance-Pflicht und unter der DSGVO eine rechtliche Grundvoraussetzung.
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, Einwilligung, 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.
Art. 10 EU AI Act verlangt für Hochrisiko-Systeme: Trainingsdaten müssen relevant, repräsentativ, fehlerfrei und vollständig sein. 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 die Art. 10-Prüfung, egal wie akkurat die Vorhersagen sind.
Dokumentationspflicht: Data Lineage muss nachweisbar sein – welche Daten, welche Quellen, welche Verarbeitungsschritte. Der Provider oder Deployer 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.
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 britischen Fall «New York Times v. OpenAI» argumentieren die Kläger, dass es keine «faire Balance» zwischen dem Interesse des Trainierens und dem Interesse der Urheber gibt.
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 unterworfen zu werden. Relevant für KI-Systeme, die Entscheidungen über Menschen treffen (Kredit, Bewerbung, Versicherung). 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.
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 GPT-4, Claude, Gemini, Mistral 7B/Large, und bald noch mehr.
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.
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 | Executive Order 14110 (2023), teilweise zurückgenommen | 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).
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) AI Act-Bewährung, (2) DSGVO-Beschwerde eines abgelehnten Antragstellers. Der Antragsteller hätte ein Recht auf Erklärung (DSGVO Art. 15). Das Unternehmen kann nicht erklären, warum das Modell so funktioniert – die Trainingsdaten sind nicht dokumentiert. Ergebnis: Das System wird vom Markt genommen, die Zertifizierung entzogen, Geldbußen.
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.
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.