Schlagwort: EU AI Act

So bereiten sich Anbieter vor

Die Konformitätsbewertung ist der Nachweis, dass ein Hochrisiko-KI-System alle Anforderungen der KI-Verordnung erfüllt, bevor es in Verkehr gebracht wird.Art. 43 sieht für Hochrisiko-KI-Systeme grundsätzlich zwei Konformitätsbewertungsverfahren vor: die interne Kontrolle nach Anhang VI und die Bewertung unter Beteiligung einer Benannten Stelle nach Anhang VII. Welches Verfahren gilt, hängt davon ab, ob es sich um ein Hochrisiko-KI-System nach Anhang III handelt oder um ein KI-System als Teil eines regulierten Produkts nach Anhang I. Dieser Beitrag analysiert beide Verfahren, ordnet die Rolle der Benannten Stellen ein und zeigt, welche Vorbereitungsschritte Unternehmen bis August 2026 priorisieren sollten.

Der Artikel erklärt die Konformitätsbewertung Hochrisiko-KI als verpflichtenden Nachweis der EU-KI-Verordnung, dass ein Hochrisiko-KI-System vor dem Inverkehrbringen alle Anforderungen erfüllt. Er definiert die Unterschiede zwischen interner Kontrolle nach Anhang VI und Drittbewertung durch eine Benannte Stelle nach Anhang VII.

Zwei Wege zur Konformität

Art. 43 unterscheidet zwei Konformitätsbewertungsverfahren; maßgeblich ist dabei insbesondere, ob das System unter Anhang III oder unter Anhang I fällt.

Der erste Weg ist die interne Kontrolle nach Anhang VI. Sie gilt für Hochrisiko-KI-Systeme nach Anhang III, Punkte 2 bis 8 – also für Systeme in den Bereichen kritische Infrastruktur, Bildung, Beschäftigung, öffentliche Leistungen, Strafverfolgung, Migration und Rechtspflege (Anhang III Punkte 2 bis 8). Bei der internen Kontrolle bewertet der Anbieter selbst, ob sein System die Anforderungen erfüllt. Eine externe Prüfstelle ist nicht erforderlich. Das bedeutet allerdings nicht, dass die Anforderungen geringer wären – der Anbieter muss dieselben materiellen Pflichten erfüllen und die Konformität vollständig dokumentieren. Die interne Kontrolle ist eine Verfahrenserleichterung, keine inhaltliche Reduktion.

Die Bewertung unter Beteiligung einer Benannten Stelle nach Anhang VII ist für Systeme nach Anhang III, Punkt 1, erforderlich, wenn keine harmonisierten Normen oder gemeinsamen Spezifikationen angewendet werden, sowie für KI-Systeme im Anwendungsbereich von Anhang I, soweit das jeweilige sektorale Recht eine Drittprüfung vorsieht.

Sie ist in zwei Fällen vorgeschrieben: erstens für KI-Systeme, die als Sicherheitskomponente in ein reguliertes Produkt nach Anhang I eingebettet sind – hier wird die KI-Konformitätsbewertung in die bestehende sektorale Bewertung integriert, etwa in die Konformitätsbewertung nach der der jeweils einschlägigen harmonisierten Produktrechtsvorschrift nach Anhang I oder der Maschinenverordnung.
Zweitens für biometrische Identifikationssysteme und andere Systeme nach Anhang III Punkt 1, wenn der Anbieter keine harmonisierten Normen oder gemeinsamen Spezifikationen vollständig anwendet. Wendet er diese vollständig an, besteht ein Wahlrecht zwischen interner Kontrolle und Drittbewertung. Diese Systeme tragen ein besonders hohes Grundrechtsrisiko, weshalb der Gesetzgeber eine externe Prüfung als zusätzliche Absicherung vorsieht.

Interne Kontrolle nach Anhang VI

Die interne Kontrolle nach Anhang VI umfasst zwei Kernelemente.

Das erste ist die Überprüfung des Qualitätsmanagementsystems nach Art. 17. Der Anbieter muss nachweisen, dass sein QMS die Anforderungen der Verordnung abdeckt – von der Entwicklungsstrategie über das Risikomanagement bis zur Post-Market-Überwachung. Die Überprüfung umfasst die Dokumentation der QMS-Prozesse, die Nachvollziehbarkeit der Verantwortlichkeiten und den Nachweis, dass das QMS tatsächlich angewendet wird und nicht nur auf dem Papier existiert.

Das zweite ist die Prüfung der technischen Dokumentation nach Art. 11 und Anhang IV. Der Anbieter muss die technische Dokumentation nach Art. 11 und Anhang IV vollständig erstellen, prüfen und sicherstellen, dass Design, Entwicklung und Testing den dokumentierten Prozessen entsprechen.
Die Konsistenz zwischen Dokumentation und tatsächlichem System ist der kritische Prüfpunkt: Wenn die Dokumentation ein Risikomanagementsystem beschreibt, das in der Praxis anders funktioniert, besteht keine Konformität.

Die interne Kontrolle verlangt keine externe Validierung – aber sie verlangt eine ehrliche und dokumentierte Selbstbewertung. Der Anbieter muss nachweisen können, dass er jede Anforderung systematisch geprüft und die Ergebnisse festgehalten hat. Marktüberwachungsbehörden können jederzeit die Dokumentation der internen Kontrolle anfordern und deren Qualität bewerten. In der Praxis empfiehlt sich ein internes Audit-Team, das unabhängig von der Entwicklungsabteilung agiert und die Konformität mit dem Blick einer externen Prüfstelle bewertet. Unternehmen, die diese Fähigkeit nicht intern aufbauen können, sollten externe Berater hinzuziehen, auch wenn das Verfahren formal keine Benannte Stelle erfordert.

Bewertung durch Benannte Stellen nach Anhang VII

Die Bewertung nach Anhang VII umfasst die Prüfung des Qualitätsmanagementsystems und der technischen Dokumentation; zusätzliche Tests können ergänzend durchgeführt werden-

Die erste Stufe ist das QMS-Audit. Die Benannte Stelle prüft, ob das Qualitätsmanagementsystem des Anbieters die Anforderungen nach Art. 17 erfüllt – nicht nur formal, sondern auch in der praktischen Umsetzung. Sie prüft Prozesse, Verantwortlichkeiten, Schulungsnachweise und die Integration des Risikomanagements in den Entwicklungsprozess.

Die zweite Stufe ist die Bewertung der technischen Dokumentation. Die Benannte Stelle erhält vollständigen Zugang zur technischen Dokumentation und zu den Trainings-, Validierungs- und Testdatensätzen. Sie bewertet die Vollständigkeit, Konsistenz und Nachvollziehbarkeit der Dokumentation und prüft, ob die dokumentierten Risikomanagementmaßnahmen, Testverfahren und Leistungsmetriken den Anforderungen der Verordnung entsprechen.

Die dritte Stufe kann zusätzliche Tests umfassen. Die Benannte Stelle kann eigenständig Tests des KI-Systems durchführen oder vom Anbieter durchgeführte Tests verifizieren. Sie kann auch Zugang zu den Entwicklungs- und Testeinrichtungen verlangen, um die Übereinstimmung zwischen Dokumentation und tatsächlichem System zu überprüfen.

Am Ende des Verfahrens kann die Benannte Stelle eine Bescheinigung über die Konformitätsbewertung beziehungsweise die technische Dokumentation ausstellen, je nach einschlägigem Verfahren.
Diese Bescheinigung hat eine begrenzte Gültigkeit, sie richtet sich nach dem einschlägigen Verfahren und der Bescheinigung, und muss bei wesentlichen Systemänderungen erneuert werden. Die Benannte Stelle kann die Bescheinigung auch aussetzen oder widerrufen, wenn sie feststellt, dass das System die Anforderungen nicht mehr erfüllt. Für Anbieter bedeutet das: Die Konformitätsbewertung endet nicht mit der Bescheinigung, sondern begründet ein dauerhaftes Verhältnis zur Benannten Stelle, das regelmäßige Nachprüfungen einschließt.

Benannte Stellen: Anforderungen und Kapazitäten

Art. 44 bis 46 definieren die Anforderungen an Benannte Stellen und das Verfahren ihrer Benennung durch die Mitgliedstaaten.

Benannte Stellen müssen unabhängig vom Anbieter und von dessen Wettbewerbern sein. Ihr Bewertungspersonal muss über Fachkompetenz in KI-Technologien, Risikomanagement und den spezifischen Anwendungsbereichen verfügen. Die Mitgliedstaaten benennen die zuständigen Behörden für die Notifizierung und Überwachung der Benannten Stellen.

Für Unternehmen, die eine Drittbewertung benötigen, ist die Kapazitätsfrage drängend: Die Zahl qualifizierter Benannter Stellen für KI-Systeme wird zum Stichtag 2. August 2026 voraussichtlich begrenzt sein. Der Aufbau der notwendigen Kompetenz und Infrastruktur bei den Prüfstellen läuft parallel zum Aufbau der Compliance bei den Anbietern. Unternehmen sollten frühzeitig Kontakt zu potenziellen Benannten Stellen aufnehmen und Bewertungsslots reservieren – eine Vorlaufzeit von sechs bis neun Monaten ist realistisch.

CE-Kennzeichnung und Konformitätserklärung

Nach erfolgreicher Konformitätsbewertung folgen zwei formale Schritte.

Die EU-Konformitätserklärung nach Art. 47 ist ein maschinenlesbares Dokument, in dem der Anbieter erklärt, dass das KI-System die Anforderungen des Abschnitts 2 der Verordnung erfüllt. Sie wird zehn Jahre aufbewahrt und den Aufsichtsbehörden auf Verlangen vorgelegt. Die Konformitätserklärung verweist auf die technische Dokumentation und auf die angewendeten Normen oder, in Abwesenheit harmonisierter Normen, auf die Grundlage, anhand derer die Konformität nachgewiesen wird.

Die CE-Kennzeichnung nach Art. 48 wird sichtbar und dauerhaft am KI-System oder, wenn dies nicht möglich ist, auf der Verpackung oder in den Begleitunterlagen angebracht. Bei Systemen, die einer Drittbewertung unterzogen wurden, folgt auf das CE-Zeichen die Kennnummer der Benannten Stelle. Die CE-Kennzeichnung signalisiert den Marktüberwachungsbehörden und Nutzern, dass das System die Konformitätsbewertung durchlaufen hat. Für digital bereitgestellte Hochrisiko-KI-Systeme ist eine digitale CE-Kennzeichnung zu verwenden, sofern sie über die Benutzeroberfläche oder ein leicht zugängliches maschinenlesbares Mittel erreichbar ist, eine Praxis, die sich von der klassischen Produktkennzeichnung unterscheidet und für viele Softwareanbieter Neuland darstellt.

Sektorale Integration: Anhang-I-Produkte

Für KI-Systeme, die Sicherheitskomponenten regulierter Produkte nach Anhang I sind, gelten besondere Regeln. Die Konformitätsbewertung erfolgt im Rahmen der jeweiligen sektoralen Gesetzgebung – der Medizinprodukte-Verordnung, der Maschinenverordnung, der Aufzugsrichtlinie oder der entsprechenden Produktvorschrift. Die KI-spezifischen Anforderungen der KI-Verordnung werden in diese bestehende Bewertung integriert, sodass eine einzige Konformitätsbewertung beide Regelwerke abdeckt.

In der Praxis bedeutet das: Die sektorale Benannte Stelle muss auch KI-Kompetenz vorweisen. Für Medizinproduktehersteller, die KI-basierte Diagnosesysteme entwickeln, wird die bestehende MDR-Benannte Stelle die KI-Anforderungen mitprüfen. Ob die bestehenden Benannten Stellen diese zusätzliche Kompetenz zum Stichtag flächendeckend aufgebaut haben, ist eine offene Frage. Für Hersteller regulierter Produkte ergibt sich daraus eine doppelte Herausforderung: Sie müssen nicht nur ihre eigene KI-Compliance aufbauen, sondern auch sicherstellen, dass ihre Benannte Stelle die KI-spezifischen Aspekte der Bewertung fachlich abdecken kann. Ein frühzeitiges Gespräch mit der bestehenden Benannten Stelle über den KI-Bewertungsumfang ist dringend empfohlen.

