Anforderungen an KI-Trainingsdaten nach dem EU AI Act: Artikel 10 und Daten-Governance

Wenn es eine Vorschrift im EU AI Act gibt, die Organisationen zwingen wird, ihre Art, KI-Systeme zu bauen, zu ändern, dann ist es Artikel 10. Nicht, weil er etwas verbietet. Nicht, weil er ein Bußgeld verhängt. Sondern weil er in die Machine-Learning-Pipeline selbst hineingreift und vorschreibt, wie Trainingsdaten erhoben, vorbereitet, dokumentiert und gesteuert werden müssen, bevor das System überhaupt auf den Markt kommt. Für Anbieter (Provider) von Hochrisiko-KI-Systemen verwandelt Artikel 10 Daten-Governance von einer internen Best Practice in eine rechtliche Pflicht. Für Anbieter von Modellen mit allgemeinem Verwendungszweck (GPAI) verlangt ein paralleles Transparenzregime nach Artikel 53 detaillierte Zusammenfassungen der Trainingsdaten. Dieser Leitfaden schlüsselt jede Anforderung auf, erklärt, wie Compliance in der Praxis aussieht, und gibt Ihnen die Schritte, um sie vor der Frist am 2. August 2026 zu erreichen.

Kurzfassung: das Wesentliche zu den Anforderungen an Trainingsdaten

• Wer: Jeder Anbieter eines Hochrisiko-KI-Systems (eingestuft nach Anhang III oder sektorspezifischer Gesetzgebung) und jeder Anbieter eines GPAI-Modells.
• Was: Artikel 10 schreibt Daten-Governance- und -Management-Praktiken für den gesamten Datenlebenszyklus vor: Konzeption, Erhebung, Aufbereitung, Kennzeichnung, Bereinigung, Anreicherung, Aggregation, Prüfung auf Verzerrungen, Erkennung von Lücken und Dokumentation.
• Wann: Die Pflichten für Hochrisiko-KI-Systeme gelten ab dem 2. August 2026. Die GPAI-Pflichten gelten bereits ab dem 2. August 2025, mit einer Übergangsfrist bis zum 2. August 2027 für Modelle, die bereits auf dem Markt sind.
• Erfasste Datensätze: Trainingsdaten, Validierungsdaten und Testdaten, alle drei.
• Bias-Pflicht: Datensätze müssen auf mögliche Verzerrungen geprüft werden, und Anbieter müssen geeignete Maßnahmen ergreifen, um sie zu erkennen, zu verhindern und zu mindern.
• Besondere Kategorien von Daten: Artikel 10(5) schafft eine Rechtsgrundlage für die Verarbeitung ansonsten verbotener personenbezogener Daten (ethnische Herkunft, Geschlecht, Gesundheit usw.), wenn dies für die Bias-Überwachung unbedingt erforderlich ist, unter strengen Schutzvorkehrungen.
• GPAI-Transparenz: Artikel 53(1)(d) verlangt von GPAI-Anbietern, eine hinreichend detaillierte Zusammenfassung der Trainingsdateninhalte zu veröffentlichen, unter Verwendung der im Juli 2025 veröffentlichten standardisierten EU-Vorlage.
• Dokumentation: Alle Daten-Governance-Praktiken müssen in der technischen Dokumentation nach Anhang IV, Abschnitt 2, dokumentiert werden.

Warum Daten-Governance das Fundament der AI-Act-Compliance ist

Jedes KI-System lernt aus Daten. Die Qualität, Repräsentativität und Fairness dieser Daten entscheiden darüber, ob das System korrekt funktioniert, still versagt oder Menschen aktiv schadet. Der EU-Gesetzgeber hat das beim Entwurf des AI Act verstanden und darauf reagiert, indem er Daten-Governance zu einer der detailliertesten und vorschreibendsten Anforderungen der gesamten Verordnung gemacht hat.

Das Prinzip ist einfach: Müll rein, Müll raus. Eine Recruiting-KI, die auf historischen Einstellungsdaten mit Geschlechtsverzerrung trainiert wird, wird diese Verzerrung in großem Maßstab reproduzieren. Ein medizinisches Diagnosesystem, das auf Datensätzen trainiert wird, die bestimmte ethnische Gruppen unterrepräsentieren, wird für diese Gruppen weniger genaue Diagnosen liefern. Ein Kreditscoring-Modell, das auf Daten trainiert wird, die Geografie mit Kreditwürdigkeit vermischen, wird Antragsteller aus bestimmten Postleitzahlgebieten systematisch benachteiligen. In jedem Fall entsteht der Schaden in den Daten.

Artikel 10 steht im Zentrum der Anforderungsarchitektur des AI Act. Er verbindet sich direkt mit:

• Artikel 9 (Risikomanagement): Datenbezogene Risiken müssen im Risikomanagement-System identifiziert und gemindert werden.
• Artikel 11 (Technische Dokumentation): Daten-Governance-Praktiken müssen in Anhang IV, Abschnitt 2, dokumentiert werden.
• Artikel 13 (Transparenz): Nutzer müssen über die Daten informiert werden, mit denen das System trainiert wurde.
• Artikel 15 (Genauigkeit, Robustheit, Cybersicherheit): Genauigkeitskennzahlen sind nur aussagekräftig, wenn sie auf repräsentativen, korrekt gekennzeichneten Daten berechnet werden.
• Artikel 72 (Marktbeobachtung): Die laufende Beobachtung muss Data Drift und Verschlechterung über die Zeit erkennen.

Das bedeutet: Sie können den AI Act nicht erfüllen, ohne Artikel 10 zu erfüllen. Er ist nicht eine Anforderung unter vielen, er ist das Fundament, auf dem jede andere technische Anforderung aufbaut.

