Alle Artikel
KI-Risikomanagement-System: Leitfaden zu Artikel 9
AI Act

KI-Risikomanagement-System: Leitfaden zu Artikel 9

Vollständiger Leitfaden zum Risikomanagement-System nach Artikel 9 des AI Act. Kontinuierliche Risikobewertung, Restrisiko, Testprotokolle und Compliance über den Lebenszyklus.

Legalithm Team25 Min. Lesezeit
Teilen
Lesezeit25 Min.
ThemaAI Act
AktualisiertMärz 2026
Inhaltsverzeichnis

Das KI-Risikomanagement-System nach Artikel 9: Der vollständige Umsetzungsleitfaden

TL;DR

  • Artikel 9 des EU AI Act schreibt für jedes Hochrisiko-KI-System ein umfassendes Risikomanagement-System vor. Es ist keine einmalige Bewertung, sondern ein kontinuierlicher, fortlaufender Prozess, der den gesamten KI-Lebenszyklus umspannt, vom ersten Design über den Betrieb nach dem Inverkehrbringen bis zur Außerbetriebnahme.
  • Das Risikomanagement-System muss bekannte und vernünftigerweise vorhersehbare Risiken identifizieren und analysieren, Risiken aus sowohl bestimmungsgemäßer Nutzung als auch vernünftigerweise vorhersehbarer Fehlanwendung bewerten und Erkenntnisse aus Daten der Marktbeobachtung in einer fortlaufenden Rückkopplungsschleife einbeziehen.
  • Das Restrisiko, also das Risiko, das nach der Minderung verbleibt, muss als akzeptabel beurteilt werden, wenn es gegen den Nutzen des KI-Systems abgewogen wird. Anbieter müssen Restrisiken den Betreibern über die Betriebsanleitung mitteilen.
  • Tests sind nicht optional oder kosmetisch. Artikel 9(5), (7) verlangt Tests gegen vordefinierte Metriken, unter realen Bedingungen, wo angebracht, und mit besonderem Augenmerk auf die Auswirkungen auf Kinder und schutzbedürftige Gruppen.
  • Die Anforderungen von Artikel 9 decken sich weitgehend mit ISO 42001 (Abschnitt 6.1) und dem NIST AI RMF (Funktionen GOVERN und MAP), was Organisationen ermöglicht, einen einheitlichen Compliance-Rahmen aufzubauen.
  • Die Durchsetzung der Hochrisiko-Pflichten beginnt am 2. August 2026. Nichteinhaltung kann Bußgelder von bis zu 15 Millionen EUR oder 3 % des weltweiten Jahresumsatzes nach sich ziehen.
  • Nutzen Sie das AI-Act-Bewertungstool von Legalithm, um festzustellen, ob Ihr KI-System als hochriskant gilt und welche Risikomanagement-Pflichten gelten.

Wenn Sie nur einen einzigen Artikel des EU AI Act lesen, dann Artikel 9. Das Risikomanagement-System ist das Fundament, auf dem jede andere Hochrisiko-Pflicht ruht. Die technische Dokumentation verlangt von Ihnen, Ihren Risikomanagement-Prozess zu beschreiben. Die Daten-Governance stützt sich auf Risiken, die Sie identifiziert haben. Die menschliche Aufsicht muss auf die Restrisiken abgestimmt sein. Die Marktbeobachtung speist in das Risikomanagement-System zurück. Jeder Weg führt zu und von Artikel 9.

Dennoch ist das Risikomanagement der Punkt, an dem viele Organisationen stolpern, weil sie es als ein Compliance-Häkchen behandeln statt als den lebenden, fortlaufenden Prozess, den Artikel 9 verlangt. Dieser Leitfaden schlüsselt jeden Absatz von Artikel 9 auf, übersetzt die rechtlichen Anforderungen in Umsetzungsschritte, ordnet sie internationalen Standards zu und liefert die Werkzeuge, die Sie brauchen, um ein konformes Risikomanagement-System aufzubauen.

Warum Artikel 9 das Rückgrat der AI-Act-Compliance ist

Eine grundlegende Pflicht für alle Hochrisiko-KI

Wenn Ihr KI-System in die Hochrisiko-Kategorie fällt, sei es über Anhang I (als Sicherheitsbauteil regulierter Produkte) oder Anhang III (eigenständige Hochrisiko-Anwendungsfälle wie biometrische Identifizierung, kritische Infrastruktur, Beschäftigung, Kreditwürdigkeit oder Strafverfolgung), gilt Artikel 9. Nicht sicher, ob Ihr System darunterfällt? Unser Einstufungsleitfaden führt durch die Analyse, und die AI-Act-Bewertung von Legalithm kann Ihnen in Minuten eine Antwort geben.

Artikel 9 ist die erste substanzielle Pflicht in Abschnitt 2 (Artikel 8-15). Sie können die Anforderungen an Daten-Governance, Transparenz, Genauigkeit, Robustheit oder menschliche Aufsicht nicht sinnvoll erfüllen, solange Sie nicht zuerst die Risiken identifiziert haben, die Ihr System birgt.

Kontinuierlich, fortlaufend und über den Lebenszyklus reichend

Artikel 9(1) legt fest, dass das Risikomanagement-System ein "kontinuierlicher iterativer Prozess sein muss, der über den gesamten Lebenszyklus eines Hochrisiko-KI-Systems geplant und durchgeführt wird". Das schließt einmalige Bewertungen aus, ebenso statische Dokumente, die für die Konformitätsbewertung erstellt und dann archiviert werden, sowie sporadische Überprüfungen, die nur durch Vorfälle ausgelöst werden. Stattdessen verlangt Artikel 9 einen Prozess, der geplant ist (mit definierten Aktivitäten, Zeitplänen und Verantwortlichkeiten), fortlaufend ist (jeder Zyklus informiert den nächsten) und den Lebenszyklus umspannt (vom Design bis zur Außerbetriebnahme). Hersteller von Medizinprodukten arbeiten seit Jahrzehnten unter ähnlichen Rahmenwerken (ISO 14971), Artikel 9 bringt KI in dasselbe Paradigma.

Durchsetzung ab August 2026

Die Pflichten aus Artikel 9 werden am 2. August 2026 durchsetzbar. Anbieter, die ein Hochrisiko-KI-System an oder nach diesem Datum auf dem EU-Markt in Verkehr bringen, müssen ein vollständig umgesetztes Risikomanagement-System haben. Systeme, die bereits auf dem Markt sind, müssen in die Konformität gebracht werden. Für alle Durchsetzungsdaten siehe unseren EU-AI-Act-Zeitplan.

