EU AI Act Daten-Governance: Was KI-Unternehmen im Jahr 2026 dokumentieren müssen

Der EU AI Act — Regulation (EU) 2024/1689 — trat am 1. August 2024 in Kraft. Für Teams, die KI-Produkte in Europa entwickeln, markierte dieses Datum den Beginn einer Compliance-Uhr, nicht nur eine politische Schlagzeile. Verpflichtungen für Anbieter von Allzweck-KI-Modellen gelten ab August 2025. Die Anforderungen für Hochrisiko-KI-Systeme gelten vollständig ab August 2026. Das Zeitfenster zum Aufbau Ihrer Dokumentationsinfrastruktur ist jetzt.

Dieser Artikel konzentriert sich auf die Bestimmungen, die für KI-Unternehmen kurzfristig am ehesten rechtliche Risiken erzeugen: die Daten-Governance-Anforderungen des Artikel 10, die Aufzeichnungspflichten des Artikel 12 und die praktische Herausforderung, die Herkunft von Trainingsdaten nachzuweisen — ein Problem, das die meisten Teams noch nicht operationalisiert haben.

Was Artikel 10 tatsächlich verlangt

Artikel 10 des EU AI Act legt verbindliche Daten-Governance-Praktiken für Anbieter von Hochrisiko-KI-Systemen fest. Die Bestimmung trägt den Titel „Daten und Daten-Governance“ und ist keine Absichtserklärung — sie erlegt spezifische, überprüfbare Verpflichtungen auf.

Gemäß Artikel 10(2) müssen Trainings-, Validierungs- und Testdatensätze angemessenen Daten-Governance- und Datenverwaltungspraktiken unterliegen. Im Einzelnen müssen Anbieter dokumentieren:

- Die relevanten Designentscheidungen — warum bestimmte Datensätze ausgewählt wurden, nach welchen Kriterien ihre Aufnahme oder ihr Ausschluss erfolgte

- Datenerfassungsprozesse und den Ursprung der Daten — woher die Daten stammen, unter welchen Umständen sie erworben wurden und wer zum Zeitpunkt des Erwerbs die Rechte daran hielt

- Datenvorbereitungsmaßnahmen — Bereinigung, Kennzeichnung, Anreicherung, Aggregation, Annotation; jede Transformation, die den Datensatz vor dem Training veränderte

- Eine statistische Bewertung der Datensätze — zur Erkennung und Minderung potenzieller Verzerrungen, die Grundrechte beeinträchtigen könnten, insbesondere in Hochrisiko-Anwendungsbereichen

- Bekannte Einschränkungen — Lücken in der Abdeckung, zeitliche Verzerrungen, geografische Schieflagen oder andere Eigenschaften des Datensatzes, die die Systemleistung unter Betriebsbedingungen beeinflussen könnten

Artikel 10(3) ergänzt, dass Trainingsdaten so weit wie möglich relevant, hinreichend repräsentativ und fehlerfrei sein müssen. Artikel 10(5) erlaubt die Verarbeitung besonderer Kategorien personenbezogener Daten zur Erkennung und Korrektur von Verzerrungen — jedoch nur unter den strengen Bedingungen und Schutzmaßnahmen des EU-Datenschutzrechts und mit Zugriffskontrollen, die die Exposition auf das notwendige Minimum beschränken.

Für Unternehmen, die Trainingsdatensätze bisher als interne technische Artefakte und nicht als rechtliche Dokumente behandelt haben, stellt Artikel 10 einen grundlegenden Wandel in der Struktur des Datensatzmanagements dar.

Die vier Dokumentationskategorien, die Artikel 10 fordert

Wenn Aufsichtsbehörden oder eine nationale Aufsichtsbehörde Ihre Artikel-10-Konformität prüfen, suchen Sie nach Nachweisen in vier Dokumentationskategorien. Jede erfordert einen anderen operativen Ansatz.

1. Datenprovenienz und Herkunftsnachweise

