Artikel 9 — Risikomanagementsystem Praxisleitfaden.

Zusammenfassung. Artikel 9 der Verordnung (EU) 2024/1689 verpflichtet jeden Anbieter von Hochrisiko-KI, ein Risikomanagementsystem einzurichten, umzusetzen, zu dokumentieren und als kontinuierlichen iterativen Prozess über den gesamten Lebenszyklus des Systems aufrechtzuerhalten. Es handelt sich nicht um ein einmaliges Dokument. Ohne ein nachweisfähiges Risikomanagementsystem kann die Konformitätsbewertung nicht abgeschlossen werden, das Technische Dossier gemäß Anhang IV ist unvollständig, und das System kann weder mit dem CE-Kennzeichen versehen noch auf dem EU-Markt bereitgestellt werden. Dieser Leitfaden erläutert, was Artikel 9 tatsächlich verlangt, wie der vierstufige Zyklus operationalisiert wird, welche Nachweise Aufsichtsbehörden und Benannte Stellen erwarten und wie das Risikomanagementsystem nach der Inbetriebnahme aufrechtzuerhalten ist.

Inhalt

1. Warum Artikel 9 die tragende Wand der KI-Verordnung ist
2. Der vierstufige iterative Zyklus gemäß Artikel 9(2)
3. Schritt 1 — Identifikation bekannter und vernünftigerweise vorhersehbarer Risiken
4. Schritt 2 — Schätzung und Bewertung von Risiken
5. Schritt 3 — Maßnahmen des Risikomanagements
6. Schritt 4 — Testen über den gesamten Lebenszyklus
7. Dokumentation: Inhalt der RMS-Akte
8. Lebenszykluscharakter: Das Risikomanagementsystem ist kein Lieferobjekt, sondern ein Prozess
9. Stellung des Risikomanagementsystems in der Konformitätsbewertung
10. Wesentliche Änderung löst die erneute Ausführung des Risikomanagementsystems aus
11. Praktische Einrichtungs-Checkliste
12. Häufige Fehler aus Scoping-Gesprächen
13. DACH-spezifische Besonderheiten
14. Nächster Schritt

Warum Artikel 9 die tragende Wand der KI-Verordnung ist

Von den Pflichten, die die Verordnung (EU) 2024/1689 den Anbietern von Hochrisiko-KI auferlegt, ist Artikel 9 derjenige, dessen Fehlen alle nachgelagerten Anforderungen zum Scheitern bringt. Die Technische Dokumentation nach Artikel 11 in Verbindung mit Anhang IV lässt sich ohne die Ergebnisse des Risikomanagementsystems nicht vollständig erstellen. Das Qualitätsmanagementsystem nach Artikel 17 verweist ausdrücklich auf das Risikomanagementsystem als integralen Bestandteil. Die Konformitätsbewertung nach Artikel 43 — ob durch interne Kontrolle gemäß Anhang VI oder durch Drittbewertung einer Benannten Stelle gemäß Anhang VII — setzt voraus, dass der Bewerter nachweist, dass ein Risikomanagementsystem eingerichtet wurde und aufrechterhalten wird. Die Beobachtung nach dem Inverkehrbringen gemäß Artikel 72 erfordert einen Plan, der auf dem Risikomanagementsystem aufbaut — ohne dieses gibt es keinen Maßstab für die Überwachung.

Die Sanktionen bei Nichterfüllung der Pflichten für Hochrisiko-KI gemäß den Artikeln 9, 10, 13, 14, 15 und 16 sind gestuft auf bis zu EUR 15 Mio. oder 3 % des gesamten weltweiten Jahresumsatzes, je nachdem welcher Betrag höher ist. Der Aufsichtsmechanismus ist kein Selbstattestierungsregime. Die Bewertung durch eine Benannte Stelle gemäß Anhang VII ist selbst eine Dokumentations- und Verfahrensprüfung; die interne Kontrolle nach Anhang VI verpflichtet den Anbieter dennoch, die Dokumentation zehn Jahre nach dem Inverkehrbringen des Systems oder seiner Inbetriebnahme aufzubewahren und den nationalen zuständigen Behörden auf Anfrage vorzulegen.

Die praktische Konsequenz: Ein Anbieter, der beabsichtigt, ein Hochrisiko-KI-System ab dem 2. August 2026 auf dem EU-Markt bereitzustellen, kann Artikel 9 nicht aufschieben. Das Risikomanagementsystem muss zum Zeitpunkt der Konformitätsbewertung bereits nachweisbare Ergebnisse vorweisen.

