EU AI Act Art. 10: Datenqualität, die Prüfungen standhält

Wir sind bereits früher in das Thema eingestiegen -> Die Auswirkungen des EU AI Act auf Business Intelligence. Mit dieser dreiteiligen Reihe übersetzen wir nun das in operative Praxis. Teil 1 startet bei der Basis, nämlich Datenqualität nach Art. 10.

Hinweis: Hierbei handelt es sich nicht um Rechtsberatung, sondern eine technische, praxisorientierte Einordnung.
‍

Warum das jetzt zählt

Eine kurze Einordnung:

Parallel zur gestaffelten Anwendung werden aktuell Vereinfachungen und mögliche Anpassungen des Startpunkts für Teile der High Risk Regeln diskutiert. Es wird geprüft, den Startpunkt an die Verfügbarkeit von Support Tools und Standards zu koppeln. Dazu liegen Vorschläge vor, die noch in Abstimmung sind.

Stand Q1/2026: Details und Erleichterungen sind noch nicht final. Maßgeblich für die Orientierung sind aktuell veröffentlichte Leitlinien und FAQs der EU Kommission.

Der EU AI Act ist seit 1. August 2024 in Kraft. Er wird grundsätzlich ab 2. August 2026 anwendbar. Die Anwendung ist gestaffelt. Unter anderem gelten Übergänge bis 2. August 2027 für bestimmte High Risk KI als Sicherheitskomponente in regulierten Produkten.

Für Data Teams heißt das: Nachweisfähigkeit entsteht nicht durch Dokumente, sondern durch kontrollierte Datenprozesse.‍

‍

Der Denkfehler: Compliance ist kein Modellproblem, sondern oft ein Datenproblem

‍Viele diskutieren Regulierung auf Modellebene, etwa über Dokumentation, Explainability oder Frameworks. In gewachsenen BI und Datenlandschaften scheitert es jedoch häufig früher. Compliance scheitert selten am Modell, sondern viel mehr an Daten, die nie als prüfbar gebaut wurden. Damit wird Data Engineering zum Compliance Anker. Nicht als Bremse, sondern als Team, das Messbarkeit und Betrieb in die Datenkette bringt.‍

‍

Art. 10 in Engineering Sprache: von „Adjektiven“ zu Controls

‍Art. 10 („Data and data governance“) adressiert Anforderungen an Daten und Data Governance für High Risk AI Systeme. Das gilt insbesondere dort, wo Daten für Training, Validierung oder Testing eingesetzt werden.

Hinweis zur Vollständigkeit:
Wenn kein Modelltraining stattfindet, gelten die Pflichten aus Art. 10 Abs. 2 bis 5 für Testing Datensätze und, soweit vorgesehen, auch für Validierungsdatensätze.

Ob eine BI oder Analytics Anwendung überhaupt unter den AI Act fällt, hängt davon ab, ob sie die Definition eines „AI system“ erfüllt. Die Kommission hat dazu Guidelines veröffentlicht. Wenn ein System unter den AI Act fällt und zusätzlich in eine High Risk Kategorie fällt, greifen unter anderem die Art 10 Pflichten zur Datenqualität und Data Governance. ‍

‍

Warum BI und Data Organisationen trotzdem betroffen sein können

‍Datenplattformen sind häufig Shared Infrastructure. Sobald ein AI Use Case, der auf diese Plattform zugreift, tatsächlich in eine High Risk Kategorie fällt, muss die vorgelagerte Datenkette die dafür nötige Nachweisbarkeit liefern. Beispiele sind HR Selektion, Kredit Scoring oder kritische Infrastruktur.

Operativ bedeutet das:
Datenqualität und Data Governance müssen für High Risk Kontexte messbar und auditierbar gemacht werden. Dazu gehören dokumentierte Datenaufbereitung und Kontrollen, etwa Repräsentativität sowie Fehlerarmut und Vollständigkeit „to the best extent possible“. Quality as Code kann dabei ein wirksamer Baustein sein. Entscheidend ist, dass Kontrollen und Evidenz dauerhaft im Betrieb verankert sind.

‍

Wo es in der Praxis kippt

