Published on

Art. 10 EU AI Act: Daten und Daten-Governance

Authors

Art. 10 ist die datenbezogene Konkretisierung des Risikomanagements. Während Art. 9 den Prozess vorgibt, adressiert Art. 10 die Ressource, aus der datengetriebene Hochrisiko-Systeme ihre Eigenschaften beziehen: die Trainings-, Validierungs- und Testdatensätze. Die Norm ist juristisch anspruchsvoll, weil sie technische Qualitätsanforderungen mit datenschutzrechtlichen Grenzen verschränkt — und weil sie an einer Stelle eine Verarbeitungsbefugnis für besondere Kategorien personenbezogener Daten schafft, die im Verhältnis zur DSGVO gesondert begründet werden muss.

Normtext

Art. 10 Abs. 1: Hochrisiko-KI-Systeme, in denen Techniken eingesetzt werden, bei denen KI-Modelle mit Daten trainiert werden, werden auf der Grundlage von Trainings-, Validierungs- und Testdatensätzen entwickelt, die den in den Absätzen 2 bis 5 genannten Qualitätskriterien entsprechen, wenn solche Datensätze verwendet werden.

Art. 10 Abs. 2: Für Trainings-, Validierungs- und Testdatensätze gelten Datenverwaltungs- und Datenverwaltungsverfahren, die für die Zweckbestimmung des Hochrisiko-KI-Systems geeignet sind. Diese Verfahren betreffen insbesondere die relevanten Entwurfsentscheidungen, die Datenerhebungsverfahren und die Herkunft der Daten, die Datenaufbereitungsvorgänge, die Aufstellung von Annahmen, die Bewertung von Verfügbarkeit, Menge und Eignung der Datensätze, die Untersuchung im Hinblick auf mögliche Verzerrungen, geeignete Maßnahmen zu deren Erkennung, Verhinderung und Abschwächung sowie die Ermittlung relevanter Datenlücken oder Mängel. (Wortlaut gekürzt.)

Art. 10 Abs. 3: Die Trainings-, Validierungs- und Testdatensätze müssen im Hinblick auf die Zweckbestimmung relevant, hinreichend repräsentativ und so weit wie möglich fehlerfrei und vollständig sein. Sie müssen die geeigneten statistischen Merkmale haben, auch bezüglich der Personen oder Personengruppen, für die das Hochrisiko-KI-System bestimmungsgemäß verwendet werden soll.

Art. 10 Abs. 6: Bei der Entwicklung von Hochrisiko-KI-Systemen, die nicht mit Daten trainiert werden, gelten die Absätze 2 bis 5 nur für Testdatensätze.

Einordnung

Art. 10 steht im Abschnitt 2 des Kapitels III zwischen dem Risikomanagement (Art. 9) und der technischen Dokumentation (Art. 11). Diese Stellung ist kein Zufall: Die Datengüte ist einer der Faktoren, die Art. 9 als Risikoquelle zu erfassen hat, und die Dokumentationspflicht des Art. 11 nimmt über Anhang IV die Datenherkunft und -aufbereitung ausdrücklich auf. Wer Art. 10 isoliert liest, übersieht, dass die Norm operativ erst über Art. 9 ausgelöst und über Art. 11 nachweispflichtig wird.

Systematisch bemerkenswert ist die Reichweitenbegrenzung des Abs. 1 in Verbindung mit Abs. 6. Die vollen Anforderungen gelten für Systeme, deren Modelle mit Daten trainiert werden. Für regelbasierte oder anderweitig nicht trainierte Hochrisiko-Systeme reduziert Abs. 6 den Anwendungsbereich auf Testdatensätze. Damit entfällt die Norm nicht — sie schrumpft auf den Nachweis, dass die Erprobung selbst auf tragfähiger Datengrundlage erfolgt ist.

Das Verhältnis zur DSGVO ist komplementär, nicht verdrängend. Art. 10 begründet Qualitätsanforderungen an Daten; er ersetzt keine Rechtsgrundlage für deren Verarbeitung. Nur Abs. 5 enthält eine eigenständige, eng begrenzte Verarbeitungsbefugnis.

Erwägungsgründe

Prägend ist Erwägungsgrund 67, der die Datenqualität als eine Voraussetzung dafür beschreibt, dass Hochrisiko-KI-Systeme bestimmungsgemäß und sicher funktionieren und nicht zur Quelle einer nach Unionsrecht verbotenen Diskriminierung werden. Der Erwägungsgrund verknüpft Repräsentativität und Fehlerfreiheit ausdrücklich mit dem Zweck des Systems: Der Maßstab ist relativ, nicht absolut. Er erläutert zudem, dass sich die Anforderungen an Datensätze auch durch den Rückgriff auf Dritte erfüllen lassen — die Verantwortung des Anbieters bleibt davon unberührt.

Erwägungsgrund 70 trägt die Ausnahme des Abs. 5: Die Verarbeitung besonderer Datenkategorien zur Erkennung und Korrektur von Verzerrungen wird als Ausnahmefall behandelt, der nur greift, wenn sich das Ziel nicht mit synthetischen, anonymisierten oder sonstigen Daten erreichen lässt. Die dort genannten Schutzvorkehrungen sind damit nicht Beiwerk, sondern Tatbestandsvoraussetzung der Befugnis.

Auslegung

