Anforderungen des EU-KI-Gesetzes: Vollständige Aufschlüsselung der Pflichten, Kontrollen und Compliance-Schritte

Sie wissen vielleicht bereits, dass die EU-KI-Richtlinie für Sie gilt; Sie kennen die Pflichten, aber Sie wissen nicht genau, was Sie tun müssen. Die Richtlinie listet Artikel auf. Ihr Wirtschaftsprüfer verlangt Nachweise. Ihr Entwicklerteam benötigt Spezifikationen. Aus dem Rechtstext konkrete Handlungsanweisungen abzuleiten, ist nicht einfach, und genau hier scheitern Teams oft.

Ich möchte Sie bei dieser Herausforderung unterstützen. Artikel für Artikel erkläre ich Ihnen, was jede Anforderung von Ihnen verlangt, was Sie dokumentieren müssen, was Sie in das Produkt integrieren müssen und was Sie nach dem Launch weiterführen sollten. Dabei zeige ich Ihnen auch, wie Ihre bestehenden SOC-2- oder ISO-27001-Compliance-Workflows mit den Verpflichtungen des AI Act übereinstimmen, was die harmonisierten Standards nicht abdecken und wie Sie den GPAI-Verhaltenskodex bei Verhandlungen mit Anbietern von Foundation-Modellen anwenden.

Risikobasierter Rahmen des EU-KI-Gesetzes

Das Gesetz teilt KI-Systeme in vier Stufen ein. Die Anforderungen, die Sie erfüllen müssen, hängen davon ab, in welche Stufe Ihre Systeme fallen. In diesem Abschnitt werden die einzelnen Stufen und die damit verbundenen spezifischen Anforderungen geordnet, sodass Sie direkt zu den entsprechenden Details weiter unten springen können.

Die meisten Teams, die den Klassifizierungstest durchführen, stellen ehrlich fest, dass ihre KI ein minimales Risiko birgt und sie daher nicht weiter in Betrieb nehmen müssen. Diejenigen Teams, die in die Kategorie „hohes Risiko“ fallen, benötigen den Rest dieses Artikels.

Risikostufe	Was es auslöst
Verboten (Artikel 5)	Die Einhaltung der Vorschriften kann nicht erreicht werden. Das System kann nicht eingesetzt werden. Das Omnibusgesetz fügte ein Verbot ab Dezember 2026 hinzu, das die Erstellung von CSAM oder nicht einvernehmlichem intimen Bildmaterial durch KI untersagt.
Hohes Risiko	Das vollständige Paket: Artikel 9 bis 15, Artikel 17 QMS, Konformitätsbewertung, CE-Kennzeichnung, EU-Datenbankregistrierung, Marktüberwachung, Meldung von Vorfällen.
Begrenztes Risiko	Es gelten ausschließlich die Transparenzpflichten gemäß Artikel 50. Chatbots müssen ihre KI offenlegen. Synthetische Inhalte müssen maschinenlesbar sein. Deepfakes müssen gekennzeichnet werden.
Minimales Risiko	Aus dem Gesetz ergeben sich keine spezifischen Verpflichtungen, die DSGVO und branchenspezifische Gesetze bleiben jedoch weiterhin gültig.

Eine detaillierte Aufschlüsselung der einzelnen Stufen mit Beispielen sowie eine Analyse der Ausstiegsklausel gemäß Artikel 6(3) finden Sie im Compliance-Leitfaden.

Anforderungen verschiedener Interessengruppen

Ihre Verpflichtungen ergeben sich aus zwei Aspekten: Ihrer Rolle in der KI-Wertschöpfungskette und der Risikoklassifizierung jedes Systems. Wenn Sie einen dieser Aspekte falsch einschätzen, steht Ihr gesamtes Programm auf einem mangelhaften Fundament. 

Funktion / Rolle (Role) *	Artikel, die gelten	Kernpflichten
Provider (von risikoreicher KI)	Artikel 9 bis 15, 17, 43, 47, 48, 49, 72, 73	Risikomanagement, Datenverwaltung, technische Dokumentation, Protokollierung, Transparenz gegenüber Anwendern, menschliche Aufsicht, Genauigkeit und Robustheit, Qualitätsmanagementsystem, Konformitätsbewertung, CE-Kennzeichnung, EU-Datenbankregistrierung, Marktbeobachtung, Meldung von Vorfällen.
Deployer (von risikoreicher KI)	Artikel 26, Teile der Artikel 14 und 27	Nutzung gemäß Gebrauchsanweisung, menschliche Aufsicht beim Betrieb, Protokollierung, Transparenz, wo angebracht, Grundrechtefolgenabschätzung für öffentliche Stellen und bestimmte private Einrichtungen.
Import	Artikel 23	Prüfen Sie, ob der Anbieter die Konformitätsverpflichtungen erfüllt hat, ob eine technische Dokumentation vorhanden ist, ob die CE-Kennzeichnung angebracht ist und ob eine Gebrauchsanweisung vorliegt.
Vertriebspartner	Artikel 24	Prüfen Sie die CE-Kennzeichnung und die zugehörigen Dokumente. Ergreifen Sie Korrekturmaßnahmen, wenn Grund zur Annahme besteht, dass das System nicht den Vorschriften entspricht.
Downstream-Anbieter	Übernimmt die Verpflichtungen des Anbieters	Wenn Sie ein risikoreiches KI-System wesentlich verändern oder es unter Ihrem eigenen Namen auf den Markt bringen, werden Sie zum Anbieter und übernehmen die volle Verantwortung gemäß Artikel 9 bis 15 und Artikel 17.

Sehen Sie sich die vollständige Anleitung zum Verständnis von ISO 42001 und dem EU-KI-Gesetz mit Babl AI an →

Die Regelung für nachgelagerte Anbieter sollten SaaS-Teams besonders sorgfältig prüfen. Die Feinabstimmung eines Basismodells für Ihr Produkt, das erneute Training mit eigenen Daten oder die Bereitstellung der integrierten KI unter Ihrer eigenen Marke können dazu führen, dass Sie von Bereitstellungs- zu Anbieterpflichten wechseln. Unser Abschnitt zu SaaS-Archetypen, die die Einhaltung des EU-KI-Gesetzes gewährleisten , erläutert dies anhand von drei konkreten Beispielen.