Die Frist 2. August 2026 gilt für alle Pflichten von Hochrisiko-KI-Systemen, einschließlich Artikel 10. Wenn Sie ein System bauen, das unter Anhang III fällt, biometrische Identifizierung, kritische Infrastruktur, Bildung, Beschäftigung, Zugang zu wesentlichen Diensten, Strafverfolgung, Migration oder Rechtspflege, müssen Ihre Trainingsdatenpraktiken diese Anforderungen vor diesem Datum erfüllen. Fangen Sie jetzt an. Nachträgliche Dokumentation dauert zwei- bis dreimal so lange wie vorausschauende.

Artikel 10, die rechtlichen Anforderungen erklärt

Artikel 10 trägt den Titel "Daten und Daten-Governance". Er gilt für Hochrisiko-KI-Systeme, die Techniken einsetzen, bei denen KI-Modelle mit Daten trainiert werden. Er ist einer der längsten und detailliertesten Artikel der Verordnung und umfasst fünf Absätze, die von Designentscheidungen bis zu besonderen Kategorien personenbezogener Daten reichen. Hier ist, was jeder Absatz verlangt.

Daten-Governance- und -Management-Praktiken (Artikel 10(2))

Artikel 10(2) ist die Kernvorschrift. Er besagt, dass Trainings-, Validierungs- und Testdatensätze Daten-Governance- und -Management-Praktiken unterliegen müssen, die für die Zweckbestimmung des KI-Systems angemessen sind. Diese Praktiken müssen mindestens die in den Buchstaben (a) bis (f) aufgeführten Elemente betreffen.

Das Wort "angemessen" ist wichtig. Der AI Act schreibt kein einheitliches Datenmanagement für alle vor. Was angemessen ist, hängt von der Zweckbestimmung, dem Risikoniveau, dem Stand der Technik und den spezifischen Merkmalen der Daten ab. Ein Gesichtserkennungssystem, das auf biometrischen Daten trainiert wird, verlangt eine andere Governance als ein System zur Qualitätskontrolle in der Fertigung, das auf Produktbildern trainiert wird. Aber beide müssen nachweisen, dass Governance-Praktiken existieren, dokumentiert und verhältnismäßig sind.

Designentscheidungen für Datensätze (Artikel 10(2)(a), (f))

Die sechs verpflichtenden Elemente sind:

(a) Die relevanten Designentscheidungen: Dies betrifft die grundlegenden Entscheidungen über Ihre Datensätze, welche Daten einzubeziehen, welche auszuschließen sind, was die Zielvariable darstellt, was die Eingabemerkmale sind, wie die Daten strukturiert sind. Jede Designentscheidung muss dokumentiert und begründet werden. Wenn Sie sich entschieden haben, bestimmte Datenquellen auszuschließen, erklären Sie, warum. Wenn Sie eine bestimmte Kennzeichnungs-Taxonomie gewählt haben, dokumentieren Sie sie.

(b) Datenerhebungsprozesse und die Herkunft der Daten, bei personenbezogenen Daten auch der ursprüngliche Zweck der Datenerhebung: Sie müssen wissen, woher Ihre Daten kommen. Dokumentieren Sie für jeden Datensatz die Quelle, die Erhebungsmethode und den Zeitraum. Für personenbezogene Daten müssen Sie zusätzlich den ursprünglichen Zweck dokumentieren, für den die Daten erhoben wurden, was direkte Folgen für die Prüfung der DSGVO-Rechtsgrundlage hat.

(c) Relevante Datenaufbereitungs-Verarbeitungsvorgänge: Dazu gehören Bereinigung, Filterung, Normalisierung, Kodierung, Feature Engineering, Augmentierung, Imputation und jede andere Transformation der Rohdaten. Jeder Vorgang muss dokumentiert werden, einschließlich der Begründung für seine Wahl und seiner Auswirkung auf den Datensatz.

(d) Die Formulierung von Annahmen: Alle Annahmen, die den Datensätzen zugrunde liegen, müssen explizit gemacht werden. Wenn Sie annehmen, dass historische Daten repräsentativ für künftige Bedingungen sind, dokumentieren Sie diese Annahme. Wenn Sie annehmen, dass eine Proxy-Variable mit der eigentlich interessierenden Variable korreliert, dokumentieren Sie diese Annahme und die sie stützenden Belege.

(e) Eine Bewertung der Verfügbarkeit, Menge und Eignung der benötigten Datensätze: Sie müssen bewerten, ob Sie genügend Daten haben, ob diese Daten für die Zweckbestimmung geeignet sind und ob Lücken bestehen. Das ist keine einmalige Prüfung, es muss neu bewertet werden, wenn sich das System oder seine Einsatzbedingungen ändern.

(f) Prüfung auf mögliche Verzerrungen, die die Gesundheit und Sicherheit von Personen beeinträchtigen, Grundrechte negativ beeinflussen oder zu Diskriminierung führen können: Das ist die Pflicht zur Bias-Prüfung. Sie verlangt eine proaktive Prüfung der Datensätze, nicht nur der Modellausgaben, auf Verzerrungen, die Schaden verursachen könnten. Auf die Prüfung müssen geeignete Maßnahmen zur Erkennung, Verhinderung und Minderung dieser Verzerrungen folgen. Einen ausführlichen Leitfaden zur Umsetzung dieser Anforderung finden Sie in unserem eigenen Artikel zu Bias-Tests von KI für die EU-AI-Act-Compliance.

Relevant, repräsentativ und fehlerfrei (Artikel 10(3))

Artikel 10(3) setzt drei Qualitätsstandards für Trainings-, Validierungs- und Testdatensätze:

1. Relevant: Die Daten müssen für die Zweckbestimmung relevant sein. Ein System, das Kreditrisiken bewerten soll, muss auf Daten trainiert werden, die tatsächlich mit Kreditwürdigkeit zusammenhängen, nicht auf nur am Rande verwandten Proxys.