Ist Ihr KI-System hochriskant?

Finden Sie es in 2 Minuten heraus, kostenlos, ohne Anmeldung.

Jetzt prüfen

Artikel 9, die rechtlichen Anforderungen erklärt

Einrichtung eines Risikomanagement-Systems (Artikel 9(1))

Artikel 9(1) verlangt, dass ein Risikomanagement-System eingerichtet, umgesetzt, dokumentiert und aufrechterhalten wird, vier Verben, vier eigenständige Pflichten. Das System muss förmlich mit definierter Governance und Methodik geschaffen werden (eingerichtet), aktiv ausgeführt statt bloß in einer Richtlinie beschrieben werden (umgesetzt), für Prüfer und Aufsichtsbehörden hinreichend detailliert festgehalten werden (dokumentiert) und aktuell gehalten werden, während sich das System und sein Umfeld weiterentwickeln (aufrechterhalten).

Artikel 9(1) legt zudem eine "regelmäßige systematische Aktualisierung" fest, Aktualisierungen dürfen nicht sporadisch oder informell sein, sondern müssen einer definierten Taktung und Methodik folgen.

Identifizierung und Analyse bekannter und vorhersehbarer Risiken (Artikel 9(2)(a))

Artikel 9(2)(a) verlangt die Identifizierung und Analyse bekannter Risiken (dokumentiert im Stand der Technik, in Tests beobachtet oder in früheren Versionen gemeldet) und vernünftigerweise vorhersehbarer Risiken (solche, die eine fachkundige Person erwarten würde, auch wenn sie noch nicht beobachtet wurden).

Der Anwendungsbereich umfasst Gesundheit, Sicherheit und Grundrechte, das heißt, die Risikoidentifizierung muss über technische Ausfallmodi hinausgehen und Auswirkungen auf Privatsphäre, Nichtdiskriminierung, Meinungsfreiheit und andere Rechte der Charta einbeziehen. Die Grundrechte-Folgenabschätzung (FRIA) ergänzt diese Analyse für Betreiber.

Abschätzung und Bewertung von Risiken aus bestimmungsgemäßer Nutzung und vorhersehbarer Fehlanwendung (Artikel 9(2)(b))

Artikel 9(2)(b) verlangt die Abschätzung und Bewertung von Risiken aus sowohl der Zweckbestimmung (dem dokumentierten Zweck, für den das System ausgelegt ist) als auch der vernünftigerweise vorhersehbaren Fehlanwendung (Nutzungen, die nicht beabsichtigt sind, aber auf Grundlage menschlichen Verhaltens und der Fähigkeiten des Systems vorhergesagt werden können). Zum Beispiel könnte eine KI zum Screening bei der Einstellung missbraucht werden, um Kandidaten anhand geschützter Merkmale zu filtern, die mit legitimen Kriterien korrelieren.

Diese Anforderung zwingt Sie zu der Frage: "Was passiert, wenn Menschen es auf eine Weise nutzen, die wir nicht beabsichtigt, aber hätten vorhersehen sollen?" Die vorhersehbare Fehlanwendung nicht zu berücksichtigen, ist eine der häufigsten Compliance-Lücken.

Bewertung von Risiken aus Daten der Marktbeobachtung (Artikel 9(2)(c))

Artikel 9(2)(c) schafft eine formelle Rückkopplungsschleife zwischen der Marktbeobachtung und dem Risikomanagement. Reale Daten zu Leistung, Ausfällen, Beinahe-Vorfällen und Vorfällen müssen in das Risikomanagement-System zurückfließen und dabei Risiken aufdecken, die vor dem Inverkehrbringen nicht erkannt wurden, bekannte Risiken, die sich anders manifestieren als geschätzt, oder neue Risiken aus Umgebungsänderungen wie Distribution Shift. Die Marktbeobachtung ist ein Input für das Risikomanagement, keine parallele Pflicht.

Ergreifen geeigneter Risikomanagement-Maßnahmen (Artikel 9(2)(d))

Artikel 9(2)(d) verlangt das Ergreifen "geeigneter und gezielter" Risikomanagement-Maßnahmen. Die Maßnahmen müssen verhältnismäßig (katastrophale Risiken verlangen robuste Minderung), spezifisch (jedes identifizierte Risiko braucht eine entsprechende Maßnahme, generische Aussagen wie "wir werden das System beobachten" sind unzureichend) und wirksam (das Risiko tatsächlich reduzierend, nicht bloß den Anschein einer Reduktion erweckend) sein.

Der AI Act schreibt keine bestimmten Maßnahmen vor und gibt Anbietern Flexibilität, aber die Beweislast liegt eindeutig beim Anbieter, wenn er von einer Marktüberwachungsbehörde in Frage gestellt wird.

Restrisiko, was akzeptabel ist (Artikel 9(3), (4))

Die Artikel 9(3) und 9(4) legen drei entscheidende Grundsätze für das Restrisiko fest:

  1. Wechselwirkungen zählen. Minderungsmaßnahmen können sich gegenseitig beeinflussen, ein Risiko zu reduzieren kann ein anderes erhöhen. Das System muss diese Wechselwirkungen ganzheitlich betrachten.
  2. Ausgewogenheit ist erforderlich. Sie müssen eine angemessene Ausgewogenheit zwischen Compliance-Aufwand und Risiken erreichen. Alle Risiken zu beseitigen, ist weder erwartet noch möglich.
  3. Das Restrisiko muss akzeptabel sein. Nach aller Minderung muss das verbleibende Risiko als akzeptabel beurteilt werden, für jede einzelne Gefahr und für das Gesamtsystem.

Die Akzeptanz wird durch Abwägung des Restrisikos gegen Nutzen, Stand der Technik, gesellschaftliche Erwartungen und einschlägige harmonisierte Normen bestimmt. Wir behandeln dies ausführlich in einem eigenen Abschnitt weiter unten.

Tests zur Sicherstellung gleichbleibender Leistung (Artikel 9(5), (7))

Die Artikel 9(5), (7) legen vier Testanforderungen fest:

  • Zweckgetrieben, das Testen ist mit der Identifizierung geeigneter Risikomanagement-Maßnahmen verknüpft, nicht bloß mit dem Nachweis technischer Leistung.
  • Kriterienbasiert, gegen vordefinierte Metriken und probabilistische Schwellenwerte, nicht gegen im Nachhinein gewählte Ad-hoc-Benchmarks.
  • Kontinuierlich, durchgeführt über die gesamte Entwicklung und vor dem Inverkehrbringen, nicht nur am Ende.
  • Auf Konsistenz ausgerichtet, die Ergebnisse müssen ein zuverlässiges Verhalten über den gesamten Bereich der Bedingungen belegen, denen das System begegnen wird, nicht nur Genauigkeit auf einem durchschnittlichen Datensatz.