Wann die Anforderungen des EU-KI-Gesetzes Anwendung finden

Verpflichtung	Ursprüngliches Datum	Datum nach dem Omnibus
Verbotene Praktiken (Artikel 5)	2. Februar 2025	2. Februar 2025 (unverändert)
KI-Kompetenz (Artikel 4)	2. Februar 2025	2. Februar 2025 (unverändert)
GPAI-Modellverpflichtungen	August 2, 2025	2. August 2025 (unverändert)
Neues CSAM/Nudifier-Verbot	n/a	December 2, 2026
Artikel 50(2) Wasserzeichen (neue Systeme)	August 2, 2026	2. August 2026 (unverändert)
Artikel 50(2) Wasserzeichen (Systeme im Markt)	August 2, 2026	December 2, 2026
Hochrisikoverpflichtungen gemäß Anhang III	August 2, 2026	December 2, 2027
Anhang I Hochrisikoverpflichtungen	August 2, 2027	August 2, 2028
Durchsetzungsbefugnisse der GPAI	August 2, 2026	2. August 2026 (unverändert)

Wie bestehende Zertifizierungen den Anforderungen des AI Act entsprechen

Wenn Sie bereits SOC 2, ISO 27001 oder ISO 42001 anwenden , beginnen Sie die Einhaltung des EU-Gesetzes zur künstlichen Intelligenz (AI Act) nicht bei null. Möglicherweise stellen Sie fest, dass Ihre bereits implementierten Kontrollen 40–60 % der Anforderungen des AI Act abdecken. Die entscheidende Frage ist: Welche Artikel erfordern neue Nachweise und welche können mit den bereits vorhandenen Kontrollen erfüllt werden?

Die folgende Tabelle zeigt die Überschneidungen. Nutzen Sie sie, bevor Sie etwas Neues entwickeln, damit Sie keine bereits vorhandenen Steuerelemente neu erstellen und dabei die wirklich KI-spezifischen Lücken unberücksichtigt lassen.

Vorhandene Zertifizierung	Beinhaltet Teile von	Deckt nicht ab
SOC 2	Artikel 15 Cybersicherheit (Zugriffskontrollen, Schwachstellenmanagement, Reaktion auf Sicherheitsvorfälle), Teile von Artikel 17 Qualitätsmanagementsystem (Änderungsmanagement, Überwachung), Teile von Artikel 12 (Protokollierungsinfrastruktur für Sicherheitsereignisse)	KI-spezifisches Risikomanagement (Artikel 9), Daten-Governance für Trainingsdaten (Artikel 10), Gestaltung der menschlichen Aufsicht (Artikel 14), technische Dokumentation gemäß Anhang IV (Artikel 11), Konformitätsbewertung (Artikel 43)
ISO 27001	Die gleichen Sicherheitskontrollen wie bei SOC 2, plus ein ISMS-Gerüst, das Teilen von Artikel 17 und Teilen von Artikel 15 (Behandlung von Informationssicherheitsrisiken) entspricht.	Alle KI-spezifischen Verpflichtungen. Risikomanagement für das KI-System selbst, Daten-Governance, Transparenz, menschliche Aufsicht, technische Dokumentation, Konformitätsbewertung
ISO 42001	Wesentliche Teile von Artikel 17 QMS, Teile von Artikel 9 (Rahmenwerk für das KI-Risikomanagement), Teile von Artikel 10 (Daten-Governance), Teile von Artikel 14 (Aufsichtsgrundsätze)	Spezifische Inhalte der technischen Dokumentation gemäß Anhang IV, Konformitätsbewertung nach Artikel 43, EU-Konformitätserklärung, CE-Kennzeichnung, EU-Datenbankregistrierung, Besonderheiten der Marktüberwachung nach Artikel 72
Datenschutz	Teile von Artikel 10 (wo KI-Trainingsdaten personenbezogene Daten sind), Teile von Artikel 13 (Transparenz gegenüber den betroffenen Personen), Teile von Artikel 27 (Grundlagen der Folgenabschätzung)	Die meisten KI-spezifischen Verpflichtungen. Die DSGVO basiert auf Rechten, das KI-Gesetz auf Produktsicherheit. Beide bestehen nebeneinander, ersetzen sich aber nicht.
NIST AI RMF	Konzeptionelles Gerüst für das Risikomanagement gemäß Artikel 9. Die Funktionen Regieren, Kartieren, Messen und Managen orientieren sich auf der Prinzipienebene am Zyklus gemäß Artikel 9.	Freiwilliger US-Rahmen ohne direkte rechtliche Entsprechung zum AI Act. Nützlich als Gerüst, nicht als Beweismittel.

Anforderungen an KI mit hohem Risiko (zentrale Compliance-Verpflichtungen)

Wird Ihr KI-System als risikoreich eingestuft, gelten die Verpflichtungen aus den Artikeln 9 bis 15 sowie Artikel 17. Jede dieser Verpflichtungen stellt eine separate Anforderung mit eigenem Nachweisverfahren dar.

Artikel 9 ist der Kern. Er fordert Sie auf, ein stets aktuelles Bild davon zu erstellen, was schiefgehen könnte, wenn Ihre KI wie vorgesehen funktioniert. Alles andere fließt entweder in dieses Bild ein oder reagiert darauf. 

Anforderungen an das KI-Risikomanagement (Artikel 9)

Artikel 9 fordert ein Risikomanagementsystem, das während des gesamten Lebenszyklus des KI-Systems kontinuierlich läuft. Keine einmalige Risikobewertung bei der Inbetriebnahme. Kein Dokument in SharePoint. Ein fortlaufender Prozess, der so lange aktiv ist, wie das System genutzt wird.

Der Prozess umfasst vier notwendige Schritte: 