Sie müssen für jeden Datensatz oder jede Datensatzkomponente nachweisen können, woher die Daten stammen. Dazu gehören: die Quelle (öffentliches Repository, lizenziertes Korpus, vertraglich gebundener Datenanbieter, Web-Scraping, synthetische Erzeugung), das Erwerbsdatum, die Rechtsgrundlage, unter der Sie die Daten besitzen und nutzen, sowie alle vertraglichen Bedingungen, die die Verarbeitung einschränken. Ein Provenienznachweis, der Wochen oder Monate nach dem Erwerb erstellt wurde — rekonstruiert aus dem Gedächtnis von Ingenieuren oder informellen Slack-Nachrichten — wird einen Prüfer nicht zufriedenstellen.

2. Bias-Bewertungen und Einschränkungsprotokolle

Artikel 10(2)(f) verlangt von Anbietern ausdrücklich, bekannte Verzerrungen oder potenzielle Lücken in Datensätzen zu identifizieren und zu dokumentieren, die Risiken für Gesundheit, Sicherheit oder Grundrechte begründen könnten. Dies ist keine einmalige Übung. Da sich Datensätze über Trainingsläufe hinweg weiterentwickeln, müssen Bias-Bewertungen aktualisiert und die Historie dieser Bewertungen aufbewahrt werden. Die Dokumentation muss festhalten, was gefunden wurde, welche Abhilfemaßnahmen angewandt wurden und welche Einschränkungen in der endgültigen Trainingskonfiguration noch bestehen.

3. Datenverarbeitungs- und Transformationsprotokolle

Jede Vorverarbeitungsoperation — Deduplizierung, Normalisierung, Filterung, synthetische Augmentierung, Annotationsrevision — muss mit ausreichender Detailtiefe protokolliert werden, um den Zustand des Datensatzes an jedem Punkt in der Pipeline zu rekonstruieren. Zweck ist die Prüfbarkeit: Wenn eine Regulierungsbehörde einen Systemfehler oder diskriminierende Ausgaben identifiziert, muss sie die Ursachenkette durch die Trainingsdaten zurückverfolgen können. Eine vage Beschreibung von „standardmäßiger Datenbereinigung“ wird diesem Anspruch nicht gerecht.

4. Einwilligungs- und Rechtsdokumentation

Wenn Trainingsdaten personenbezogene Daten enthalten, müssen Einwilligungsnachweise und die Rechtsgrundlagen für die Verarbeitung in einer abrufbaren und zeitgestempelten Form dokumentiert werden. Wenn Daten von Dritten lizenziert werden, müssen die Lizenzbedingungen, etwaige Nutzungsbeschränkungen und die vom jeweiligen Lizenz abgedeckte Version des Datensatzes für die gesamte Betriebsdauer des Systems — und darüber hinaus — aufbewahrt werden, da die Marktüberwachungspflichten gemäß Artikel 72 das relevante Dokumentationsfenster verlängern.

Artikel 12: Technische Dokumentation und Aufzeichnungspflichten

Artikel 12 des EU AI Act begründet Aufzeichnungspflichten, die neben den Daten-Governance-Anforderungen des Artikel 10 bestehen. Gemäß Artikel 12 müssen Anbieter von Hochrisiko-KI-Systemen sicherstellen, dass ihre Systeme in der Lage sind, automatisch Ereignisse zu protokollieren, die für die Erkennung von Risiken für Gesundheit, Sicherheit oder Grundrechte während des gesamten Lebenszyklus des Systems relevant sind.

Im weiteren Sinne legt Anhang IV der Verordnung (referenziert in Artikel 11) die technische Dokumentation fest, die vor der Markteinführung oder Inbetriebnahme eines Hochrisiko-KI-Systems vorzubereiten ist. Abschnitt 2 von Anhang IV bezieht sich direkt auf die Anforderungen des Artikel 10: Er verlangt eine allgemeine Beschreibung der verwendeten Trainingsmethoden und -techniken sowie der verwendeten Trainings-, Validierungs- und Testdatensätze einschließlich ihrer Herkunft, ihres Umfangs und ihrer wesentlichen Merkmale.