Eine Checkliste zur Prüfung, ob Ihr KI-System überhaupt als Hochrisiko-KI nach Anhang III einzustufen ist, finden Sie unter Anhang III Scoping-Checkliste für DACH-Organisationen.

Der vierstufige iterative Zyklus gemäß Artikel 9(2)

Artikel 9(2) schreibt die strukturelle Form des Risikomanagementsystems vor. Es muss sich um handeln:

„einen kontinuierlichen iterativen Prozess, der über den gesamten Lebenszyklus eines Hochrisiko-KI-Systems geplant und durchgeführt wird und eine regelmäßige systematische Überprüfung und Aktualisierung erfordert."

Die vier Schritte, die den Zyklus bilden, sind in Artikel 9(2)(a)–(d) aufgeführt:

1. Identifikation und Analyse der bekannten und vernünftigerweise vorhersehbaren Risiken, die das Hochrisiko-KI-System für Gesundheit, Sicherheit oder Grundrechte darstellen kann, wenn es entsprechend seiner Zweckbestimmung verwendet wird.
2. Schätzung und Bewertung der Risiken, die entstehen können, wenn das System entsprechend seiner Zweckbestimmung sowie unter Bedingungen vernünftigerweise vorhersehbaren Missbrauchs verwendet wird.
3. Bewertung weiterer Risiken, die sich möglicherweise aus der Analyse der im Rahmen der Beobachtung nach dem Inverkehrbringen gemäß Artikel 72 gewonnenen Daten ergeben.
4. Ergreifung angemessener und gezielter Risikomanagementsmaßnahmen zur Behandlung der identifizierten Risiken.

Der Zyklus ist iterativ. Das Ergebnis von Schritt vier fließt in Schritt eins zurück, sobald sich das System, seine Umgebung, die verwendeten Daten oder die Anwendungsfälle weiterentwickeln. Dies ist der strukturelle Grund, warum ein Risikomanagementsystem, das als einziges, unverändertes Dokument auf einem Dateiserver abgelegt ist, Artikel 9 nicht genügt: Bereits nach dem zweiten Monat der Nutzung ist das Dokument veraltet und das Risikomanagementsystem hat aufgehört zu existieren.

ISO/IEC 23894:2023 ist der am engsten abgestimmte Standard für KI-spezifisches Risikomanagement und wird von Praktikern zunehmend als Grundlage herangezogen. ISO/IEC 42001:2023 liegt eine Ebene darüber und schreibt das Managementsystem vor, in dem das Risikomanagementsystem verankert ist. Keiner der beiden Standards ist bislang formal als harmonisierter Standard im Sinne der KI-Verordnung anerkannt, ihre Anwendung ist jedoch derzeit der effizienteste Weg zu einem nachweisfähigen Risikomanagementsystem.

Schritt 1 — Identifikation bekannter und vernünftigerweise vorhersehbarer Risiken

Der Schritt der Risikoidentifikation umfasst zwei analytische Dimensionen. Die erste betrifft die Risiken bei bestimmungsgemäßer Verwendung — die Risiken, die entstehen, wenn das KI-System genau so eingesetzt wird, wie der Anbieter es dokumentiert hat, und der Betreiber die Gebrauchsanweisung befolgt. Die zweite betrifft die Risiken bei vernünftigerweise vorhersehbarem Missbrauch — die Risiken, die entstehen, wenn der Betreiber oder Endnutzer von der Zweckbestimmung in einer Weise abweicht, die der Anbieter hätte antizipieren können. Beide Dimensionen müssen in der RMS-Akte enthalten sein.

Die Risikokategorien, die Artikel 9(3) ausdrücklich benennt, sind:

• Risiken für Gesundheit und Sicherheit — physische Schäden, die direkt oder indirekt durch die Ausgaben oder das Verhalten des Systems verursacht werden
• Risiken für Grundrechte nach der Charta — einschließlich Nichtdiskriminierung, Würde, Privatsphäre, Meinungsfreiheit, Recht auf ein faires Verfahren und Rechte von Kindern
• Risiken für Personen in schutzbedürftigen Situationen gemäß Artikel 9(8) — Risiken, die Gruppen betreffen, deren Schutzbedürftigkeit durch den Einsatzkontext verstärkt wird (Kinder, ältere Menschen, Menschen mit Behinderungen, Personen in Abhängigkeitsverhältnissen)
• Risiken für Kinder gemäß Artikel 9(9) — besondere Berücksichtigung, wenn das System für die Verwendung durch oder für Kinder vorgesehen ist oder deren Interessen berührt