Vorbereitung: Fünf Schritte bis August 2026

Die Konformitätsbewertung kommt nicht am Ende – sie muss von Anfang an mitgedacht werden. Fünf Vorbereitungsschritte sind prioritär.

Der erste Schritt ist die Bestimmung des anwendbaren Verfahrens: Fällt das System unter Anhang III (eigenständig) oder Anhang I (eingebettetes Produkt)? Handelt es sich um biometrische Fernidentifikation? Die Antwort bestimmt, ob interne Kontrolle genügt oder eine Benannte Stelle erforderlich ist.

Der zweite Schritt ist die Gap-Analyse gegen die materiellen Anforderungen: Art. 9 (Risikomanagement), Art. 10 (Daten-Governance), Art. 11 (technische Dokumentation), Art. 12 (Logging/Protokollierung), Art. 13 (Transparenz), Art. 14 (menschliche Aufsicht), Art. 15 (Genauigkeit, Robustheit, Cybersicherheit) und Art. 17 (QMS). Jede Lücke muss vor der Bewertung geschlossen werden.

Der dritte Schritt ist die Aufbereitung der technischen Dokumentation nach Anhang IV – vollständig, aktuell und prüfbar. Die Dokumentation ist das zentrale Prüfobjekt, sowohl bei der internen Kontrolle als auch bei der Drittbewertung.

Der vierte Schritt ist ein internes Probeaudit: Die eigene Konformität mit dem Blick einer externen Prüfstelle bewerten, Schwachstellen identifizieren und vor der eigentlichen Bewertung beheben. Dieser Schritt ist bei interner Kontrolle die einzige Qualitätssicherung; bei Drittbewertung reduziert er das Risiko negativer Prüfergebnisse.

Der fünfte Schritt ist, bei Bedarf, die frühzeitige Kontaktaufnahme mit einer Benannten Stelle. Die Kapazitäten werden begrenzt sein, und Bewertungsverfahren dauern mehrere Monate. Wer erst im Sommer 2026 einen Termin sucht, wird Schwierigkeiten haben. Die Vorbereitung auf die Konformitätsbewertung beginnt nicht mit dem Bewertungsverfahren selbst, sondern mit der systematischen Erfüllung aller materiellen Anforderungen – sie ist das Ergebnis einer Compliance-Reise, nicht deren Startpunkt.

Fazit: Konformitätsbewertung als Ziellinie der Compliance-Reise

Die Konformitätsbewertung ist der Punkt, an dem alle vorherigen Compliance-Schritte zusammenlaufen: das Risikomanagementsystem nach Art. 9, die technische Dokumentation nach Art. 11, das QMS nach Art. 17 – sie alle werden hier geprüft. Drei Aspekte verdienen besondere Beachtung.

Erstens: Die Mehrzahl der Hochrisiko-KI-Systeme nach Anhang III kann die interne Kontrolle nutzen, aber „intern“ heißt nicht „einfach“. Der Anbieter trägt die volle Verantwortung für eine belastbare Selbstbewertung. Zweitens: Für Systeme mit Drittbewertungspflicht ist die Kapazität der Benannten Stellen der kritische Engpass, frühzeitige Planung ist keine Empfehlung, sondern Notwendigkeit. Drittens: Die Konformitätsbewertung ist kein einmaliger Vorgang. Wesentliche Änderungen am System erfordern eine erneute Bewertung. Der Konformitätsnachweis muss über den gesamten Lebenszyklus aufrechterhalten werden.

Wo sich Pflichten überschneiden, und wo nicht

Die häufigste Frage, die Datenschutzbeauftragte und Compliance-Verantwortliche zur KI-Verordnung stellen, lautet: Wie verhält sich der EU AI Act zur DSGVO? Die Antwort ist weder „ersetzt“ noch „ergänzt“, sie lautet: Beide Regelwerke gelten parallel, adressieren unterschiedliche Schutzgüter mit unterschiedlicher Regulierungslogik und erzeugen an spezifischen Stellen Überschneidungen, die Unternehmen integriert managen müssen. Dieser Beitrag kartiert die Schnittstellen, benennt die Trennlinien und zeigt, welche Governance-Strukturen für die parallele Compliance sinnvoll sind.

Der Artikel erklärt die Schnittstellen zwischen EU AI Act und DSGVO. Die DSGVO regelt den Umgang mit personenbezogenen Daten, der EU AI Act die Anforderungen an KI-Systeme. Beide Regelwerke gelten parallel und müssen integriert umgesetzt werden.

Zwei Regelwerke, zwei Schutzrichtungen

Die DSGVO schützt das Grundrecht auf Datenschutz (Art. 8 EU-Grundrechtecharta). Sie reguliert die Verarbeitung personenbezogener Daten, unabhängig davon, ob KI im Spiel ist oder nicht. Ihr Gegenstand ist der Umgang mit Daten natürlicher Personen.

Der EU AI Act schützt ein breiteres Spektrum: Gesundheit, Sicherheit und Grundrechte insgesamt. Er reguliert das Inverkehrbringen und den Betrieb von KI-Systemen, unabhängig davon, ob personenbezogene Daten verarbeitet werden. Sein Gegenstand ist das KI-System als technisches System sowie dessen Bereitstellung und Nutzung. Anders als die DSGVO reguliert der EU AI Act nicht primär die Verarbeitung personenbezogener Daten, sondern die Anforderungen an KI-Systeme und deren Einsatz.

Art. 2 Abs. 7 der KI-Verordnung stellt klar: „Diese Verordnung lässt die Verordnung (EU) 2016/679 […] unberührt.“ Die DSGVO gilt also uneingeschränkt weiter. Der AI Act tritt daneben, nicht an ihre Stelle. Erwägungsgrund 10 konkretisiert: Die KI-Verordnung ergänzt bestehendes EU-Recht und soll komplementär wirken, nicht verdrängen.

Für Unternehmen bedeutet das: Ein KI-System, das personenbezogene Daten verarbeitet, muss beide Regelwerke vollständig erfüllen. Compliance mit dem einen entbindet nicht vom anderen. Diese Parallelität ist kein Versehen, sondern gewollt: Der Gesetzgeber hat bewusst darauf verzichtet, Datenschutzanforderungen in den AI Act zu integrieren, und stattdessen auf die bewährte DSGVO-Infrastruktur verwiesen.

Wo sich Pflichten überschneiden

An fünf Stellen erzeugen beide Regelwerke Anforderungen, die denselben Sachverhalt aus unterschiedlicher Perspektive adressieren.

Transparenz. Die DSGVO verlangt nach Art. 13 und 14, dass Betroffene über die Verarbeitung ihrer Daten informiert werden, einschließlich der Logik automatisierter Entscheidungen (Art. 13 Abs. 2 lit. f DSGVO). Der AI Act verlangt nach Art. 13, dass Hochrisiko-KI-Systeme so gestaltet werden, dass ihr Betrieb hinreichend transparent ist, und nach Art. 50, dass bestimmte KI-Systeme ihre KI-Natur offenlegen. Die Perspektiven unterscheiden sich, Datenschutz-Transparenz richtet sich auf die Information betroffener Personen über die Verarbeitung ihrer Daten. Die Transparenzpflichten des AI Act richten sich auf die Eigenschaften, Funktionsweise und den Einsatz von KI-Systemen. Beide verfolgen unterschiedliche Schutzziele, können aber organisatorisch gemeinsam umgesetzt werden.

Automatisierte Entscheidungen. Art. 22 DSGVO gibt Betroffenen das Recht, nicht einer ausschließlich auf automatisierter Verarbeitung beruhenden Entscheidung unterworfen zu werden, die rechtliche Wirkung entfaltet. Der AI Act stellt an Hochrisiko-KI-Systeme umfassende Anforderungen an menschliche Aufsicht (Art. 14), Risikomanagement (Art. 9) und Erklärbarkeit. Beide Regime zielen auf den Schutz vor intransparenter maschineller Entscheidungsmacht, aber aus unterschiedlichen Richtungen: Die DSGVO gibt dem Individuum ein Abwehrrecht, der AI Act stellt Systemanforderungen an den Anbieter.

Folgenabschätzungen. Die DSGVO verlangt eine Datenschutz-Folgenabschätzung (DSFA) nach Art. 35 bei hohem Risiko für Rechte und Freiheiten natürlicher Personen. Der AI Act verlangt nach Art. 27 für bestimmte Betreiber bestimmter Hochrisiko-KI-Systeme eine Grundrechte-Folgenabschätzung (Fundamental Rights Impact Assessment, FRIA). Die Pflicht betrifft nicht sämtliche Hochrisiko-KI-Systeme, sondern insbesondere bestimmte Systeme nach Anhang III sowie deren Einsatz durch öffentliche Stellen oder Anbieter öffentlicher Dienstleistungen. Die DSFA fokussiert auf Datenschutzrisiken; die FRIA adressiert das gesamte Spektrum der Grundrechte, einschließlich Nichtdiskriminierung, Menschenwürde, Meinungsfreiheit und Arbeitnehmerrechte. Für KI-Systeme, die personenbezogene Daten verarbeiten und zugleich unter die FRIA-Pflichten des Art. 27 fallen, werden häufig sowohl eine Datenschutz-Folgenabschätzung (DSFA) als auch eine Grundrechte-Folgenabschätzung erforderlich sein. Art. 27 Abs. 4 ermöglicht ausdrücklich, die FRIA mit der DSFA nach Art. 35 DSGVO zu kombinieren, eine pragmatische Regelung, die Doppelarbeit vermeidet.

Datenqualität und Daten-Governance. Art. 10 des AI Act stellt Anforderungen an die Qualität, Repräsentativität und Governance der Trainings-, Validierungs- und Testdaten. Art. 5 Abs. 1 lit. d DSGVO verlangt Datenrichtigkeit. Beide adressieren Datenqualität, aber in unterschiedlichem Kontext: Die DSGVO schützt die Genauigkeit personenbezogener Daten im Interesse der Betroffenen; der AI Act fordert Datenqualität im Interesse der Systemleistung und der Vermeidung diskriminierender Ergebnisse.

Verarbeitung besonderer Datenkategorien. Art. 10 Abs. 5 des AI Act enthält eine bemerkenswerte Ausnahme: Er erlaubt die Verarbeitung besonderer Kategorien personenbezogener Daten (Art. 9 DSGVO) zum Zweck der Erkennung und Korrektur von Verzerrungen in Hochrisiko-KI-Systemen. Die Bedingungen sind eng gefasst: Die Verarbeitung muss strikt erforderlich sein, angemessene Schutzmaßnahmen für die Grundrechte und Grundfreiheiten natürlicher Personen müssen bestehen, die Daten müssen in einer gesicherten Verarbeitungsumgebung verbleiben, und sie dürfen nicht an Dritte übermittelt oder für andere Zwecke verwendet werden. Diese Regelung adressiert ein praktisches Dilemma: Ohne Zugang zu Daten über Geschlecht, Ethnie oder Behinderung kann ein Anbieter nicht prüfen, ob sein System bestimmte Gruppen systematisch benachteiligt, aber genau diese Daten genießen unter der DSGVO den höchsten Schutz. Die Ausnahme ist eng auszulegen: Die Verarbeitung besonderer Kategorien personenbezogener Daten ist nur zulässig, soweit sie für die Erkennung und Korrektur von Verzerrungen erforderlich ist und die gesetzlichen Schutzvorkehrungen eingehalten werden. Sie schafft keine allgemeine Rechtsgrundlage für den Einsatz solcher Daten im Entwicklungs- oder Trainingsprozess.

Wo sie sich nicht überschneiden

Drei fundamentale Unterschiede trennen beide Regelwerke.