Die gemäß Artikel 10 und 12 erstellte Dokumentation dient nicht primär dem internen Gebrauch. Sie muss den nationalen zuständigen Behörden auf Anfrage zur Verfügung gestellt werden. Sie muss mindestens zehn Jahre nach der Markteinführung oder Inbetriebnahme des Systems aufbewahrt werden. Und sie muss aktualisiert werden, wenn das System eine wesentliche Änderung erfährt.

Artikel 53: Verpflichtungen für Anbieter von Allzweck-KI-Modellen

Für Unternehmen, die Allzweck-KI-Modelle entwickeln — Large Language Models, multimodale Foundation-Modelle und ähnliche Systeme — führt Artikel 53 des EU AI Act ab August 2025 eine parallele Reihe von Verpflichtungen ein. Anbieter von GPAI-Modellen müssen technische Dokumentation führen, die Trainingsdaten und die für Training, Test und Evaluierung verwendeten Methoden abdeckt. Wenn ein GPAI-Modell gemäß Artikel 51 als Modell mit systemischem Risiko eingestuft wird, gelten zusätzliche Verpflichtungen zu adversarialem Testen und zur Meldung von Vorfällen.

Das Zusammenspiel von Artikel 53 und Artikel 10 ist für Unternehmen wichtig, deren Allzweckmodelle nachträglich von nachgelagerten Betreibern in Hochrisiko-KI-Anwendungen integriert werden. Der nachgelagerte Betreiber ist für die Einhaltung von Artikel 10 verantwortlich, ist jedoch auf genaue Provenienzinformationen des Foundation-Model-Anbieters angewiesen. Lücken in der Dokumentation des GPAI-Anbieters untergraben direkt die Fähigkeit des Betreibers zur Compliance — und in der Praxis folgt die vertragliche Haftung.

Das Proveniezproblem: Warum die Dokumentation von Trainingsdaten schwierig ist

Theoretisch sind die Dokumentationsanforderungen des Artikel 10 unkompliziert. In der Praxis stehen KI-Teams vor einer strukturellen Herausforderung: Die Art und Weise, wie Trainingsdatensätze in der modernen ML-Entwicklung zusammengestellt, iteriert und wiederverwendet werden, war nie auf rechtliche Prüfbarkeit ausgelegt.

Trainingskorpora werden typischerweise über Monate oder Jahre zusammengestellt und schöpfen aus Dutzenden von Quellen — öffentliche Datensätze, lizenzierte Korpora, Web-Crawls, Annotationsanbieter unter Vertrag und interne synthetische Erzeugungspipelines. Versionskontrolle für Code ist ausgereift; Versionskontrolle für groß angelegte Datensätze ist es nicht. Ein Datensatz, der „in Q3 2024 gesammelt wurde“, ist oft ein Kompositum aus Akquisitionen über mehrere Quartale, verarbeitet von mehreren Teams, mit informeller Verfolgung dessen, was sich zwischen den Läufen geändert hat.

Wenn Artikel 10 Sie auffordert, „den Ursprung der Daten“ und „Datenerfassungsprozesse“ zu dokumentieren, erfordert dies ein Maß an retrospektiver Präzision, das viele Teams derzeit schlicht nicht liefern können. Die Lücke zwischen dem, was Sie über Ihre Trainingsdaten wissen, und dem, was Sie beweisen können — gegenüber einer Regulierungsbehörde, einem Gericht, einer Gegenpartei in einem IP-Streit — ist dort, wo sich das Artikel-10-Risiko konzentriert.

Es gibt eine zusätzliche zeitliche Dimension. Heute erstellte Dokumentation, die heute erworbene Daten beschreibt, ist relativ einfach herzustellen. Dokumentation, die in fünf oder zehn Jahren noch glaubwürdig und rechtlich zuverlässig sein wird — nachdem Systeme aktualisiert wurden, Teammitglieder gewechselt haben und Quelllizenzen sich geändert haben — erfordert dauerhafte, manipulationssichere Aufzeichnungen statt interner Wikis oder Tabellenkalkulationen.