1. Identifizieren Sie bekannte und vernünftigerweise vorhersehbare Risiken für Gesundheit, Sicherheit und Grundrechte.
2. Schätzen und bewerten Sie diese Risiken
3. Minderungsmaßnahmen ergreifen
4. Prüfen Sie, ob die Schutzmaßnahmen unter Bedingungen funktionieren, die der realen Nutzung entsprechen. 

Dann wiederholen Sie den Vorgang. Jedes Mal, wenn Sie das Modell neu trainieren, die Architektur ändern, den Anwendungsfall erweitern oder den Bereitstellungskontext ändern, beginnt der Zyklus von Neuem.

Die Aufsichtsbehörden erwarten bei ihren Untersuchungen nicht nur die aktuelle Risikobewertung. Sie benötigen die Historie der einzelnen Schritte: die Methodik, die in jeder Phase identifizierten Risiken, die ergriffenen Maßnahmen zur Risikominderung und den dokumentierten Zusammenhang zwischen jedem identifizierten Risiko und der jeweiligen Kontroll- oder Konstruktionsentscheidung. Ein Risikoregister ohne Rückverfolgbarkeit zu den Risikominderungsmaßnahmen ist nicht ausreichend.

Die Teams, die Artikel 9 gut handhaben, behandeln ihn als Teil des Modellfreigabeprozesses und nicht als separate vierteljährliche Überprüfung.

Andere risikoreiche Verpflichtungen

Die übrigen Hochrisikoartikel setzen verschiedene Aspekte der Risikobewertung gemäß Artikel 9 um. Artikel 10 regelt die eingehenden Daten. Artikel 14 regelt die menschliche Kontrolle. Artikel 15 regelt Leistung und Sicherheit. Artikel 17 beschreibt das Managementsystem, das alle Aspekte miteinander verbindet. Jeder dieser Aspekte erfordert eine eindeutige Nachweiskette.

1. Daten und Daten-Governance (Artikel 10)

Artikel 10 regelt, welche Daten in Ihr System gelangen. Trainings-, Validierungs- und Testdatensätze müssen relevant, für den vorgesehenen Zweck ausreichend repräsentativ und, soweit vernünftigerweise praktikabel, fehlerfrei und vollständig sein.

Die Dokumentationspflicht umfasst die gesamte Datenpipeline: Designentscheidungen, Erhebungsmethodik und -ursprung, Aufbereitungsvorgänge (Annotation, Kennzeichnung, Bereinigung, Anreicherung, Aggregation), Annahmen, die in jeder Phase getroffen wurden, Bewertung der Datenverfügbarkeit und -eignung, Prüfung auf Verzerrungen und Identifizierung von Lücken.

Das Digital Omnibus vom Mai 2026 erweiterte eine Bestimmung in diesem Bereich. Anbieter und Betreiber von Systemen ohne hohes Risiko dürfen nun besondere Kategorien personenbezogener Daten zum Zweck der Erkennung und Korrektur von Verzerrungen verarbeiten, sofern dies zwingend erforderlich ist. Vor dem Omnibus war diese Ausnahme auf Systeme mit hohem Risiko beschränkt.

2. Menschliche Aufsicht (Artikel 14)

Artikel 14 verlangt, dass KI-Systeme mit hohem Risiko so konzipiert sein müssen, dass sie während ihrer Nutzung von natürlichen Personen effektiv überwacht werden können. Der Begriff „konzeptionell“ spielt hier eine entscheidende Rolle. Es handelt sich um eine Produktanforderung, nicht um eine politische Vorgabe. Die Überwachungsfunktion muss vor der Auslieferung in das System integriert sein.

Die praktischen Anforderungen: Menschliche Aufseher müssen in der Lage sein, die Fähigkeiten und Grenzen des Systems vollständig zu verstehen, sich der Automatisierungsverzerrung bewusst zu bleiben, die Ausgabe richtig zu interpretieren, zu entscheiden, sie nicht zu verwenden oder zu überschreiben, und über eine Stopptaste oder einen gleichwertigen Mechanismus einzugreifen oder zu unterbrechen.

Speziell für biometrische Fernidentifizierungssysteme schreibt Artikel 14 vor, dass Entscheidungen, die auf KI-Ergebnissen beruhen, von mindestens zwei natürlichen Personen überprüft und bestätigt werden müssen, bevor irgendwelche Folgemaßnahmen ergriffen werden.

Wenn Sie eine risikoreiche KI-Funktion entwickeln und die menschliche Überwachung erst in einer späteren Produktiteration einführen möchten, gehen Sie den falschen Weg. Die Überwachung muss von Anfang an in die Spezifikation einbezogen werden.

3. Genauigkeit, Robustheit und Cybersicherheit (Artikel 15)

Artikel 15 legt die Mindestanforderungen an Leistung und Sicherheit fest. Hochrisiko-KI-Systeme müssen während ihres gesamten Lebenszyklus ein angemessenes Maß an Genauigkeit, Robustheit und Cybersicherheit gewährleisten. Die Genauigkeitsstufen und die zu ihrer Messung verwendeten Metriken müssen in der Gebrauchsanweisung angegeben werden.

Robustheit bezeichnet die Widerstandsfähigkeit eines Systems gegenüber Fehlern, Störungen und Inkonsistenzen, einschließlich Versuchen, sein Verhalten zu verändern. Die Erwägungsgründe nennen die spezifischen Angriffsvektoren: Datenvergiftung, Modellvergiftung, Modellumgehung, Vertraulichkeitsangriffe und Adversarial Examples.

EEAT: Das sind keine theoretischen Bedrohungen mehr.

Sprinto'S 2026 Pulse Check-Bericht Eine Studie ergab, dass über 30 % der US-amerikanischen Organisationen in den letzten zwölf Monaten bereits einen schwerwiegenden KI-bezogenen Sicherheitsvorfall erlebt haben. Die häufigsten Angriffsmuster waren dabei die Nutzung von Schatten-KI, Datenlecks/Modellinversionen, API-Missbrauch und Datenvergiftung. Die Robustheitsklausel in Artikel 15 ist notwendig, da diese Angriffsflächen mittlerweile operative Realität und keine zukünftigen Risiken mehr darstellen.