Für ausführliche Anleitungen zu Testmethoden, einschließlich Bias-Tests, siehe unseren Leitfaden zu KI-Bias-Tests und Fairness.

Risikomanagement für bestimmte Gruppen (Artikel 9(8), (9))

Artikel 9(8) verlangt, dass beim Testen von Hochrisiko-KI-Systemen besonders berücksichtigt wird, ob das System wahrscheinlich von Kindern oder anderen schutzbedürftigen Gruppen genutzt wird oder sie betrifft. Artikel 9(9) erweitert die Pflicht auf den Entwicklungsprozess selbst und verlangt, dass das Risikomanagement-System die spezifischen Bedürfnisse und Merkmale der vorgesehenen Nutzer berücksichtigt, einschließlich ihres technischen Wissens, ihrer Erfahrung und möglicher Schwächen.

Das hat praktische Folgen:

  • KI-Systeme in der Bildung müssen Risiken bewerten, die spezifisch für die kognitive Entwicklung von Kindern, ihre Anfälligkeit für Manipulation und den Datenschutz sind (siehe unseren AI-Act-Leitfaden zur Compliance in der Bildung).
  • KI-Systeme im Gesundheitswesen müssen Risiken bewerten, die spezifisch für Patienten sind, einschließlich schutzbedürftiger Gruppen wie älterer Menschen, Menschen mit Behinderungen und Menschen mit geringer Gesundheitskompetenz.
  • KI-Systeme in der Beschäftigung müssen Risiken für Gruppen bewerten, die in Einstellungsprozessen strukturelle Nachteile erfahren können.

Testdatensätze und -szenarien müssen so gestaltet sein, dass sie diese bestimmten Gruppen widerspiegeln, nicht nur den "durchschnittlichen" Nutzer.

Der Risikomanagement-Lebenszyklus

Artikel 9 beschreibt einen kontinuierlichen, fortlaufenden Prozess. In der Praxis lässt sich dieser Prozess in fünf Phasen gliedern, die auf den KI-Lebenszyklus abgestimmt sind. Die folgende Tabelle fasst jede Phase und ihren Bezug zu den Anforderungen von Artikel 9 zusammen.

PhaseLebenszyklusstufeBezug zu Artikel 9Kernaktivitäten
1. RisikoidentifizierungVor-Entwicklung und Design9(2)(a)Bekannte und vorhersehbare Risiken für Gesundheit, Sicherheit und Grundrechte identifizieren
2. Risikoanalyse und -bewertungEntwicklung9(2)(a), 9(2)(b)Wahrscheinlichkeit und Schwere abschätzen; Risiken aus bestimmungsgemäßer Nutzung und vorhersehbarer Fehlanwendung bewerten
3. Risikobehandlung und -minderungVor dem Einsatz9(2)(d), 9(3)Minderungsmaßnahmen gestalten, umsetzen und testen; Wechselwirkungen berücksichtigen
4. Restrisiko-BewertungEinsatz9(4)Akzeptanz des Restrisikos für jede Gefahr und das Gesamtsystem beurteilen
5. Marktbeobachtung und RückkopplungBetrieb9(2)(c)Betriebsdaten sammeln; in einen neuen Zyklus der Risikoidentifizierung einspeisen

Phase 1, Risikoidentifizierung (Vor-Entwicklung)

Bevor eine einzige Zeile Code geschrieben oder ein Trainingsdatensatz ausgewählt wird, legt die Phase der Risikoidentifizierung die Risikolandschaft fest. Zu den Aktivitäten gehören:

  • Kontextanalyse. Was ist die Zweckbestimmung des KI-Systems? Wer sind die vorgesehenen Nutzer? Wer sind die betroffenen Personen? In welchem Umfeld wird das System betrieben?
  • Regulatorische Zuordnung. Welche branchenspezifischen Vorschriften gelten zusätzlich zum AI Act? (z. B. MDR für Medizinprodukte, CRD für Kredit-Scoring, DSGVO für personenbezogene Daten). Siehe unsere EU-AI-Act-Compliance-Checkliste für einen umfassenden Überblick.
  • Gefahrenidentifizierung. Welche Kategorien von Schaden könnte das System verursachen? Auswirkungen auf Gesundheit und Sicherheit, Auswirkungen auf Grundrechte (Diskriminierung, Privatsphäre, Meinungsfreiheit), wirtschaftliche Auswirkungen, Umweltauswirkungen.
  • Konsultation von Interessenträgern. Beziehen Sie Fachexperten, potenzielle Nutzer, betroffene Gemeinschaften und Rechtsberatung ein, um Risiken aufzudecken, die interne Teams möglicherweise nicht vorhersehen.

Phase 2, Risikoanalyse und -bewertung (Entwicklung)

Während der Entwicklung werden die identifizierten Risiken vertieft analysiert:

  • Wahrscheinlichkeitsabschätzung. Wie wahrscheinlich ist es, dass jedes Risiko eintritt? Stützen Sie dies auf technische Analyse, empirische Tests, historische Daten vergleichbarer Systeme und Experteneinschätzung.
  • Schwereabschätzung. Wenn das Risiko eintritt, wie schwer wäre die Auswirkung? Berücksichtigen Sie sowohl das wahrscheinlichste als auch das schlimmste Szenario.
  • Risikoeinstufung. Kombinieren Sie Wahrscheinlichkeit und Schwere zu einem Risikoniveau (siehe die Risikomatrix im nächsten Abschnitt).
  • Analyse der vorhersehbaren Fehlanwendung. Gehen Sie über die bestimmungsgemäße Nutzung hinaus und modellieren Sie, wie Nutzer das System missbrauchen könnten. Welche Anreize für Missbrauch gibt es? Welche Folgen?

Phase 3, Risikobehandlung und -minderung (vor dem Einsatz)

Für jedes Risiko, das die definierte Risikoakzeptanz-Schwelle überschreitet, gestalten und setzen Sie Minderungsmaßnahmen um:

  • Beseitigung. Kann das Risiko durch Änderung des Systemdesigns vollständig beseitigt werden? (z. B. Entfernen einer Funktion, die ein nicht zu rechtfertigendes Risiko schafft)
  • Reduktion. Kann das Risiko auf ein akzeptables Niveau reduziert werden? (z. B. Hinzufügen einer Eingabevalidierung, Beschränken von Ausgaben, Einführen von Konfidenzschwellen)
  • Übertragung. Kann das Risiko auf eine Stelle übertragen werden, die besser gerüstet ist, es zu steuern? (z. B. Verlangen einer menschlichen Prüfung für Entscheidungen oberhalb einer bestimmten Konfidenzschwelle, mit direktem Bezug zu den Anforderungen an die menschliche Aufsicht nach Artikel 14)
  • Beobachtung. Kann bei Risiken, die nicht beseitigt oder hinreichend reduziert werden können, eine kontinuierliche Beobachtung erkennen, wann sie sich zu manifestieren beginnen?