Wie kryptografische Zeitstempel die Provenenzlücke schließen

Die technische Antwort auf das Dokumentationsproblem der Provenienz ist die kryptografische Zeitstempelung, angewandt zum Zeitpunkt der Datenerfassung und bei jeder nachfolgenden Verarbeitungsstufe.

Gemäß eIDAS Regulation Artikel 41 trägt ein qualifizierter elektronischer Zeitstempel eine gesetzliche Vermutung der Richtigkeit des angegebenen Datums und der Uhrzeit sowie der Integrität der daran gebundenen Daten. Dies ist keine kommerzielle Marketingaussage — es ist ein gesetzlicher Beweisstandard, der in allen EU-Mitgliedstaaten gilt. Wenn Sie einem Datensatz zum Zeitpunkt der Erfassung einen qualifizierten Zeitstempel aufbringen, schaffen Sie einen gesetzlich vermutlich-authentischen Nachweis, dass der Datensatz zu diesem genauen Zeitpunkt in genau diesem Zustand existierte, unabhängig von späteren Behauptungen oder Streitigkeiten.

Dies adressiert drei der vier Artikel-10-Dokumentationskategorien gleichzeitig:

- Provenienz und Ursprung — der Zeitstempel belegt, wann der Datensatz erworben wurde, und wenn das Siegel Metadaten enthält, aus welcher Quelle

- Verarbeitungsprotokolle — die Versiegelung des Datensatzes nach jeder Transformationsstufe erstellt einen zeitgestempelten Nachweis des Zustands des Datensatzes an jedem Punkt in der Pipeline

- Versionsintegrität — jede spätere Änderung am Datensatz macht den kryptografischen hash ungültig, sodass Manipulationen erkennbar werden

Entscheidend ist, dass der Datensatz selbst nicht offenbart werden muss, um das Siegel zu verifizieren. Die Verifikation erfolgt gegen den kryptografischen hash, nicht gegen die zugrunde liegenden Daten — was bedeutet, dass Provenienzaufzeichnungen mit Regulierungsbehörden geteilt werden können, ohne kommerziell sensible Trainingskorpora oder die darin enthaltenen personenbezogenen Daten preiszugeben.

Für die Langzeitgültigkeit — wesentlich angesichts der zehnjährigen Dokumentationsaufbewahrungspflicht gemäß Artikel 12 — bleiben Siegel, die mit Long-Term Validation (LTV)-Kodierung ausgestellt wurden, lange nach Ablauf des ausstellenden Zertifikats unabhängig verifizierbar, da die vollständige Validierungskette zum Zeitpunkt der Unterzeichnung in das versiegelte Dokument eingebettet ist.

Praktischer Arbeitsablauf: Dokumentation des Datensatzerwerbs mit Swiss Trust Layer

Swiss Trust Layer unterstützt KI-Unternehmen bei der Erfüllung der Dokumentationsanforderungen der Artikel 10 und 12 durch qualifizierte kryptografische Siegel, die über Swisscom Trust Services ausgestellt werden, einem Qualified Trust Service Provider (QTSP) sowohl im Rahmen von ZertES (Schweiz) als auch von eIDAS (EU). Die Siegel tragen die gesetzlichen Vermutungen des eIDAS Artikel 41 und sind in allen EU-Jurisdiktionen vor Gericht verwendbar.

Ein praktischer Artikel-10-Dokumentationsworkflow mit Swiss Trust Layer funktioniert wie folgt:

- Bei der Erfassung — wenn ein Datensatz oder eine Datensatzkomponente aufgenommen wird, erzeugen Sie einen kryptografischen hash des Datensatzes und der begleitenden Metadatendatei (die Quelle, Erwerbsdatum, Rechtsgrundlage und bekannte Einschränkungen dokumentiert). Versiegeln Sie beides über Swiss Trust Layers KI-Datensatz-Versiegelungsworkflow. Das resultierende Zertifikat ist der Provenienznachweis für diese Datensatzkomponente.