Regulierungsgegenstand. Die DSGVO reguliert Datenverarbeitung, jede Verarbeitung personenbezogener Daten, ob durch KI oder Tabellenkalkulationen. Der AI Act reguliert ein Produkt, das KI-System als technisches Artefakt, unabhängig davon, ob es personenbezogene Daten verarbeitet. Ein KI-System zur Qualitätskontrolle in der industriellen Fertigung, das keine personenbezogenen Daten verarbeitet, fällt unter den AI Act, aber nicht unter die DSGVO. Umgekehrt fällt eine manuelle Verarbeitung sensibler Gesundheitsdaten unter die DSGVO, aber nicht unter den AI Act.

Regulierungslogik. Die DSGVO folgt einer Verarbeitungslogik: Jede einzelne Verarbeitung braucht eine Rechtsgrundlage, einen Zweck und muss verhältnismäßig sein. Der AI Act folgt einer Produktsicherheitslogik: Das System als Ganzes wird gegen Anforderungen geprüft, bevor es auf den Markt kommt. Die DSGVO ist prozessorientiert, der AI Act ist produktbezogen.

Durchsetzung. Die DSGVO wird von Datenschutzaufsichtsbehörden durchgesetzt, in Deutschland der BfDI auf Bundesebene und die Landesdatenschutzbeauftragten. Der AI Act wird von Marktüberwachungsbehörden durchgesetzt. In Deutschland sieht der Entwurf des KI-Marktüberwachungsgesetzes (KI-MIG) vor, der Bundesnetzagentur eine zentrale Koordinierungsrolle zuzuweisen, ergänzt um sektorale Zuständigkeiten etwa der BaFin für Finanzdienstleistungen oder des BfArM für Medizinprodukte.. Die Zuständigkeitsabgrenzung zwischen Datenschutzaufsicht und KI-Marktüberwachung ist eine der offenen Governance-Fragen, die das KI-MIG noch konkretisieren muss. In der Praxis werden Fälle auftreten, in denen beide Behörden zuständig sind, etwa wenn ein Hochrisiko-KI-System gleichzeitig gegen Datenschutzanforderungen und gegen Transparenzpflichten des AI Act verstößt. Kooperationsmechanismen zwischen den Aufsichtsstrukturen werden entscheidend sein, um widersprüchliche Aufsichtsentscheidungen zu vermeiden.

Governance-Integration in der Praxis

Die parallele Geltung beider Regelwerke wirft für Unternehmen die Frage auf, ob Datenschutz-Governance und KI-Governance getrennt oder integriert organisiert werden sollten.

Die Argumente für Integration sind stark: Viele Prüfschritte überlappen (Folgenabschätzungen, Transparenz-Dokumentation, Datenqualitätssicherung). Die verantwortlichen Personen arbeiten mit denselben Systemen. Getrennte Governance erzeugt Redundanz, widersprüchliche Bewertungen und Abstimmungsaufwand.

Die Argumente für Differenzierung sind ebenfalls berechtigt: Die Kompetenzprofile unterscheiden sich (Datenschutzrecht vs. Produktsicherheitsrecht vs. KI-Technik). Die Aufsichtsbehörden sind verschieden. Die Zeitzyklen differieren, DSGVO-Compliance ist kontinuierlich, AI-Act-Compliance hat einen starken Fokus auf den Marktzugang.

Der pragmatische Ansatz: Eine integrierte Governance-Struktur mit differenzierten Fachverantwortungen. Der Datenschutzbeauftragte bleibt für DSGVO-Compliance zuständig, ein KI-Governance-Verantwortlicher für AI-Act-Compliance, aber beide arbeiten in einer gemeinsamen Governance-Struktur mit abgestimmten Prozessen, gemeinsamen Registern und koordinierten Folgenabschätzungen. Für Hochrisiko-KI-Systeme, die personenbezogene Daten verarbeiten, sollte eine kombinierte DSFA/FRIA Standard sein, nicht die Ausnahme.

Ein konkretes Integrationsmodell umfasst drei Ebenen: Auf der strategischen Ebene ein gemeinsames KI- und Daten-Governance-Board, das Grundsatzentscheidungen über den Einsatz von KI-Systemen trifft und Risikotoleranzgrenzen definiert. Auf der operativen Ebene ein gemeinsames Register aller KI-Systeme, das sowohl die AI-Act-Klassifizierung als auch die datenschutzrechtliche Bewertung enthält, das KI-Inventar und das Verarbeitungsverzeichnis nach Art. 30 DSGVO können in ein integriertes Register überführt werden. Auf der Prüfebene kombinierte Folgenabschätzungen, die Datenschutzrisiken und Grundrechtsrisiken in einem Prozess adressieren, sowie koordinierte Audit-Zyklen, die beide Regelwerke abdecken.

Unternehmen, die bereits über ein reifes Datenschutz-Managementsystem verfügen, haben einen strukturellen Vorteil: Prozesse für Verarbeitungsverzeichnisse, Folgenabschätzungen und Betroffenenrechte lassen sich auf AI-Act-Anforderungen erweitern. Wer bei null anfängt, sollte von vornherein integriert planen, statt zwei parallele Systeme aufzubauen.

Bußgeldrahmen im Vergleich

Beide Regelwerke sehen erhebliche Bußgelder vor, die sich im Einzelfall kumulieren können.

Die DSGVO sieht nach Art. 83 Bußgelder bis 20 Millionen Euro oder 4 Prozent des weltweiten Jahresumsatzes vor, je nachdem, welcher Betrag höher ist. Der AI Act sieht nach Art. 99 gestaffelte Bußgelder vor: bis zu 35 Millionen Euro oder 7 Prozent des Umsatzes für verbotene KI-Praktiken, bis zu 15 Millionen Euro oder 3 Prozent für Verstöße gegen Hochrisiko-Anforderungen, bis zu 7,5 Millionen Euro oder 1 Prozent für falsche Angaben gegenüber Behörden.

Ein KI-System, das sowohl gegen DSGVO-Pflichten als auch gegen AI-Act-Anforderungen verstößt, kann theoretisch nach beiden Regelwerken sanktioniert werden. Die Verordnung enthält Proportionalitätsregelungen: Für KMU und Start-ups gilt jeweils der niedrigere der beiden Beträge (fester Betrag oder Umsatzanteil). Eine vollständige Doppelbestrafung für denselben Sachverhalt wäre zudem durch den allgemeinen Grundsatz des ne bis in idem begrenzt, aber wenn verschiedene Verstöße gegen verschiedene Regelwerke vorliegen, können sich die Bußgelder durchaus kumulieren. Ein Beispiel: Wenn ein Hochrisiko-KI-System zur Personalauswahl gleichzeitig gegen die Transparenzpflichten des AI Act (Art. 13) und gegen die Informationspflichten der DSGVO (Art. 13/14) verstößt und zusätzlich Datenqualitätsmängel sowohl nach Art. 10 AI Act als auch nach Art. 5 Abs. 1 lit. d DSGVO aufweist, können die Aufsichtsbehörden jeweils unterschiedliche Verstöße sanktionieren, die Kappung greift nur bei identischem Sachverhalt.

Fazit: Komplementarität als Gestaltungsprinzip

EU AI Act und DSGVO sind keine Konkurrenten, sondern komplementäre Instrumente mit unterschiedlichen Schutzrichtungen. Für Unternehmen, die KI-Systeme mit personenbezogenen Daten entwickeln oder betreiben, bedeutet das: Beide Regelwerke müssen gleichzeitig erfüllt werden, aber die Erfüllung kann integriert organisiert werden.

Drei Handlungsempfehlungen ergeben sich. Erstens: Folgenabschätzungen kombinieren, Art. 27 Abs. 4 erlaubt dies ausdrücklich und reduziert den Gesamtaufwand erheblich. Zweitens: Governance integrieren, aber Fachverantwortungen differenzieren, der Datenschutzbeauftragte ist kein KI-Auditor und der KI-Governance-Verantwortliche kein Datenschutzexperte, aber beide müssen koordiniert arbeiten. Drittens: Die Sonderregelung des Art. 10 Abs. 5 kennen und nutzen, die Verarbeitung besonderer Kategorien zur Bias-Erkennung ist unter strengen Bedingungen zulässig und für faire KI-Systeme oft unerlässlich. Wer die Schnittstellen zwischen beiden Regelwerken frühzeitig identifiziert und integriert adressiert, reduziert nicht nur den Compliance-Aufwand, sondern baut eine Governance-Struktur, die auch kommenden regulatorischen Anforderungen standhält.

Was Art. 11 und Anhang IV verlangen

Die technische Dokumentation ist der Nachweis, dass ein Hochrisiko-KI-System die Anforderungen der KI-Verordnung erfüllt. Art. 11 verpflichtet Anbieter, diese Dokumentation vor dem Inverkehrbringen zu erstellen und über den gesamten Lebenszyklus aktuell zu halten. Anhang IV definiert, was sie enthalten muss, von der Systembeschreibung über das Risikomanagement bis zum Post-Market-Monitoring-Plan. Dieser Beitrag analysiert die Anforderungen im Detail, ordnet die Dokumentation in das Gesamtsystem der Verordnung ein und zeigt, welche praktischen Herausforderungen Unternehmen bei der Umsetzung erwarten.

Der Artikel definiert die Technische Dokumentation Hochrisiko-KI als verpflichtenden Nachweis nach Art. 11 EU AI Act, der vor dem Inverkehrbringen erstellt und während des gesamten Lebenszyklus aktualisiert werden muss. Er erläutert die neun Dokumentationsbereiche aus Anhang IV, darunter Risikomanagement, Testing, Daten-Governance und Post-Market-Monitoring.

Art. 11: Struktur und Kernpflichten

Art. 11 umfasst drei Absätze, die den Rahmen für die technische Dokumentation setzen.

Absatz 1 begründet die zentrale Pflicht: Die technischen Unterlagen für ein Hochrisiko‑KI‑System müssen vor dem Inverkehrbringen oder der Inbetriebnahme erstellt und auf dem neuesten Stand gehalten werden; sie müssen den Nachweis ermöglichen, dass das System die Anforderungen des Kapitels III Abschnitt 2 erfüllt, und die in Anhang IV genannten Elemente mindestens enthalten. Gleichzeitig enthält Absatz 1 eine Erleichterung für kleine und mittlere Unternehmen: KMU einschließlich Start‑ups dürfen die in Anhang IV geforderten Elemente in vereinfachter Form bereitstellen; zu diesem Zweck stellt die Kommission ein vereinfachtes Formular für die technische Dokumentation bereit, das auf die Bedürfnisse kleiner und Kleinstunternehmen zugeschnitten ist und von den notifizierten Stellen für die Konformitätsbewertung akzeptiert wird.

Absatz 2 adressiert Hochrisiko-KI-Systeme, die Bestandteil eines Produkts sind, das unter eine der in Anhang I aufgeführten Harmonisierungsrechtsvorschriften fällt. In diesen Fällen wird eine einzige technische Dokumentation erstellt, die sowohl die Anforderungen der KI-Verordnung als auch die des jeweiligen sektoralen Rechtsrahmens abdeckt. Damit vermeidet die Verordnung parallele Dokumentationspflichten für KI-Systeme in regulierten Produkten wie Medizinprodukten, Maschinen oder Aufzügen.

Absatz 3 ermächtigt die Kommission, mittels delegierter Rechtsakte Anhang IV zu ändern – eine Flexibilitätsklausel, die eine Anpassung der Dokumentationsanforderungen an den technologischen Fortschritt ohne vollständiges Gesetzgebungsverfahren ermöglicht. Für Unternehmen bedeutet das: Die Dokumentationsanforderungen können sich im Laufe der Zeit weiterentwickeln, auch ohne legislative Änderung der Verordnung selbst.

Anhang IV: Die neun Dokumentationsbereiche

Anhang IV definiert den konkreten Inhalt der technischen Dokumentation in neun Bereichen. Zusammen bilden sie ein vollständiges Bild des Systems – von der Konzeption über die Entwicklung bis zum geplanten Betriebsmonitoring.

Der erste Bereich – allgemeine Beschreibung – verlangt die Angabe des Anbieters, der Systemversion, der Zweckbestimmung, der Interaktionen mit Hardware und Software sowie der vorgesehenen Einsatzumgebung. Diese Beschreibung definiert den Rahmen, innerhalb dessen alle weiteren Anforderungen bewertet werden. Eine unpräzise Zweckbestimmung an dieser Stelle führt unweigerlich zu Unschärfen in Risikoanalyse und Testing.