Das Identifikationsartefakt in der RMS-Akte ist üblicherweise ein Gefahrenregister: Jede Zeile bezeichnet eine Gefahr, jede Spalte gibt die Quelle der Gefahr an (Daten, Modell, Einsatz, Menschliche Faktoren, Integration), den betroffenen Stakeholder, die Lebenszyklusphase, in der die Gefahr auftritt, sowie den zugehörigen Test. Die Abdeckung der für das System relevanten Anhang-III-Kategorien muss erkennbar sein — ein System zur Kreditentscheidung muss beispielsweise nachweisen, dass Fairness, Transparenz, Anfechtbarkeit und die Anforderungen des Art. 22 DSGVO zur automatisierten Entscheidungsfindung sämtlich im Register erfasst sind, nicht nur die Modellgenauigkeit.

Bei Systemen, die personenbezogene Daten verarbeiten, ist der Risikoidentifikationsschritt im Risikomanagementsystem mit der Datenschutz-Folgenabschätzung gemäß Art. 35 DSGVO zu koordinieren. Eine separate DSFA erfüllt Artikel 9 nicht; eine Risikoidentifikation nach Artikel 9, die DSGVO-relevante Gefahren außer Acht lässt, erfüllt die DSGVO nicht. Beide müssen kohärent sein.

Schritt 2 — Schätzung und Bewertung von Risiken

Sobald die Gefahren identifiziert sind, muss für jede die Eintrittswahrscheinlichkeit und die Schwere der Folgen geschätzt sowie anhand einer vom Anbieter festgelegten Akzeptabilitätsschwelle bewertet werden. Artikel 9 schreibt kein bestimmtes Bewertungsschema vor. Praktiker verwenden typischerweise entweder eine qualitative Matrix (niedrig / mittel / hoch / kritisch) oder eine halbquantitative Skala, die anhand historischer Belege und vergleichbarer Einsatzsituationen kalibriert wurde.

Folgendes muss nachweisfähig sein:

• Die Akzeptabilitätsschwelle ist dokumentiert und auf einer angemessenen Autoritätsebene innerhalb der Anbieterorganisation genehmigt — üblicherweise die Geschäftsleitung oder ein Aufsichtsgremium, nicht allein das Entwicklungsteam.
• Die Schätzmethodik ist konsistent über alle Gefahren hinweg angewendet. Der Wechsel zwischen Skalen innerhalb desselben Registers untergräbt die gesamte Bewertung.
• Für die Gefahren mit dem größten Schadenspotenzial wurde eine Sensitivitätsanalyse durchgeführt: Wie verändert sich der Risikoscore, wenn sich der Einsatzkontext ändert, die Datenbasis driftet oder der Nutzerkreis erweitert wird?
• Ungewissheit wird anerkannt. Wenn Eintrittswahrscheinlichkeit oder Schweregrad nicht mit Sicherheit bekannt sind, ist dieser Umstand im Dokument festzuhalten, anstatt eine scheinbar gesicherte Zahl einzusetzen.

Artikel 9(2)(c) verlangt ausdrücklich, dass die Bewertung Daten der Beobachtung nach dem Inverkehrbringen einbezieht, sobald diese verfügbar sind. Das bedeutet: Für die erste Version des Risikomanagementsystems vor der Inbetriebnahme sind solche Daten definitionsgemäß noch nicht vorhanden, der Bewertungsrahmen muss aber so aufgebaut sein, dass reale Telemetriedaten nach dem Start der Überwachung gemäß Artikel 72 einfließen können.

Das Ergebnis von Schritt zwei ist eine priorisierte Gefahrenliste: welche Gefahren vor dem Inverkehrbringen behandelt werden müssen, welche einer laufenden Überwachung bedürfen und welche unterhalb der Akzeptabilitätsschwelle liegen und nur einer Dokumentation bedürfen.

Schritt 3 — Maßnahmen des Risikomanagements

Artikel 9(4) schreibt die Maßnahmenhierarchie vor: Das Risikomanagementsystem muss angemessene und gezielte Maßnahmen in dieser Prioritätsreihenfolge ergreifen:

„(a) Beseitigung oder Reduzierung von Risiken, soweit technisch durchführbar, durch eine angemessene Konzipierung und Entwicklung des Hochrisiko-KI-Systems;

(b) soweit angemessen, Umsetzung geeigneter Minderungs- und Kontrollmaßnahmen zur Behandlung von Risiken, die nicht beseitigt werden können;

(c) Bereitstellung der gemäß Artikel 13 erforderlichen Informationen und — soweit angemessen — Schulung der Betreiber."

