Am 2. August 2026 werden die Pflichten für Hochrisiko-KI-Systeme nach Anhang III anwendbar. Von allen Anforderungen aus Kapitel III ist Art. 9 — das Risikomanagementsystem die, an der in der Praxis die meisten Projekte hängen. Nicht, weil sie besonders exotisch wäre, sondern weil sie fortlaufend ist und sauber dokumentiert sein muss.
Was Art. 9 verlangt
Art. 9 Abs. 1 verlangt, dass ein Risikomanagementsystem „eingerichtet, angewandt, dokumentiert und aufrechterhalten” wird — vier Verben, die zusammen deutlich mehr sind als ein Dokument. Abs. 2 macht daraus einen kontinuierlichen iterativen Prozess über den gesamten Lebenszyklus, der eine regelmäßige systematische Überprüfung und Aktualisierung erfordert. Der Kern besteht aus vier Schritten:
- Risiken ermitteln und analysieren — die bekannten und vernünftigerweise vorhersehbaren Risiken für Gesundheit, Sicherheit oder Grundrechte bei bestimmungsgemäßer Verwendung.
- Fehlanwendung abschätzen — ausdrücklich auch die vernünftigerweise vorhersehbare Fehlanwendung, nicht nur der Idealfall.
- Felddaten auswerten — Risiken, die sich aus der Beobachtung nach dem Inverkehrbringen ergeben. Art. 9 verweist dafür auf das System nach Art. 72 AI Act.
- Gezielte Maßnahmen ergreifen, um die ermittelten Risiken zu bewältigen.
Abs. 3 zieht dabei eine wichtige Grenze: Gemeint sind nur Risiken, die sich durch Entwicklung, Konzeption oder ausreichende technische Informationen angemessen mindern lassen. Art. 9 verlangt nicht, jedes denkbare Übel der Welt zu lösen — aber alles, was im Einflussbereich des Anbieters liegt.
Die Rangfolge der Maßnahmen
Weniger bekannt, aber prüfungsrelevant: Abs. 5 gibt eine Reihenfolge vor. Das Restrisiko — je Gefahr und insgesamt — muss am Ende als vertretbar beurteilt werden, und der Weg dorthin ist gestuft:
- Beseitigen oder verringern durch geeignete Konzeption und Entwicklung, soweit technisch möglich.
- Angemessene Minderungs- und Kontrollmaßnahmen für Risiken, die sich nicht ausschließen lassen.
- Informationen nach Art. 13 AI Act und, wo nötig, Schulung der Betreiber.
Wer Stufe 1 überspringt und alles über einen Warnhinweis im Handbuch löst, hat die Rangfolge verfehlt. Zu berücksichtigen sind dabei ausdrücklich die technischen Kenntnisse, die Erfahrung und der Bildungsstand, die vom Betreiber erwartet werden können — sowie der Kontext, in dem das System eingesetzt werden soll.
Testen ist keine Kür
Der in der Praxis am häufigsten übersehene Teil steht in Abs. 6 bis 8: Hochrisiko-Systeme müssen getestet werden, um die geeigneten Maßnahmen überhaupt zu bestimmen. Und zwar
- zu jedem geeigneten Zeitpunkt während des Entwicklungsprozesses — und in jedem Fall vor dem Inverkehrbringen oder der Inbetriebnahme;
- anhand vorab festgelegter Metriken und Wahrscheinlichkeitsschwellenwerte, die zur Zweckbestimmung passen;
- optional als Test unter Realbedingungen nach Art. 60 AI Act.
„Vorab festgelegt” ist der entscheidende Halbsatz. Eine Evaluation, deren Schwellenwerte erst nach dem Ergebnis definiert wurden, ist kein Nachweis — sie ist eine Erzählung.
Fünf Lücken, die wir immer wieder sehen
1. Das Dokument ohne Prozess. Es existiert eine Risikoanalyse als PDF, aber niemand aktualisiert sie. Abs. 2 verlangt ausdrücklich eine regelmäßige systematische Überprüfung. Ein eingefrorenes Dokument erfüllt die Pflicht nicht.
2. Nur Modellrisiken, keine Grundrechte. Viele Analysen kommen aus dem ML-Team und listen Genauigkeit, Drift und Robustheit. Abs. 2 nennt aber ausdrücklich auch Grundrechte — Diskriminierung, Eingriffe in die Privatsphäre, Auswirkungen auf betroffene Personen.
3. Fehlanwendung wird ausgeklammert. „So ist das System nicht gemeint” ist keine Risikobehandlung. Vernünftigerweise vorhersehbarer Missbrauch gehört in die Analyse.
4. Schutzbedürftige Gruppen fehlen. Abs. 9 verlangt, zu berücksichtigen, ob das System wahrscheinlich nachteilige Auswirkungen auf Personen unter 18 Jahren oder andere schutzbedürftige Gruppen hat. In Bildungs-, Bewerbungs- oder Kreditkontexten ist das keine Randnotiz.
5. Keine Verbindung zu den anderen Artikeln. Das Risikomanagement steht nicht allein: Es speist die technische Dokumentation (Art. 11 AI Act, Anhang IV), begründet die Maßnahmen zur menschlichen Aufsicht (Art. 14 AI Act) und setzt die Zielwerte für Genauigkeit und Robustheit (Art. 15 AI Act). Wer Art. 9 isoliert bearbeitet, produziert Widersprüche zwischen den Dokumenten — und genau die fallen bei einer Prüfung auf.
Wenn Sie schon Risikomanagement betreiben
Abs. 10 ist die gute Nachricht für regulierte Branchen: Unterliegen Sie bereits nach anderem Unionsrecht internen Risikomanagement-Anforderungen, können die Aspekte aus Art. 9 Bestandteil dieser Verfahren sein oder mit ihnen kombiniert werden. Für Finanzunternehmen, die ohnehin an DORA arbeiten, heißt das: kein zweites, paralleles System aufbauen — aber belegen, dass die Punkte aus Art. 9 darin tatsächlich abgedeckt sind.
Was das bis zum Stichtag heißt
Für die verbleibende Zeit ist die Reihenfolge entscheidend:
- Zuerst einstufen. Nur Hochrisiko-Systeme brauchen Art. 9 in voller Tiefe. Der kostenlose Risiko-Check klärt das in unter zwei Minuten.
- Dann die Lücke ehrlich benennen. Nicht „haben wir”, sondern: Gibt es einen dokumentierten, wiederkehrenden Prozess mit Verantwortlichen, Terminen und vorab definierten Testmetriken?
- Dann die Querverweise ziehen. Risikomanagement, technische Dokumentation und Aufsichtsmaßnahmen müssen dieselbe Geschichte erzählen.
Wenn Sie wissen wollen, wie weit Ihre Unterlagen tatsächlich tragen: KomplAI gleicht Ihre Dokumente und Ihren Quellcode gegen die einschlägigen Normen ab und belegt jeden Verweis gegen die amtlichen EUR-Lex-Texte — inklusive Maßnahmenplan. Mehr dazu im Pflichten-Leitfaden ab August 2026 und im Fahrplan.