2. Hinreichend repräsentativ: Die Datensätze müssen für die Personen oder Bedingungen repräsentativ sein, bei denen das System eingesetzt wird. Ein EU-weit eingesetztes Recruiting-Tool muss auf Daten trainiert werden, die die Vielfalt des EU-Arbeitsmarktes abbilden, nicht auf Daten aus einem einzigen Land oder einer einzigen demografischen Gruppe.

3. So weit wie möglich fehlerfrei und vollständig: Die Verordnung verwendet realistische Sprache, "so weit wie möglich", und erkennt an, dass perfekte Daten nicht existieren. Aber sie verlangt eine nachweisbare, dokumentierte Anstrengung, Fehler zu erkennen und zu korrigieren, fehlende Werte zu behandeln und Vollständigkeit sicherzustellen.

Diese drei Standards schaffen eine fortlaufende Pflicht. Ändert sich der Einsatzkontext, etwa wenn ein auf niederländischen Gesundheitsdaten trainiertes System in Rumänien eingesetzt wird, muss die Bewertung der Repräsentativität aktualisiert werden.

Berücksichtigung spezifischer geografischer, kontextueller und verhaltensbezogener Rahmenbedingungen (Artikel 10(4))

Artikel 10(4) verlangt, dass Datensätze die spezifischen geografischen, kontextuellen, verhaltensbezogenen oder funktionalen Rahmenbedingungen berücksichtigen, in denen das System eingesetzt werden soll. Diese Vorschrift zielt auf einen häufigen Fehlermodus: Systeme, die in der Umgebung, in der sie entwickelt wurden, gut funktionieren, aber versagen, wenn sie in einem anderen Kontext eingesetzt werden.

Praxisbeispiel: Ein Betrugserkennungssystem, das auf Transaktionsmustern nordeuropäischer Bankenmärkte trainiert wurde, funktioniert womöglich nicht genau, wenn es in südeuropäischen Märkten eingesetzt wird, wo sich Zahlungsverhalten, Transaktionsvolumina und Betrugsmuster deutlich unterscheiden. Artikel 10(4) verlangt vom Anbieter, diese Unterschiede in den Trainingsdaten zu berücksichtigen.

Das gilt genauso für den sprachlichen Kontext (ein System muss die Sprachen und Dialekte seines Einsatzmarktes beherrschen), den zeitlichen Kontext (Daten von 2019 bilden vielleicht kein Verhalten nach der Pandemie ab) und den demografischen Kontext.

Verarbeitung besonderer Kategorien personenbezogener Daten (Artikel 10(5))

Artikel 10(5) behandelt eine der heikelsten Schnittstellen der KI-Regulierung: die Notwendigkeit, Daten über ethnische Herkunft, Geschlecht, Gesundheit, Religion, sexuelle Orientierung und andere geschützte Merkmale zu verarbeiten, um Verzerrungen zu erkennen und zu korrigieren, obwohl die Verarbeitung solcher Daten nach DSGVO Artikel 9 grundsätzlich verboten ist.

Der AI Act löst diese Spannung, indem er eine spezifische Rechtsgrundlage für die Verarbeitung besonderer Kategorien von Daten schafft, aber nur, wenn alle folgenden Bedingungen erfüllt sind:

• Die Verarbeitung ist für den Zweck der Bias-Überwachung, -Erkennung und -Korrektur unbedingt erforderlich.
• Die Verarbeitung unterliegt geeigneten Schutzvorkehrungen für die Grundrechte und Grundfreiheiten natürlicher Personen.
• Diese Schutzvorkehrungen umfassen technische Beschränkungen der Weiterverwendung und den Einsatz von dem Stand der Technik entsprechenden Sicherheits- und Datenschutzmaßnahmen wie Pseudonymisierung oder Verschlüsselung, wenn eine Anonymisierung den verfolgten Zweck erheblich beeinträchtigen würde.
• Die besonderen Kategorien von Daten müssen gelöscht werden, sobald die Verzerrung korrigiert wurde oder die Aufbewahrungsfrist abgelaufen ist, je nachdem, was zuerst eintritt.
• Der Anbieter muss Aufzeichnungen führen, warum die Verarbeitung erforderlich war und welche Schutzvorkehrungen angewandt wurden.

Das ist für Compliance-Teams bedeutsam. Es heißt, Sie dürfen, und in vielen Fällen sollten Sie, demografische Daten zum Zweck von Bias-Tests erheben. Aber die Schutzvorkehrungen sind nicht verhandelbar. Daten müssen pseudonymisiert, zugriffsbeschränkt, zweckgebunden und gelöscht werden, wenn sie nicht mehr benötigt werden. Für eine tiefere Analyse dieser Überschneidung siehe unseren Leitfaden zum Zusammenspiel von AI Act und DSGVO.

Zusammenfassung der Anforderungen aus Artikel 10

Trainings-, Validierungs- und Testdatensätze, was Sie dokumentieren müssen

Artikel 10 existiert nicht isoliert. Seine Anforderungen fließen direkt in die technische Dokumentation nach Anhang IV ein, besonders in Abschnitt 2 (detaillierte Angaben zum Entwicklungsprozess, einschließlich der Daten). Hier ist, was Sie für jeden Datensatztyp dokumentieren müssen.

Datenherkunft und Ursprung

Für jeden Datensatz, der beim Training, bei der Validierung oder beim Test verwendet wird, müssen Sie beantworten können:

• Woher kamen die Daten? Identifizieren Sie jede Quelle, interne Datenbanken, Drittanbieter von Daten, öffentliche Datensätze, Web Scraping, nutzergenerierte Inhalte, synthetische Erzeugung oder andere Ursprünge.
• Wann wurden die Daten erhoben? Nennen Sie den Zeitraum und etwaige zeitliche Einschränkungen.
• Wer hat die Daten erhoben? Nennen Sie die für die Erhebung verantwortliche Stelle.
• Auf welcher Rechtsgrundlage? Für personenbezogene Daten nennen Sie die DSGVO-Rechtsgrundlage nach Artikel 6, und für besondere Kategorien von Daten die herangezogene Ausnahme nach Artikel 9.
• Welche Lizenzen oder Bedingungen gelten für die Daten? Für Datensätze von Dritten oder öffentliche Datensätze dokumentieren Sie die Lizenzbedingungen und etwaige Nutzungsbeschränkungen.