Diese Prioritätsreihenfolge ist verbindlich. Dokumentation allein ist kein Ersatz für technische Minderungsmaßnahmen, wo diese durchführbar sind. Die Schulung des Betreibers ist kein Ersatz für die Entwicklung sichereren Systemverhaltens. Die RMS-Akte muss gefahrenweise darlegen, warum eine bestimmte Maßnahme gewählt wurde, warum Maßnahmen höherer Priorität — sofern zutreffend — nicht durchführbar waren, und welches Restrisiko nach Ergreifung der Maßnahme verbleibt.

Beispiele für in der Praxis eingesetzte Maßnahmenkategorien:

• Beseitigung in der Entwurfsphase — Entfernung eines Merkmals, Einschränkung der Zweckbestimmung, Begrenzung des Nutzerkreises, Entfernung geschützter Attribute aus den Trainingsdaten
• Architektonische Minderungsmaßnahmen — Leitplanken (Guardrails), Ensemble-Prüfungen, Konfidenzgrenzen unterhalb derer das System keine Aktion auslöst, Kontrollpunkte mit menschlicher Aufsicht
• Operative Minderungsmaßnahmen — Gebrauchsanweisungen, die spezifische Einsatzkonfigurationen vorschreiben, zulässige Eingabebereiche, verbotene Anwendungsfälle, Aufsichtsprotokolle nach Artikel 14
• Offenlegung und Schulung — Transparenzinformationen für Betreiber nach Artikel 13, Betreiberschulung nach Artikel 26, Transparenzpflichten gegenüber natürlichen Personen nach Artikel 50, soweit anwendbar

Das Ergebnis von Schritt drei ist ein Maßnahmenregister: Jede Maßnahme ist mit einer oder mehreren Gefahren verknüpft und enthält den Verantwortlichen, die Verifikationsmethode und den nach Umsetzung verbleibenden Restrisikoscore, der in den Zyklus zurückfließt.

Für Betreiber, die diesen Leitfaden lesen: Artikel 26 legt Ihnen Pflichten auf, die das Risikomanagementsystem des Anbieters nicht abdeckt. Siehe Artikel 26 — Pflichten der Betreiber für die Betreiberseite desselben Themas.

Schritt 4 — Testen über den gesamten Lebenszyklus

Artikel 9(5)–(7) verlangt die Prüfung des Hochrisiko-KI-Systems, um konsistente Leistung für die Zweckbestimmung sowie die Erfüllung der Anforderungen von Kapitel III Abschnitt 2 sicherzustellen. Drei Unterabsätze sind maßgeblich:

• Artikel 9(5) — Testverfahren müssen geeignet sein, die Zweckbestimmung zu erreichen; Tests werden anhand vorab festgelegter Metriken und probabilistischer Schwellenwerte durchgeführt, die dem System angemessen sind.
• Artikel 9(6) — Das Testen erfolgt während des gesamten Entwicklungsprozesses und vor dem Inverkehrbringen oder der Inbetriebnahme.
• Artikel 9(7) — Realwelt-Tests unter den Bedingungen des Artikels 60 sind unter spezifischen Schutzmaßnahmen und Registrierung in der EU-Datenbank zulässig.

Praktiker sehen sich mehreren unterschiedlichen Prüfbereichen gegenüber:

• Funktionstest — erfüllt das System seine bestimmungsgemäße Funktion über die Eingabeverteilung, auf die es im Einsatz trifft?
• Robustheitstest — Leistung bei Verteilungsverschiebung, adversarischen Eingaben und Randfällen
• Bias- und Fairness-Test — disparate Auswirkungen auf geschützte Gruppen, Kalibrierung über Teilgruppen hinweg, Fairness-Metriken abgestimmt auf den Einsatzkontext
• Sicherheitstest — adversarische Angriffe auf maschinelles Lernen, Prompt-Injection (bei Systemen mit generativer KI), Datenextraktionsangriffe, Modellinversion
• Test der menschlichen Aufsicht — greift der Aufsichtsmechanismus nach Artikel 14 tatsächlich Fehler auf, die das System macht?
• Integrationstest — verhält sich das System korrekt innerhalb des übergeordneten Workflows des Betreibers?

Jede Testkategorie erzeugt Nachweise. Nachweise sind das, was die Konformitätsbewertungsstelle prüft. Die RMS-Akte muss jedes identifizierte Risiko mit dem oder den Tests verknüpfen, die es prüfen, mit protokollierten Ergebnissen und vorab festgelegten — nicht nachträglich angepassten — Bestehens- und Nichtbestehens-Kriterien.

Dokumentation: Inhalt der RMS-Akte