Der zweite Bereich – Entwicklung und Design – umfasst die Beschreibung der Entwicklungsmethoden, der Designentscheidungen, der verwendeten vortrainierten Systeme und Drittanbieter-Werkzeuge. Für Systeme, die auf Foundation Models aufbauen, ist hier die Abgrenzung zwischen eigenem Beitrag und zugekaufter Komponente relevant: Welche Teile des Systems hat der Anbieter selbst entwickelt, welche übernommen, und wie wurde deren Eignung für die spezifische Zweckbestimmung validiert?

Der dritte Bereich – Überwachung, Funktionsweise und Kontrolle – beschreibt die Leistungsfähigkeit des Systems, den Grad seiner Genauigkeit, bekannte Einschränkungen und vorhersehbare Risiken. Hier wird sichtbar, was das System kann und was nicht – eine Information, die für Betreiber nach Art. 26 ebenso relevant ist wie für Aufsichtsbehörden.

Der vierte Bereich betrifft die Leistungsmetriken und deren Angemessenheit. Es genügt nicht, Metriken zu nennen – die Dokumentation muss begründen, warum die gewählten Metriken für die spezifische Zweckbestimmung geeignet sind. Ein biometrisches Identifikationssystem erfordert andere Metriken als ein System zur Kreditwürdigkeitsprüfung.

Der fünfte Bereich verlangt die detaillierte Beschreibung des Risikomanagementsystems nach Art. 9. Die Risikoanalyse, die identifizierten Risiken, die ergriffenen Maßnahmen und die Restrisikobewertung müssen dokumentiert sein. Die technische Dokumentation ist damit der Ort, an dem die Ergebnisse des Risikomanagements in prüfbarer Form vorliegen.

Der sechste Bereich – Validierung und Testing – umfasst die Testverfahren, die verwendeten Datensätze, die Testergebnisse und die Genauigkeits- und Robustheitsmetriken. Testprotokolle müssen nachvollziehbar sein: Welche Tests wurden durchgeführt, unter welchen Bedingungen, mit welchen Ergebnissen? Dieser Bereich bildet die Brücke zu Art. 9 Abs. 6 bis 8, der das Testing als integralen Bestandteil des Risikomanagements verankert.

Der siebte Bereich dokumentiert die angewendeten Normen – harmonisierte Normen, soweit vorhanden, oder die Lösungen, die der Anbieter stattdessen gewählt hat, um die Anforderungen zu erfüllen. In der aktuellen Normenlücke (vgl. den Beitrag zu harmonisierten Normen, KW19-B) ist hier besonders sorgfältig darzulegen, auf welcher Grundlage Konformität beansprucht wird.

Der achte Bereich betrifft die EU-Konformitätserklärung nach Art. 47. Sie ist das formale Dokument, mit dem der Anbieter erklärt, dass das System alle anwendbaren Anforderungen erfüllt. Sie verweist auf die technische Dokumentation als Nachweisgrundlage.

Der neunte Bereich verlangt die Beschreibung des Post-Market-Monitoring-Systems nach Art. 72 – wie der Anbieter plant, das System nach der Inverkehrbringung zu überwachen, welche Daten systematisch erhoben werden, welche Schwellenwerte eine Neubewertung auslösen und welche Maßnahmen bei erkannten Abweichungen vorgesehen sind. Dieser Bereich schließt den Kreis zum Risikomanagement: Das Monitoring-Konzept muss kohärent mit der Risikoanalyse aus Bereich 5 sein.

Dokumentation als lebender Prozess

Die Formulierung „auf dem neuesten Stand zu halten“ in Art. 11 Abs. 1 transformiert die technische Dokumentation von einem statischen Compliance-Artefakt zu einem lebenden Prozess. Jede wesentliche Änderung am System – sei es ein Modellupdate, eine Änderung der Trainingsdaten, eine Anpassung der Schwellenwerte oder eine Erweiterung der Zweckbestimmung – muss sich in der Dokumentation widerspiegeln.

In der Praxis erfordert das einen dokumentationsintegrierten Entwicklungsprozess: Änderungen am System und Änderungen an der Dokumentation müssen synchron laufen. Unternehmen, die Dokumentation als nachgelagerte Aufgabe behandeln – „erst entwickeln, dann dokumentieren“ – werden zwangsläufig Dokumentationslücken produzieren, die bei einer Konformitätsbewertung oder Marktüberwachung auffallen. Erfahrungen aus der Medizinprodukte-Regulierung zeigen, dass nachgelagerte Dokumentation typischerweise drei- bis fünfmal teurer ist als entwicklungsbegleitende: Entscheidungsgründe sind nicht mehr rekonstruierbar, Testbedingungen müssen erneut hergestellt werden, und die beteiligten Personen sind möglicherweise nicht mehr verfügbar.

Die Aufbewahrungsfrist beträgt nach Art. 18 zehn Jahre nach dem Inverkehrbringen oder der Inbetriebnahme. Für Systeme mit langer Betriebsdauer bedeutet das: Die Dokumentation muss über einen Zeitraum archiviert und abrufbar gehalten werden, der die übliche Lebenszeit vieler IT-Systeme übersteigt. Versionierung, Zugänglichkeit und Lesbarkeit über diesen Zeitraum hinweg sind keine trivialen Anforderungen.

Einordnung im Gesamtsystem der Verordnung

Die technische Dokumentation steht nicht isoliert. Sie ist der Knotenpunkt, an dem die verschiedenen Anforderungen der Verordnung materiell zusammenlaufen.

Art. 9 (Risikomanagement) liefert die Inhalte für Anhang IV Bereich 5 – die Risikoanalyse, die Bewertung und die Maßnahmen. Ohne funktionierendes Risikomanagementsystem fehlt der Dokumentation ihr analytischer Kern.

Art. 10 (Daten-Governance) spiegelt sich in der Beschreibung der Trainings-, Validierungs- und Testdaten. Anhang IV verlangt die Angabe der Datencharakteristiken, der Herkunft, des Umfangs und der Eignung der verwendeten Datensätze. Datenlücken oder Qualitätsmängel, die hier nicht dokumentiert sind, werden bei einer Prüfung als Versäumnis gewertet.

Art. 12 (Aufzeichnungspflichten) ergänzt die technische Dokumentation um automatische Protokollierung: Hochrisiko-KI-Systeme müssen Logdateien erzeugen, die den Betrieb nachvollziehbar machen. Diese Logs sind Teil des Gesamtdokumentationssystems, auch wenn sie operativ und nicht einmalig erstellt werden.

Art. 17 (Qualitätsmanagementsystem) bildet den organisatorischen Rahmen: Das QMS definiert die Prozesse, nach denen Dokumentation erstellt, geprüft, freigegeben und aktualisiert wird. Ein QMS ohne Dokumentationsprozess ist unvollständig; eine Dokumentation ohne QMS-Einbettung ist nicht nachhaltig pflegbar.

Art. 43 (Konformitätsbewertung) definiert den Prüfkontext: Benannte Stellen erhalten vollständigen Zugang zur technischen Dokumentation und zu den Trainings-, Validierungs- und Testdatensätzen. Sie können zusätzliche Tests anfordern und Zugang zu den Entwicklungsräumlichkeiten verlangen. Die Dokumentation muss also nicht nur vollständig, sondern auch verständlich und prüfbar aufbereitet sein – eine Anforderung, die über reine Existenz hinausgeht und die Qualität der Darstellung betrifft.

Art. 26 (Pflichten der Betreiber) schafft eine zusätzliche Perspektive: Betreiber müssen die vom Anbieter bereitgestellten Gebrauchsanweisungen einhalten und das System entsprechend überwachen. Die technische Dokumentation ist damit auch die Grundlage für die Betreiberanweisungen – was dort nicht beschrieben ist, kann vom Betreiber nicht umgesetzt werden.

Praktische Herausforderungen

Vier Herausforderungen begegnen Unternehmen regelmäßig bei der Umsetzung der Dokumentationspflichten.

Die erste ist die Traceability: die durchgängige Nachvollziehbarkeit von der Anforderung über die Designentscheidung bis zur Implementierung und zum Test. Klassische Softwareentwicklung dokumentiert oft nur den Endzustand, nicht den Entscheidungspfad. Die Verordnung verlangt aber beides – was gewählt wurde und warum.

Die zweite ist die Versionskonsistenz: Wenn ein Modell in Version 3.2 dokumentiert ist, aber in Version 3.4 betrieben wird, besteht eine Compliance-Lücke. Automatisierte Versionskontrolle der Dokumentation – idealerweise gekoppelt an die Modell- und Code-Versionierung – ist kein Nice-to-have, sondern operative Notwendigkeit.

Die dritte ist die Abgrenzung bei zusammengesetzten Systemen: Wenn ein Hochrisiko-System ein vortrainiertes Foundation Model nutzt, welche Teile der Dokumentation liegen in der Verantwortung des Anbieters und welche beim Upstream-Provider des Basismodells? Art. 53 verpflichtet GPAI-Anbieter, hinreichende technische Dokumentation und Information bereitzustellen, damit nachgelagerte Anbieter ihre eigenen Pflichten erfüllen können. In der Praxis bleibt die Informationsasymmetrie dennoch eine Herausforderung.

Die vierte ist die Ressourcenintensität. Die Erstellung einer vollständigen technischen Dokumentation nach Anhang IV erfordert Expertise aus Entwicklung, Datenwissenschaft, Risikomanagement und Regulatorik. Für KMU kann der Aufwand erheblich sein, auch wenn die vereinfachte Form nach Art. 11 Abs. 1 eine Erleichterung bietet. Entscheidend ist, dass „vereinfacht“ nicht „unvollständig“ bedeutet: Alle Anhang-IV-Bereiche müssen adressiert werden, die Darstellungstiefe darf aber angemessen reduziert werden. Bis die Kommission das vereinfachte Formular veröffentlicht, fehlt KMU allerdings eine konkrete Orientierung, welches Maß an Vereinfachung als ausreichend gilt, ein weiterer Aspekt der regulatorischen Übergangsunsicherheit bis zum Stichtag.

Fazit: Dokumentation als Compliance-Infrastruktur

Die technische Dokumentation nach Art. 11 und Anhang IV ist kein bürokratischer Anhang, sondern die zentrale Compliance-Infrastruktur für Hochrisiko-KI. Sie macht die Einhaltung der Anforderungen prüfbar, archivierbar und nachvollziehbar. Drei Punkte verdienen besondere Beachtung.

Erstens: Die Dokumentation muss vor dem Inverkehrbringen stehen – nicht als Nachdokumentation, sondern als integraler Bestandteil des Entwicklungsprozesses. Zweitens: Sie ist ein lebender Prozess mit zehnjähriger Aufbewahrungspflicht – Versionierung und Aktualität sind keine optionalen Qualitätsmerkmale, sondern regulatorische Anforderungen. Drittens: Die Konformitätsbewertung prüft die Dokumentation als Erstes – sie ist das Fenster, durch das Benannte Stellen und Aufsichtsbehörden auf das System blicken. Was dort nicht steht, existiert für die Aufsicht nicht.

Was Art. 9 des EU AI Act konkret verlangt

Art. 9 bildet einen zentralen operativen Baustein der Hochrisiko-Anforderungen. Er definiert, wie Anbieter Risiken ihrer KI-Systeme systematisch identifizieren, bewerten und steuern müssen, als kontinuierlicher Prozess über den gesamten Lebenszyklus. Dieser Beitrag analysiert die zehn Absätze des Artikels, zeigt die Verbindungen zu Art. 10 und Art. 15 auf und ordnet ein, welche Methoden und Werkzeuge sich für die operative Umsetzung eignen.

Der Artikel definiert Art. 9 des EU AI Act als Pflicht zum kontinuierlichen Risikomanagement für Hochrisiko-KI über den gesamten Lebenszyklus hinweg. Er erläutert, wie Anbieter Risiken identifizieren, bewerten, mitigieren und mit vorab definierten Metriken sowie Schwellenwerten dokumentieren müssen.

