EU AI Act Artikel 10 einfach erklärt: Datenqualität für KI

Beitragsbild: KI-generiertes Symbolbild. Keine Aufnahme eines realen Ereignisses.

Eine KI kann technisch beeindruckend sein und trotzdem schlechte Entscheidungen treffen, wenn ihre Datengrundlage nicht zum Einsatz passt. Genau hier setzt Artikel 10 des EU AI Act an. Er behandelt Daten und Daten-Governance bei Hochrisiko-KI: Woher kommen die Daten, was bilden sie ab und wie werden ihre Schwächen erkannt?

Für Unternehmen ist das eine praktische Frage. Wer eine KI für einen anspruchsvollen Entscheidungsprozess entwickelt oder einkauft, sollte nicht nur nach dem Modellnamen fragen. Entscheidend ist auch, ob die Daten die Menschen, Situationen und Bedingungen im späteren Einsatz sinnvoll abbilden.

Dieser Beitrag setzt unsere Reihe nach Artikel 9 zum Risikomanagement fort. Die folgenden Beispiele sind vereinfachte, eigene Anwendungsszenarien und keine Beschreibungen realer Kundenprojekte.

Was Artikel 10 verlangt – verständlich zusammengefasst

Artikel 10 betrifft die Entwicklung von Hochrisiko-KI-Systemen. Verwendete Trainings-, Validierungs- und Testdaten müssen zum vorgesehenen Zweck passen: relevant, ausreichend repräsentativ sowie möglichst fehlerfrei und vollständig. Auch der konkrete Einsatzkontext zählt. Die Eigenschaften können durch einzelne Datensätze oder deren Kombination erfüllt werden.

Zur Daten-Governance gehören insbesondere: begründete Designentscheidungen; Datenherkunft und Erhebungszweck; Aufbereitung; Annahmen über die Aussagekraft; Prüfung von Menge und Eignung; Untersuchung möglicher schädlicher Verzerrungen; Gegenmaßnahmen; und das Erkennen sowie Beheben relevanter Datenlücken. Bei Hochrisiko-Systemen ohne Modelltraining beziehen sich die entsprechenden Anforderungen auf die Testdaten.

Quelle: Artikel 10 im offiziellen AI Act Service Desk der Europäischen Kommission.

Betrifft das jede Nutzung von ChatGPT?

Nein. Artikel 10 ist keine pauschale Anweisung an jedes Unternehmen, das einen KI-Assistenten für E-Mails oder Präsentationen verwendet. Zuerst müssen das konkrete System, sein Zweck, seine Risikoeinstufung und die Rolle des Unternehmens geklärt werden. Die Grundlagen erläutert unsere Folge zu Artikel 8 und den Anforderungen an Hochrisiko-KI.

Auch ein Unternehmen, das ein fertiges Hochrisiko-System einkauft, sollte Datenfragen nicht ignorieren. Nach Artikel 26 Absatz 4 müssen Betreiber, soweit sie die Eingabedaten kontrollieren, deren Relevanz und ausreichende Repräsentativität für den vorgesehenen Zweck sicherstellen. Wer nur Software verwendet und wer selbst als Anbieter verantwortlich ist, hat unterschiedliche Aufgaben. Diese Unterscheidung gehört an den Anfang eines KI-Projekts.

Quelle: Artikel 26 zu den Pflichten der Betreiber.

Training, Validierung und Test: drei unterschiedliche Aufgaben

Stellen wir uns eine KI vor, die Dokumente nach bestimmten Merkmalen einordnet. Drei Arbeitsschritte helfen dabei, ihre Qualität sinnvoll zu prüfen:

• Training: Das Modell lernt anhand von Beispielen. Es ist vergleichbar mit dem Üben vor einer Prüfung.
• Validierung: Während der Entwicklung werden Einstellungen und Lösungsansätze verglichen. Welche Variante funktioniert bei geeigneten Kontrollbeispielen besser?
• Test: Anschließend wird an dafür zurückgehaltenen Fällen geprüft, wie gut das fertige System arbeitet.