Wenn Ihr risikoreiches KI-System auch ein Produkt mit digitalen Elementen gemäß dem EU-Cyberresilience-Act (CRA) ist, überschneiden sich Artikel 15 und der CRA erheblich. Diese Überschneidungen sollten Sie frühzeitig ermitteln. Sie beeinflussen, welche benannte Stelle (falls überhaupt) Sie benötigen und wie Sie Ihre technische Dokumentation strukturieren.

4. Qualitätsmanagementsystem (Artikel 17)

Artikel 17 verpflichtet Anbieter von KI-Systemen mit hohem Risiko, vor der Markteinführung ein Qualitätsmanagementsystem (QMS) einzurichten und dieses während des gesamten Lebenszyklus des Systems betriebsbereit zu halten.

Das Qualitätsmanagementsystem muss eine Strategie zur Einhaltung gesetzlicher Vorschriften, Verfahren für Design und Entwicklung, Test- und Verifizierungsverfahren, angewandte technische Spezifikationen und Normen, Datenmanagementsysteme, das Risikomanagementsystem gemäß Artikel 9, Verfahren zur Überwachung nach dem Inverkehrbringen, Verfahren zur Meldung von Vorfällen gemäß Artikel 73 sowie einen Verantwortlichkeitsrahmen umfassen.

ISO/IEC 42001 bietet ein nützliches Rahmenwerk für die Qualitätsmanagement-Governance, und Unternehmen mit einer bestehenden 42001-Zertifizierung haben einen Vorteil hinsichtlich Artikel 17. Allein die Norm 42001 genügt jedoch nicht für die Konformität. Das EU-Büro für Künstliche Intelligenz (AKI) hat darauf hingewiesen, dass die bestehenden ISO-Qualitätsmanagementnormen den Ansatz der EU nicht vollständig widerspiegeln. Die harmonisierte europäische Norm prEN 18286, die vom CEN-CENELEC JTC 21 erarbeitet wird und voraussichtlich Ende 2026 veröffentlicht wird, wird schließlich die Konformitätsvermutung schaffen. Bis dahin sollten Sie Ihr Qualitätsmanagementsystem an den Anforderungen von Artikel 17 ausrichten.

5. Konformitätsbewertung, CE-Kennzeichnung und Registrierung in der EU-Datenbank

Bevor ein KI-System mit hohem Risiko ausgeliefert wird, sind vier Schritte erforderlich. Zunächst die Konformitätsbewertung, die EU-Konformitätserklärung und die CE-Kennzeichnung. Anschließend muss das System, bevor es auf den Markt kommt, in der EU-Datenbank registriert werden.

• Konformitätsbewertung: Dies beinhaltet die Überprüfung, ob das System die Artikel 9 bis 15 und Artikel 17 erfüllt. Es gibt zwei Wege. Die interne Kontrolle (Anhang VI) findet auf die meisten Systeme gemäß Anhang III Anwendung, wobei der Anbieter die Bewertung intern ohne Beteiligung Dritter durchführt. Die Bewertung durch eine benannte Stelle (Anhang VII) findet Anwendung auf Systeme zur biometrischen Fernidentifizierung, KI-Sicherheitskomponenten in regulierten Produkten und Fälle, in denen der Anbieter keine harmonisierten Normen angewendet hat.

Interne Kontrolle bedeutet nicht weniger Arbeit. Sie bedeutet, dass Sie selbst die Zertifizierungsstelle sind. Ihre Dokumentation muss auch ohne das Siegel einer benannten Stelle einer behördlichen Prüfung standhalten.

• EU-Konformitätserklärung (Artikel 47): Nach Abschluss der Prüfung erstellt der Anbieter eine Erklärung, dass das System alle geltenden Anforderungen erfüllt. Es handelt sich um ein rechtsverbindliches Dokument, nicht um eine Formalität.
• CE-Kennzeichnung (Artikel 48): Das CE-Zeichen ist das EU-Standardzeichen für die Konformität mit EU-Vorschriften und findet sich auf Produkten aller Art – von Spielzeug über Medizinprodukte bis hin zu Industriemaschinen –, die in der EU verkauft werden. Bei KI-Systemen mit hohem Risiko ist die Anbringung des CE-Zeichens eine rechtsverbindliche Erklärung, dass der Anbieter die Konformitätsbewertung abgeschlossen hat und das System den Anforderungen der Verordnung entspricht. Die CE-Kennzeichnung wird erst nach Erstellung der Konformitätserklärung gemäß Artikel 47 angebracht. Eine Anbringung vor Abschluss der Konformitätsbewertung stellt einen Verstoß dar.
• EU-Datenbankregistrierung (Artikel 49): Bevor Anbieter ein System auf den Markt bringen, müssen sie es in der öffentlichen KI-Datenbank der EU registrieren. Das Omnibusgesetz hat diese Pflicht nun auch für Systeme wieder eingeführt, die sich auf die Ausnahmeregelung nach Artikel 6 Absatz 3 berufen. Grund dafür ist die Rückverfolgbarkeit.

Anforderungen an die technische Dokumentation des AI Act

Die technische Dokumentation gemäß dem Gesetz umfasst zwei unterschiedliche Dinge, die leicht verwechselt werden können. Die Datei in Anhang IV beschreibt das System. Die Ereignisprotokollierung nach Artikel 12 erfasst die Systemaktivitäten während des Betriebs. Die eine Dokumentation wird vor der Markteinführung erstellt, die andere nach der Markteinführung. Beide sind erforderlich.

1. Die technische Dokumentationsdatei gemäß Anhang IV

Anhang IV spezifiziert neun Abschnitte. Dies ist die Datei, die eine Aufsichtsbehörde als erstes anfordert. Erstellen Sie sie von Anfang an, versionskontrolliert zusammen mit dem System.