Art. 9: Zehn Absätze, ein System

Art. 9 umfasst zehn Absätze, die zusammen das Risikomanagementsystem für Hochrisiko-KI definieren. Die Struktur folgt einer klaren Logik: vom Grundprinzip über die operative Methodik bis zu spezifischen Anforderungen an Testing und Schutzbedürftige.

Absatz 1 etabliert das Grundprinzip: Das Risikomanagementsystem ist ein kontinuierlicher iterativer Prozess, der während des gesamten Lebenszyklus des KI-Systems angewendet und regelmäßig systematisch überprüft und aktualisiert wird. Es ist kein statisches Dokument, sondern ein lebender Prozess.

Absatz 2 definiert den operativen Kern in vier Schritten: die Ermittlung und Analyse bekannter und vorhersehbarer Risiken für Gesundheit, Sicherheit und Grundrechte; die Abschätzung und Bewertung dieser Risiken bei bestimmungsgemäßer Verwendung und vernünftigerweise vorhersehbarer Fehlanwendung; die Bewertung weiterer Risiken auf Grundlage der Post-Market-Monitoring-Daten nach Art. 72; und die Ergreifung gezielter Risikomanagementmaßnahmen.

Absatz 3 begrenzt den Anwendungsbereich: Nur solche Risiken sind relevant, die durch Maßnahmen in Design, Entwicklung oder durch technische Information vernünftigerweise gemindert oder beseitigt werden können.

Absatz 4 fordert die Berücksichtigung von Wechselwirkungen mit anderen Anforderungen der Verordnung, insbesondere mit Art. 10 (Daten-Governance) und Art. 15 (Genauigkeit, Robustheit, Cybersicherheit).

Absatz 5 verlangt, dass jedes verbleibende Restrisiko und das Gesamtrestrisiko des Systems als vertretbar beurteilt werden. In der Praxis empfiehlt sich die Dokumentation nachvollziehbarer Akzeptanzkriterien für verbleibende Restrisiken. Vertretbarkeit ist dabei kein Nullrisiko-Standard, sondern eine kontextbezogene Abwägung zwischen dem Nutzen des Systems und den verbleibenden Risiken – unter Berücksichtigung des Stands der Technik und der Erwartungen der betroffenen Personen.

Absatz 6 schreibt vor, dass das Hochrisiko-KI-System getestet werden muss, um die geeignetsten Risikomanagementmaßnahmen zu ermitteln und die Funktionsfähigkeit des Systems sicherzustellen.

Absatz 7 erlaubt, dass Testing auch Tests unter Realbedingungen nach Art. 60 umfassen kann.

Absatz 8 stellt die Anforderung an das Testing: Es erfolgt zu jedem geeigneten Zeitpunkt während des Entwicklungsprozesses und vor dem Inverkehrbringen, anhand vorab festgelegter Metriken und probabilistischer Schwellenwerte, die zur Zweckbestimmung des Systems passen.

Absatz 9 verlangt die besondere Berücksichtigung schutzbedürftiger Gruppen – insbesondere Personen unter 18 Jahren und Menschen mit Behinderungen – hinsichtlich möglicher nachteiliger Auswirkungen.

Absatz 10 adressiert Anbieter, die bereits Risikomanagementpflichten aus anderen einschlägigen EU-Rechtsvorschriften unterliegen. In diesen Fällen können die Anforderungen aus den Absätzen 1 bis 9 Teil der bestehenden Risikomanagementverfahren sein oder mit diesen kombiniert werden – eine Regelung, die Doppelstrukturen vermeidet und die Integration in bestehende sektorale Compliance-Systeme ermöglicht.

Der Vier-Schritte-Ansatz im Detail

Der operative Kern des Risikomanagements nach Art. 9 Abs. 2 lässt sich in vier Handlungsschritte übersetzen, die iterativ durchlaufen werden.

Der erste Schritt – Identifikation und Analyse – verlangt eine systematische Erfassung aller bekannten und vorhersehbaren Risiken. Dabei sind nicht nur die beabsichtigte Nutzung, sondern auch die vernünftigerweise vorhersehbare Fehlanwendung zu berücksichtigen. In der Praxis bedeutet das: Szenarien durchspielen, in denen das System unter ungünstigen Bedingungen, mit unerwarteten Eingabedaten oder durch nicht geschulte Nutzer eingesetzt wird. Die Verordnung verwendet bewusst den Maßstab der „vernünftigen Vorhersehbarkeit“ – nicht jede denkbare Fehlanwendung muss adressiert werden, wohl aber solche, die ein informierter Beobachter als plausibel einstufen würde. Für ein KI-gestütztes Bewerbermanagement bedeutet das beispielsweise: nicht nur den Fall, dass ein qualifizierter Kandidat abgelehnt wird, sondern auch den Fall, dass das System bei bestimmten Namensmuster oder Bildungswegen systematisch benachteiligt.

Der zweite Schritt – Bewertung – verlangt eine Einschätzung von Eintrittswahrscheinlichkeit und Schwere der identifizierten Risiken. Die Schwere ist dabei nicht nur technisch, sondern auch grundrechtlich zu bewerten: Welche Auswirkungen hat ein Fehler auf die Rechte und Freiheiten betroffener Personen? Aus den Erwägungsgründen und dem risikobasierten Ansatz des AI Act lässt sich ableiten, dass bei der Risikobewertung unter anderem die Reversibilität des Schadens, die Anzahl potenziell betroffener Personen und die besondere Verletzlichkeit bestimmter Gruppen zu berücksichtigen sind. Ein System, das über den Zugang zu öffentlichen Leistungen entscheidet, trägt eine andere Risikoschwere als eines, das Produktempfehlungen generiert, selbst wenn die technische Fehlerrate identisch wäre.

Der dritte Schritt – Risikobewertung auf Basis von Post-Market-Daten – schließt die Rückkopplung aus dem Betrieb ein. Daten aus dem Post-Market-Monitoring nach Art. 72 fließen in die Neubewertung bestehender Risiken ein und können zur Identifikation neuer Risiken führen, die in der Entwicklungsphase nicht erkennbar waren.

Der vierte Schritt – Maßnahmen – kennt drei Hierarchiestufen: Risikominderung durch Design und Entwicklung hat Vorrang; wo dies nicht ausreicht, kommen technische Minderungs- und Kontrollmaßnahmen zum Einsatz; und als dritte Stufe die Information und Schulung der Betreiber über verbleibende Risiken und die korrekte Nutzung des Systems. Diese Hierarchie folgt dem bewährten Prinzip aus dem Arbeitsschutz: Vermeidung vor technischer Absicherung vor organisatorischer Maßnahme.

Risikomanagement über den KI-Lebenszyklus

Der Lebenszyklusansatz nach Art. 9 Abs. 1 bedeutet, dass Risikomanagement keine Phase ist, die irgendwann abgeschlossen wird. Stattdessen begleitet es das System von der Konzeption bis zur Außerbetriebnahme. Verschiedene Phasen bringen unterschiedliche Risikoprofile mit sich.

In der Design- und Spezifikationsphase liegen die Risiken in unzureichenden Anforderungsdefinitionen, unpräzisen Zielmetriken und der fehlenden Berücksichtigung schutzbedürftiger Gruppen. In der Datenerhebung und -aufbereitung (Art. 10) entstehen Risiken durch Verzerrungen in Trainingsdaten, unzureichende Repräsentation relevanter Populationen und mangelnde Datenqualität. In der Trainings- und Validierungsphase sind Overfitting, Feedback-Schleifen und unzureichende Robustheit gegenüber adversariellen Eingaben typische Risikoquellen. In der Testing-Phase vor Inverkehrbringen (Art. 9 Abs. 6-8) geht es um die Validierung gegen vorab festgelegte Metriken und Schwellenwerte. Im Betrieb entstehen Risiken durch Datendrift, unvorhergesehene Nutzungsszenarien und Cybersicherheitsbedrohungen nach Art. 15. Im Post-Market-Monitoring (Art. 72) werden diese Betriebsrisiken systematisch erfasst und in das Risikomanagementsystem zurückgespeist.

Schnittstellen zu Art. 10 und Art. 15

Art. 9 steht nicht isoliert. Abs. 4 verlangt ausdrücklich die Berücksichtigung von Wechselwirkungen mit anderen Verordnungsanforderungen.

Art. 10 (Daten-Governance) definiert Anforderungen an die Qualität, Repräsentativität und Governance der Trainings-, Validierungs- und Testdaten. Im Risikomanagementsystem müssen Datenrisiken adressiert werden: systematische Verzerrungen, fehlende Repräsentation geschützter Gruppen, Qualitätsmängel in den Quelldaten und Risiken durch die Verknüpfung verschiedener Datensätze. Ein Risikoregister ohne Datenrisiken ist unvollständig.

Art. 15 verlangt, dass Hochrisiko-KI-Systeme ein angemessenes Maß an Genauigkeit, Robustheit und Cybersicherheit erreichen. Diese Anforderungen fließen direkt in die Schwellenwertdefinition nach Art. 9 Abs. 8 ein: Die vorab festzulegenden Metriken für Genauigkeit (Typische technische Leistungsmetriken können beispielsweise sein: Precision, Recall, F1-Score) und die probabilistischen Schwellenwerte müssen kontextangemessen sein. Ein System zur Kreditwürdigkeitsprüfung hat andere Genauigkeitsanforderungen als ein System zur Prüfungsüberwachung. Robustheit gegen Drift, gegen Feedback-Schleifen und gegen adversarielle Angriffe muss getestet und dokumentiert sein. Cybersicherheitsmaßnahmen müssen unbefugte Manipulation von Eingaben und Ausgaben verhindern.

Metriken und Schwellenwerte: Art. 9 Abs. 8 in der Praxis

Art. 9 Abs. 8 verlangt vorab festgelegte Metriken und probabilistische Schwellenwerte, die zur Zweckbestimmung des Systems passen. In der Praxis stellt diese Anforderung Unternehmen vor die Frage: Welche Metriken sind die richtigen, und wo liegt die Akzeptanzschwelle?

Die Antwort hängt von der Zweckbestimmung und dem Einsatzkontext ab. Für ein HR-Auswahlsystem sind Fairness-Metriken über geschützte Gruppen hinweg zentral. Für ein Medizinprodukt sind Sensitivität und Spezifität entscheidend. Für ein System zur Kreditentscheidung sind False-Positive- und False-Negative-Raten mit ihren jeweiligen Auswirkungen auf Betroffene relevant.

Die Verordnung gibt keine konkreten Zahlenwerte vor. Das bleibt absichtlich dem Anbieter überlassen, weil die richtige Metrik vom Kontext abhängt. Was die Verordnung verlangt, ist Folgendes: Die Metriken müssen vorab festgelegt sein, nicht nachträglich gewählt. Die Schwellenwerte müssen dokumentiert und begründet sein. Die Tests müssen tatsächlich durchgeführt und die Ergebnisse festgehalten werden. Und die Schwellenwerte müssen im Verhältnis zum Risiko stehen – ein System mit Auswirkungen auf Grundrechte braucht strengere Schwellenwerte als eines mit geringerem Schadenspotenzial.

In der Praxis empfiehlt sich ein dreistufiges Vorgehen: Zunächst die relevanten Leistungsmetriken aus der Zweckbestimmung ableiten, etwa Accuracy, Precision, Recall, F1-Score, AUC-ROC oder domänenspezifische Metriken wie die Equal Error Rate in biometrischen Systemen. Dann die Akzeptanzschwellen festlegen, wobei der Stand der Technik, vergleichbare Systeme und die mögliche Schadensschwere als Orientierung dienen. Schließlich die Testbedingungen definieren: unter welchen Datensätzen, mit welchen Populationsverteilungen und unter welchen Betriebsbedingungen die Schwellenwerte eingehalten werden müssen. Die Dokumentation dieser Entscheidungen – einschließlich verworfener Alternativen und ihrer Begründung – ist Teil der technischen Dokumentation nach Art. 11 und Anhang IV.

Post-Market-Monitoring als geschlossener Regelkreis

