Artikel 9 des AI Act: Risiken in überprüfbare Kontrollen und Tests übersetzen

Was dieser Leitfaden abdeckt – und was nicht

Artikel 9 der europäischen KI-Verordnung (AI Act) verpflichtet Anbieter von Hochrisiko-KI-Systemen dazu, ein Risikomanagementsystem einzurichten, anzuwenden, zu dokumentieren und aufrechtzuerhalten. Die praktische Leitidee dieses Leitfadens ist einfach: Jedes ermittelte Risiko soll mit einer Maßnahme verknüpft sein, und es soll feststehen, wie überprüft wird, ob diese Maßnahme das Risiko tatsächlich mindert.

Der Leitfaden beschränkt sich auf diesen Artikel. Er ist weder eine vollständige Erläuterung der Verordnung noch eine rechtliche Bewertung eines Produkts oder eine eigenständige Methode zur Einstufung eines Systems als Hochrisiko-KI. Er unterstellt auch nicht, dass jedes KI-Tool Artikel 9 unterliegt. Zunächst muss geklärt werden, ob das System und seine Zweckbestimmung in den einschlägigen Anwendungsbereich der Verordnung fallen. Erst dann ist es sinnvoll, diese Vorlage als Arbeitshilfe zu nutzen.

Artikel 9 begründet Pflichten für Anbieter von Hochrisiko-KI-Systemen. Daraus folgt nicht, dass jede Person, die ein System einsetzt, automatisch das von den Anbietern geforderte Risikomanagementsystem einrichten und aufrechterhalten muss. Die Pflichten anderer Akteure, etwa der Betreiber, müssen gesondert geprüft werden. Einen Überblick über den weiteren Rahmen bieten die Inferama-Leitfäden zu Sicherheit, Systemvergleichen und der Suche nach KI-Tools; sie ersetzen nicht die Prüfung der Pflichten im konkreten Einzelfall.

Im Folgenden unterscheiden wir zwei Ebenen. „Anforderung der Verordnung“ bezeichnet, was Artikel 9 festhält. „Operative Empfehlung“ bezeichnet eine praktische Möglichkeit, die Arbeit zu strukturieren und die Umsetzung nachvollziehbar zu machen. Sie ist jedoch nicht mit einem Formular oder einem Feld gleichzusetzen, das die Verordnung wörtlich vorschreibt.

Vorab prüfen: Fällt das System in den Anwendungsbereich?

Bevor Sie Risiken nach Artikel 9 erfassen, bestimmen Sie das konkrete System und seine Zweckbestimmung. Die Einstufung hängt nicht allein davon ab, ob ein Produkt ein fortgeschrittenes Modell nutzt, eine Organisation es als sensibel einstuft oder seine Ergebnisse weitreichende Folgen haben. Die Verordnung legt anhand von Kategorien und Bedingungen fest, welche Systeme als Hochrisiko-KI gelten. Die Einstufung kann davon abhängen, wie ein System eingesetzt wird und welche Funktion es erfüllt.

Beschreiben Sie zunächst die tatsächliche und vorgesehene Nutzung so genau, dass sie geprüft werden kann: Wer bedient das System? Wer erhält oder verwendet seine Ergebnisse? Welche Entscheidung oder welcher Prozess wird unterstützt? In welchem Zusammenhang wird es eingesetzt? Vergleichen Sie diese Beschreibung anschließend mit den einschlägigen Bestimmungen der Verordnung, einschließlich der relevanten Kategorien sowie möglicher Bedingungen oder Ausnahmen. Wenn die Zuordnung zu einer Kategorie, die Rolle der Organisation oder der zeitliche Anwendungsbeginn einer Pflicht unklar ist, sollte die Einschätzung rechtlich geprüft werden, bevor eine vorläufige Schlussfolgerung als gesicherte Tatsache behandelt wird.

Stufen Sie ein System nicht allein anhand einer Produktbeschreibung, der verwendeten Technologie oder der Bezeichnung einer Kategorie ein. Ein System kann für unterschiedliche Zwecke eingesetzt werden; die Prüfung muss sich auf die konkret betrachtete Nutzung beziehen. Das später angeführte Beispiel zur Auswahl von Bewerbungen ist hypothetisch und soll zeigen, wie sich ein Risiko dokumentieren lässt. Es besagt nicht, dass jedes System zur Bewerberauswahl automatisch dieselbe rechtliche Einstufung hat.