- Nach jeder Verarbeitungsstufe — nach Deduplizierung, Bereinigung, Annotation oder synthetischer Augmentierung, versiegeln Sie den transformierten Datensatz. Die Kette versiegelter Versionen dokumentiert die vollständige Verarbeitungshistorie, die gemäß Artikel 10(2)(c) erforderlich ist.

- Vor Trainingsläufen — versiegeln Sie die endgültige Trainingskonfiguration (Datensatzmanifest, Versions-hashes, Bias-Bewertungsausgabe). Dies erstellt einen zeitpunktgenauen Nachweis des exakten Datenzustands, der für jeden Trainingslauf verwendet wurde, und ermöglicht die systemweite Rückverfolgbarkeit, die gemäß Artikel 12 erforderlich ist.

- Für regulatorische Offenlegung — teilen Sie Siegelzertifikate auf Anfrage mit nationalen zuständigen Behörden. Die Verifikation erfordert keinen Zugriff auf die zugrunde liegenden Daten — nur das Zertifikat und den öffentlichen Verifizierungsendpunkt bei Swiss Trust Layers Verifizierungsdienst.

Für Unternehmen, die bereits KI-generierte Inhalte veröffentlicht oder KI-Systeme eingesetzt haben und rückwirkend die Provenienz für bestehende Datensätze nachweisen müssen, gilt derselbe Workflow — mit dem Verständnis, dass heute erstellte Siegel die Provenienz ab heute, nicht rückwirkend, belegen. Eine frühzeitige Umsetzung ist daher die operativ kluge Wahl.

Dieser Workflow berührt auch die weiter gefassten IP-Dokumentationsanforderungen, die in unserem Beitrag über KI-generierte Inhalte und IP-Schutz nach EU-Recht erörtert werden — insbesondere für Unternehmen, deren Trainingskorpora synthetische Daten enthalten, die sie erzeugt haben und als proprietäre Vermögenswerte schützen möchten.

Implementierungszeitplan: Wann Anforderungen gelten

Der schrittweise Umsetzungsplan des EU AI Act wird häufig falsch gelesen. Die wichtigsten Daten für KI-Unternehmen sind:

- 1. August 2024 — Die Verordnung trat in Kraft. Bestimmungen zu verbotenen Praktiken begannen sechs Monate später zu gelten (Februar 2025).

- 2. August 2025 — GPAI-Modellverpflichtungen gemäß Artikel 53 gelten. Unternehmen, die Allzweck-KI-Modelle entwickeln oder einsetzen, müssen bis zu diesem Datum über technische Dokumentation verfügen.

- 2. August 2026 — Hochrisiko-KI-System-Verpflichtungen gemäß Artikel 10, 11 und 12 gelten vollumfänglich. Anbieter und Betreiber von Systemen, die unter die Kategorien des Anhangs III fallen, müssen konform sein.

- 2. August 2027 — Bestimmte eingebettete KI-Systeme (Hochrisiko-Systeme gemäß Artikel 6(1), die bereits im Rahmen anderer EU-Produktsicherheitsgesetzgebung auf dem Markt platziert wurden) erhalten einen weiteren Übergangszeitraum.

Die August-2026-Frist liegt zum Zeitpunkt der Abfassung dieses Artikels etwa vierzehn Monate in der Zukunft. Für Unternehmen, die noch nicht mit dem Aufbau ihrer Artikel-10-Dokumentationsinfrastruktur begonnen haben, ist das keine komfortable Vorlaufzeit. Daten-Governance-Prozesse werden nicht in einem Sprint implementiert — sie erfordern Pipeline-Änderungen, Tooling-Beschaffung, rechtliche Prüfung bestehender Datensatzlizenzen und in vielen Fällen eine rückwirkende Prüfung, was wann gesammelt wurde.

Die gemäß Artikel 70 benannten nationalen zuständigen Behörden haben noch keine einheitliche Durchsetzungspraxis entwickelt, aber der Text der Verordnung ist klar: Die Nichteinhaltung der Dokumentationsanforderungen des Artikel 10 setzt Anbieter Bußgeldern von bis zu EUR 15 Millionen oder 3 % des gesamten weltweiten Jahresumsatzes aus, je nachdem, welcher Betrag höher ist, gemäß Artikel 99(3).