Datenherkunft ist nicht nur eine Dokumentationsübung, sie ist ein Haftungsschutz. Wenn ein nachgelagerter Fehler auf eine bestimmte Datenquelle zurückgeführt wird, ermöglichen Herkunftsnachweise, das Problem einzugrenzen und Sorgfalt nachzuweisen.

Methodik der Datenerhebung

Dokumentieren Sie die Methodik, mit der jeder Datensatz erhoben wurde:

• Stichprobenstrategie: Zufalls-, geschichtete, Gelegenheits- oder gezielte Stichprobe? Was war der Stichprobenrahmen?
• Einschluss-/Ausschlusskriterien: Welche Kriterien bestimmten, welche Datenpunkte einbezogen oder ausgeschlossen wurden?
• Annotations-/Kennzeichnungsprozess: Wer hat die Daten gekennzeichnet? Welchen Leitlinien folgten sie? Wie hoch war die Übereinstimmung zwischen den Annotatoren (Inter-Annotator Agreement)?
• Qualitätskontrolle während der Erhebung: Welche Prüfungen wurden während der Erhebung angewandt, um Genauigkeit sicherzustellen?

Statistische Eigenschaften und Repräsentativität

Artikel 10(3) verlangt, dass Datensätze "hinreichend repräsentativ" sind. Um das nachzuweisen, müssen Sie dokumentieren:

• Verteilungen der Schlüsselvariablen: Zusammenfassende Statistiken, Histogramme und Verteilungsanalysen für alle Merkmale, die für den Zweck des Systems relevant sind.
• Demografische Zusammensetzung: Für Systeme, die natürliche Personen betreffen, die demografische Aufschlüsselung des Datensatzes im Vergleich zur Zielpopulation.
• Klassenbalance: Für Klassifizierungsaufgaben die Verteilung der Zielklassen und etwaiges Ungleichgewicht.
• Zeitliche Verteilung: Wie die Daten über die Zeit verteilt sind und ob zeitliche Trends bestehen.
• Geografische Verteilung: Wo sich die betroffenen Personen oder Datenpunkte befinden und wie das zur beabsichtigten Einsatzgeografie passt.

Praxisbeispiel: Ein Anbieter einer Hochrisiko-Recruiting-KI, die in Deutschland, Frankreich und Spanien eingesetzt wird, muss dokumentieren, dass seine Trainingsdaten Bewerber aus allen drei Ländern in Anteilen enthalten, die die Einsatzpopulation abbilden. Wenn 80 % der Trainingsdaten aus Deutschland stammen, aber 40 % der Nutzung in Frankreich erfolgt, muss der Anbieter diese Lücke erklären und die ergriffenen Minderungsmaßnahmen beschreiben (z. B. Oversampling, Domänenanpassung oder separates Modelltuning).

Schritte zur Bias-Identifikation und -Minderung

Hier trifft Artikel 10(2)(f) auf die Anhang-IV-Dokumentation. Sie müssen dokumentieren:

• Welche Verzerrungen geprüft wurden: Die konkreten geprüften Bias-Typen (historisch, Repräsentation, Messung, Aggregation, Bewertung, Einsatz).
• Die verwendete Methodik: Welche Werkzeuge, Kennzahlen und Tests angewandt wurden. Beispiele sind Analyse der demografischen Parität, Tests auf Equalized Odds, Disparate-Impact-Verhältnisse und Vergleiche der Leistung nach Untergruppen.
• Die Ergebnisse: Welche Verzerrungen erkannt wurden, ihr Schweregrad und welche Gruppen betroffen waren.
• Die Minderungsmaßnahmen: Was zur Behebung jeder erkannten Verzerrung getan wurde, Resampling, Reweighting, adversarielles Debiasing, Schwellenanpassung, Datenaugmentierung oder andere Techniken.
• Das Restrisiko: Welche Verzerrung nach der Minderung bleibt und warum sie angesichts der Zweckbestimmung und des Risikoniveaus des Systems als akzeptabel gilt.

Eine Schritt-für-Schritt-Methodik finden Sie in unserem Leitfaden zu Bias-Tests und Fairness von KI.

Erkennung und Schließen von Lücken

Artikel 10(2)(e) verlangt eine Bewertung, ob die verfügbaren Daten ausreichend und geeignet sind. Werden Lücken erkannt, müssen Sie dokumentieren:

• Welche Lücken bestehen: Unterrepräsentierte Untergruppen, fehlende Zeiträume, geografische blinde Flecken, unzureichende Randfälle.
• Wie Lücken erkannt wurden: Durch statistische Analyse, Prüfung durch Fachexperten, Vergleich mit der Zielpopulation oder andere Methoden.
• Wie Lücken behandelt wurden: Datenaugmentierung, Erzeugung synthetischer Daten, zusätzliche Datenerhebung, Transfer Learning oder, wenn Lücken nicht geschlossen werden können, Beschränkungen des Einsatzbereichs des Systems.
• Verbleibende Lücken: Welche Lücken nach der Behebung bleiben und wie sie die Leistung und Fairness des Systems beeinflussen.

Transparenz der Trainingsdaten von GPAI-Modellen

Der AI Act sieht ein eigenes, aber verwandtes Regime für Modelle mit allgemeinem Verwendungszweck nach Artikel 53 vor. Während Artikel 10 die Daten-Governance für Hochrisiko-Systeme regelt, regelt Artikel 53 die Transparenz der Trainingsdaten für GPAI-Modelle, und die beiden Regime überschneiden sich, wenn ein GPAI-Modell in ein Hochrisiko-System integriert wird.