Halten Sie fest, welche Informationen die vorläufige Einschätzung stützen: Produktunterlagen, erklärte Zweckbestimmung, Beschreibung des Prozesses und Einsatzbedingungen. Wenn die Einschätzung von noch unbestätigten Annahmen abhängt, kennzeichnen Sie diese als offen. So wird verhindert, dass eine hypothetische Einstufung in der Vorlage wie eine endgültige Feststellung erscheint.

Vom Nutzungskontext zu einem prüfbaren Risiko

Artikel 9 sieht einen kontinuierlichen und iterativen Prozess vor, der den gesamten Lebenszyklus des Systems umfasst. Beschreiben Sie zunächst den Nutzungskontext, bevor Sie mögliche Schäden auflisten. Dieselbe Ausgabe eines Systems kann je nach ihrer Interpretation, den vorhandenen zusätzlichen Prüfungen und der Möglichkeit, einen Fehler vor seinen Auswirkungen zu korrigieren, unterschiedliche Folgen haben.

Die Verordnung bezieht sich auf bekannte und vernünftigerweise vorhersehbare Risiken für Gesundheit, Sicherheit und Grundrechte, wenn das System bestimmungsgemäß verwendet wird. Sie verlangt außerdem, Risiken zu schätzen und zu bewerten, die sich aus dieser Zweckbestimmung sowie aus vernünftigerweise vorhersehbarem Missbrauch ergeben können. Daher sollten sowohl der vorgesehene Einsatz als auch vorhersehbare Abweichungen betrachtet werden, ohne jede entfernte Möglichkeit als nachgewiesenes Risiko darzustellen.

Trennen Sie bei jedem Szenario drei Aspekte: die bekannte Tatsache, die zu prüfende Hypothese und den möglichen Schaden. Eine Tatsache könnte beispielsweise sein, dass das System eine Einstufung ausgibt. Eine Hypothese wäre, dass bestimmte unvollständige Datensätze die Wahrscheinlichkeit einer falschen Einstufung erhöhen. Ein plausibler Schaden könnte darin bestehen, dass eine Person ohne angemessene Überprüfung aus einem Bewertungsverfahren ausgeschlossen wird. Der Test sollte klären, ob die Hypothese zutrifft und unter welchen Bedingungen.

Berücksichtigen Sie die potenziell betroffenen Personen und die Bedingungen, die das Ergebnis verändern können: Datenqualität oder fehlende Daten, Sprache, Einsatzumgebung, menschliches Eingreifen, Abhängigkeit von anderen Komponenten und Änderungen im Prozess. Sie müssen keine Sicherheit vortäuschen, wenn lediglich eine Hypothese vorliegt. Es ist besser, fehlende Informationen und die geplante Klärung zu benennen, als eine unbelegte Schätzung als Messwert auszugeben.

Für jedes Risiko eine geeignete Maßnahme bestimmen

Beschreiben Sie nach der Darstellung des Szenarios, welche Änderung das Risiko verhindern oder mindern könnte und warum Sie eine Wirkung erwarten. Artikel 9 verlangt geeignete Risikomanagementmaßnahmen, die auf die ermittelten Risiken ausgerichtet sind. Außerdem sieht er vor, Risiken durch angemessene Gestaltung und Entwicklung technisch so weit wie möglich zu beseitigen oder zu verringern. Lassen sich Risiken nicht beseitigen, sind geeignete Minderungs- und Kontrollmaßnahmen anzuwenden.

Eine Maßnahme kann sich in der Praxis auf die Gestaltung des Systems, seine Konfiguration, Anweisungen oder seine Einbindung in einen Prozess beziehen. Welche Option passt, hängt vom Risiko und vom System ab. Gehen Sie nicht davon aus, dass ein Hinweis in der Benutzeroberfläche oder eine allgemein gehaltene menschliche Prüfung ausreicht. Beschreiben Sie, was die Maßnahme bewirkt, wann sie greift, wer eingreifen kann und welche Grenzen sie hat. Wenn eine Person Informationen oder Schulungen benötigt, um das System angemessen einzusetzen, halten Sie fest, was sie wissen muss und wie diese Informationen bereitgestellt werden. Artikel 9 berücksichtigt auch Informationen und Schulungen für Betreiber, soweit dies einschlägig ist.