Der strategische Fall für den Aufbau einer Provenienzinfrastruktur jetzt

Jenseits der regulatorischen Compliance gibt es eine Wettbewerbsdimension bei der Dokumentation der Datensatzprovenienz, die vorausschauende KI-Unternehmen zunehmend erkennen. Da KI-generierte Inhalte und KI-trainierte Modelle Gegenstand von IP-Rechtsstreitigkeiten werden — insbesondere in Rechtsordnungen, in denen Urheberrechtsstreitigkeiten über Trainingsdaten aktiv verhandelt werden — wird die Fähigkeit, genau nachzuweisen, womit trainiert wurde, wann die Daten erworben wurden und auf welcher Rechtsgrundlage, zu einem strategischen Vorteil.

Unternehmen, die qualifizierte, manipulationssichere Provenienzaufzeichnungen als Reaktion auf einen Datenanspruch oder eine Informationsanfrage einer Regulierungsbehörde vorweisen können, werden in einer grundlegend stärkeren Position sein als jene, die rekonstruierte Protokolle und Tabellenkalkulationen vorlegen. Die Kosten für den Aufbau dieser Infrastruktur vor einem Streit sind ein Bruchteil der Kosten für die Verteidigung eines Anspruchs ohne sie.

Die Daten-Governance-Anforderungen des EU AI Act und der praktische Geschäftsbedarf für den IP-Schutz von Datensätzen sind in dieser Hinsicht perfekt aufeinander abgestimmt. Die Einhaltung von Artikel 10 ist kein Overhead — sie ist die Grundlage vertretbarer KI-Entwicklung.

Nächste Schritte für Ihr KI-Unternehmen

Wenn Ihre Organisation KI-Systeme entwickelt, trainiert oder einsetzt, die unter die Hochrisikokategorien des EU AI Act fallen — oder wenn Sie Allzweck-KI-Modelle bereitstellen, die Artikel 53 unterliegen — sind folgende Maßnahmen zeitkritisch:

- Klassifizieren Sie Ihre KI-Systeme anhand von Anhang III, um zu ermitteln, welche Produkte ab August 2026 in den Anwendungsbereich fallen

- Prüfen Sie Ihre bestehende Trainingsdatensatz-Dokumentation anhand der Anforderungen des Artikel 10(2) — identifizieren Sie Lücken in Provenienz, Bias-Aufzeichnungen und Verarbeitungsprotokollen

- Etablieren Sie ein Datensatz-Versiegelungsprotokoll für alle neuen Akquisitionen und Verarbeitungsstufen ab sofort

- Beauftragen Sie qualifizierte Rechtsanwälte, Ihr Datensatzlizenzportfolio hinsichtlich der Rechtsdokumentationsanforderungen des Artikel 10(2)(b) zu prüfen

- Prüfen Sie die technischen Dokumentationsanforderungen von Anhang IV anhand Ihrer aktuellen Dokumentationspraktiken

Der KI-Datensatz-Provenienz-Versiegelungsdienst von Swiss Trust Layer unterstützt die Schritte drei und fünf — er stellt die qualifizierte kryptografische Infrastruktur für die zeitgestempelte, manipulationssichere Dokumentation bereit, die Artikel 10 und 12 erfordern. Siegel werden über Swisscom Trust Services unter eIDAS und ZertES ausgestellt, mit unabhängiger Verifizierung unter /compliance. Der Preis beginnt bei CHF 5 pro Dokument.

Der EU AI Act ist Gesetz. Die Dokumentationsuhr läuft. Die Frage ist nicht, ob Ihr KI-Unternehmen Artikel-10-konforme Provenienzaufzeichnungen benötigen wird — sondern ob Sie die Infrastruktur aufgebaut haben werden, um sie vor der ersten Regulierungsanfrage vorlegen zu können.