Risikomanagement für KI-Systeme

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.