Die Begründung einer Maßnahme sollte mit dem Mechanismus des Risikos zusammenhängen. Wenn unvollständige Daten als Ursache für unzuverlässige Ergebnisse gelten, kann eine Kontrolle, die lediglich den Ausführungszeitpunkt protokolliert, die Ursache unangetastet lassen. Denkbar wären stattdessen Mechanismen, die unvollständige Daten erkennen, verhindern, dass ein ungültiges Ergebnis ohne Prüfung verwendet wird, oder die bedienende Person benachrichtigen. Das sind zu prüfende Möglichkeiten, keine allgemeingültigen Vorgaben. Der Test muss zeigen, ob sie im konkreten Kontext geeignet und wirksam sind.

Berücksichtigen Sie, dass die Verordnung das Risikomanagement mit dem Kenntnisstand und dem Stand der Technik sowie mit der vorgesehenen Zweckbestimmung und vernünftigerweise vorhersehbarem Missbrauch verknüpft. Das Register sollte daher nachvollziehbar machen, warum eine Maßnahme gewählt wurde und welche Informationen diese Wahl stützen. Wenn die Maßnahme das Risiko nicht beseitigt, halten Sie fest, was verbleibt und unter welchen Bedingungen die Kontrolle versagen könnte.

Tests planen, bevor sie durchgeführt werden

Artikel 9 sieht Tests von Hochrisiko-KI-Systemen vor, um die am besten geeigneten Risikomanagementmaßnahmen zu ermitteln. Soweit angemessen, sollen die Tests in verschiedenen Entwicklungsphasen stattfinden und in jedem Fall vor dem Inverkehrbringen oder der Inbetriebnahme. Die Verordnung sieht vor, dass sie anhand vorab festgelegter probabilistischer Metriken und Schwellenwerte durchgeführt werden, die für die vorgesehene Zweckbestimmung geeignet sind. Der Artikel selbst legt keine einzelne Metrik fest, die für alle Systeme gilt.

Damit ein Test eine Entscheidungsgrundlage bietet, legen Sie vorab fest, welches Szenario er abdeckt, welche Daten oder Bedingungen einbezogen werden, welches Ergebnis beobachtet werden soll und welches Kriterium als ausreichend gilt. Erläutern Sie, warum das Kriterium für den vorgesehenen Einsatz relevant ist. Wird es erst nach Sichtung der Ergebnisse festgelegt, steigt das Risiko, die Bewertung an das bereits Beobachtete anzupassen und wichtige Fehler nicht zu erkennen.

Prüfen Sie auch die Bedingungen, die für das Risiko relevant sind, etwa fehlende Daten, Sprachwechsel, Grenzfälle, Eingaben außerhalb der üblichen Bedingungen oder die vorgesehene menschliche Intervention. Die Auswahl sollte begründet werden; es ist nicht nötig, Szenarien ohne Bezug zur Nutzung aufzulisten. Wenn eine Stichprobe verwendet wird, erläutern Sie ihre Grenzen und welche Gruppen, Situationen oder Bedingungen sie nicht abbildet. Ein positives Ergebnis in einem begrenzten Test beweist nicht von selbst, dass das System in jeder Umgebung sicher ist.

Ein Ergebnis kann positiv, unzureichend oder nicht schlüssig sein. In den beiden letzten Fällen sollten Sie festhalten, was fehlgeschlagen ist oder warum keine Schlussfolgerung möglich ist, die Maßnahme gegebenenfalls anpassen und einen neuen Test festlegen. Bewahren Sie die relevanten Ergebnisse und Entscheidungen als Nachweis dafür auf, wie das Risiko behandelt wurde. Die Testpflicht sollte nicht auf das Speichern eines Kennwerts reduziert werden: Ziel ist es, geeignete Maßnahmen zu bewerten und das Verhalten des Systems im Verhältnis zu seiner Zweckbestimmung zu prüfen.