Entscheidend ist, dass Artikel 9(3) von Ihnen verlangt, Wechselwirkungen zwischen Minderungsmaßnahmen zu berücksichtigen. Das Hinzufügen einer Konfidenzschwelle kann falsch positive Ergebnisse reduzieren, aber falsch negative erhöhen. Das Hinzufügen einer menschlichen Prüfung kann automatisierte Fehler reduzieren, aber menschlichen Bias einführen. Dokumentieren Sie diese Zielkonflikte.

Phase 4, Restrisiko-Bewertung (Einsatz)

Bewerten Sie vor dem Einsatz das Restrisiko, also das Risiko, das nach allen Minderungsmaßnahmen verbleibt:

  • Individuelles Restrisiko. Wie hoch ist für jede identifizierte Gefahr das verbleibende Risikoniveau nach der Minderung?
  • Gesamtes Restrisiko. Wie sieht unter Berücksichtigung aller Gefahren zusammen, einschließlich der Wechselwirkungen, das gesamte Restrisikoprofil des Systems aus?
  • Akzeptanzurteil. Ist das Restrisiko akzeptabel, gemessen am Nutzen des Systems, am Stand der Technik und an den gesellschaftlichen Erwartungen?
  • Kommunikation. Alle Restrisiken müssen dokumentiert und den Betreibern über die Betriebsanleitung mitgeteilt werden, wie es Artikel 13 verlangt.

Phase 5, Marktbeobachtung und Rückkopplung (Betrieb)

Sobald das System in Betrieb ist, setzt sich der Risikomanagement-Zyklus fort:

  • Leistungsbeobachtung. Verfolgen Sie zentrale Leistungskennzahlen anhand der im Risikomanagement-Plan definierten Metriken und Schwellenwerte.
  • Vorfallverfolgung. Erfassen und analysieren Sie Vorfälle, Beinahe-Vorfälle, Nutzerbeschwerden und Anomalien.
  • Datenanalyse. Nutzen Sie Daten aus der Marktbeobachtung, um Risikoabschätzungen zu bestätigen oder zu revidieren. Treten Risiken mit der erwarteten Häufigkeit und Schwere ein?
  • Rückkopplungsschleife. Speisen Sie Erkenntnisse zurück in Phase 1 und lösen Sie einen neuen Zyklus der Risikoidentifizierung aus. Dies ist der Mechanismus, durch den Artikel 9(2)(c) erfüllt wird.

Für ausführliche Anleitungen zur Einrichtung von Systemen zur Marktbeobachtung siehe unseren Leitfaden zu Marktbeobachtung und Meldung von Vorfällen.

Risikoidentifizierung und -analyse in der Praxis

Bekannte Risiken vs. vorhersehbare Risiken

Bekannte Risiken sind in der akademischen Literatur dokumentiert, während Tests beobachtet, aus früheren Versionen gemeldet oder durch regulatorische Leitlinien und harmonisierte Normen identifiziert worden. Vernünftigerweise vorhersehbare Risiken wurden in Ihrem konkreten System noch nicht beobachtet, können aber auf Grundlage der Architektur, der Daten und des Einsatzkontexts des Systems vorhergesehen werden, Risiken, die eine fachkundige Person angesichts des aktuellen Wissens erwarten würde.

Der Maßstab ist "vernünftigerweise vorhersehbar", nicht "jedes denkbare Risiko". Von Ihnen wird nicht erwartet, dass Sie Schwarze-Schwan-Ereignisse vorhersagen, aber Sie müssen das Maß an Voraussicht anwenden, das ein sorgfältiger Anbieter walten lassen würde.

Bestimmungsgemäße Nutzung vs. vernünftigerweise vorhersehbare Fehlanwendung

Während die bestimmungsgemäße Nutzung einfach ist (der dokumentierte Zweck, für den das System ausgelegt ist), erfordert die vernünftigerweise vorhersehbare Fehlanwendung eine kreativere Analyse. Häufige Missbrauchsmuster sind:

  • Übermäßiges Vertrauen, KI-Empfehlungen als endgültige Entscheidungen zu behandeln.
  • Scope Creep, das System über seinen vorgesehenen Umfang hinaus zu nutzen (z. B. ein Screening-Tool auf eine andere Population anzuwenden).
  • Feindliche Manipulation, Eingaben zu gestalten, die Systemschwächen ausnutzen.
  • Umgehung von Sicherungen, Sicherheitsfunktionen zugunsten von Durchsatz oder Bequemlichkeit zu deaktivieren.

Dokumentieren Sie sowohl Szenarien der bestimmungsgemäßen Nutzung als auch der vorhersehbaren Fehlanwendung, mit entsprechenden Risiken und Minderungsmaßnahmen für jedes.

Techniken zur Risikoidentifizierung

Keine einzelne Technik ist ausreichend. Beste Praxis kombiniert mehrere Ansätze:

TechnikBeschreibungAm besten geeignet für
Fehlermöglichkeits- und Einflussanalyse (FMEA)Jede Komponente und Funktion des KI-Systems systematisch untersuchen, um zu ermitteln, wie sie ausfallen könnte und welche Auswirkungen dieser Ausfall hätteTechnische Ausfallmodi, Risiken auf Komponentenebene
BedrohungsmodellierungPotenzielle Angreifer, Angriffsvektoren und gefährdete Werte identifizierenSicherheitsrisiken, feindliche Manipulation, Datenvergiftung
SzenariotestsKonkrete Anwendungsfall-Szenarien entwickeln, einschließlich Grenzfällen und Belastungsbedingungen, und das Systemverhalten bewertenVorhersehbare Fehlanwendung, betriebliche Risiken, Grenzfälle
Stakeholder-WorkshopsStrukturierte Sitzungen mit Fachexperten, Nutzern, betroffenen Personen und Aufsichtsbehörden, um Risiken aus mehreren Perspektiven aufzudeckenAuswirkungen auf Grundrechte, nutzerspezifische Risiken, bereichsspezifische Gefahren
LiteraturrechercheVeröffentlichte Forschung, Vorfalldatenbanken und regulatorische Leitlinien zu Risiken vergleichbarer KI-Systeme sichtenBekannte Risiken, Benchmarking am Stand der Technik
Red TeamingFeindliches Testen durch ein unabhängiges Team, das damit beauftragt ist, Schwachstellen und Ausfallmodi zu findenSicherheitslücken, Robustheitsschwächen, Bias-Erkennung