Eine praktische Falle: Derselbe Vorgang taucht in leicht veränderter Form im Trainings- und Testbestand auf. Das Modell scheint dann sehr zuverlässig, weil es ähnliche Fälle bereits kennt. Für eine saubere Projektprüfung empfiehlt sich deshalb, auch Dubletten und versteckte Überschneidungen zu untersuchen. Eine hohe Testzahl allein erklärt noch nicht, ob ein Test aussagekräftig ist.

Warum mehr Daten nicht automatisch bessere Daten bedeuten

Beispiel: Ein Anbieter entwickelt ein System für einen deutschen Personalprozess. Sein Bestand enthält sehr viele historische Bewerbungsunterlagen, aber überwiegend eine bestimmte Berufsgruppe, aus einer einzigen Region und aus einem alten Zeitraum. Die Menge wirkt überzeugend. Trotzdem bleiben wichtige Fragen offen: Passen die Fälle zum geplanten Einsatz? Welche Gruppen und Lebensläufe fehlen? Haben sich Anforderungen inzwischen geändert?

Ein sinnvoller Projektauftrag lautet deshalb nicht einfach: „Sammelt noch mehr Daten.“ Besser ist: „Welche fehlenden Fälle brauchen wir, um unsere konkrete Fragestellung vernünftig zu prüfen?“ Eine kleine, gezielt ausgewählte Ergänzung kann für die Bewertung hilfreicher sein als ein weiterer großer Bestand ähnlicher Fälle.

Ähnlich bei Dokumenten: Ein Test ausschließlich mit perfekten PDF-Dateien sagt wenig darüber aus, wie ein System mit schrägen Scans, schlechter Bildqualität oder unterschiedlichen Formularversionen umgeht. Solche Fälle sollten in einem praktisch brauchbaren Prüfplan bewusst berücksichtigt werden.

Daten-Governance: Ordnung statt Datenchaos

Daten-Governance lässt sich im Projektalltag als nachvollziehbarer Umgang mit Daten verstehen. Ein Team sollte erklären können, welcher Bestand verwendet wird, wer ihn pflegt, welche Veränderungen vorgenommen wurden und welche Einschränkungen bekannt sind.

Eine einfache Arbeitsgrundlage ist ein Datensteckbrief. Darin können beispielsweise Herkunft, Zeitraum, fachlicher Zweck, zuständige Person, Bearbeitungsschritte und bekannte Schwächen stehen. Ergänzend hilft ein Änderungsprotokoll: Welche Datensätze wurden ausgetauscht? Welche Fehler wurden korrigiert? Mit welcher Version wurde der letzte Test durchgeführt?

Das ist eine praktische Umsetzungsidee, keine Behauptung, dass jedes Projekt ein bestimmtes Formular oder eine besondere Software kaufen muss. Wichtig ist, dass die Beteiligten ihre Entscheidungen später erklären und prüfen können.

Verzerrungen erkennen: Was bedeutet „Bias“?

„Bias“ beschreibt hier eine Verzerrung. Stellen wir uns vor, frühere Entscheidungen bevorzugten systematisch bestimmte Lebensläufe. Ein Modell, das diese Entscheidungen als Muster übernimmt, kann dieselbe Schieflage weitertragen. Historische Daten sind also nicht allein deshalb eine gute Orientierung, weil sie aus dem eigenen Unternehmen stammen.

Für ein Projektteam ist eine brauchbare Frage: „Für welche Fälle funktioniert unsere Lösung erkennbar schlechter?“ Ein einziger Durchschnittswert kann solche Unterschiede verdecken. Neben der Gesamtqualität sind deshalb gezielt ausgewählte Teilgruppen und schwierige Situationen interessant.

Auch Rückkopplungen verdienen Aufmerksamkeit. Wenn ein System bestimmte Fälle seltener berücksichtigt und spätere Daten vor allem aus den berücksichtigten Fällen entstehen, kann eine anfängliche Schieflage mit jeder Runde stärker erscheinen. Ein praktischer Prüfplan sollte erklären, ob und wie Ergebnisse später wieder in die Datengrundlage einfließen.

Weiterführende Erläuterung: Erwägungsgrund 67 zu Datenqualität und möglichen Verzerrungen.

Sensible Daten sind keine frei verfügbare Lösung