Art. 72 verpflichtet Anbieter, ein Post-Market-Monitoring-System einzurichten, das systematisch und aktiv Leistungsdaten über das KI-System nach dessen Inverkehrbringen erhebt. Die Ergebnisse dieses Monitorings fließen über Art. 9 Abs. 2 direkt zurück in die Risikobewertung. Der Kreislauf ist damit geschlossen: Risiken werden identifiziert, Maßnahmen ergriffen, das System in Betrieb genommen, Betriebsdaten erhoben, neue Risiken identifiziert oder bestehende neu bewertet.

Art. 73 ergänzt dies um eine Meldepflicht bei schweren Vorfällen. Die Meldefristen sind nach Schwere gestaffelt: Bei weitverbreiteten Verstößen oder schwerwiegenden Auswirkungen auf kritische Infrastruktur beträgt die Frist zwei Tage, bei Vorfällen mit Todesfolge zehn Tage, bei sonstigen schweren Vorfällen fünfzehn Tage nach Kenntnisnahme. Ein schwerer Vorfall liegt vor, wenn das System ernsthafte Auswirkungen auf Gesundheit, Sicherheit oder Grundrechte von Personen hat. Die Meldepflicht setzt voraus, dass der Anbieter Prozesse zur Erkennung solcher Vorfälle etabliert hat – ein weiterer Baustein des Risikomanagementsystems.

Methodik und Werkzeuge

Die Verordnung schreibt keine bestimmte Risikobewertungsmethodik vor. In der Praxis eignen sich bewährte Methoden aus regulierten Branchen, die für den KI-Kontext adaptiert werden.

Die Fehlermöglichkeits- und Einflussanalyse (FMEA) identifiziert potenzielle Fehlermodi, bewertet deren Schwere, Auftretenswahrscheinlichkeit und Entdeckbarkeit und priorisiert Maßnahmen nach einer Risikoprioritätszahl. Sie eignet sich insbesondere für die strukturierte Bewertung von Fehlerszenarien in einzelnen Systemkomponenten.

Die Bow-Tie-Methode visualisiert Ursache-Wirkungs-Ketten: links die Ursachen eines unerwünschten Ereignisses mit ihren Präventionsbarrieren, rechts die Konsequenzen mit ihren Mitigationsbarrieren. Für KI-Systeme bietet sie eine intuitive Darstellung der Beziehung zwischen Datenrisiken, Systemfehlverhalten und Auswirkungen auf Betroffene.

Threat Modeling adressiert spezifisch Cybersicherheits- und Robustheitsrisiken: adversarielle Angriffe, Data Poisoning, Model Extraction und Manipulation von Eingabedaten. Für Hochrisiko-Systeme, die in sicherheitskritischen Kontexten eingesetzt werden, kann Threat Modeling insbesondere bei sicherheitskritischen Hochrisiko-Systemen sinnvoll sein.

ISO/IEC 23894 bietet darüber hinaus einen strukturierten Rahmen für KI-Risikomanagement auf Basis von ISO 31000, der die phasenspezifischen Risiken des KI-Lebenszyklus systematisch adressiert.

Die Wahl der Methodik hängt vom Systemtyp und vom Einsatzkontext ab. Für Systeme mit klar definierten Eingabe-Ausgabe-Beziehungen – etwa regelbasierte Entscheidungsunterstützung – genügt oft eine klassische FMEA. Für komplexere Machine-Learning-Systeme mit schwer interpretierbarem Verhalten empfiehlt sich eine Kombination: FMEA für bekannte Fehlermodi, ergänzt um Bow-Tie für Wirkungsketten und Threat Modeling für Sicherheitsrisiken. Die Verordnung verlangt keine bestimmte Methode, wohl aber ein nachvollziehbares, dokumentiertes Vorgehen, das der Komplexität des Systems angemessen ist.

Fazit: Risikomanagement als operativer Kern der Compliance

Art. 9 ist nicht die komplexeste, aber die folgenreichste Anforderung der KI-Verordnung für Hochrisiko-Systeme. Ein funktionierendes Risikomanagementsystem ist die Voraussetzung für alle weiteren Compliance-Schritte: die technische Dokumentation nach Art. 11 referenziert die Risikoanalyse, die Konformitätsbewertung prüft sie, das Post-Market-Monitoring speist sie.

Drei Aspekte verdienen besondere Beachtung

• Erstens: Der Lebenszyklusansatz bedeutet, dass Risikomanagement nicht nach der Inverkehrbringung endet, sondern dort erst in seine operative Phase eintritt.
• Zweitens: Die vorab festgelegten Metriken und Schwellenwerte nach Abs. 8 stellen einen wesentlichen Bestandteil des Compliance-Nachweises dar, ohne sie bleibt jede Risikobewertung beliebig.
• Drittens: Die besondere Berücksichtigung schutzbedürftiger Gruppen nach Abs. 9 ist nicht optional, sondern eine eigenständige Pflicht, die in der Risikoanalyse adressiert werden muss.

Fünf Schritte für den Einstieg

Ab dem 2. August 2026 gelten für Anbieter und bestimmte Betreiber von Hochrisiko-KI-Systemen u. a. Pflichten zu einem dokumentierten Qualitätsmanagementsystem und einem systematischen Risikomanagement über den gesamten Lebenszyklus. Für viele Unternehmen stellt sich damit eine operative Frage: Wie baut man ein KI-Governance-System auf, das die Anforderungen der KI-Verordnung erfüllt, in bestehende Compliance-Strukturen passt und nicht an der Komplexität des Themas scheitert? Dieser Beitrag strukturiert den Einstieg in fünf Schritte und ordnet die regulatorischen Anforderungen in einen praktikablen Handlungsrahmen ein.

Ein KI-Governance-System ist der organisatorische und dokumentierte Rahmen für Risikomanagement, menschliche Aufsicht und Qualitätsmanagement nach Art. 9, 14 und 17 der EU-KI-Verordnung für Hochrisiko-KI-Systeme.

Die regulatorischen Eckpfeiler: Art. 9, Art. 14 und Art. 17

Drei Artikel der KI-Verordnung bilden das Fundament jedes KI-Governance-Systems für Hochrisiko-Anwendungen.

Art. 9 verlangt ein Risikomanagementsystem, das über den gesamten Lebenszyklus des KI-Systems angewendet und regelmäßig überprüft wird. Der Prozess ist iterativ und umfasst vier Kernschritte: die Identifikation und Analyse von Risiken für Gesundheit, Sicherheit und Grundrechte; die Bewertung dieser Risiken; die Implementierung von Maßnahmen zur Risikominderung durch Design, technische Absicherung und Nutzerinformation; und die Dokumentation verbleibender Risiken als akzeptabel. Art. 9 verlangt zudem Tests über den gesamten Lebenszyklus und verstärkte Risikoanalyse und ggf. zusätzliche Tests, wenn das System Kinder oder vulnerable Gruppen betreffen kann.

Art. 14 verlangt, dass Hochrisiko-KI-Systeme so gestaltet sind, dass eine wirksame menschliche Aufsicht möglich ist. Die Verordnung verlangt u. a., dass beaufsichtigende Personen die Fähigkeiten und Grenzen des Hochrisiko‑KI‑Systems verstehen, Anomalien erkennen können, Automation‑Bias vermeiden und die Ergebnisse korrekt interpretieren können. Die Intensität der menschlichen Aufsicht muss proportional zum Risiko, zur Autonomie des Systems und zum Nutzungskontext sein.

Art. 17 verlangt ein dokumentiertes Qualitätsmanagementsystem, das proportional zur Unternehmensgröße ausgestaltet sein muss. Die Verordnung benennt mehr als zehn Komponenten, die das QMS abdecken muss: eine Compliance-Strategie und Verfahren zur Einhaltung der Verordnung, Verfahren für Design und Entwicklung, Testing und Validierung, technische Spezifikationen und Standards, Datenmanagement und Daten-Governance, das Risikomanagementsystem nach Art. 9, Post-Market-Monitoring, Verfahren für Incident Reporting, Kommunikationsprozesse mit Behörden und Betroffenen, Aufzeichnungspflichten sowie Ressourcenmanagement und Rechenschaftsstrukturen.

Art. 9 und Art. 17 stehen in einem klaren Verhältnis zueinander: Art. 9 definiert den technisch-inhaltlichen Kern des Risikomanagements. Art. 17 strukturiert diesen Kern organisatorisch und dokumentarisch – wer ist verantwortlich, in welchen Prozessen, mit welchen Nachweisen. Ein Unternehmen, das Art. 17 erfüllen will, braucht Art. 9 als inhaltliche Grundlage. Umgekehrt kann ein Risikomanagementsystem nach Art. 9 nur wirken, wenn es in die organisatorische Struktur eines QMS eingebettet ist.

Fünf Schritte zum KI-Governance-System

Aus den regulatorischen Anforderungen lässt sich eine priorisierte Implementierungslogik ableiten.

Schritt 1: KI-Inventar erstellen. Bevor eine Klassifizierung oder Risikoanalyse stattfinden kann, braucht das Unternehmen eine vollständige Übersicht über alle eingesetzten KI-Systeme – entwickelte, zugekaufte, eingebettete, experimentelle. Das Inventar erfasst für jedes System: Bezeichnung, Anbieter oder interner Verantwortlicher, Einsatzzweck, betroffene Personengruppen, eingesetzte Daten, Entscheidungsrelevanz und aktuellen Status. Erste Erhebungen und Praxisberichte deuten darauf hin, dass, dass über die Hälfte deutscher Unternehmen kein vollständiges KI-Inventar führen. Häufig werden eingebettete KI-Funktionen in Standardsoftware oder durch Fachabteilungen eigenständig beschaffte Tools übersehen. Die praktische Empfehlung: Das Inventar sollte nicht nur IT-zentral, sondern auch durch Self-Assessment-Fragebögen in den Fachbereichen aufgebaut werden. Ein gutes KI-Inventar unterscheidet zwischen Systemen, die das Unternehmen als Anbieter verantwortet, und Systemen, die es als Betreiber einsetzt – denn die Pflichtenprofile unterscheiden sich grundlegend.

Schritt 2: Risikoklassifizierung durchführen. Jedes System im Inventar wird gegen die Kategorien der Verordnung geprüft: Ist es verboten (Art. 5)? Hochrisiko nach Anhang I oder Anhang III (Art. 6)? Greift eine Ausnahme nach Art. 6 Abs. 3? Unterliegt es Transparenzpflichten nach Art. 50? Ist es ein GPAI-basiertes System mit Downstream-Pflichten? Die Klassifizierung ist dokumentationspflichtig – auch für Systeme, die als nicht hochrisiko eingestuft werden.

Schritt 3: Gap-Analyse gegen die Verordnungsanforderungen. Für jedes als hochrisiko eingestufte System wird systematisch geprüft, welche der Anforderungen aus Art. 9 bis 15 und Art. 17 bereits erfüllt sind und wo Lücken bestehen. Die Gap-Analyse deckt typischerweise auf, dass Teile des Risikomanagements bereits existieren (etwa durch DSGVO-Folgenabschätzungen oder sektorale Anforderungen), aber nicht die Vollständigkeit und Dokumentationstiefe der KI-Verordnung erreichen. Konkret lässt sich die Gap-Analyse entlang der zehn QMS-Komponenten nach Art. 17 strukturieren: Für jede Komponente wird dokumentiert, ob sie vollständig, teilweise oder nicht abgedeckt ist, welche bestehenden Prozesse angepasst werden können und welcher Aufwand für die Schließung der Lücke geschätzt wird. Das Ergebnis ist eine priorisierte Maßnahmenliste, die als Grundlage für die Ressourcenplanung dient.

Schritt 4: Governance-Struktur und QMS aufbauen. Auf Basis der Gap-Analyse wird das Qualitätsmanagementsystem nach Art. 17 strukturiert. Dies umfasst die Festlegung von Rollen und Verantwortlichkeiten, die Erstellung von Verfahrensanweisungen, die Einrichtung von Dokumentationsprozessen und die Integration in bestehende Management-Systeme. In diesem Schritt werden die Schnittstellen zu Datenschutz, IT-Sicherheit, Produktsicherheit und sektoraler Compliance definiert.