Risikomatrix, Wahrscheinlichkeit vs. Schwere

Eine Risikomatrix bietet einen strukturierten Rahmen zur Einstufung identifizierter Risiken. Auch wenn der AI Act kein bestimmtes Matrixformat vorschreibt, ist eine 5×5-Matrix weit verbreitet:

Vernachlässigbare SchwereGeringe SchwereMittlere SchwereGroße SchwereKatastrophale Schwere
Fast sicherMittelHochHochKritischKritisch
WahrscheinlichNiedrigMittelHochHochKritisch
MöglichNiedrigMittelMittelHochHoch
UnwahrscheinlichNiedrigNiedrigMittelMittelHoch
SeltenNiedrigNiedrigNiedrigMittelMittel

Als "Hoch" oder "Kritisch" eingestufte Risiken müssen dokumentierte Minderungsmaßnahmen haben. "Mittlere" Risiken sollten Minderungsmaßnahmen oder eine begründete Rechtfertigung für die Akzeptanz haben. Berücksichtigen Sie bei der Bewertung der Schwere alle Auswirkungsdimensionen: Gesundheit und Sicherheit (körperlicher/psychischer Schaden), Grundrechte (Diskriminierung, Verletzung der Privatsphäre, Verweigerung eines fairen Verfahrens), wirtschaftlich (finanzieller Verlust, Verweigerung von Diensten) und gesellschaftlich (Erosion von Vertrauen, systemische Diskriminierung).

Restrisiko, die am meisten missverstandene Anforderung

Was "akzeptables" Restrisiko bedeutet

Artikel 9(4) verlangt, dass das Restrisiko "als akzeptabel beurteilt" wird. Diese Formulierung sorgt für mehr Verwirrung als jede andere in Artikel 9, weil die Verordnung "akzeptabel" nicht mit einer klaren Grenze definiert. Das ist Absicht, die Akzeptanz hängt vom Kontext ab.

Das Urteil über die Akzeptanz umfasst die Abwägung von:

  1. Dem Restrisiko selbst. Wie hoch sind die verbleibende Wahrscheinlichkeit und Schwere eines Schadens, nachdem die Minderungsmaßnahmen angewandt wurden?
  2. Dem Nutzen des KI-Systems. Welche positiven Ergebnisse liefert das System für Nutzer, betroffene Personen und die Gesellschaft? Je größer der Nutzen, desto mehr Restrisiko kann tolerierbar sein.
  3. Dem Stand der Technik. Welche Risikoniveaus sind mit aktueller Technologie erreichbar? Wenn Ihr System ein Restrisiko aufweist, das mit verfügbaren Techniken reduziert werden könnte, die Sie nicht umgesetzt haben, ist dieses Risiko schwerer zu rechtfertigen.
  4. Den gesellschaftlichen Erwartungen. Welches Risikoniveau erwarten und tolerieren Menschen und Aufsichtsbehörden für diese Art von Anwendung? Höhere Erwartungen bestehen für Systeme, die schutzbedürftige Gruppen oder Grundrechte betreffen.
  5. Den verfügbaren Alternativen. Gibt es alternative Ansätze, einschließlich Nicht-KI-Ansätze, die denselben Nutzen mit geringerem Risiko erreichen?

Nutzen gegen Risiken abwägen

Die Abwägung ist nicht rein mathematisch, sie erfordert ein dokumentiertes, durch Belege gestütztes Urteil. Für jedes Restrisiko: (1) das Risikoniveau nach der Minderung dokumentieren, (2) erklären, warum es nicht weiter reduziert werden kann, (3) die Nutzen dokumentieren, die die Akzeptanz rechtfertigen, (4) mit dem Stand der Technik und den harmonisierten Normen vergleichen und (5) das endgültige Akzeptanzurteil mit Begründung und Identität des Entscheidungsträgers festhalten.

Dokumentationsanforderungen

Die Restrisiko-Bewertung muss Teil der technischen Dokumentation nach Anhang IV sein, einschließlich: eines Risikoregisters mit Niveaus vor und nach der Minderung, Beschreibungen jeder Minderungsmaßnahme und ihrer Wirksamkeit, Restrisiko-Aussagen je Gefahr, einer Gesamtbewertung des Systems, des Akzeptanzurteils mit Begründung und der Qualifikationen der Entscheidungsträger.

Kommunikation an die Betreiber

Restrisiken müssen den Betreibern über die Betriebsanleitung (Artikel 13) mitgeteilt werden und Folgendes abdecken: Art und Niveau der Restrisiken, Bedingungen, unter denen Risiken erhöht sein können, empfohlene Maßnahmen auf Betreiberebene und Nutzungsbeschränkungen. Betreiber müssen diese Informationen bei ihrer Grundrechte-Folgenabschätzung und ihren Maßnahmen zur menschlichen Aufsicht berücksichtigen.

Testanforderungen nach Artikel 9

Vor dem Inverkehrbringen und über den gesamten Lebenszyklus

Das Testen nach Artikel 9 ist kein Tor, das Sie einmal passieren. Artikel 9(7) legt fest, dass das Testen "zu jedem Zeitpunkt während des Entwicklungsprozesses und in jedem Fall vor dem Inverkehrbringen oder der Inbetriebnahme" durchgeführt werden muss. Das bedeutet:

  • Während der Entwicklung: Schrittweises Testen, während das System gebaut, trainiert und verfeinert wird.
  • Vor der Freigabe: Umfassende Validierungstests gegen den vollständigen Satz vordefinierter Metriken und Schwellenwerte.
  • Nach dem Einsatz: Laufendes Testen, ausgelöst durch Systemaktualisierungen, Änderungen des Betriebsumfelds oder Erkenntnisse aus der Marktbeobachtung.

Gegen vorab definierte Metriken

Artikel 9(6) verlangt Tests "gegen vorab definierte Metriken und probabilistische Schwellenwerte". Sie können nicht Tests durchführen und im Nachhinein schmeichelhafte Metriken auswählen, Metriken und Bestanden/Nicht-bestanden-Schwellen müssen im Risikomanagement-Plan definiert werden, bevor das Testen beginnt. "Genauigkeit über 90 %" ist ein Schwellenwert; "gute Genauigkeit" ist keiner.

Häufige Metriken sind:

Metrik-KategorieBeispiele
LeistungGenauigkeit, Präzision, Trefferquote (Recall), F1-Wert, AUC-ROC
FairnessDemografische Parität, ausgeglichene Quoten, prädiktive Parität über geschützte Gruppen hinweg
RobustheitLeistung unter Distribution Shift, feindlicher Störung, verrauschter Eingabe
ZuverlässigkeitKonsistenz der Ausgaben, Fehlerrate, mittlere Betriebsdauer zwischen Ausfällen
Latenz und VerfügbarkeitAntwortzeit, Betriebszeit, kontrollierte Degradation unter Last

Für eine vertiefte Betrachtung von Fairness-Metriken und Bias-Tests siehe unseren Leitfaden zu KI-Bias-Tests und Fairness.

Tests unter realen Bedingungen

Labortests auf kuratierten Datensätzen sind notwendig, aber nicht ausreichend. Tests unter realen Bedingungen sollten vielfältige Eingabedaten umfassen, die tatsächliche Populationen widerspiegeln, während der Risikoidentifizierung erkannte Grenzfälle, betriebliche Belastungen (hohes Volumen, verrauschte Daten) und Variabilität im Nutzerverhalten über erfahrene und unerfahrene Nutzer hinweg.

Spezifische Tests für Kinder und schutzbedürftige Gruppen

Wenn ein System wahrscheinlich Kinder oder schutzbedürftige Gruppen betrifft, verlangt Artikel 9(8) eigene Testdatensätze, die diese Populationen repräsentieren, spezifische Leistungsmetriken, die separat gemessen werden (nicht nur im Aggregat), szenariobasierte Tests, die simulieren, wie schutzbedürftige Nutzer mit dem System interagieren, und eine Folgenabschätzung, die anerkennt, dass derselbe Fehler für ein Kind schwerwiegendere Folgen haben kann als für einen Erwachsenen.

Artikel 9 zu ISO 42001 und NIST AI RMF zuordnen

Organisationen, die ISO/IEC 42001 oder das NIST AI Risk Management Framework anstreben, werden erhebliche Überschneidungen mit Artikel 9 finden. Auf bestehenden Rahmenwerken aufzubauen, reduziert den Aufwand und vermeidet Lücken. Siehe unseren Framework-Crosswalk für eine umfassende Zuordnung.

Zuordnung zu ISO 42001, Abschnitt 6.1

ISO/IEC 42001 (Norm für KI-Managementsysteme) adressiert Risiko über Abschnitt 6.1, Maßnahmen zum Umgang mit Risiken und Chancen. Die Zuordnung:

Anforderung aus Artikel 9ISO-42001-AbschnittAnmerkungen
Risikomanagement-System einrichten (9(1))6.1.1, AllgemeinesISO 42001 verlangt, Risiken und Chancen zu bestimmen, die zu behandeln sind
Risiken identifizieren und analysieren (9(2)(a))6.1.2, KI-RisikobewertungISO 42001 verlangt einen systematischen Prozess zur KI-Risikobewertung
Risikobehandlungsmaßnahmen (9(2)(d))6.1.3, KI-RisikobehandlungISO 42001 verlangt die Auswahl und Umsetzung von Optionen zur Risikobehandlung
Restrisiko (9(4))6.1.3, RisikoakzeptanzISO 42001 verlangt die Akzeptanz des Restrisikos durch das zuständige Management
Kontinuierliche Iteration (9(1))9.1, Überwachung, Messung, Analyse, BewertungISO 42001 verlangt eine laufende Überwachung und Überprüfung des Managementsystems
Tests (9(5), (7))8.4, Prozesse des KI-SystemlebenszyklusISO 42001 adressiert Verifizierung und Validierung von KI-Systemen

Zentrale Lücke: ISO 42001 verlangt Tests gegen vordefinierte Metriken und probabilistische Schwellenwerte nicht so spezifisch, wie es Artikel 9(6) tut. Organisationen, die sich allein auf ISO 42001 stützen, müssen ihren Testrahmen ergänzen, um die präskriptiven Anforderungen von Artikel 9 zu erfüllen.

Für einen vollständigen Leitfaden zur Umsetzung von ISO 42001 siehe unseren ISO-42001-Zertifizierungsleitfaden.

NIST AI RMF, Funktionen GOVERN und MAP

Das NIST AI Risk Management Framework gliedert das Risikomanagement in vier Funktionen: GOVERN, MAP, MEASURE und MANAGE. Die Zuordnung zu Artikel 9:

Anforderung aus Artikel 9NIST-AI-RMF-FunktionNIST-Kategorie
RMS einrichten und aufrechterhalten (9(1))GOVERNGV-1 (Richtlinien), GV-3 (Prozesse)
Risikoidentifizierung (9(2)(a))MAPMP-2 (Systemeigenschaften), MP-3 (Nutzen und Kosten), MP-5 (Auswirkungscharakterisierung)
Vorhersehbare Fehlanwendung (9(2)(b))MAPMP-3 (Auswirkungen), MP-5 (Missbrauchscharakterisierung)
Risikomaßnahmen (9(2)(d))MANAGEMG-1 (Minderung), MG-2 (Risikoreaktion)
Tests (9(5), (7))MEASUREMS-1 (Test und Bewertung), MS-2 (Leistungsverfolgung)
Rückkopplung aus der Marktbeobachtung (9(2)(c))MANAGEMG-3 (Beobachtung nach dem Einsatz)

Zentrale Lücke: Das NIST AI RMF ist ein freiwilliges Rahmenwerk und schreibt keine spezifischen Dokumentationsanforderungen vor. Organisationen, die das NIST AI RMF als Grundlage nutzen, müssen sicherstellen, dass ihre Dokumentation die präskriptiven Anforderungen von Artikel 9 und Anhang IV erfüllt.

Effizienz eines kombinierten Ansatzes

Für Organisationen, die sowohl im EU- als auch im US-Markt tätig sind: Nutzen Sie ISO 42001 als Rückgrat des Managementsystems (Plan-Do-Check-Act-Governance), NIST AI RMF für die Methodik der Risikoidentifizierung (Unterkategorien der MAP-Funktion) und legen Sie die Spezifika von Artikel 9 obenauf (vordefinierte Metriken mit probabilistischen Schwellenwerten, ausdrückliche Akzeptanzurteile zum Restrisiko, Tests für schutzbedürftige Populationen und Dokumentation nach Anhang IV). Das vermeidet Doppelarbeit und stellt zugleich die Compliance mit allen drei Rahmenwerken sicher. Für eine detaillierte Zuordnung siehe unseren Framework-Crosswalk-Leitfaden.