Kein Sonderfall, sondern Alltag:
‍
• Schattenlogik (KPI Definitionen verteilt in SQL, Excel oder BI Layern)
• stille Schema Änderungen upstream, die downstream weiterlaufen
• manuelle Fixes ohne Audit Trail
• Tests ohne Entscheidung (Fail ohne Stop oder Eskalation)
‍
In High Risk Kontexten werden diese Punkte Compliance und Audit relevant. Entscheidend ist, was im Betrieb kontrolliert, dokumentiert und nachvollziehbar ist.

‍

-> Ab hier wird es praktisch:
Minimum Viable Controls (MVC) für Datenqualität

Viele Organisationen scheitern nicht an der Idee, sondern am Overload. MVC heißt: klein genug, um zu starten. Robust genug, um zu skalieren.
‍

1. Data Contracts und Schema Guards

Erwartete Spalten, Datentypen, Nullability und Semantik werden als Contract festgehalten. Dazu gehören Regeln, was ein Breaking Change ist und wie Versionierung und Kommunikation laufen.

Ergebnis: Weniger stille Brüche und weniger Überraschungen im Reporting.

2. Quality Gates in der Pipeline

Basiskontrollen wie Pflichtfelder, Eindeutigkeit auf Business Keys, Referenzintegrität und Wertebereiche sind schnell etabliert. Entscheidend ist die Konsequenz: Stop, Quarantäne oder Alert plus dokumentierte Freigabe.

Aus dem inics Alltag: In dbt Setups nutzen wir dbt Docs und Metadaten häufig als pragmatischen Data Catalog Einstieg. So sind Modelle, Definitionen und Abhängigkeiten für Teams auffindbar und nachvollziehbar. Das ist eine gute Basis für spätere Katalog und Governance Ausbaustufen.

3. SLOs für Daten

Qualität wird als Service messbar. Dazu gehören verbindliche Erwartungen an Aktualität und Vollständigkeit, zum Beispiel „werktags bis 06:30 vollständig“ oder „≥ 99,x % der erwarteten Records“ mit Toleranzfenster. Zusätzlich, nur dort wo es wirklich zählt, kommen End to End Latenz Ziele für kritische Datenprodukte hinzu.

4. Repräsentativität und Bias als Pipeline Thema

Repräsentativität ist nicht „später im Modell“. Ein praktischer Start ist: Coverage prüfen (Segmente, Regionen, Kanäle vorhanden), Drift und Anomalien auf Schlüsselmerkmalen messen und Data Gaps sichtbar machen. Das passt zur Governance Logik von Art. 10.
‍

5. Minimaler Evidence Output aus DQ Controls

Ziel: Nachweise entstehen automatisch, ohne Compliance PowerPoint. Für Teil 1 reicht bewusst ein schlanker Scope. Pro Run werden Testergebnisse, Row Counts, Freshness Status und der Versionsstand der Pipeline als Evidenz abgelegt.

Wichtig: Die größere Architekturfrage, also Lineage, Metadaten, Change Gatesund Audit Trails als System, ist Thema von Teil 2 „Traceability by Design“.

Aus dem inics Alltag (RAG und GenAI):
‍Wenn RAG Systeme im Einsatz sind, loggen wir zusätzlich systematisch, welche Quellen tatsächlich abgerufen wurden (Dokument und Abschnitts IDs), welche Index und Embedding Version verwendet wurde und welche Prompt und Pipeline Version die Antwort erzeugt hat. So muss Nachvollziehbarkeit später nicht rekonstruiert werden.

6. Klare Ownership, wer entscheidet bei einem Fail

Minimaler Zuschnitt, der in der Praxis funktioniert: Data Owner (Business) definiert Ziele und Toleranzen. Engineering Owner verantwortet Umsetzung und Ursachenbehebung. Plattform und Ops stellen Monitoring, Runbooks und Eskalation.
-> Ohne Ownership bleiben Alerts nur Lärm. Mit Ownership werden sie steuerbar.

Fazit: Der AI Act belohnt nicht mehr Dokumentation

Er belohnt Plattformen, die Qualität im Betrieb herstellen und belegen können. Wer Datenqualität als Engineering und Ownership Thema behandelt, reduziert Risiko. Gleichzeitigsteigen Stabilität, Liefertempo und Vertrauen.

‍
Kleiner Ausblick:

Im nächsten Teil (2/3) geht es um Traceability by Design. Wir zeigen, wie Lineage, Metadaten und Change Gates so umgesetzt werden, dass Audit Fähigkeit im Betrieb entsteht.

‍