„Geeignete" Datenverwaltungsverfahren (Abs. 2). Der Katalog des Abs. 2 ist ein Regelbeispielkatalog („insbesondere"), keine abschließende Liste. Die Verfahren müssen der Zweckbestimmung angemessen sein — was bei einem System zur Kreditwürdigkeitsprüfung anderes verlangt als bei einem System zur Steuerung kritischer Infrastruktur. Juristisch bedeutsam ist die Aufnahme des ursprünglichen Erhebungszwecks bei personenbezogenen Daten: Sie zwingt Anbieter, die Zweckänderung gegenüber der ursprünglichen Erhebung offenzulegen und datenschutzrechtlich zu tragen.

Bias-Untersuchung als Pflicht, nicht als Kür. Abs. 2 verlangt sowohl die Untersuchung auf mögliche Verzerrungen als auch geeignete Maßnahmen zu deren Erkennung, Verhinderung und Abschwächung. Der Tatbestand nennt drei Anknüpfungspunkte: Beeinträchtigung von Gesundheit und Sicherheit, negative Auswirkungen auf Grundrechte, und Verzerrungen, die zu einer nach Unionsrecht verbotenen Diskriminierung führen. Erfasst sind ausdrücklich auch Rückkopplungseffekte, bei denen Ausgaben des Systems als Eingaben künftiger Betriebsvorgänge wirken. Strittig ist, welche Bias-Metriken den Anforderungen genügen; die Verordnung schreibt keine vor und delegiert die Konkretisierung faktisch an harmonisierte Normen und den Stand der Technik.

„So weit wie möglich fehlerfrei und vollständig" (Abs. 3). Die Formulierung ist eine Verhältnismäßigkeitsklausel. Sie verlangt keine perfekten Datensätze, sondern eine begründete Ausschöpfung des Machbaren. Der eigentliche Prüfmaßstab liegt in der Repräsentativität und in den „geeigneten statistischen Merkmalen" — insbesondere im Hinblick auf die Personengruppen, für die das System bestimmt ist. Praktisch verschiebt das die Beweislast: Anbieter müssen darlegen können, gegen welche Referenzpopulation sie Repräsentativität geprüft haben.

Kontextuelle Merkmale (Abs. 4). Datensätze müssen, soweit für die Zweckbestimmung erforderlich, die geografischen, kontextuellen, verhaltensbezogenen oder funktionalen Rahmenbedingungen des vorgesehenen Einsatzes berücksichtigen. Für Anbieter, die ein System in mehreren Rechtsräumen anbieten — DE, EU27-Rest, UK, CH —, ist das keine theoretische Anforderung: Ein Datensatz, der eine Population abbildet, trägt die Repräsentativitätsaussage für eine andere nicht automatisch.

Die Ausnahme des Abs. 5. Die Verarbeitung besonderer Kategorien personenbezogener Daten ist nur zulässig, soweit sie für die Erkennung und Korrektur von Verzerrungen unbedingt erforderlich ist, und nur unter kumulativen Vorkehrungen: Vorrang alternativer Daten, technische Beschränkungen der Weiterverwendung, Sicherheits- und Pseudonymisierungsmaßnahmen nach dem Stand der Technik, strikte Zugriffsbeschränkung mit Vertraulichkeitsbindung, keine Übermittlung an Dritte, Löschung nach Behebung der Verzerrung oder Ablauf der Aufbewahrungsfrist sowie Dokumentation der Gründe. Der Ausnahmecharakter ist eng zu handhaben; die Dokumentationspflicht ist zugleich die Stelle, an der die Zulässigkeit später überprüfbar wird.

Praxis-Konsequenzen

Für Provider verlagert Art. 10 den Compliance-Schwerpunkt nach vorn in die Entwicklung. Datenherkunft, Aufbereitungsschritte, getroffene Annahmen und Bias-Prüfungen müssen zum Zeitpunkt der Konformitätsbewertung als nachvollziehbare Kette vorliegen — nicht als nachträgliche Beschreibung. Bewährt hat sich, jede Datensatz-Version mit dem zugehörigen Prüfbefund und der daraus abgeleiteten Maßnahme zu verknüpfen, so dass sich der Weg von der Datenquelle bis zur Modellversion prüffähig rekonstruieren lässt. Genau darin liegt der Unterschied zwischen einer Behauptung über Datenqualität und einem evidenzbasierten, audit-fähigen Nachweis.

Für Deployer wirkt Art. 10 mittelbar, aber nicht folgenlos. Wer ein Hochrisiko-System betreibt und es mit eigenen Eingabedaten speist, trifft nach Art. 26 eine eigene Pflicht zur Eignung dieser Daten. Beim Fremdbezug von Modellen oder Datensätzen wird die Datengüte damit zum Vertrags- und Nachweisthema gegenüber dem Anbieter. Maßgeblicher Stichtag für die Anwendbarkeit des Hochrisiko-Regimes bleibt der Forcing Event am 02.12.2027 nach den Übergangsregeln des Art. 113 — die Datenhistorie, die Art. 10 verlangt, entsteht jedoch lange vorher und lässt sich nicht rückwirkend erzeugen.

Verweise

Eine systematische Operationalisierung der KI-Verordnung als Trust-Infrastructure: aegira.ai.

Discuss on Twitter • View on GitHub