Ihr Risikomanagement-System aufbauen, Schritt für Schritt

Die folgenden sieben Schritte bieten einen praktischen Fahrplan für die Compliance mit Artikel 9. Lesen Sie sie gemeinsam mit unserem Leitfaden zum KI-Governance-Rahmen.

Schritt 1, Umfang und Kontext definieren

Bevor Sie Risiken analysieren, definieren Sie die Grenzen des Risikomanagement-Systems:

  • Beschreibung des KI-Systems. Was tut das System? Was sind seine Eingaben, Ausgaben und seine Zweckbestimmung?
  • Vorgesehene Nutzer. Wer wird das System bedienen? Wie sind ihr Schulungsstand und ihre Fachkenntnis?
  • Betroffene Personen. Wer ist von den Ausgaben des Systems betroffen? Sind betroffene Personen schutzbedürftig?
  • Einsatzkontext. In welchem Umfeld, welcher Geografie und welchem regulatorischen Kontext wird das System betrieben?
  • Systemgrenzen. Wo endet das KI-System und wo beginnt sein Betriebsumfeld? Welche vor- und nachgelagerten Systeme interagieren mit ihm?

Dokumentieren Sie diesen Umfang in einem Risikomanagement-Plan, dem übergeordneten Dokument, das alle nachfolgenden Risikomanagement-Aktivitäten steuert.

Schritt 2, Risikokriterien und Schwellenwerte festlegen

Legen Sie die Kriterien fest, die zur Bewertung und Einstufung von Risiken genutzt werden:

  • Schema zur Risikoeinstufung. Definieren Sie Risikoniveaus (z. B. Niedrig, Mittel, Hoch, Kritisch) und die Kriterien für jedes Niveau.
  • Wahrscheinlichkeitsskala. Definieren Sie, was "selten", "unwahrscheinlich", "möglich", "wahrscheinlich" und "fast sicher" im Kontext Ihres Systems bedeuten, mit quantitativen Bereichen, wo machbar.
  • Schwereskala. Definieren Sie Schwereniveaus für jede Auswirkungskategorie (Gesundheit, Sicherheit, Grundrechte, wirtschaftlich).
  • Akzeptanzschwellen. Definieren Sie das Risikoniveau, ab dem eine Minderung verpflichtend ist, und das Niveau, ab dem ein System nicht eingesetzt werden darf.
  • Metrik-Schwellenwerte. Definieren Sie die Metriken für Leistung, Fairness und Robustheit sowie ihre Bestanden/Nicht-bestanden-Schwellen, wie es Artikel 9(6) verlangt.

Schritt 3, Workshop zur Risikoidentifizierung durchführen

Bringen Sie ein funktionsübergreifendes Team zusammen, Data Scientists, Ingenieure, Fachexperten, Rechtsberatung, Ethiker und Nutzervertreter, um Risiken mit FMEA, Bedrohungsmodellierung, Szenariotests und Literaturrecherche systematisch zu identifizieren. Das Ergebnis ist ein Risikoregister, das jedes identifizierte Risiko mit seiner Beschreibung, Quelle, Kategorie und ersten Bewertung dokumentiert. Strukturierte Workshops sollten die Ausfallmodi jeder Systemkomponente, Szenarien der bestimmungsgemäßen Nutzung und der Fehlanwendung sowie populationsspezifische Risiken für schutzbedürftige Gruppen abdecken.

Schritt 4, Risiken analysieren und bewerten

Für jedes Risiko im Register:

  • Schätzen Sie die Wahrscheinlichkeit anhand der verfügbaren Belege (technische Analyse, Testdaten, Literatur, Experteneinschätzung).
  • Schätzen Sie die Schwere für jede Auswirkungskategorie.
  • Wenden Sie die Risikomatrix an, um das Risikoniveau zu bestimmen.
  • Priorisieren Sie Risiken für die Behandlung anhand des Risikoniveaus und der in Schritt 2 festgelegten Risikoakzeptanz-Schwellen.

Dokumentieren Sie die Analysemethodik, die Datenquellen, die Annahmen und die Unsicherheiten für jedes Risiko. Diese Dokumentation ist wesentlich für die technische Dokumentation nach Anhang IV und für die Verteidigung Ihrer Risikoanalyse gegenüber Aufsichtsbehörden.

Schritt 5, Minderungsmaßnahmen gestalten

Für jedes Risiko, das die Akzeptanzschwelle überschreitet:

  • Identifizieren Sie mögliche Maßnahmen. Sammeln Sie mehrere potenzielle Minderungsmaßnahmen.
  • Bewerten Sie die Wirksamkeit. Schätzen Sie für jede mögliche Maßnahme, wie stark sie das Risiko reduziert.
  • Bewerten Sie die Machbarkeit. Berücksichtigen Sie technische Machbarkeit, Kosten, Auswirkung auf die Systemleistung und Wechselwirkung mit anderen Maßnahmen.
  • Wählen Sie Maßnahmen. Wählen Sie die Kombination von Maßnahmen, die das Risiko unter Berücksichtigung der Wechselwirkungen am wirksamsten auf ein akzeptables Niveau reduziert.
  • Definieren Sie Umsetzungsanforderungen. Legen Sie für jede Maßnahme fest, was gebaut, konfiguriert, dokumentiert oder kommuniziert werden muss.

Schritt 6, Umsetzen und dokumentieren

Bauen Sie Maßnahmen in das System ein (Eingabevalidierung, Ausgabebeschränkungen, Konfidenzschwellen, Bias-Minderung, Auslöser für menschliche Prüfung) und richten Sie unterstützende betriebliche Prozesse ein (Aufsichtsverfahren, Meldung von Vorfällen, Überprüfungszyklen). Aktualisieren Sie den Risikomanagement-Plan, das Risikoregister, die technische Dokumentation und die Betriebsanleitung. Die Dokumentation muss ausreichen, damit eine benannte Stelle oder Marktüberwachungsbehörde die Angemessenheit bewerten kann.

Schritt 7, Beobachten und iterieren

Setzen Sie nach dem Einsatz Telemetrie, Protokollierung, Nutzerfeedback und Meldung von Vorfällen um. Analysieren Sie die Daten regelmäßig anhand vordefinierter Metriken und Schwellenwerte. Definieren Sie Auslöser für Ad-hoc-Überprüfungen (Überschreitung von Schwereschwellen, Nichtbestehen von Metriken, Systemaktualisierungen, regulatorische Änderungen). Aktualisieren Sie das Risikoregister mit neu identifizierten Risiken und revidierten Abschätzungen und speisen Sie die Erkenntnisse zurück in Schritt 3, um eine neue Iteration zu beginnen.