Artikel 9 verpflichtet zur Dokumentation als Teil des Systems; Anhang IV(3) macht das Risikomanagementsystem zum Pflichtinhalt der Technischen Dokumentation, die für die Konformitätsbewertung eingereicht wird. Der Mindestinhalt der RMS-Akte umfasst:

• Geltungsbereichs- und Zweckbestimmungsbeschreibung — welches System durch dieses Risikomanagementsystem erfasst ist, in welchen Konfigurationen und für welche Anwendungsfälle
• Rollen und Verantwortlichkeiten — wer das Risikomanagementsystem verantwortet, wer es überprüft, Eskalationswege, namentlich benannte Personen, soweit Regulatoren persönliche Verantwortlichkeit verlangen
• Risikoidentifikationsregister — Gefahren bei bestimmungsgemäßer Verwendung und bei vernünftigerweise vorhersehbarem Missbrauch
• Risikoschätzmethodik und Ergebnisse — Bewertungsschema, Akzeptabilitätsschwelle, Sensitivitätsanalyse
• Maßnahmenregister — Maßnahmen verknüpft mit Gefahren, mit Prioritätsbegründung gemäß Artikel 9(4)
• Testplan und Nachweise — umfasst die Testbereiche nach Artikel 9(5)–(7)
• Plan zur Beobachtung nach dem Inverkehrbringen — wie Telemetriedaten gemäß Artikel 72 in das Risikomanagementsystem zurückfließen, Überprüfungsfrequenz
• Register wesentlicher Änderungen — Auslöserprotokoll gemäß Artikel 43(4)
• Überprüfungsturnus und Änderungshistorie — wann das Risikomanagementsystem überprüft wurde, durch wen, was geändert wurde, Versionshistorie

Ein in der Praxis bewährtes Muster: Die RMS-Akte ist als versioniertes, fortlaufend gepflegtes Dokument angelegt — typischerweise im selben Konfigurationsmanagementsystem wie das Technische Dossier nach Anhang IV — wird mindestens vierteljährlich sowie bei jeder wesentlichen Änderung überprüft, und die aktuelle Überprüfungszusammenfassung ist der Geschäftsleitung zugänglich.

Lebenszykluscharakter: Das Risikomanagementsystem ist kein Lieferobjekt, sondern ein Prozess

Die folgenreichste Einzelaussage in Artikel 9(2) ist, dass das Risikomanagementsystem „ein kontinuierlicher iterativer Prozess" ist, „der über den gesamten Lebenszyklus eines Hochrisiko-KI-Systems geplant und durchgeführt wird." Ein Dokument, das einmalig für die Konformitätsbewertung erstellt und danach nicht mehr aktualisiert wird, erfüllt Artikel 9 nicht. Der Prozess muss laufen.

Operativ erfordert dies:

• Einen festgelegten Überprüfungsturnus (typischerweise vierteljährlich für Systeme im Betrieb; häufiger in der Vorbereitungsphase und unmittelbar nach der Inbetriebnahme)
• Einen verbindlichen Überprüfungsauslöser bei jeder wesentlichen Änderung (Artikel 43(4))
• Einen verbindlichen Überprüfungsauslöser bei jedem Befund der Beobachtung nach dem Inverkehrbringen (Artikel 72) oberhalb eines definierten Schweregradgrenzwertes
• Einen verbindlichen Überprüfungsauslöser bei jedem gemäß Artikel 73 gemeldeten Vorfall (schwerwiegende Vorfälle)
• Einen verbindlichen Überprüfungsauslöser bei jedem Aufsichtsbehördenbefund oder jeder Leitlinienaktualisierung, die das System betrifft
• Einen klar definierten Außerdienstnahme-Pfad — wird das System stillgelegt, hält die RMS-Akte den abschließenden Zustand sowie die Grundlage der Stillegungsentscheidung fest

Für Systeme mit hoher Änderungsfrequenz (kontinuierliches Lernen, häufiges Neutrainieren, häufige Funktionsupdates) kann der Überprüfungsturnus auf monatliche oder sogar kontinuierliche Zyklen verdichtet sein, bei denen automatisierte Telemetrie das Gefahrenregister speist und ein Eskalationsprotokoll greift, sobald Scores Schwellenwerte überschreiten.

Stellung des Risikomanagementsystems in der Konformitätsbewertung

Die Konformitätsbewertung — ob nach interner Kontrolle gemäß Anhang VI oder Drittbewertung gemäß Anhang VII — prüft das Risikomanagementsystem als Teil des Technischen Dossiers nach Anhang IV. Die Bewertungsstelle wird Folgendes prüfen:

• Nachweis, dass das Risikomanagementsystem als dokumentierter Prozess existiert, nicht nur als Einzeldokument
• Nachweis, dass der vierstufige Zyklus vor dem Inverkehrbringen mindestens einmal vollständig ausgeführt wurde
• Nachweis, dass die Tests nach Artikel 9(5)–(7) abgeschlossen wurden und die Testergebnisse mit vorab festgelegten Kriterien dokumentiert sind
• Nachweis, dass die Risikomanagementsmaßnahmen nach Artikel 9(4) die vorgeschriebene Prioritätsreihenfolge einhalten
• Nachweis, dass das Risikomanagementsystem in das übergeordnete Qualitätsmanagementsystem nach Artikel 17 integriert ist

Welcher Konformitätsbewertungsweg für Ihr spezifisches System in Frage kommt, hängt vom Systemtyp und den verfügbaren harmonisierten Standards ab. Siehe Konformitätsbewertung: Anhang VI vs. Anhang VII für die Entscheidungsgrundlage und die jeweiligen Anforderungen.

Wesentliche Änderung löst die erneute Ausführung des Risikomanagementsystems aus

Artikel 43(4) definiert die wesentliche Änderung und verlangt bei deren Vorliegen die erneute Durchführung der Konformitätsbewertung. Für das Risikomanagementsystem bedeutet dies:

• Eine Änderung der Zweckbestimmung des Systems
• Eine Änderung des grundlegenden Risikoprofils (neue Schadenskategorien, neue betroffene Bevölkerungsgruppen, neue Datenabhängigkeiten)
• Eine Änderung der Risikomanagementsmaßnahmen, die im vorangegangenen Risikomanagementsystem nicht vorgesehen war
• Eine Änderung der Leistung, die außerhalb des zuvor validierten Testbereichs liegt
• Bei Systemen mit Lernfähigkeit nach der Inbetriebnahme: Wenn die Lernentwicklung die in der Technischen Dokumentation vorab definierten und validierten Grenzen überschreitet, liegt eine wesentliche Änderung vor

Viele Anbieter dokumentieren die Auslöser für wesentliche Änderungen unzureichend und stellen bei der nächsten Konformitätsbewertung fest, dass die RMS-Akte der tatsächlichen Systementwicklung um zwölf bis achtzehn Monate hinterherhinkt. Die praktische Gegenstrategie ist ein Register wesentlicher Änderungen, das als Bestandteil der RMS-Akte geführt wird, mit datierten Einträgen, Entscheidung durch eine namentlich benannte verantwortliche Person und Begründung, ob eine erneute Durchführung erforderlich ist.

Praktische Einrichtungs-Checkliste

Für Organisationen, die erstmals ein Risikomanagementsystem einrichten, ist die folgende Abfolge der Mindest-Implementierungspfad:

1. Bestätigen Sie die Hochrisiko-Einstufung — Artikel 6 in Verbindung mit Anhang III. Falls unklar, führen Sie den kostenlosen EU-KI-Schnelltest (10 Minuten) für eine erste Klassifizierung durch.
2. Definieren Sie den Systemgeltungsbereich — was ist im Risikomanagementsystem enthalten, was nicht. Ein einzelnes Hochrisiko-KI-System mit klar definierter Zweckbestimmung.
3. Bestimmen Sie den RMS-Verantwortlichen — namentlich benannte Person innerhalb der Anbieterorganisation mit ausreichender Befugnis zur Genehmigung von Risikomanagementsmaßnahmen.
4. Legen Sie das Format des Risikoregisters fest — Gefahr, Quelle, betroffener Stakeholder, Lebenszyklusphase, Bewertung, verknüpfte Maßnahmen, verknüpfte Tests.
5. Legen Sie die Akzeptabilitätsschwelle fest — genehmigt auf geeigneter Leitungsebene, dokumentiert in der RMS-Akte.
6. Führen Sie die erste Identifikationsrunde durch — Gefahren bei bestimmungsgemäßer Verwendung, bei vernünftigerweise vorhersehbarem Missbrauch, aus Daten, aus menschlichen Faktoren. Berücksichtigen Sie Anhang-III-spezifische Aspekte und Grundrechte nach der Charta.
7. Schätzen und bewerten Sie jede Gefahr anhand der Schwelle.
8. Ergreifen Sie Maßnahmen gemäß der Prioritätsreihenfolge nach Artikel 9(4). Dokumentieren Sie, warum Maßnahmen höherer Priorität gegebenenfalls nicht gewählt wurden.
9. Definieren und führen Sie den Testplan aus — Funktion, Robustheit, Bias, Sicherheit, Aufsicht, Integration.
10. Dokumentieren Sie die RMS-Akte in der unter Abschnitt 7 beschriebenen Struktur.
11. Definieren Sie den Überprüfungsturnus und das Register wesentlicher Änderungen.
12. Definieren Sie den Plan zur Beobachtung nach dem Inverkehrbringen gemäß Artikel 72 sowie dessen Rückkopplung in das Risikomanagementsystem.
13. Integrieren Sie das Risikomanagementsystem in das Qualitätsmanagementsystem nach Artikel 17 — das Risikomanagementsystem ist Bestandteil des QMS, nicht neben diesem angesiedelt.
14. Reichen Sie zur Konformitätsbewertung nach dem für das System maßgeblichen Verfahren ein.

