Template: Datenqualitäts-Statement nach Art. 10 EU AI Act

Wofür

Das Datenqualitäts-Statement dokumentiert, dass die Trainings-, Validierungs- und Testdaten eines Hochrisiko-KI-Systems den Data-Governance-Anforderungen des EU AI Act genügen. Es ist das zentrale Evidenz-Artefakt für die Frage, die Auditoren und Konformitätsbewertungsstellen bei datengetriebenen Systemen zuerst stellen: Woher kommen die Daten, sind sie für den Zweck geeignet, und wie wurde auf Verzerrungen geprüft? Das Statement wird pro KI-System und pro relevantem Datensatz geführt und bei jedem wesentlichen Daten-Update fortgeschrieben.

Wann es Pflicht ist

Art. 10 der KI-Verordnung (VO 2024/1689) verpflichtet Provider von Hochrisiko-KI-Systemen, die mit Daten trainiert werden, zu Daten-Governance- und Datenverwaltungsverfahren für Trainings-, Validierungs- und Testdatensätze. Die Datensätze müssen relevant, hinreichend repräsentativ und — so weit wie möglich — fehlerfrei und vollständig im Hinblick auf die Zweckbestimmung sein. Verlangt wird außerdem die Untersuchung auf mögliche Verzerrungen (Bias), die sich auf Gesundheit, Sicherheit oder Grundrechte auswirken oder zu verbotener Diskriminierung führen können. Die Dokumentation dieser Verfahren fließt in die technische Dokumentation nach Anhang IV ein — das Statement ist der praktikable Weg, diese Nachweise strukturiert vorzuhalten. Für Deployer ist es zugleich das Dokument, das sie beim Provider-Onboarding anfordern sollten.

Das Artefakt selbst

# Datenqualitäts-Statement — [KI-System-Name], Version [X.Y]

## 1. Geltungsbereich
- KI-System / Modell-Version:
- Datensatz-ID(s) und Version(en):
- Verwendungszweck der Daten: [ ] Training [ ] Validierung [ ] Test
- Verantwortlich (Rolle, nicht Person):
- Datum / Review-Zyklus:

## 2. Herkunft und Erhebung (Art. 10 Abs. 2 lit. b)
- Datenquellen (intern / extern / lizenziert / synthetisch):
- Erhebungsverfahren und -zeitraum:
- Rechtsgrundlage der Verarbeitung (Verweis auf DSGVO-Doku):

## 3. Design-Entscheidungen (Art. 10 Abs. 2 lit. a)
- Annahmen über die Daten und ihre Aussagekraft:
- Aufbereitungsschritte (Labeling, Cleaning, Anreicherung, Aggregation):

## 4. Eignung für die Zweckbestimmung (Art. 10 Abs. 3)
- Relevanz: warum diese Daten für den Intended Purpose:
- Repräsentativität: abgedeckte Populationen / Segmente / Geografien:
- Bekannte Lücken und Ausschlüsse + Kompensationsmaßnahmen:
- Statistische Eigenschaften (Verteilungen, Klassenbalance):

## 5. Bias-Untersuchung (Art. 10 Abs. 2 lit. f, g)
- Geprüfte Verzerrungsarten und betroffene Merkmale:
- Methode(n) der Prüfung:
- Befunde:
- Mitigationsmaßnahmen und Restrisiko:

## 6. Besondere Kategorien personenbezogener Daten (Art. 10 Abs. 5)
- Verwendet? [ ] nein [ ] ja — Begründung der strikten Erforderlichkeit
  zur Bias-Erkennung/-Korrektur + Schutzmaßnahmen:

## 7. Kontext-Eignung (Art. 10 Abs. 4)
- Berücksichtigung des geografischen, verhaltensbezogenen,
  kontextuellen oder funktionalen Einsatzumfelds:

## 8. Freigabe
- Geprüft durch / am:
- Nächstes Review:

Ausfüll-Anleitung

Pro Datensatz-Version ein Statement — nicht pro System pauschal. Bei Retraining mit neuen Daten entsteht eine neue Version des Statements.
Abschnitt 2: externe und lizenzierte Quellen mit Vertrag/Lizenz referenzieren; bei synthetischen Daten das Generierungsverfahren beschreiben.
Abschnitt 3: Labeling-Anweisungen und Annotations-Guidelines verlinken, nicht hineinkopieren — das Statement bleibt lesbar, die Details liegen im Engineering-Repo.
Abschnitt 4: Repräsentativität konkret machen: welche Nutzergruppen, Sprachen, Regionen deckt der Datensatz ab — und welche bewusst nicht. "So weit wie möglich fehlerfrei" heißt: dokumentierte Fehlerquote plus Umgang damit, kein Perfektionsanspruch.
Abschnitt 5: Methode benennen (z. B. Subgruppen-Vergleich definierter Metriken), Befunde ehrlich festhalten. Ein Statement ohne einen einzigen Befund wirkt auf Auditoren unglaubwürdiger als eines mit dokumentierten und mitigierten Befunden.
Abschnitt 6: nur ausfüllen, wenn tatsächlich besondere Kategorien (Art. 9 DSGVO) verarbeitet wurden — dann aber vollständig, inklusive der Schutzmaßnahmen.
Abschnitt 7: das Einsatzumfeld des Deployers beschreiben, nicht das Labor-Setting des Providers.
Verantwortlichkeit als Rolle eintragen (z. B. "Data Governance Lead"), damit das Dokument Personalwechsel übersteht.

Audit-Erwartung

Auditoren lesen das Statement quer zur technischen Dokumentation nach Anhang IV und zum Risk Assessment nach Art. 9: die dort benannten datenbezogenen Risiken müssen sich hier in der Bias-Untersuchung und den Lücken-Angaben wiederfinden. Rote Flaggen sind pauschale Aussagen ohne Beleg ("Daten wurden auf Bias geprüft") und fehlende Versionierung — wenn das Modell dreimal retrainiert wurde, das Statement aber von der Erstversion stammt, ist die Data Governance offensichtlich nicht gelebt. Stark wirkt ein Statement, das Lücken benennt und die Kompensation zeigt: nachvollziehbare Evidenz statt Vollständigkeits-Behauptung.

Wofür

Wann es Pflicht ist

Das Artefakt selbst

Ausfüll-Anleitung

Audit-Erwartung

Verwandte Artefakte