Wer mögliche Benachteiligungen untersucht, darf daraus keine allgemeine Erlaubnis ableiten, beliebige sensible personenbezogene Daten zu sammeln. Im aktuellen Rechtsstand wurde die frühere Sonderregel in Artikel 10 Absatz 5 gestrichen; die entsprechenden Regelungen finden sich nun in Artikel 4a.

Dort ist eine ausnahmsweise Verarbeitung besonderer Kategorien personenbezogener Daten zur Erkennung und Korrektur von Verzerrungen an enge Voraussetzungen und Schutzmaßnahmen gebunden. Dazu gehören insbesondere strikte Erforderlichkeit, die Prüfung anderer Datenalternativen, begrenzte Weiterverwendung, gesicherte und dokumentierte Zugriffe sowie Löschung nach den vorgesehenen Bedingungen. Datenschutzrecht gilt daneben weiter.

Für die Praxis bedeutet das: Eine Bias-Prüfung gehört mit Datenschutzverantwortlichen abgestimmt. „Wir benötigen diese Informationen vielleicht irgendwann“ ist keine saubere Projektbegründung.

Quelle: aktueller Artikel 4a im offiziellen AI Act Service Desk.

Sechs Fragen für den nächsten KI-Projekttermin

1. Zweck: Welche konkrete Entscheidung oder Aufgabe soll das System unterstützen?
2. Rolle: Entwickeln wir das System als Anbieter oder nutzen wir es als Betreiber?
3. Daten: Woher stammen die Bestände, wie aktuell sind sie und welche Fälle fehlen?
4. Prüfung: Wie unterscheiden sich Lernmaterial und unabhängige Prüffälle?
5. Schwächen: Welche Fehler und Verzerrungen sind bekannt, und wie gehen wir damit um?
6. Verantwortung: Wer entscheidet über die Datengrundlage, dokumentiert Änderungen und prüft neue Einsatzbedingungen?

Diese Fragen ersetzen keine vollständige Konformitätsbewertung. Sie helfen aber, ein Gespräch von allgemeinen Versprechen zu überprüfbaren Projektentscheidungen zu bringen.

Was bedeutet das für KI-Beratung im Unternehmen?

Eine gute Einführung beginnt mit dem tatsächlichen Arbeitsprozess. Welche Daten werden heute verwendet? Wo entstehen Fehler? Welche Entscheidung braucht fachliche Prüfung? Erst danach lässt sich sinnvoll beurteilen, welchen Beitrag KI leisten kann und welche Voraussetzungen dafür fehlen.

Bei Consulting Entenmann unterstützen wir Unternehmen dabei, KI-Anwendungen verständlich einzuordnen und Verantwortlichkeiten, Schulungsbedarf und praktische nächste Schritte zu klären. Wenn dein Team den EU AI Act in den Arbeitsalltag übersetzen möchte, findest du weitere Informationen zur EU-AI-Act-Schulung für Unternehmen.

Häufige Fragen zu Artikel 10

Müssen Daten absolut fehlerfrei sein?

Die Formulierung des Artikels verlangt möglichst fehlerfreie und vollständige Daten im Hinblick auf den vorgesehenen Zweck. Eine pauschale Garantie, dass kein einziger Fehler existiert, wäre eine falsche Darstellung. Bekannte Schwächen sollten im Projekt dennoch ernst genommen und nachvollziehbar bearbeitet werden.

Reicht die Aussage des Herstellers, sein Modell sei gut trainiert?

Für eine vernünftige Beschaffungsentscheidung sind konkrete Informationen hilfreicher: Einsatzgrenzen, geprüfte Situationen und bekannte Einschränkungen. Welche Unterlagen rechtlich erforderlich sind, hängt vom System und deiner Rolle ab.

Worum geht es in der nächsten Folge?

Artikel 11 behandelt die technische Dokumentation. Dort stellt sich die nächste Frage: Wie wird nachvollziehbar festgehalten, was ein Hochrisiko-KI-System leistet und wie seine Anforderungen erfüllt werden?

Recherchestand: 2. Oktober 2026. Grundlage ist die im offiziellen AI Act Service Desk ausgewiesene konsolidierte Fassung vom 27. Juli 2026. Anwendungsfristen und rechtliche Einordnung sind je nach System gesondert zu prüfen. Dieser Beitrag dient der allgemeinen Information.

Autor: Niklas Entenmann