Die meisten Organisationen stellen fest, dass die Schritte 6 bis 9 mehr Zeit in Anspruch nehmen als die eigentliche technische Entwicklung des Systems. Dies ist kein Zeichen für Ineffizienz, sondern die tatsächliche Kostenseite des regulatorischen Regimes.

Häufige Fehler aus Scoping-Gesprächen

Die folgenden Muster treten in Scoping-Gesprächen mit DACH-regulierten Organisationen regelmäßig auf und führen bei der Konformitätsbewertung zum Scheitern, wenn sie nicht korrigiert werden:

Das Einzeldokument-Risikomanagementsystem. Ein Dokument, das für eine interne Prüfung erstellt und danach eingefroren wurde. Artikel 9(2) verlangt einen kontinuierlichen Prozess; das Dokument ist das Artefakt, der Prozess ist die Pflicht. Ein Dokument ohne Überprüfungsturnus und Register wesentlicher Änderungen ist kein Risikomanagementsystem.

Die DSFA als Risikomanagementsystem. Eine Datenschutz-Folgenabschätzung nach Art. 35 DSGVO deckt Datenschutzrisiken ab. Sie deckt weder Sicherheitsrisiken noch Fairness-Risiken jenseits der Daten, noch Robustheitsrisiken, noch die Beobachtung nach dem Inverkehrbringen im Sinne von Artikel 72 ab. Die DSFA ist dort erforderlich, wo personenbezogene Daten verarbeitet werden; als Risikomanagementsystem ist sie nicht ausreichend.

Die Modellkarte als Risikomanagementsystem. Eine Modellkarte (Model Card) beschreibt das Modell. Sie stellt kein Risikomanagement dar. Die Modellkarte als RMS-Akte zu behandeln verfehlt die gesamte Prozessdimension von Artikel 9.

Nachträglich angepasste Testergebnisse. Das Testen nach Artikel 9(5)–(7) ist Nachweisführung — die Kriterien müssen vor dem Test definiert sein, nicht nach Vorliegen des Ergebnisses festgelegt werden. Konformitätsbewertungsstellen achten zunehmend auf das Versionsdatum des Testplans im Verhältnis zum Datum der Testergebnisse, um eine Nachpassung zu erkennen.

Nichtbeachtung der Prioritätsreihenfolge nach Artikel 9(4). Offenlegungen und Schulungen als einzige Minderungsmaßnahme dokumentieren, obwohl eine Beseitigung in der Entwurfsphase oder eine architektonische Minderungsmaßnahme technisch durchführbar gewesen wäre. Artikel 9(4) macht die Reihenfolge verbindlich; das Risikomanagementsystem muss begründen, warum jede Hierarchieebene gewählt oder übersprungen wurde.

Wesentliche Änderung als vages Konzept behandeln. Ohne ein Register und eine namentlich benannte Entscheidungsperson werden wesentliche Änderungen informell durch Entwicklungsteams vorgenommen, ohne dass die Konformitätsbewertungskonsequenzen auf der richtigen Organisationsebene sichtbar werden. Bei der nächsten Konformitätsprüfung stimmt die Akte nicht mehr mit der Realität überein.

DACH-spezifische Besonderheiten

Für deutsche, österreichische und schweizerische Organisationen, die zusätzlicher sektorspezifischer Regulierung unterliegen:

Banken und Finanzdienstleistungen — Die Anforderungen der BaFin aus MaRisk AT 9 für das Drittanbieter-Risikomanagement überlagern die KI-Verordnung, wenn die KI von einem Dritten bereitgestellt wird. Das Risikomanagementsystem muss die Auslagerungsdimension ausdrücklich adressieren. Für Kreditinstitute und Versicherungsunternehmen, die KI für die Kreditwürdigkeitsprüfung oder Versicherungspreisgestaltung einsetzen, verweist Artikel 29a der KI-Verordnung ausdrücklich auf die betreiberseitige Grundrechte-Folgenabschätzung, die das Risikomanagementsystem des Betreibers zu koordinieren hat.