Abschnitt 1, allgemeine Beschreibung: Name, Version, Verwendungszweck, Anbieter und Komponenten, auf denen das System basiert (einschließlich Drittanbietermodelle), Hardware, auf der es läuft, und Gebrauchsanweisung.

Abschnitt 2, detaillierte Beschreibung der Systemelemente: Entwicklungsmethoden, Designspezifikationen, Architektur, Rechenressourcen, Anforderungen an Trainingsdaten und die Begründung für jede wichtige Designentscheidung.

Abschnitt 3, Überwachung, Funktionsweise und Steuerung: Wie das System im Betrieb überwacht wird, seine Funktionsparameter und die den Betreibern und Anwendern zur Verfügung stehenden Steuerungsmöglichkeiten. Ihre Mechanismen zur menschlichen Aufsicht gemäß Artikel 14 sind hier dokumentiert.

Abschnitt 4, Leistungskennzahlen: Die Kennzahlen, die zur Beurteilung von Genauigkeit, Robustheit und Verzerrung verwendet werden, mit Begründung, warum diese Kennzahlen für den beabsichtigten Zweck geeignet sind.

Abschnitt 5, Dokumentation zum Risikomanagement: Die Ergebnisse Ihres Prozesses gemäß Artikel 9, die Iterationen, die identifizierten Risiken und die konkreten eingesetzten Risikominderungsmaßnahmen.

Abschnitt 6, Lebenszyklusänderungen: Wird jedes Mal aktualisiert, wenn das System modifiziert, neu trainiert oder sein Anwendungsfall erweitert wird.

Abschnitt 7, Angewendete Normen und Spezifikationen: Die angewandten harmonisierten Normen mit spezifischen Bestimmungsverweisen. Wo keine harmonisierte Norm angewendet wurde, eine Beschreibung der alternativen Lösung, die zum Nachweis der Konformität verwendet wurde.

Abschnitt 8, EU-Konformitätserklärung: Eine Kopie der Erklärung nach Artikel 47.

Abschnitt 9, Plan zur Überwachung nach der Markteinführung: Die Überwachungsmethodik, Kennzahlen und Schwellenwerte, die Korrekturmaßnahmen auslösen, sowie die Verfahren zur Meldung von Vorfällen. Dieser Abschnitt muss vor der Auslieferung des Systems vorhanden sein.

Sie können nicht vor Gericht argumentieren, dass unvollständige Dokumentation akzeptabel war, weil die harmonisierten Normen nicht veröffentlicht waren. Normen sind ein freiwilliger Weg zur Einhaltung der Vorschriften. Ihr Fehlen hindert das Gesetz nicht an der Anwendung.

2. Automatische Ereignisprotokolle (Artikel 12)

Artikel 12 schreibt vor, dass KI-Systeme mit hohem Risiko mit einer automatischen Protokollierung ausgestattet sein müssen, die Ereignisse zur Risikoidentifizierung und wesentliche Änderungen während ihrer gesamten Betriebsdauer aufzeichnet. Die Protokolle müssen die Überwachung nach der Markteinführung ermöglichen, die Risikoidentifizierung unterstützen und den Anwendern die Überwachung des Systembetriebs gestatten.

Die Mindestanforderung: die für jede Entscheidung verwendeten Eingangsdaten, die abgefragten Referenzdatenbanken, die gegebenenfalls an der Überprüfung des Ergebnisses beteiligten natürlichen Personen und der Zeitraum für jede Verwendung.

Die Aufbewahrungsfrist beträgt mindestens sechs Monate. Im Finanzdienstleistungs- und Gesundheitswesen sind in der Regel längere Aufbewahrungsfristen erforderlich; prüfen Sie die branchenspezifischen Bestimmungen, bevor Sie Aufbewahrungszeiträume festlegen.

Erstellen Sie die Protokollierungsschicht, bevor Sie die Funktionen entwickeln. Die nachträgliche Integration einer strukturierten Ereignisprotokollierung ist teuer, erzeugt historische Lücken, die bei einer Überprüfung deutlich werden, und erfordert Architekturänderungen, die Produktteams im Nachhinein nur ungern vornehmen.

Transparenzanforderungen des EU-KI-Gesetzes

Die Transparenzpflichten gemäß dem Gesetz lassen sich in zwei Kategorien unterteilen, die oft fälschlicherweise als eine einzige Kategorie behandelt werden. Artikel 13 regelt die Informationspflichten der Anbieter gegenüber den Systembetreibern. Artikel 50 regelt die Informationspflichten des Systems gegenüber den Nutzern. Die beiden Artikel haben unterschiedliche Zuständigkeiten und funktionieren nach unterschiedlichen Mechanismen.

1. Artikel 13, Transparenz gegenüber den Anwendern

Artikel 13 verpflichtet Anbieter, KI-Systeme mit hohem Risiko mit prägnanten, vollständigen, korrekten und verständlichen Gebrauchsanweisungen zu versehen. Diese müssen die Identität und Kontaktdaten des Anbieters, die Eigenschaften, Fähigkeiten und Grenzen des Systems (einschließlich der getesteten Genauigkeitsniveaus und bekannter, vorhersehbarer Risiken), die vom Anwender zu gewährleistenden Überwachungsmaßnahmen, die erwartete Betriebsdauer und Wartung sowie eine Beschreibung der Protokollierungsmechanismen enthalten.

Gebrauchsanweisungen sind ein rechtsverbindliches Dokument. Verfassen Sie sie unter der Annahme, dass sowohl die Rechtsabteilung des Anbieters als auch die Aufsichtsbehörde sie lesen werden.

2. Artikel 50, Transparenz gegenüber den Nutzern

Artikel 50 umfasst vier Verpflichtungen, die jeweils durch eine andere Art von KI-System ausgelöst werden.