Artikel 53(1)(d), Pflicht zur Zusammenfassung der Trainingsdaten

Artikel 53(1)(d) verlangt von jedem Anbieter eines GPAI-Modells, eine hinreichend detaillierte Zusammenfassung über die für das Training verwendeten Inhalte des Modells mit allgemeinem Verwendungszweck zu erstellen und öffentlich zugänglich zu machen. Diese Zusammenfassung muss nach einer Vorlage des AI Office erstellt werden.

Der Zweck ist zweifach: nachgelagerten Anbietern zu ermöglichen, die Datengrundlagen des Modells zu verstehen, und Rechteinhabern zu ermöglichen, zu erkennen, ob ihre Inhalte im Training verwendet wurden.

Die EU-Vorlage für Transparenz der Trainingsdaten (veröffentlicht Juli 2025)

Das AI Office hat die standardisierte Vorlage für die Zusammenfassung der Trainingsdaten im Juli 2025 nach öffentlicher Konsultation veröffentlicht. Die Vorlage ist ein strukturiertes Dokument, das GPAI-Anbieter ausfüllen und veröffentlichen müssen. Sie ist so gestaltet, dass sie sowohl maschinen- als auch menschenlesbar ist, was eine systematische Analyse durch Regulierer und Forscher ermöglicht.

Was die Vorlage verlangt

Die Transparenzvorlage ist in drei Hauptabschnitte gegliedert:

1. Allgemeine Metadaten:

• Modellname, Version und Veröffentlichungsdatum
• Name und Kontaktdaten des Anbieters
• Modelltyp (Foundation Model, feinabgestimmt, Retrieval-Augmented usw.)
• Unterstützte Modalitäten (Text, Bild, Audio, Video, Code, multimodal)
• Beabsichtigte nachgelagerte Nutzungen und bekannte Grenzen

2. Kategorien und Beschreibungen der Datenquellen:

• Kategorisierte Liste der Datenquellen (z. B. Web-Crawl, lizenzierte Datensätze, gemeinfreie Werke, Behördendaten, nutzerbeigetragene Daten, synthetische Daten)
• Für jede Kategorie: eine Beschreibung der Art der Inhalte, das ungefähre Volumen, die vertretenen Sprachen, die geografische Herkunft und der Zeitraum
• Angabe, ob urheberrechtlich geschützte Werke enthalten sind, und wenn ja, welche Kategorien (Bücher, Nachrichtenartikel, wissenschaftliche Arbeiten, Musik, Bilder, Code-Repositories usw.)
• Alle ausdrücklich ausgeschlossenen Datenquellen und der Grund für den Ausschluss

3. Datenverarbeitung und -Governance:

• Angewandte Verfahren zur Datenfilterung und -bereinigung
• Methodik der Deduplizierung
• Filterung zur Inhaltssicherheit (Entfernung von CSAM, toxischen Inhalten, personenbezogenen Daten)
• Mechanismen zur Qualitätsbewertung oder -auswahl
• Umgang mit personenbezogenen Daten, ob personenbezogene Daten enthalten sind, und wenn ja, welche Kategorien und welche Schutzvorkehrungen angewandt werden
• Opt-out-Mechanismen für betroffene Personen oder Rechteinhaber

Die Vorlage verlangt nicht die Offenlegung der tatsächlichen Trainingsdaten oder der konkreten verwendeten URLs oder Dokumente. Sie verlangt eine Zusammenfassung, detailliert genug, um aussagekräftig zu sein, aber nicht so feingranular, dass sie Geschäftsgeheimnisse preisgibt.

Übergangsfrist: 2. August 2027 für bestehende Modelle

Die GPAI-Pflichten nach Artikel 53 gelten ab dem 2. August 2025 für neue Modelle, die nach diesem Datum auf den Markt gebracht werden. Für GPAI-Modelle, die vor dem 2. August 2025 bereits auf dem Markt waren, gilt eine Übergangsfrist, Anbieter müssen bis zum 2. August 2027 konform sein.

Das gibt bestehenden GPAI-Anbietern zwei Jahre, um Zusammenfassungen der Trainingsdaten für Modelle zu rekonstruieren oder zusammenzustellen, die möglicherweise trainiert wurden, bevor die Transparenzanforderungen bekannt waren.

Verzerrungen in Trainingsdaten, Erkennung und Minderung

Artikel 10(2)(f) verlangt von Anbietern, Datensätze auf Verzerrungen zu prüfen und geeignete Maßnahmen zu ihrer Behebung zu ergreifen. Dieser Abschnitt gibt einen Überblick über die für die Compliance relevanten Bias-Typen, die verfügbaren Testmethoden und die erforderliche Dokumentation. Einen vollständigen technischen Leitfaden finden Sie in unserem eigenen Artikel zu Bias-Tests von KI.

Bias-Typen

Testmethoden

Bias-Tests nach Artikel 10 müssen auf Datenebene (Prüfung der Datensätze vor und während des Trainings) und auf Modellebene (Bewertung der Ausgaben über Untergruppen) durchgeführt werden. Wichtige Ansätze sind:

• Untergruppenanalyse: Leistungskennzahlen (Genauigkeit, Precision, Recall, F1) nach geschützten Merkmalen (Geschlecht, ethnische Herkunft, Alter, Behinderungsstatus) aufschlüsseln.
• Disparate-Impact-Verhältnis: Ergebnisraten über Gruppen hinweg vergleichen. Ein Verhältnis unter 0,8 (Vier-Fünftel-Regel) ist ein häufiger Indikator für nachteilige Auswirkungen.
• Equalized Odds: Prüfen, ob das Modell über Gruppen hinweg gleiche True-Positive- und False-Positive-Raten hat.
• Kontrafaktische Fairness: Geschützte Merkmale in der Eingabe ändern und prüfen, ob sich die Ausgabe ändert.
• Intersektionale Analyse: Auf Verzerrung an der Schnittstelle mehrerer Merkmale prüfen (z. B. Frauen über 50, junge Männer aus ethnischen Minderheiten).