Cloud und Infrastruktur — BSI C5 Cloud-Computing-Compliance-Kriterien gelten, wenn die KI auf Cloud-Infrastruktur betrieben wird. Die Risikomanagementsystem-Gefahren hinsichtlich Cloud-Unterauftragsverarbeiter, Datenhaltungsort und Incident-Handling müssen mit den C5-Pflichten übereinstimmen, die der Anbieter oder Betreiber separat übernommen hat.

Öffentlicher Sektor — Zusätzliche Grundrechte-Folgenabschätzung gemäß Artikel 26(6) für Stellen des öffentlichen Rechts und private Betreiber, die Dienste im öffentlichen Interesse erbringen. Die betreiberseitige Grundrechte-Folgenabschätzung ist ein eigenständiges Dokument gegenüber dem Anbieter-Risikomanagementsystem, steht jedoch mit diesem in Wechselwirkung.

Gesundheitswesen und Medizinprodukte — Überschneidung mit der Medical Device Regulation (MDR). KI unter MDR-Anhang I Hochrisiko-Klassifizierung ist nach Artikel 6(1) der KI-Verordnung zugleich Anhang-III-hochrisikorelevant; eine koordinierte Bewertung ist erforderlich, und das Risikomanagementsystem muss auf beide regulatorischen Grundlagen verweisen.

Datenschutz — Der Bundesbeauftragte für den Datenschutz und die Informationsfreiheit (BfDI) sowie die Landesbehörden für den Datenschutz haben Leitlinien zu KI und personenbezogenen Daten veröffentlicht, die geprüft und im Risikomanagementsystem berücksichtigt werden sollten, soweit die Verarbeitung personenbezogener Daten in den Geltungsbereich fällt.

Das Aufsichtsumfeld im DACH-Raum ist anspruchsvoll. Die Nachweise des Risikomanagementsystems nach Artikel 9 müssen spezifisch, dokumentiert, aktuell und auf angemessener Leitungsebene unterzeichnet sein. Generische Vorlagen bestehen aufsichtsbehördliche Prüfungen nicht.

Nächster Schritt

Die Hochrisikopflichten der Verordnung (EU) 2024/1689, einschließlich Artikel 9, gelten ab dem 2. August 2026. Organisationen, die beabsichtigen, Hochrisiko-KI-Systeme ab diesem Datum auf dem EU-Markt bereitzustellen, sollten den Risikomanagementsystem-Zyklus bereits einmal mit dokumentierten Ergebnissen durchgeführt haben, bevor die Konformitätsbewertung eingeleitet werden kann.

Für eine erste Klassifizierung, ob Ihr KI-System in den Anwendungsbereich fällt, erzeugt der EU-KI-Schnelltest unter app.ekmgc.de in ca. zehn Minuten eine personalisierte Risikostufung und einen 30-Tage-Plan. Anonym, ausschließlich im Browser, ohne Registrierung. Zweisprachig DE / EN.

Für Organisationen, die von der Klassifizierung zu einem dokumentierten Risikomanagementsystem, einer Konformitätsbewertung und einem Technischen Dossier nach Anhang IV übergehen müssen — einschließlich solcher mit sektorspezifischen Überlagerungen in Finanzdienstleistungen, Gesundheitswesen, öffentlichem Sektor oder Cloud — bietet die EU-KI-Compliance-Praxis der EKM Global Consulting GmbH auftragsbasierte Beratungsleistungen an. Siehe ekmgc.de/eu-ai-act.html oder wenden Sie sich direkt an elshan.musayev@ekmgc.de.

Betrieben von der EKM Global Consulting GmbH (Baden-Baden, gegründet im Januar 2013). Gründer: Elshan Musayev.

Informationszusammenfassung der Verordnung (EU) 2024/1689. Keine Rechtsberatung. Die EU-KI-Verordnung ist ein komplexes und sich fortentwickelndes regulatorisches Regime; die konkrete Anwendbarkeit und die sich daraus ergebenden Pflichten erfordern eine formelle Prüfung anhand der tatsächlichen Systeme und Anwendungsfälle Ihrer Organisation.

Verwandte Beiträge

• Anhang III Scoping-Checkliste für DACH-Organisationen
• Konformitätsbewertung: Anhang VI vs. Anhang VII
• Artikel 26 — Pflichten der Betreiber