Schritt 5: Betrieb, Monitoring und kontinuierliche Verbesserung. Ein KI-Governance-System ist kein einmaliges Projekt. Art. 9 verlangt regelmäßige Überprüfung und Aktualisierung, Art. 72 ein Post-Market-Monitoring-System. Das Unternehmen muss Prozesse etablieren, die Veränderungen am System, an den Daten oder am Nutzungskontext erkennen und bewerten. Incident Reporting, Feedback-Schleifen und periodische Audits sind Bestandteil des laufenden Betriebs. Das Post-Market-Monitoring nach Art. 72 verlangt eine aktive, systematische Datenerhebung über die Leistung des KI-Systems nach dessen Inverkehrbringen. Anbieter müssen einen Plan erstellen, der definiert, welche Daten erhoben werden, mit welchen Methoden und in welchen Abständen. Die Ergebnisse fließen in die Aktualisierung des Risikomanagements zurück – ein geschlossener Regelkreis, der sicherstellt, dass das Governance-System mit dem System selbst mitwächst.

Organisatorische Verankerung: Rollen und Strukturen

Die KI-Verordnung schreibt keine bestimmte Organisationsform vor. Die Governance-Struktur muss zur Unternehmensgröße, zur Anzahl und Kritikalität der KI-Systeme und zur bestehenden Compliance-Organisation passen. In der Praxis kristallisieren sich drei Ebenen heraus.

Auf strategischer Ebene braucht es eine Führungsrolle, die die Gesamtverantwortung für KI-Governance trägt, ob als dedizierter Chief AI Officer, als Erweiterung des Verantwortungsbereichs eines CDO oder CIO oder als Aufgabe eines KI-Governance-Boards. Diese Ebene verantwortet die KI-Strategie, die Risikotoleranz und die Ressourcenallokation.

Auf operativer Ebene braucht es Fachverantwortliche, die das QMS pflegen, Risikobewertungen koordinieren und als Ansprechpartner für Aufsichtsbehörden fungieren. In größeren Organisationen ist dies ein dediziertes KI-Compliance-Team; in kleineren Organisationen kann es eine Erweiterung bestehender Compliance-Funktionen sein.

Auf der Ebene der menschlichen Aufsicht braucht es qualifizierte Personen in den Fachabteilungen, die die Anforderungen nach Art. 14 operativ umsetzen. Sie überwachen die Systemausgaben, erkennen Anomalien und können bei Bedarf eingreifen. Ihre Qualifikation muss dokumentiert sein.

Die Verknüpfung mit dem Datenschutzbeauftragten ist dabei nicht optional, sondern sachlogisch geboten. Die Überlappung zwischen KI-Verordnung und DSGVO ist erheblich – bei Daten-Governance, bei der Folgenabschätzung, bei Betroffenenrechten und bei der Aufsichtskommunikation.

Bestehende Standards als Orientierung

Unternehmen, die bereits Management-Systeme nach ISO-Normen betreiben, können auf diesen Strukturen aufbauen.

ISO 42001, veröffentlicht im Dezember 2023, definiert ein KI-Management-System und deckt etwa 40 bis 50 Prozent der Anforderungen des EU AI Act ab. Die Norm bietet eine Struktur für Governance, Risikomanagement und Lebenszyklusmanagement, ist aber freiwillig und ersetzt nicht die spezifischen Vorgaben der Verordnung. ISO/IEC 23894 ergänzt dies durch einen detaillierten Leitfaden für KI-Risikomanagement auf Basis der ISO 31000.

Die harmonisierte Norm prEN 18286 hätte die direkte Konformitätsvermutung mit Art. 17 ermöglichen sollen. Nach dem gescheiterten Enquiry-Votum im Januar 2026 befindet sich die Norm in der Revision. Eine Publikation im EU-Amtsblatt wird frühestens für Herbst 2026 erwartet. Bis dahin fehlt die formale Konformitätsvermutung, Unternehmen müssen die Anforderungen des Art. 17 direkt aus dem Verordnungstext ableiten.

Für Unternehmen mit bestehenden ISO-9001-Systemen ergibt sich ein pragmatischer Anknüpfungspunkt: Die Prozesslogik (Plan-Do-Check-Act), die Dokumentationsstruktur und das Auditverständnis sind übertragbar. Was fehlt, sind die KI-spezifischen Inhalte: Risikobewertung nach Art. 9, Daten-Governance nach Art. 10, Transparenz nach Art. 13 und die Anforderungen an menschliche Aufsicht nach Art. 14.

Der NIST AI Risk Management Framework bietet einen ergänzenden Referenzpunkt, auch wenn er auf den US-Markt ausgerichtet ist. Die vier Kernfunktionen des NIST-Rahmenwerks – Govern, Map, Measure, Manage – lassen sich als strukturelle Blaupause nutzen, die mit den spezifischen Vorgaben der EU-KI-Verordnung ausgefüllt wird. In der Praxis empfiehlt sich ein kombinierter Ansatz: ISO 42001 für die Managementsystem-Struktur, NIST AI RMF für die Risikomanagement-Funktionen und die EU-KI-Verordnung für die verbindlichen inhaltlichen Anforderungen. Dieser dreistufige Ansatz vermeidet Doppelarbeit und schafft Anschlussfähigkeit an internationale Anforderungen über den EU-Raum hinaus.

Die Implementierungsdauer für ein vollständiges KI-Management-System nach ISO 42001 wird in der Praxis auf acht bis zwölf Monate geschätzt. Für Unternehmen, die zum 2. August 2026 compliant sein müssen, ist der Zeitrahmen damit eng. Der pragmatische Ansatz: die kritischen Elemente – Inventar, Klassifizierung, Risikobewertung für die wichtigsten Systeme und Kernprozesse des QMS – priorisieren und die vollständige Systemreife iterativ nachreifen lassen.

Typische Fallstricke und wie man sie vermeidet

Drei Herausforderungen treten in der Praxis besonders häufig auf.

Die erste ist Shadow AI (Schatten-IT): KI-Systeme, die ohne Wissen der Governance-Funktion im Unternehmen eingesetzt werden. Ein KI-Inventar, das nur zentral beschaffte Systeme erfasst, greift zu kurz. Fachabteilungen nutzen eigenständig KI-Tools für Textgenerierung, Datenanalyse oder Prozessautomatisierung. Das Governance-System muss Prozesse etablieren, die diese Nutzung sichtbar machen, etwa durch Beschaffungsrichtlinien, IT-Monitoring oder regelmäßige Self-Assessments der Fachbereiche.

Die zweite ist die Zuständigkeitsfrage. Wenn KI-Governance weder IT noch Compliance noch Datenschutz eindeutig zugeordnet ist, bleibt sie im Niemandsland. Die Lösung liegt nicht in einer einzigen zuständigen Stelle, sondern in einer klaren Rollenmatrix mit definierten Verantwortlichkeiten, Eskalationspfaden und Entscheidungsbefugnissen.

Die dritte ist die Übergranularität der Dokumentation. Art. 17 verlangt ein dokumentiertes QMS proportional zur Unternehmensgröße. Unternehmen, die versuchen, jede Anforderung mit maximaler Detailtiefe zu dokumentieren, bevor überhaupt ein System klassifiziert ist, verlieren sich. Der pragmatische Ansatz: zuerst die Systeme mit dem höchsten Risiko und der größten Sichtbarkeit dokumentieren, dann das System iterativ auf weitere Anwendungen ausweiten.

Fazit: Governance als Betriebsmodell, nicht als Projekt

Ein KI-Governance-System ist kein Einmal-Projekt mit definiertem Abschluss, sondern ein dauerhaftes Betriebsmodell. Die Verordnung verlangt kontinuierliche Überprüfung, Aktualisierung und Anpassung. Unternehmen, die jetzt mit den fünf Schritten beginnen, schaffen die Grundlage für eine belastbare Compliance-Position zum Stichtag 2. August 2026.

Drei Aspekte verdienen besondere Beachtung.

• Erstens: Das KI-Inventar ist der Ausgangspunkt, ohne den keine weitere Maßnahme sinnvoll priorisiert werden kann.
• Zweitens: Das QMS nach Art. 17 muss nicht bei null beginnen: ISO 42001, bestehende ISO-9001-Systeme und sektorale Management-Systeme bieten belastbare Strukturen, auf denen aufgebaut werden kann.
• Drittens: Die harmonisierte Norm prEN 18286 ist noch nicht verfügbar. wer darauf wartet, verliert Zeit. Die Anforderungen des Art. 17 sind im Verordnungstext hinreichend konkret, um mit der Implementierung zu beginnen.

Die Integration von Art. 4 (KI-Kompetenz) ist dabei kein Nebenaspekt, sondern eine Voraussetzung: Ein Governance-System, dessen Akteure die Grundlagen nicht verstehen, bleibt formale Hülle ohne operative Wirkung.

Wo stehen CEN/CENELEC und was bedeutet die Lücke?

Harmonisierte Normen sind das zentrale Instrument, mit dem die EU Konformität messbar und nachweisbar macht. Wer eine solche Norm einhält, darf davon ausgehen, dass die entsprechenden gesetzlichen Anforderungen erfüllt sind, die sogenannte Konformitätsvermutung. Für den EU AI Act sollte dieses System bis zum Stichtag 2. August 2026 stehen. Es steht nicht. Von rund 40 beauftragten Normen sind die meisten noch in Arbeit, die zentrale QMS-Norm hat die Enquiry-Phase nicht bestanden, und eine Referenzierung im EU-Amtsblatt wird realistisch erst im Laufe des Jahres 2027 erwartet, frühestens im ersten Quartal. Dieser Beitrag ordnet den aktuellen Stand ein und zeigt, wie Unternehmen mit der Normenlücke umgehen können.

Was harmonisierte Normen im EU AI Act bewirken

Art. 40 der KI-Verordnung regelt die Wirkung harmonisierter Normen: Hochrisiko-KI-Systeme, die mit harmonisierten Normen oder Teilen davon übereinstimmen, deren Fundstellen im Amtsblatt der Europäischen Union veröffentlicht wurden, genießen eine Konformitätsvermutung in Bezug auf die von diesen Normen abgedeckten Anforderungen. Das Prinzip ist aus der Produktregulierung bekannt: Die Norm übersetzt die abstrakte Verordnungsanforderung in konkrete, prüfbare Kriterien.

Die Konformitätsvermutung ist kein Automatismus. Sie setzt voraus, dass die Norm im EU-Amtsblatt referenziert wird und dass das Unternehmen die Norm tatsächlich anwendet. Sie entbindet nicht von der Pflicht zur Konformitätsbewertung, erleichtert aber deren Durchführung erheblich: Eine Konformitätsbewertungsstelle, die ein System gegen eine harmonisierte Norm prüft, kann auf die normative Spezifikation zurückgreifen, statt die Verordnungsanforderungen selbst interpretieren zu müssen.

Fehlt eine harmonisierte Norm, bleibt die Verordnungsanforderung bestehen, aber der Nachweis wird aufwändiger. Unternehmen müssen dann auf Basis des Verordnungstextes selbst, verfügbarer Leitlinien und allgemeiner Spezifikationen ihre Konformität belegen.

Der Standardisierungsauftrag: JTC 21 und seine Struktur

Die Europäische Kommission hat im Mai 2023 den europäischen Normungsorganisationen CEN und CENELEC einen Standardisierungsauftrag erteilt. Das Joint Technical Committee 21 (JTC 21) wurde mit der Erarbeitung der Normen beauftragt. JTC 21 vereint über 300 Experten aus mehr als 20 Ländern in fünf Arbeitsgruppen und deckt zehn Regelungsbereiche ab: Risikomanagement, Datenqualität, technische Dokumentation, Transparenz und Informationspflichten, menschliche Aufsicht, Genauigkeit, Robustheit, Cybersicherheit, Qualitätsmanagementsystem und Konformitätsbewertungsverfahren.