1. Chatbots und KI-Systeme, die mit natürlichen Personen interagieren, müssen die Nutzer darüber informieren, dass sie mit einem KI-System interagieren, es sei denn, dies ergibt sich eindeutig aus dem Kontext. Diese Regelung gilt bereits für Systeme mit begrenztem Risiko.
2. KI-generierte synthetische Inhalte müssen mithilfe maschinenlesbarer Methoden, wie Wasserzeichen, Metadaten oder kryptografischen Markierungen, als künstlich erzeugt gekennzeichnet werden. Der Verhaltenskodex zur Kennzeichnung KI-generierter Inhalte (zweiter Entwurf, veröffentlicht am 5. März 2026) dient als operative Spezifikation. Die Kennzeichnung verschiedener Inhaltsmodalitäten erfordert unterschiedliche technische Ansätze, und der Kodex wird derzeit noch überarbeitet.
3. Deepfakes müssen als künstlich erzeugt oder manipuliert gekennzeichnet und zusätzlich als maschinenlesbar gekennzeichnet werden.
4. KI-generierte Texte, die im öffentlichen Interesse veröffentlicht werden, müssen ihren künstlichen Ursprung offenlegen. Es gelten begrenzte Ausnahmen.

Zeitlicher Ablauf: Die gemäß Artikel 50 Absatz 2 vorgeschriebene maschinenlesbare Kennzeichnung gilt ab dem 2. August 2026 für neue generative KI-Systeme. Anbieter, deren Systeme bis zu diesem Datum auf dem Markt sind, erhalten eine Übergangsfrist bis zum 2. Dezember 2026.

Das neue Verbot von KI-generierten CSAM- oder nicht einvernehmlichen intimen Bildern gemäß Artikel 5 tritt am 2. Dezember 2026 in Kraft. Es gilt für speziell entwickelte Systeme und für Anbieter von generativer KI für allgemeine Zwecke, die keine angemessenen Schutzmaßnahmen treffen.

Marktüberwachung und Meldung von Vorfällen

Sobald ein risikoreiches KI-System auf dem Markt verfügbar ist, verlagern sich die Pflichten, anstatt zu enden. Die Artikel 72 und 73 regeln den Überwachungsprozess und die Meldung von Vorfällen, die so lange gelten, wie das System in Betrieb ist. Die meisten KI-Programme unterschätzen dies. Die Entwicklungsphase erhält die gesamte Aufmerksamkeit, während die Überwachungsphase von denjenigen übernommen wird, die für die Aktivitäten nach der Auslieferung verantwortlich sind. 

a. Artikel 72, Überwachung nach dem Inverkehrbringen

Artikel 72 verpflichtet Anbieter, ein dem Risiko des Systems angemessenes System zur Überwachung nach dem Inverkehrbringen einzurichten, zu dokumentieren und aktiv zu betreiben. Dieses System muss Leistungsdaten während des gesamten Betriebslebenszyklus erfassen, dokumentieren und analysieren, damit der Anbieter beurteilen kann, ob das System weiterhin den Vorschriften entspricht.

Der Überwachungsplan, der vor der Auslieferung des Systems in Anhang IV Abschnitt 9 dokumentiert werden muss, muss die Methoden der Datenerfassung und -analyse, die Kennzahlen und Schwellenwerte, die eine Anomalie darstellen, sowie die Kriterien, die Korrekturmaßnahmen auslösen, festlegen.

b. Artikel 73, Meldung schwerwiegender Vorfälle

Artikel 73 legt die Fristen für die Meldung schwerwiegender Vorfälle an die zuständige Marktüberwachungsbehörde fest. Drei Kategorien, drei Fristen:

1. Standardmäßige schwerwiegende Vorfälle: Meldung spätestens 15 Tage nach Kenntniserlangung.
2. Vorfälle, die eine Verletzung von Grundrechten darstellen: Meldung innerhalb von 72 Stunden.
3. Bei weit verbreiteten Verstößen oder Vorfällen mit Todesfolge: Sofort, spätestens jedoch innerhalb von 2 Tagen, melden.

Diese Zeitvorgaben erfordern, dass Ihr Prozess zur Erkennung und Klassifizierung von Vorfällen eingerichtet ist, bevor Sie ihn benötigen. Das 15-Tage-Fenster ist kürzer als es scheint, wenn man interne Eskalation, rechtliche Prüfung und die Kontaktaufnahme mit der zuständigen Behörde berücksichtigt. Entwickeln Sie den Prozess. Und bewahren Sie ihn dann griffbereit auf.

Die nicht standardisierte Zone: Was harmonisierte Normen nicht abdecken

Die im Rahmen des CEN-CENELEC JTC 21 entwickelten harmonisierten europäischen Normen werden schließlich die Artikel 8 bis 15, die wesentlichen Hochrisikoverpflichtungen, abdecken. Nach ihrer Veröffentlichung gilt für diese Artikel eine Konformitätsvermutung. Sie werden jedoch nicht alle Aspekte umfassen, was von den meisten Teams falsch eingeschätzt wird.

Wenn Sie die harmonisierten Normen als die endgültige Antwort auf alle betrieblichen Fragen betrachten, werden Sie wahrscheinlich überrascht sein. Ein wesentlicher Teil Ihrer Vorbereitung auf das Gesetz wird auch nach Veröffentlichung der Normen weiterhin vom Gesetzestext, den sich entwickelnden Leitlinien der Kommission und Ihrem eigenen rechtlichen Urteilsvermögen bestimmt sein.

Was die Standards (letztendlich) umfassen werden:

• Methodik des Risikomanagements gemäß Artikel 9
• Praktiken der Daten-Governance gemäß Artikel 10
• Artikel 11 Struktur der technischen Dokumentation
• Protokollierungspflichten gemäß Artikel 12
• Artikel 13 Transparenz gegenüber den Anwendern
• Artikel 14 Mechanismen zur menschlichen Aufsicht
• Artikel 15 Genauigkeits-, Robustheits- und Cybersicherheitstests
• Artikel 17 QMS (über prEN 18286)

Was die Standards nicht abdecken:

• Risikoklassifizierung gemäß Artikel 6 und Anhang III: Die Frage, ob Ihr System ein hohes Risiko darstellt, ist eine rechtliche, keine technische. Normen können Ihnen nicht sagen, ob Ihr Einstellungstool unter Anhang III fällt; dies ergibt sich aus dem Rechtstext und den Richtlinien der Kommission.
• Die Analyse der Ausweichklausel in Artikel 6(3): Wenn Sie behaupten, Ihr System sei trotz der Einstufung in Anhang III nicht risikoreich, muss die Begründung hierfür eine juristische Beurteilung sein. Kein Standard kann Ihnen dabei helfen.
• Artikel 4 KI-Kompetenz: Der Begriff „ausreichende KI-Kompetenz“ ist auslegungsbedürftig. Die Kommission unterhält eine ständig aktualisierte Sammlung von Best Practices, aber es gibt keinen einheitlichen Standard dafür, was KI-Schulungen beinhalten sollten.
• Offenlegungspflichten gemäß Artikel 50: Der Verhaltenskodex für Kennzeichnung und Etikettierung befindet sich in der Ausarbeitung, ist aber lediglich ein Verhaltenskodex und kein harmonisierter Standard. Die Implementierung von Wasserzeichen variiert zudem je nach Inhaltsart.
• Artikel 5 verbotene Praktiken: Die Liste der verbotenen Verwendungen findet sich im Gesetzestext und wird durch Gesetzesänderungen erweitert. Normen übersetzen „verboten“ nicht in praktische Anweisungen. Man tut entweder das Verbotene oder nicht.

Verwendung des GPAI-Verhaltenskodex als Anbieterspezifikation

Wenn Sie als SaaS-Team auf Basis von OpenAI-, Anthropic-, Google- oder Mistral-Grundlagenmodellen arbeiten, ist der GPAI-Verhaltenskodex das wichtigste operative Dokument im Ökosystem des Gesetzes. Er existiert, weil nachgelagerte Anbieter (Sie) spezifische Informationen und Garantien von vorgelagerten GPAI-Anbietern benötigen, um ihren eigenen Verpflichtungen nachzukommen. Die meisten Teams haben bisher nicht erkannt, dass sie ihn als Verhandlungsinstrument im Beschaffungswesen nutzen können.

Der Kodex wurde am 10. Juli 2025 veröffentlicht und am 1. August 2025 von der Kommission und dem KI-Ausschuss formell genehmigt. Er ist in drei Kapitel unterteilt: Transparenz, Urheberrecht sowie Sicherheit. 

Die ersten beiden beziehen sich auf die Verpflichtungen aus Artikel 53, die für alle GPAI-Anbieter gelten. Der dritte Abschnitt umfasst die Verpflichtungen aus Artikel 55, die nur für Anbieter von GPAI-Modellen mit systemischem Risiko gelten (typischerweise solche, die mit mehr als 10²⁵ FLOPs Rechenleistung trainiert wurden).

OpenAI, Anthropic und Google gehören zu den Unterzeichnern. Die Einhaltung ist freiwillig, Unterzeichner profitieren jedoch von einer reduzierten Durchsetzung der Bestimmungen, und die Einhaltung wird bei der Festsetzung von Bußgeldern berücksichtigt.

Was dies in der Praxis für Ihre Lieferantenverhandlungen bedeutet:

• Sie können von Ihrem Modellanbieter eine codekonforme Dokumentation anfordern: Der Kodex legt fest, welche Informationen Anbieter nachgelagerten Integratoren zur Verfügung stellen müssen: Modellkarten, Zusammenfassungen der Trainingsdaten, Evaluierungsberichte und Dokumentationen, die eine sichere Implementierung des Modells ermöglichen. Fordern Sie diese Informationen explizit in Ihren Verträgen an.
• Die Einhaltung der Verhaltensregeln kann wie folgt bestätigt werden: Bei der Aushandlung von Vertragsverlängerungen oder Neuverträgen mit Anbietern von Foundation-Modellen sollten Sie diese bitten, schriftlich zu bestätigen, welche konkreten Verpflichtungen des Kodex sie erfüllen, und die entsprechenden Belege vorzulegen.
• Nichtunterzeichner-Lieferanten sind ein Signal für die Beschaffung: Ist ein Anbieter eines Basismodells kein Unterzeichner des Kodex, sollte dies im Rahmen der Lieferantenprüfung vermerkt werden. Dies schließt ihn zwar nicht aus, bedeutet aber einen höheren Dokumentationsaufwand für Sie als nachgelagerter Anbieter und erschwert die Beweisführung.
• Der Kodex dient als Grundlage für Ihre Dokumentation gemäß Anhang IV: Beim Verfassen von Anhang IV Abschnitt 1 (Allgemeine Beschreibung) und Abschnitt 2 (Systemelemente) verweisen Sie auf das GPAI-Modell, auf dem Ihr System basiert. Die vom Code geforderten Artefakte Ihres Modellanbieters füllen diese Verweise. Ohne diese weist Ihre Anhang-IV-Datei Lücken auf, die den Aufsichtsbehörden auffallen werden.

Was sich im Mai 2026 geändert hat: Die Kurzzusammenfassung des Digital Omnibus

Die Europäische Kommission, das Exekutivorgan der EU, schlug den Digitalen Omnibus zur KI vor, nachdem deutlich geworden war, dass die harmonisierten Standards, die Unternehmen zur Erfüllung der Verpflichtungen bis August 2026 benötigen, nicht rechtzeitig fertiggestellt sein würden. 

Anschließend wurde der Vorschlag in die Trilogverhandlungen überführt, das nichtöffentliche Verfahren, in dem die Kommission, das Europäische Parlament und der Rat der EU (als Vertreter der Regierungen der Mitgliedstaaten) einen endgültigen Kompromisstext ausarbeiten. 

Die erste Runde endete ergebnislos, doch die drei Institutionen kamen erneut zusammen und erzielten am 7. Mai 2026 eine vorläufige Einigung. Diese beinhaltete unter anderem folgende wesentliche Änderungen:

• Die Frist für die Festlegung der Hochrisikoverpflichtungen gemäß Anhang III wurde vom ursprünglichen Termin am 2. August 2026 auf den 2. Dezember 2027 verschoben.
• Die Frist für die Festlegung von Hochrisikoverpflichtungen gemäß Anhang I (KI in regulierten Produkten) wurde vom 2. August 2027 auf den 2. August 2028 verschoben.
• Die Wasserzeichenpflicht gemäß Artikel 50(2) bleibt für neue generative KI-Systeme am 2. August 2026 bestehen. Anbieter, deren Systeme zu diesem Zeitpunkt bereits auf dem Markt sind, erhalten eine Übergangsfrist bis zum 2. Dezember 2026.
• Neuer Artikel 5 verbietet KI-Systeme, die CSAM oder nicht einvernehmliche intime Bilder erzeugen (Nudifizierungswerkzeuge). Gilt ab dem 2. Dezember 2026.
• Die KMU-Hilfen wurden auf kleine und mittlere Unternehmen (KMU) ausgeweitet.
• Die Maschinenverordnung wurde vom direkten Anwendungsbereich des KI-Gesetzes ausgenommen. MDR, IVDR und die Funkanlagenrichtlinie wurden nicht verschoben.
• Die EU-Datenbankregistrierung wurde für Hochrisikosysteme, die sich auf die Ausnahmeregelung in Artikel 6(3) berufen, wieder eingeführt.

Unverändert blieben: Verbotene Praktiken, die in Artikel 4 geforderte KI-Kompetenz, die GPAI-Verpflichtungen und die materiellen Anforderungen an Hochrisikosysteme selbst.

Dies ist eine vorläufige politische Vereinbarung. Sie bedarf noch der förmlichen Zustimmung des Rates und des Parlaments, einer rechtlich-sprachlichen Überarbeitung und der Veröffentlichung im Amtsblatt. Beide Institutionen haben sich zur Annahme vor dem 2. August 2026 verpflichtet. Bis dahin bleiben die ursprünglichen Daten des AI-Gesetzes rechtlich gültig, die praktische Planungsgrundlage bilden jedoch die neuen Daten.

Schritt-für-Schritt-Anleitung zur Erfüllung der Anforderungen des EU-KI-Gesetzes

Hier erfahren Sie, wie Sie die Anforderungen des EU-KI-Gesetzes nach Kategorien erfüllen können.

1. Erstellen Sie Ihren KI-Bestand. Finden Sie jedes KI-System in Ihrer Umgebung, einschließlich der von Mitarbeitern informell eingesetzten Schatten-KI.
2. Klassifizieren Sie das Risiko für jedes System. Verwenden Sie die obige Tabelle des risikobasierten Rahmens. Dokumentieren Sie gegebenenfalls die Begründung gemäß Artikel 6 Absatz 3.
3. Ordnen Sie Ihre Rolle jedem System zu. Nutzen Sie die obige Stakeholder-Tabelle. Ihre Verpflichtungen ergeben sich daraus.
4. Die erforderlichen Kontrollmaßnahmen implementieren. Bei Hochrisikosystemen arbeiten Sie sich anhand der obigen Abschnitte durch die Artikel 9, 10, 12, 14, 15 und 17.
5. Dokumentation und Nachweise erstellen. Anhang IV neun Abschnitte, versionskontrolliert zusammen mit dem System.
6. Vollständige Konformitätsbewertung und Registrierung. Artikel 43, 47, 48, 49 in der angegebenen Reihenfolge.
7. Richten Sie Überwachung und Berichterstattung ein. Artikel 72 und 73, vor dem Start in Kraft gesetzt.

Jeder Artikel dieses Gesetzes stellt eine fortlaufende Verpflichtung dar, kein einmaliges Projekt. Das Risikomanagement gemäß Artikel 9 wird bei jeder Modellfreigabe durchgeführt. Die Protokolle gemäß Artikel 12 werden täglich erfasst. Die Überwachung gemäß Artikel 72 läuft, solange das System in Betrieb ist.

Documentation drifts the moment the system changes. The teams that handle this effectively typically don’t run compliance as a quarterly exercise; they treat it as live infrastructure. That is what Sprinto ist gebaut für.

Wie Sprinto helps you meet EU AI Act requirements

Sprinto is an Autonomous Trust Platform that maps the controls you already operate (SOC 2, ISO 27001, ISO 42001, GDPR, NIST AI RMF) to specific AI Act Articles, so the 40-60% overlap most teams have becomes operational evidence rather than evidence you build twice. When new evidence is required, the platform tells you which Articles are short and what the gap is. 

Drei Dinge sind für die Artikel in diesem Gesetz von größter Bedeutung:

1. Die Erkennung von Schatten-KI trägt zur Dokumentation nach Artikel 11 und zur Kenntnis nach Artikel 4 bei: Your Annex IV file cannot describe systems you do not know exist. Sprinto’s live registry surfaces every AI tool in your environment, including those product or marketing teams brought in informally, so your inventory is real rather than aspirational.
2. Durch die rahmenübergreifende Zuordnung werden die Artikel 9 bis 15 und 17 in Beweismittel umgewandelt, die Sie bereits besitzen: SOC-2-Kontrollen erfüllen Teile von Artikel 15. ISO-42001-Kontrollen erfüllen Teile von Artikel 17. Die Plattform verbindet diese automatisch. Die verbleibenden Aufgaben betreffen die KI-spezifischen Anpassungen und nicht das gesamte Programm.
3. Die kontinuierliche Überwachung ist Artikel 72: The post-market obligation is where most compliance programs lose ground because the team that built the system has moved on. Sprinto’s monitoring loop flags drift in real time: when a control fails, when evidence ages out, when a vendor adds an AI feature you have not assessed. The Article 72 plan that lives in your Annex IV file becomes the system that actually runs.

Vereinbaren Sie eine Demo mit unserem Team, um zu sehen, wie sich die EU-KI-Gesetzgebung auf Ihr Unternehmen auswirkt: welche Artikel für Ihre Systeme gelten, welche Kontrollmechanismen Sie bereits implementiert haben und wie die nächsten 90 Tage aussehen werden.

Häufig gestellte Fragen