Vorlage: Risiko, Kontrolle, Test und Entscheidung verknüpfen

Ein nützlicher Registereintrag macht die gesamte Logik nachvollziehbar, ohne einen vorgeschlagenen Kontrollmechanismus mit einer bereits validierten Maßnahme zu verwechseln. Beim hypothetischen Beispiel der Bewerberauswahl geht es nicht darum, eine nachgewiesene Verzerrung oder einen belegten Schaden zu behaupten. Es soll gezeigt werden, welche Informationen gesammelt werden sollten, bevor entschieden wird, ob eine Kontrolle das angenommene Risiko mindert.

Die Maßnahme muss zum Szenario passen, und der Test muss diese Maßnahme bewerten – nicht nur das System im Allgemeinen. Wenn das Szenario etwa besagt, dass ein fehlendes Datum eine Einstufung beeinflussen könnte, die anschließend nicht überprüft wird, könnte ein geeigneter Test untersuchen, was bei Fehlen dieses Datums geschieht und ob das vorgesehene Prüfverfahren ausgelöst wird. Die konkreten Kriterien und Ergebnisse dürfen nicht erfunden werden: Sie müssen für das reale System festgelegt und gemessen werden.

Dokumentieren Sie getrennt, wer die Bewertung vorbereitet hat, wer eine interne Entscheidung freigegeben hat und wer rechtliche Fragen prüfen muss. Die Zuweisung solcher Funktionen kann eine sinnvolle Governance-Praxis sein. Schreiben Sie Artikel 9 jedoch keine allgemeine Funktion oder Rolle zu, die der Wortlaut nicht festlegt. Welche Person oder Organisation verpflichtet ist, hängt von ihrer Rolle nach der Verordnung und vom konkreten Fall ab.

Umgang mit unzureichenden Ergebnissen und Restrisiken

Ein Ergebnis, das das vorgesehene Kriterium nicht erreicht, lässt sich nicht dadurch beheben, dass der Schwellenwert nachträglich geändert wird, damit es akzeptabel aussieht. Dokumentieren Sie das tatsächliche Ergebnis, erläutern Sie, welche Bedingung nicht erfüllt wurde, und prüfen Sie, ob die Ursache eine Änderung der Gestaltung, eine zusätzliche oder angepasste Minderungsmaßnahme, eine Änderung des Einsatzprozesses oder eine Einschränkung der geprüften Nutzung erfordert. Planen Sie anschließend gegebenenfalls eine erneute Bewertung.

Wenn der Test keine Schlussfolgerung ermöglicht, benennen Sie den Grund: fehlende geeignete Daten, ein nicht reproduzierbares Szenario, eine begrenzte Stichprobe oder eine nicht beobachtete Einsatzbedingung. Auch diese Unsicherheit ist eine relevante Information. Halten Sie fest, was zu ihrer Klärung erforderlich wäre und wer entscheiden muss, ob weiter untersucht, die Nutzung eingeschränkt oder die Angelegenheit eskaliert wird.

Bezeichnen Sie ein Risiko nicht als beseitigt, wenn lediglich seine Wahrscheinlichkeit verringert oder seine Auswirkungen begrenzt wurden. Die Dokumentation sollte den Unterschied zwischen dem ursprünglichen Risiko, der Wirkung der Maßnahmen und den noch nicht geprüften Aspekten sichtbar machen. So können Prüfende nachvollziehen, dass eine geplante Maßnahme nicht mit nachgewiesener Wirksamkeit verwechselt wird.

Artikel 9 verlangt die Dokumentation des Risikomanagementsystems und der relevanten Entscheidungen. Als operative Empfehlung sollten Sie Versionen der Tests, Ausführungsbedingungen, Ergebnisse und Entscheidungsbegründungen zusammen mit dem Register aufbewahren. Bevor Sie Aufbewahrungsfristen festlegen, prüfen Sie die für das System und die Organisation geltenden Bestimmungen. Dieser Leitfaden legt keine allgemeingültige Frist fest.

Überprüfung während des Lebenszyklus und Verbindung zu anderen Prozessen