Anforderungen an die Anhang-IV-Dokumentation für Verzerrungen

Anhang IV Abschnitt 2 verlangt, dass die technische Dokumentation Folgendes enthält:

• Eine Beschreibung der durchgeführten Maßnahmen zur Datenprüfung
• Die konkret geprüften Verzerrungen und warum sie ausgewählt wurden
• Die verwendeten Kennzahlen und Schwellen
• Die Ergebnisse der Bias-Tests, einschließlich quantitativer Befunde
• Die angewandten Minderungsmaßnahmen und ihre Wirksamkeit
• Etwaige verbleibende Verzerrung und die Begründung ihrer Akzeptanz
• Den Plan für die laufende Bias-Überwachung im Betrieb

Praxisbeispiel, Kreditwürdigkeitsprüfung: Ein Anbieter eines Hochrisiko-Kreditscoring-Systems, das auf historischen Kreditantragsdaten trainiert wurde, führt die folgende Bias-Bewertung durch:

1. Prüfung auf Selektionsverzerrung: Vergleich der demografischen Zusammensetzung der Trainingsdaten mit Eurostat-Bevölkerungsstatistiken für die Ziel-Einsatzländer. Befund: Frauen im Alter von 18-25 Jahren sind um 12 % unterrepräsentiert. Minderung: geschichtetes Oversampling und synthetische Datenaugmentierung für diese Untergruppe.
2. Prüfung auf historische Verzerrung: Analyse historischer Genehmigungsraten nach ethnischer Herkunft. Befund: Antragsteller mit nicht-europäisch klingenden Namen hatten 15 % niedrigere Genehmigungsraten, selbst nach Kontrolle finanzieller Indikatoren. Minderung: aus Namen abgeleitete Merkmale entfernen; Modell nachtrainieren; validieren, dass die Ungleichheit unter 3 % sinkt.
3. Prüfung auf Messverzerrung: Prüfung der Konsistenz der Einkommensangaben über die Datenquellen. Befund: Einkommen von Selbstständigen wird über drei Datenanbieter hinweg unterschiedlich gemessen. Minderung: Methodik der Einkommensberechnung vereinheitlichen und Annahmen dokumentieren.

Besondere Kategorien personenbezogener Daten

Artikel 10(5) behandelt das Paradox im Kern der KI-Fairness: Um Verzerrungen gegen geschützte Gruppen zu erkennen, brauchen Sie Daten über diese Gruppen, aber die Verarbeitung dieser Daten ist grundsätzlich verboten.

Wann die Verarbeitung nach Artikel 10(5) zulässig ist

Die Verarbeitung besonderer Kategorien von Daten ist nach Artikel 10(5) zulässig, wenn:

1. Verzerrung nicht auf andere Weise überwacht werden kann: Wenn Sie Verzerrungen mit anonymisierten oder nicht-sensiblen Daten erkennen und korrigieren können, müssen Sie das tun. Artikel 10(5) ist ein letztes Mittel, keine Standardoption.
2. Die Verarbeitung unbedingt erforderlich ist: Nicht nur nützlich oder bequem, sondern unbedingt erforderlich für den Zweck der Bias-Überwachung, -Erkennung oder -Korrektur.
3. Geeignete Schutzvorkehrungen bestehen: Technische und organisatorische Maßnahmen müssen die Daten über ihren gesamten Lebenszyklus schützen.

Zusammenspiel mit DSGVO Artikel 9

Artikel 10(5) des AI Act schafft eine sektorspezifische Ausnahme, die mit DSGVO Artikel 9(2)(g) (erhebliches öffentliches Interesse) zusammenwirkt. Die beiden Regime auferlegen jedoch kumulative Pflichten, keine alternativen. Anbieter müssen beide erfüllen:

• Die Schutzvorkehrungs-Anforderungen des AI Act nach Artikel 10(5)
• Die Datenschutzgrundsätze der DSGVO (Rechtmäßigkeit, Zweckbindung, Datenminimierung, Speicherbegrenzung, Integrität und Vertraulichkeit)
• Die Rechenschaftspflichten der DSGVO (DSFA, Verzeichnis der Verarbeitungstätigkeiten, Konsultation des Datenschutzbeauftragten)

Das bedeutet, Sie brauchen sowohl eine DSGVO-konforme Rechtsgrundlage als auch AI-Act-konforme Schutzvorkehrungen. Eine Datenschutz-Folgenabschätzung (DSFA) nach DSGVO Artikel 35 ist faktisch verpflichtend, da die Verarbeitung besonderer Kategorien von Daten zur Bias-Erkennung fast immer die Schwelle für eine "risikoreiche" Verarbeitung nach der DSGVO erreicht.

Für eine umfassende Analyse siehe unseren Artikel zu EU AI Act vs. DSGVO: Unterschiede und Überschneidungen.

Schutzvorkehrungen und Beschränkungen

Mindestens die folgenden Schutzvorkehrungen müssen umgesetzt werden:

• Pseudonymisierung: Direkte Identifikatoren durch Pseudonyme ersetzen. Echte Anonymisierung ist vorzuziehen, wo sie den Zweck der Bias-Erkennung nicht untergräbt.
• Verschlüsselung: Verschlüsselung im Ruhezustand und bei der Übertragung für alle besonderen Kategorien von Daten anwenden.
• Zugriffskontrollen: Zugriff auf besondere Kategorien von Daten auf eine definierte Gruppe befugter Personen mit dokumentiertem Bedarf beschränken.
• Zweckbindung: Besondere Kategorien von Daten dürfen nur zur Bias-Überwachung, -Erkennung und -Korrektur verwendet werden, niemals zum Modelltraining oder für andere Zwecke.
• Aufbewahrungsgrenzen: Besondere Kategorien von Daten löschen, sobald die Bias-Analyse abgeschlossen ist oder die Aufbewahrungsfrist abläuft, je nachdem, was früher eintritt.
• Protokollierung und Prüfspuren: Aufzeichnungen über jeden Zugriff auf und jede Verarbeitung von besonderen Kategorien von Daten führen.
• Technische Beschränkungen der Weiterverwendung: Technische Kontrollen (nicht nur Richtlinien) umsetzen, die verhindern, dass die Daten für andere Zwecke weiterverwendet werden.

