Artikel 10 der KI-Verordnung stellt Anforderungen an die Daten, mit denen ein Hochrisiko-System trainiert, validiert und getestet wird. Er ist der Artikel, der in der Praxis am häufigsten unterschätzt wird — nicht weil die Anforderungen schwer verständlich wären, sondern weil ihre Erfüllung Wissen voraussetzt, das oft nicht mehr existiert.
Der Kern lässt sich in einer Frage zusammenfassen: Können Sie sagen, woher jeder Datensatz stammt, mit dem Ihr System trainiert wurde, und unter welchen Bedingungen er erhoben wurde? Für viele über Jahre gewachsene Datenbestände lautet die ehrliche Antwort nein.
Was der Artikel verlangt
Die Anforderungen betreffen mehrere Dimensionen. Die Daten müssen für den vorgesehenen Zweck relevant und hinreichend repräsentativ sein. Sie sollen so weit wie möglich fehlerfrei und vollständig sein. Erhebungsverfahren und Herkunft sind zu dokumentieren. Und es ist zu prüfen, ob die Daten Verzerrungen enthalten, die zu diskriminierenden Ergebnissen führen können.
Das Wort repräsentativ ist dabei nicht abstrakt gemeint. Repräsentativ wofür? Für die Personen und Situationen, auf die das System angewendet wird. Ein Datensatz, der eine Gruppe systematisch unterrepräsentiert, erzeugt für diese Gruppe schlechtere Ergebnisse — und das ist genau der Fall, den der Artikel adressiert.
Herkunft ist der teuerste Punkt
Von allen Anforderungen ist die Dokumentation der Datenherkunft die aufwendigste, weil sie rückwirkend gilt. Ein System, das mit einem über Jahre zusammengetragenen Bestand trainiert wurde, müsste diese Herkunft nachträglich rekonstruieren — und häufig lässt sich das schlicht nicht mehr belegen.
Daraus folgt eine unangenehme, aber klare Konsequenz: Für neue Datenbestände ist die Erfassung der Herkunft ab dem ersten Tag ungleich billiger als jede spätere Rekonstruktion. Wer heute Daten sammelt, ohne festzuhalten, woher sie kommen, baut eine Schuld auf, die später mit Zinsen fällig wird.
Verzerrungen finden heisst, danach zu suchen
Die Prüfung auf Verzerrungen ist keine Formalie und lässt sich nicht durch eine Aussage erledigen. Sie verlangt, die Daten entlang der Merkmale zu betrachten, bei denen eine Ungleichbehandlung problematisch wäre — und dann zu prüfen, ob die Ergebnisse des Systems über diese Gruppen hinweg vergleichbar ausfallen.
Der methodische Fallstrick: Wer nur die Gesamtgenauigkeit betrachtet, sieht das Problem nicht. Ein System kann insgesamt gut abschneiden und für eine kleine Gruppe deutlich schlechter — und weil die Gruppe klein ist, verschwindet dieser Effekt im Durchschnitt. Die Auswertung muss deshalb nach Gruppen aufgeschlüsselt erfolgen.
Der Zusammenhang mit dem Datenschutz
Artikel 10 und die datenschutzrechtlichen Anforderungen überschneiden sich, sind aber nicht deckungsgleich. Der Datenschutz fragt nach Rechtmässigkeit, Zweckbindung und Rechten der Betroffenen. Artikel 10 fragt zusätzlich nach Eignung, Repräsentativität und Verzerrung — Fragen, die datenschutzrechtlich nicht gestellt werden.
Ein Datensatz kann datenschutzkonform erhoben und für den Zweck ungeeignet sein. Umgekehrt kann ein methodisch hervorragender Datensatz rechtswidrig zustande gekommen sein. Beide Prüfungen gehören getrennt geführt, weil sie unterschiedliche Fragen beantworten.
Was bei zugekauften Modellen gilt
Wer ein Modell nicht selbst trainiert, sondern ein fertiges System einsetzt, kann die Datenanforderungen nicht selbst erfüllen — die nötigen Angaben liegen beim Anbieter. Damit verschiebt sich die Aufgabe in die Beschaffung: Welche Auskunft gibt der Anbieter zu Datengrundlage, Repräsentativität und Verzerrungspruefung?
Ein Anbieter, der diese Fragen nicht beantwortet, macht die eigene Konformität unmöglich, unabhängig von der Qualität seines Produkts. Diese Frage vor dem Vertragsschluss zu stellen kostet nichts; sie danach zu stellen kostet die Wahlfreiheit.
Ein pragmatischer Einstieg
Für bestehende Systeme lohnt eine Bestandsaufnahme in drei Schritten. Erstens: Welche Datensätze werden tatsächlich verwendet, und welche liegen nur herum? Zweitens: Was ist zu ihrer Herkunft noch belegbar, und wo ist die Lücke? Drittens: Für welche Merkmale ist eine Ungleichbehandlung überhaupt denkbar, und liegen die Daten vor, um das zu prüfen?
Das Ergebnis dieser drei Schritte ist selten erfreulich und immer nützlich. Es zeigt, was mit vertretbarem Aufwand nachweisbar ist und wo die Alternative lautet, einen Datenbestand neu aufzubauen oder das System in seinem Einsatzbereich zu begrenzen.