Das Risikomanagement nach Artikel 9 ist nicht als einmalige Bewertung gedacht, die mit dem Abschluss eines Tests endet. Es soll während des gesamten Lebenszyklus als kontinuierlicher und iterativer Prozess funktionieren und regelmäßig sowie systematisch überprüft und aktualisiert werden. Informationen, die nach der Bereitstellung gewonnen werden, können für die Risikobewertung relevant sein. Der Artikel berücksichtigt auch Daten aus der Überwachung nach dem Inverkehrbringen, auf die die Verordnung verweist.

Als organisatorischen Vorschlag können Sie festlegen, welche Änderungen eine Überprüfung auslösen können: wesentliche Änderungen des Systems, Änderungen der Zweckbestimmung oder des Einsatzkontexts, erkannte Probleme, neue Risikoinformationen oder Ergebnisse aus der Überwachung. Bestimmen Sie, wer diese Informationen erhält und wie entschieden wird, ob die Analyse, die Maßnahmen oder die Tests aktualisiert werden müssen. Diese konkreten Auslöser sind eine Empfehlung zur praktischen Umsetzung und keine wörtliche Liste aus Artikel 9.

Unterliegt das System bereits Anforderungen an das Risikomanagement aus einer anderen Rechtsvorschrift der Union, sieht Artikel 9 unter den in der Verordnung genannten Bedingungen vor, dass das entsprechende Risikomanagementsystem Teil der dort verlangten Prozesse sein oder zu ihnen beitragen kann. Gehen Sie nicht davon aus, dass ein bestehendes Verfahren automatisch sämtliche Pflichten aus dem AI Act erfüllt. Prüfen Sie, welche Risiken, Nachweise und Anforderungen jeder Prozess tatsächlich abdeckt.

Der Zeitpunkt, zu dem eine Pflicht anwendbar wird, hängt von den einschlägigen Übergangs- und Anwendungsbestimmungen ab. Er lässt sich nicht allein aus Artikel 9 ableiten. Prüfen Sie vor der Planung eines Erfüllungstermins den geltenden amtlichen Text und die für den Systemtyp und die Rolle der Organisation maßgeblichen Bestimmungen. Wenn der Termin eine unmittelbar anstehende Entscheidung beeinflusst, holen Sie aktuelle rechtliche Beratung ein.

Praktische Kriterien vor Abschluss der Bewertung

Prüfen Sie vor Abschluss der Arbeit, ob jedes Risiko verständlich beschrieben ist und ob Beobachtungen von Hypothesen getrennt werden. Stellen Sie sicher, dass jede Maßnahme einem bestimmten Risiko zugeordnet ist, ihre Begründung nachvollzogen werden kann und der Test Kriterien enthält, die vor seiner Durchführung festgelegt wurden. Wurde eine Maßnahme noch nicht getestet, kennzeichnen Sie sie als offen. Deckt ein Test nur bestimmte Bedingungen ab, übertragen Sie sein Ergebnis nicht auf andere Bedingungen.

Vergewissern Sie sich außerdem, dass sich die Analyse auf die tatsächlich geprüfte Zweckbestimmung und den entsprechenden Kontext bezieht, vernünftigerweise vorhersehbaren Missbrauch berücksichtigt und potenziell betroffene Personen nicht auslässt. Dokumentieren Sie die Grenzen der Arbeit und Fragen, die rechtlich oder technisch geprüft werden müssen. Wenn bestehende Prozesse genutzt werden, prüfen Sie, was sie abdecken, welche Nachweise sie liefern und welche Lücken verbleiben.

Artikel 9 ist weder eine automatische Zertifizierung der Sicherheit eines Systems noch eine Garantie dafür, dass kein Schaden eintreten wird. Er bildet die Grundlage für einen Risikomanagementprozess, der aufrechterhalten und dokumentiert werden muss. Der Nutzen einer Matrix bemisst sich nicht an der Zahl ihrer Zeilen, sondern daran, ob nachvollziehbar ist, warum eine Maßnahme gewählt wurde, welcher Test sie stützt, welches Ergebnis beobachtet wurde und was weiterhin ungeklärt ist.

Weiter entdecken

Korrekturen und Transparenz

Wenn du falsche oder veraltete Angaben findest, sende uns die Seite und die zu prüfende Quelle.