Umsetzungsleitfaden, Artikel-10-Compliance erreichen

Compliance mit Artikel 10 ist keine einzelne Lieferung. Sie ist eine Reihe laufender Praktiken, die in Ihren KI-Entwicklungslebenszyklus eingebettet sind. Der folgende Schritt-für-Schritt-Leitfaden bietet einen strukturierten Ansatz.

Schritt 1: Ihre Datensätze inventarisieren

Bevor Sie Ihre Daten steuern können, müssen Sie wissen, was Sie haben. Erstellen Sie ein umfassendes Verzeichnis aller Datensätze, die für Training, Validierung und Test jedes Hochrisiko-KI-Systems verwendet werden.

Checkliste:

• Alle Trainingsdatensätze mit Quelle, Größe, Format und Erwerbsdatum auflisten
• Alle Validierungsdatensätze mit denselben Angaben auflisten
• Alle Testdatensätze mit denselben Angaben auflisten
• Identifizieren, welche Datensätze personenbezogene Daten und welche besondere Kategorien von Daten enthalten
• Datenflüsse von der Quelle bis zum Modell abbilden

Schritt 2: Daten-Governance-Richtlinien etablieren

Definieren und dokumentieren Sie Governance-Richtlinien, die die Anforderungen aus Artikel 10(2) abdecken.

Checkliste:

• Datenqualitätsrichtlinie (Bereinigung, Fehlerkorrektur, Vollständigkeitsprüfungen)
• Datenerhebungsrichtlinie (Quellen, Methoden, Einwilligung/Rechtsgrundlage)
• Datenkennzeichnungsrichtlinie (Leitlinien, Schulung der Annotatoren, Qualitätssicherung)
• Richtlinie zu Datenaufbewahrung und -löschung
• Richtlinie zur Datenzugriffskontrolle
• Richtlinie zu Datenversionierung und Änderungsmanagement

Schritt 3: Repräsentativität bewerten

Vergleichen Sie Ihre Datensätze entlang aller relevanten Dimensionen mit der Ziel-Einsatzpopulation.

Checkliste:

• Zielpopulation für jedes Hochrisiko-System identifizieren
• Demografie des Datensatzes mit der Demografie der Zielpopulation vergleichen
• Geografische Verteilung des Datensatzes mit der Einsatzgeografie vergleichen
• Zeitliche Verteilung des Datensatzes mit dem beabsichtigten Betriebszeitraum vergleichen
• Etwaige Lücken dokumentieren und einen Behebungsplan festlegen

Schritt 4: Bias-Prüfung durchführen

Führen Sie die von Artikel 10(2)(f) verlangte Bias-Prüfung durch.

Checkliste:

• Zu prüfende Bias-Typen anhand des Systemkontexts und Risikoprofils auswählen
• Geeignete Fairness-Kennzahlen und Schwellen wählen
• Bias-Analyse auf Datenebene durchführen (Verteilungsanalyse, Repräsentationsprüfungen)
• Bias-Analyse auf Modellebene durchführen (Leistung nach Untergruppen, Disparate Impact, Equalized Odds)
• Alle Befunde dokumentieren, einschließlich negativer Ergebnisse (keine Verzerrung gefunden)
• Minderungsmaßnahmen für erkannte Verzerrungen umsetzen
• Validieren, dass die Minderungsmaßnahmen wirksam sind
• Verbleibende Verzerrung und Begründung dokumentieren

Schritt 5: Alles im Anhang-IV-Format dokumentieren

Fassen Sie alles Obige in der technischen Dokumentation nach Anhang IV, Abschnitt 2, zusammen.

Checkliste:

• Designentscheidungen dokumentiert und begründet
• Datenherkunft für alle Datensätze festgehalten
• Datenaufbereitungsvorgänge dokumentiert
• Annahmen explizit gemacht
• Bewertung von Verfügbarkeit und Eignung abgeschlossen
• Ergebnisse der Bias-Prüfung und Minderung dokumentiert
• Statistische Eigenschaften und Repräsentativitätsanalyse aufgenommen
• Verarbeitung besonderer Kategorien von Daten mit Schutzvorkehrungen dokumentiert

Schritt 6: Laufende Überwachung etablieren

Artikel-10-Compliance ist kein einmaliges Tor. Datenqualität und Repräsentativität müssen über den Lebenszyklus des Systems hinweg überwacht werden, wie es die Marktbeobachtungspflichten aus Artikel 72 verlangen.

Checkliste:

• Datenqualitätskennzahlen und Überwachungshäufigkeit definieren
• Data-Drift-Erkennung für Produktionsdaten umsetzen
• Periodische Neuprüfung auf Verzerrungen einplanen (mindestens jährlich oder bei wesentlichen Änderungen)
• Auslöser für eine Neuvalidierung des Datensatzes definieren (neue Einsatzgeografie, Regulierungsänderung, Leistungsverschlechterung)
• Überwachung der Daten-Governance in das gesamte Compliance-Programm integrieren

Häufig gestellte Fragen

Gilt Artikel 10, wenn ich ein vortrainiertes Modell oder Foundation Model nutze?

Ja. Wenn Sie ein vortrainiertes oder Foundation Model feinabstimmen, anpassen oder in ein Hochrisiko-KI-System integrieren, sind Sie der Anbieter dieses Systems, und Artikel 10 gilt für die Daten, die Sie für Fine-Tuning, Validierung und Test verwenden. Für die zugrunde liegenden Vortrainingsdaten gelten die GPAI-Transparenzpflichten nach Artikel 53 für den Anbieter des GPAI-Modells. Sie sollten die Zusammenfassung der Trainingsdaten des GPAI-Anbieters anfordern und bewerten, ob die Vortrainingsdaten für Ihre Zweckbestimmung geeignet sind.