Die ursprüngliche Frist für die Lieferung der Normen war April 2025. Sie wurde mehrfach angepasst, formal zuletzt von der Kommission auf den 31. August 2025. Im Oktober 2025 haben die CEN- und CENELEC-Boards ein Beschleunigungspaket beschlossen, das die Verfügbarkeit der Schlüsselnormen bis Q4 2026 sicherstellen soll. Stand April 2026 ist die Mehrheit der Normen noch in der Entwicklung oder in der Kommentierungsphase, nur ein kleiner Teil hat fortgeschrittene Reifestadien erreicht.

Die Struktur von JTC 21 spiegelt die Architektur der KI-Verordnung: Jede Arbeitsgruppe adressiert ein oder mehrere Kapitel der Verordnung. Das Deutsche Institut für Normung (DIN) betreibt ein nationales Spiegelgremium, das die deutsche Beteiligung koordiniert. Deutsche Unternehmen können über dieses Gremium Einfluss auf die Normgestaltung nehmen, eine Möglichkeit, die insbesondere für Unternehmen relevant ist, die eigene KI-Systeme entwickeln und frühzeitig normkonforme Prozesse aufbauen möchten.

Aktueller Stand: was existiert und was fehlt

Die folgende Übersicht gibt den Stand der wichtigsten Normenvorhaben wieder, soweit er im April 2026 öffentlich dokumentiert ist.

Die zentrale QMS-Norm prEN 18286, die das Qualitätsmanagementsystem nach Art. 17 spezifizieren soll, hat die Enquiry-Phase nicht bestanden. Die öffentliche Enquiry lief vom 30. Oktober 2025 bis 22. Januar 2026. Der Entwurf erreichte weder die erforderliche Mehrheit der zustimmenden nationalen Mitglieder noch das gewichtete Bevölkerungskriterium. 1.288 Kommentare wurden eingereicht und werden im März 2026 in Lösungsvorschlägen aufbereitet, gefolgt von einer finalen Abstimmungsrunde. Der Entwurf umfasst zehn normative Klauseln und fünf informative Anhänge und wurde für Kompatibilität mit ISO 9001, ISO 13485 und ISO 42001 konzipiert. Bei erfolgreicher Publikation und Referenzierung im EU-Amtsblatt würde sie eine Konformitätsvermutung für Art. 17 begründen.

Für die Bereiche Risikomanagement (prEN 18228), Datenqualität und Datasets (prEN 18284), Cybersicherheit (prEN 18282) sowie das AI Trustworthiness Framework (prEN 18229-1/-2) befinden sich Normentwürfe in verschiedenen Stadien der Entwicklung. Einige haben die Enquiry-Phase begonnen, andere sind noch in der Erarbeitungsphase. Keine dieser Normen ist zum Stand April 2026 im EU-Amtsblatt referenziert. Die Normen prEN 18281 (Evaluierung von Computer-Vision-Systemen) und prEN 18288 (Taxonomie der KI-Aufgaben in Computer Vision) adressieren spezifische technische Bereiche, die für Hochrisiko-KI in Biometrie und kritischer Infrastruktur relevant sind.

Das Gesamtbild ergibt eine erhebliche Diskrepanz zwischen dem Regulierungsanspruch und der normativen Unterfütterung. Von den rund 40 geplanten technischen Normen sind nur wenige in einem fortgeschrittenen Stadium. Ein erheblicher Teil wird voraussichtlich erst nach dem Stichtag 2. August 2026 fertiggestellt. Die realistische Einschätzung: Die ersten harmonisierten Normen werden frühestens im ersten Quartal 2027 im EU-Amtsblatt referenziert.

Für Unternehmen bedeutet das einen Zeitraum von mehreren Monaten nach dem Stichtag, in dem sie Konformität ohne formale Normunterstützung nachweisen müssen. Die Marktüberwachungsbehörden werden in diesem Zeitraum ebenfalls ohne normativen Prüfmaßstab arbeiten, was die Frage aufwirft, an welchen Kriterien sie die Konformität messen werden. Die wahrscheinliche Antwort: am Verordnungstext selbst, an verfügbaren Leitlinien der Kommission und an den Erwägungsgründen der Verordnung, die die Absicht des Gesetzgebers dokumentieren.

Warum prEN 18286 gescheitert ist und was das signalisiert

Das Scheitern der QMS-Norm prEN 18286 in der Enquiry-Abstimmung Anfang 2026 ist kein isolierter Vorfall, sondern symptomatisch für die Herausforderungen des Normungsprozesses. Drei Faktoren spielen eine Rolle.

Erstens die Komplexität der Materie. Art. 17 verlangt ein QMS, das über zehn Komponenten abdeckt und mit sektoralen Anforderungen verzahnt werden muss. Eine einzelne Norm, die dies leisten soll und gleichzeitig branchenübergreifend anwendbar ist, stößt an die Grenzen der traditionellen Normenlogik.

Zweitens die Interessenvielfalt. JTC 21 vereint Vertreter aus Industrie, Wissenschaft, Zivilgesellschaft und Normungsinstituten. Die 1.288 Kommentare zum prEN 18286-Entwurf spiegeln divergierende Erwartungen: Die Industrie wünscht sich praxisnahe, schlanke Anforderungen; Zivilgesellschaft und Wissenschaft fordern substanzielle Prüfpflichten; nationale Normungsinstitute bringen jeweils eigene Traditionen und Systemverständnisse ein.

Drittens die Repräsentationsfrage. Kritiker bemängeln, dass der Prozess strukturell Großunternehmen begünstigt, da Teilnahmekosten und zeitlicher Aufwand als Zugangsbarrieren wirken. JTC 21 hat darauf mit einer Task Group on Inclusiveness reagiert, die KMU, NGOs und weitere Stakeholder gezielt einbinden soll, etwa über dedizierte Newsletter, Workshops und Surveys.

Die Revision von prEN 18286 wird diese Spannungen adressieren müssen. Eine Veröffentlichung bis Q4 2026 ist das erklärte Ziel von CEN/CENELEC, eine Referenzierung im EU-Amtsblatt aber erst danach möglich.

Was passiert ohne harmonisierte Normen?

Die Abwesenheit harmonisierter Normen zum Stichtag 2. August 2026 bedeutet nicht, dass die Verordnung nicht anwendbar ist. Die materiellen Anforderungen gelten unabhängig von der Verfügbarkeit von Normen. Drei Instrumente stehen Unternehmen zur Verfügung.

Erstens die direkte Anwendung des Verordnungstextes. Art. 9 bis 15 und Art. 17 sind hinreichend konkret, um Anforderungen abzuleiten und ein Compliance-System aufzubauen. Die Detailtiefe reicht nicht an eine Norm heran, aber die Pflichten sind bestimmbar.

Zweitens die allgemeinen Spezifikationen nach Art. 41. Die Kommission kann „Common Specifications“ erlassen, wenn keine harmonisierten Normen vorliegen oder wenn bestehende Normen als unzureichend bewertet werden. Diese Spezifikationen haben eine ähnliche Vermutungswirkung wie harmonisierte Normen. Ob und wann die Kommission von dieser Möglichkeit Gebrauch macht, ist Stand April 2026 noch offen.

Drittens die Nutzung internationaler Standards als Orientierung. ISO 42001 (KI-Managementsysteme) und ISO/IEC 23894 (KI-Risikomanagement) bieten strukturelle Orientierung, die den Anforderungen der KI-Verordnung nahekommt. Sie sind nicht harmonisiert und begründen keine formale Konformitätsvermutung. Aber sie bieten eine belastbare Grundlage für den Nachweis, dass ein Unternehmen systematisch und nach anerkannten Methoden vorgeht. Eine Konformitätsbewertungsstelle wird ein Unternehmen, das nach ISO 42001 zertifiziert ist, anders bewerten als eines ohne jede Management-System-Struktur.

ISO 42001 überlappt substanziell mit den Anforderungen des AI Act, deckt aber bewusst nicht alle Aspekte ab. JTC 21 stellt im Rahmen seines Inclusiveness Newsletter klar, dass ISO 42001 nicht den vollständigen Satz an QMS-Anforderungen der Verordnung abbildet. Genau diese Lücke soll prEN 18286 schließen. Was bei ISO 42001 fehlt, sind die EU-spezifischen Detailanforderungen, etwa die konkreten Vorgaben zu Datenqualität nach Art. 10, die Aufzeichnungspflichten nach Art. 12 oder die spezifischen Transparenzanforderungen nach Art. 13. CEN/CENELEC adaptiert die internationalen ISO-Normen gezielt in den EU-regulatorischen Kontext hinein. Die harmonisierten Normen werden also auf ISO-Grundlagen aufbauen, diese aber um EU-spezifische Anforderungen erweitern. Unternehmen, die heute ISO 42001 implementieren, schaffen damit eine Grundlage, die bei Erscheinen der harmonisierten Normen relativ leicht erweitert werden kann.

Schätzungen aus der Beratungspraxis veranschlagen die laufenden Kosten für ein vollständiges KI-Compliance-System je nach Unternehmensgröße, Anzahl der Hochrisiko-Systeme und Reifegrad bestehender Management-Systeme im sechsstelligen Bereich pro Jahr. Für KMU sind diese Kosten besonders relevant, ein Aspekt, den die Verordnung durch Proportionalitätsklauseln und den bevorzugten Zugang zu Reallaboren adressiert, der aber in der Praxis durch fehlende normative Orientierung verschärft wird.

Digital Omnibus und die Fristendebatte

Die Normenlücke ist einer der Treiber der politischen Debatte um den Digital Omnibus. Der Vorschlag der Kommission vom 19. November 2025 sieht vor, die Anwendung der Hochrisiko-Pflichten an die Verfügbarkeit von Compliance-Support zu koppeln: harmonisierte Normen, allgemeine Spezifikationen oder Leitlinien. Stehen diese nicht rechtzeitig zur Verfügung, verschiebt sich die operative Anwendung, mit harten Backstop-Daten am 2. Dezember 2027 für eigenständige Hochrisiko-Systeme (Annex III) und am 2. August 2028 für KI in regulierten Produkten (Annex I).

Diese Mechanik schafft einen direkten Zusammenhang zwischen dem Normungstempo und der Compliance-Frist. Das Europäische Parlament hat seine Position am 26. März 2026 mit großer Mehrheit angenommen (569:45:23). Der zweite politische Trilog am 28. April 2026 endete jedoch ohne Einigung; ein weiterer Trilog war für Mitte Mai 2026 angesetzt. Sollte der Digital Omnibus nicht vor dem 2. August 2026 verabschiedet werden, gilt der ursprüngliche Stichtag der Verordnung. Unternehmen sollten beide Szenarien planen: den unveränderten Stichtag 2. August 2026 und eine mögliche Verschiebung mit Backstop. Die sicherere Strategie ist, auf den früheren Termin hinzuarbeiten und eine eventuelle Verschiebung als zusätzliche Zeit für Optimierung zu nutzen.

Fazit: die Normenlücke als Managemententscheidung

Die Normenlücke ist real und wird zum Stichtag 2. August 2026 nicht geschlossen sein. Für Unternehmen ist das keine ausweglose Situation, aber es erfordert eine bewusste Managemententscheidung über den Compliance-Ansatz.

Drei Handlungsempfehlungen ergeben sich.

• Erstens: Nicht auf harmonisierte Normen warten. Die Anforderungen der Verordnung sind bestimmbar, ISO 42001 bietet eine belastbare Struktur und die sektoralen Orientierungshilfen geben Richtung.
• Zweitens: Den Normungsprozess beobachten. Sobald prEN 18286 oder andere Normen publiziert werden, sollte das eigene QMS darauf abgeglichen werden, die Norm wird zum Prüfmaßstab der Aufsicht, auch wenn die formale Konformitätsvermutung erst mit der OJEU-Referenzierung greift.
• Drittens: Die Beteiligung am Normungsprozess erwägen. Über die nationalen Spiegelgremien können Unternehmen die Gestaltung der Normen beeinflussen und frühzeitig Einblick in die Entwicklungsrichtung gewinnen.

Die Normenlücke ist ein Umsetzungsrisiko, aber kein Compliance-Hindernis. Sie erhöht den Aufwand für den Konformitätsnachweis, macht ihn aber nicht unmöglich.