Praktische Checkliste

Nutzen Sie diese Checkliste, um die Vollständigkeit Ihres Risikomanagement-Systems zu überprüfen:

  • Risikomanagement-Plan mit Umfang, Governance, Methodik und Überprüfungszyklus dokumentiert
  • Risikokriterien und Akzeptanzschwellen festgelegt, bevor die Risikoanalyse beginnt
  • Bekannte Risiken aus Literatur, Tests und früheren Versionen identifiziert
  • Vorhersehbare Risiken durch strukturierte Analyse identifiziert
  • Szenarien der bestimmungsgemäßen Nutzung auf Risiken analysiert
  • Szenarien der vorhersehbaren Fehlanwendung auf Risiken analysiert
  • Risikomatrix mit dokumentierten Wahrscheinlichkeits- und Schwereabschätzungen angewandt
  • Minderungsmaßnahmen für alle Risiken oberhalb der Akzeptanzschwelle gestaltet, bewertet und umgesetzt
  • Wechselwirkungen zwischen Minderungsmaßnahmen bewertet
  • Restrisiko für jede Gefahr und das Gesamtsystem bewertet
  • Akzeptanz des Restrisikos beurteilt und mit Begründung dokumentiert
  • Tests gegen vordefinierte Metriken und probabilistische Schwellenwerte durchgeführt
  • Tests unter realen oder simulierten realen Bedingungen durchgeführt
  • Auswirkungen auf schutzbedürftige Populationen, wo zutreffend, spezifisch getestet
  • Restrisiken den Betreibern in der Betriebsanleitung mitgeteilt
  • System zur Marktbeobachtung eingerichtet und in das Risikomanagement einspeisend
  • Überprüfungs- und Aktualisierungszyklus definiert und betriebsbereit
  • Alle Aktivitäten gemäß den Anforderungen von Anhang IV dokumentiert

Häufig gestellte Fragen

Wie unterscheidet sich Artikel 9 von einer herkömmlichen Risikobewertung?

Eine herkömmliche Risikobewertung ist eine Übung zu einem bestimmten Zeitpunkt. Artikel 9 verlangt einen kontinuierlichen, fortlaufenden Prozess, der den gesamten KI-Lebenszyklus umspannt und aufrechterhalten und aktualisiert wird, während sich das System weiterentwickelt, neue Risiken aus Daten der Marktbeobachtung entstehen und sich das Betriebsumfeld ändert.

Gilt Artikel 9 für KI-Modelle mit allgemeinem Verwendungszweck (GPAI)?

Artikel 9 gilt für Hochrisiko-KI-Systeme (Artikel 6-7), nicht unmittelbar für GPAI-Modelle (geregelt in Kapitel V). Wird ein GPAI-Modell jedoch in ein Hochrisiko-System integriert, muss der Anbieter dieses Systems die durch das GPAI eingeführten Risiken nach Artikel 9 abdecken. Siehe unseren Leitfaden zu GPAI-Pflichten.

Was passiert, wenn das Restrisiko als inakzeptabel eingestuft wird?

Das System darf nicht in Verkehr gebracht werden. Sie müssen möglicherweise das System neu gestalten, seinen Umfang begrenzen, Sicherungen hinzufügen oder das Produkt aufgeben. Benannte Stellen werden bewerten, ob das Urteil über das Restrisiko vertretbar ist.

Wie oft muss das Risikomanagement-System aktualisiert werden?

Artikel 9(1) verlangt eine "regelmäßige systematische Aktualisierung", ohne eine Häufigkeit festzulegen. Beste Praxis: Definieren Sie einen Überprüfungszyklus (jährlich oder halbjährlich) mit Ad-hoc-Überprüfungen, die durch Systemaktualisierungen, Vorfälle, regulatorische Änderungen, Umgebungsverschiebungen oder Erkenntnisse aus der Marktbeobachtung ausgelöst werden.

Kann ich ISO 14971 (Medizinprodukte) als Grundlage nutzen?

Ja, mit Ergänzungen. Der Lebenszyklusansatz und die Nutzen-Risiko-Analyse von ISO 14971 spiegeln Artikel 9 eng wider, aber die Norm adressiert keine KI-spezifischen Risiken wie Bias, Distribution Shift oder Auswirkungen auf Grundrechte über Gesundheit und Sicherheit hinaus. Siehe unseren Leitfaden zur Compliance im Gesundheitswesen.

Wie hoch ist die Sanktion bei Nichteinhaltung von Artikel 9?

Bußgelder von bis zu 15 Millionen EUR oder 3 % des weltweiten Jahresumsatzes, zuzüglich einer möglichen Rücknahme oder eines Rückrufs nicht konformer Systeme vom EU-Markt. Siehe unseren Leitfaden zu Sanktionen.

Nächste Schritte

Ein nach Artikel 9 konformes Risikomanagement-System aufzubauen, ist umfangreich, muss aber nicht bei null beginnen, Risikoregister, Testrahmen und Dokumentationsprozesse lassen sich aus bestehenden Qualitäts- und Risikomanagement-Systemen anpassen.

Beginnen Sie hier:

  1. Stellen Sie fest, ob Ihr System hochriskant ist. Nutzen Sie unser AI-Act-Bewertungstool, um Ihre KI-Systeme einzustufen und die anwendbaren Pflichten zu ermitteln.
  2. Erfassen Sie Ihren aktuellen Stand. Vergleichen Sie Ihre bestehenden Risikomanagement-Praktiken mit der obigen Checkliste und ermitteln Sie Lücken.
  3. Bauen Sie Ihren Governance-Rahmen auf. Richten Sie die organisatorischen Strukturen, Rollen und Prozesse ein, die in unserem Leitfaden zum KI-Governance-Rahmen beschrieben sind.
  4. Richten Sie sich an Standards aus. Nutzen Sie ISO 42001 und NIST AI RMF, um die Umsetzung zu beschleunigen. Unser Framework-Crosswalk zeigt Ihnen genau, wie sie sich zuordnen.
  5. Dokumentieren Sie fortlaufend. Nutzen Sie unsere Vorlage für die technische Dokumentation nach Anhang IV, um sicherzustellen, dass Ihre Risikomanagement-Dokumentation die regulatorischen Anforderungen erfüllt.

Die Frist am 2. August 2026 rückt näher. Der Zeitpunkt, Ihr Risikomanagement-System aufzubauen, ist jetzt.

AI Act
Risikomanagement
Artikel 9
Hochrisiko-KI
Compliance
Risikobewertung
KI-Lebenszyklus