Was, wenn meine Trainingsdaten vollständig synthetisch sind?

Synthetische Daten sind von Artikel 10 nicht ausgenommen. Die Daten-Governance-Anforderungen gelten unabhängig davon, ob die Daten echt, synthetisch oder eine Kombination sind. Sie müssen die Erzeugungsmethodik dokumentieren, überprüfen, dass die synthetischen Daten keine Verzerrungen einführen oder verstärken, und bewerten, ob sie für reale Bedingungen repräsentativ sind. Synthetische Daten können helfen, Repräsentationslücken zu schließen, aber sie bringen neue Risiken mit sich, etwa Mode Collapse oder die Verstärkung von Mustern der Ausgangsdaten, die dokumentiert und beherrscht werden müssen.

Wie wirkt Artikel 10 mit der Datenminimierung der DSGVO zusammen?

Es besteht eine inhärente Spannung. DSGVO Artikel 5(1)(c) verlangt Datenminimierung, nur das zu erheben, was notwendig ist. Artikel 10 verlangt hinreichend repräsentative und umfassende Datensätze. Der AI Act löst das in Erwägungsgrund 67, indem er klarstellt, dass Anbieter personenbezogene Daten in dem Umfang verarbeiten dürfen, der für die Bias-Überwachung, -Erkennung und -Korrektur notwendig ist, unter geeigneten Schutzvorkehrungen. Der Schlüssel ist die Zweckbestimmung: Sie müssen klar benennen, welche Daten für welchen Zweck benötigt werden, und dürfen "KI-Training" nicht als pauschale Rechtfertigung für unbegrenzte Datenerhebung nutzen. Eine ordentlich durchgeführte Datenschutz-Folgenabschätzung (DSFA) hilft, diese Balance zu finden.

Welches Maß an Datenqualität ist "gut genug" für die Compliance?

Artikel 10(3) verwendet die Formulierung "so weit wie möglich fehlerfrei und vollständig". Das ist ein Angemessenheitsmaßstab, kein Perfektionsmaßstab. Sie müssen nachweisen, dass Sie angemessene, dokumentierte Schritte unternommen haben, um Fehler zu erkennen und zu korrigieren, fehlende Werte zu behandeln und Datenqualität sicherzustellen. Was "angemessen" ist, hängt vom Risikoniveau ab, ein System, das KI-generierte Bilder klassifiziert, hat eine niedrigere Datenqualitätsschwelle als ein System, das über die Berechtigung für Sozialleistungen entscheidet. Dokumentieren Sie Ihre Qualitätsprozesse, Ihre Fehlerraten und Ihre Begründung, warum Sie das verbleibende Qualitätsniveau für akzeptabel halten.

Muss ich meine Trainingsdaten bei jedem Nachtraining erneut auf Verzerrungen prüfen?

Ja. Jeder Nachtrainings-Zyklus kann neue Daten einbringen, Datenverteilungen ändern oder das Verhältnis des Modells zu geschützten Gruppen verändern. Artikel 10(2)(f) und die Risikomanagement-Pflichten nach Artikel 9 verlangen eine laufende Prüfung. In der Praxis sollten Sie die Bias-Prüfung in Ihre CI/CD-Pipeline integrieren, sodass sie mit jedem Nachtrainings-Zyklus automatisch läuft, und tiefere manuelle Prüfungen in definierten Abständen oder bei Auslösung durch Überwachungsalarme durchführen.

Was passiert, wenn ich keine repräsentativen Daten für meine Einsatzpopulation beschaffen kann?

Wenn für einen bestimmten Einsatzkontext keine repräsentativen Daten verfügbar sind, etwa wenn Ihnen Trainingsdaten aus einem bestimmten EU-Mitgliedstaat fehlen, in dem das System eingesetzt wird, haben Sie mehrere Möglichkeiten: (1) den Einsatz auf Kontexte beschränken, für die Sie repräsentative Daten haben, und diese Beschränkungen in der Betriebsanleitung dokumentieren; (2) Transfer-Learning- oder Domänenanpassungs-Techniken nutzen und die Leistung im Zielkontext validieren; (3) synthetische Daten erzeugen, die die Repräsentativitätslücke schließen; oder (4) zusätzliche Daten erheben. Was Sie nicht tun dürfen: das System in Kontexten einsetzen, in denen Sie wissen, dass die Daten nicht repräsentativ sind, ohne diese Einschränkung Betreibern und Nutzern offenzulegen.

Nächste Schritte

Die Daten-Governance nach Artikel 10 ist ein Baustein einer breiteren Compliance-Pflicht. Um ein vollständiges Compliance-Programm aufzubauen, prüfen Sie:

• EU-AI-Act-Compliance-Checkliste 2026, Eine strukturierte Checkliste, die alle Anbieterpflichten abdeckt.
• Pflichten für GPAI-Modelle, Transparenz der Trainingsdaten und andere GPAI-Anforderungen.
• Leitfaden zu Bias-Tests von KI, Technische Umsetzung der Bias-Erkennung und -Minderung.
• Technische Dokumentation nach Anhang IV, Wie Sie Ihre Dokumentation strukturieren, einschließlich Abschnitt 2 zu Daten.
• AI Act vs. DSGVO, Der Umgang mit der Überschneidung von Datenschutz und KI-Regulierung.
• Marktbeobachtung, Laufende Beobachtungspflichten, die Datenqualität und Verzerrungen einschließen.

Nicht sicher, ob Ihr KI-System hochriskant ist? Machen Sie unsere kostenlose AI-Act-Risikobewertung, um es in fünf Minuten herauszufinden.