- Published on
Template: AI Risk Assessment nach Art. 9 EU AI Act
- Authors

- Name
- Tails Azimuth
Wofür
Dieses Template strukturiert das Risikomanagementsystem, das ein Hochrisiko-KI-System über seinen gesamten Lebenszyklus begleiten muss. Es dient Provider-Teams als wiederverwendbares Grundgerüst, um identifizierte Risiken, getroffene Maßnahmen und verbleibende Restrisiken nachvollziehbar zu dokumentieren. Das Artefakt ist bewusst als laufendes Dokument angelegt: Es wird nicht einmal ausgefüllt und abgelegt, sondern bei jeder relevanten Änderung am System, an den Daten oder am Einsatzkontext fortgeschrieben. Wer das Risk Assessment als Snapshot behandelt, erzeugt ein Dokument, das im Audit als veraltet auffällt.
Wann es Pflicht ist
Für Anbieter von Hochrisiko-KI-Systemen ist ein Risikomanagementsystem nach Art. 9 EU AI Act (Verordnung (EU) 2024/1689) verbindlich. Die Vorschrift verlangt einen kontinuierlichen, iterativen Prozess über den gesamten Lebenszyklus: Identifikation und Analyse bekannter und vernünftigerweise vorhersehbarer Risiken, Bewertung von Risiken aus der bestimmungsgemäßen Verwendung sowie aus vorhersehbarem Fehlgebrauch, und die Annahme geeigneter Risikomanagement-Maßnahmen. Art. 9 verzahnt sich dabei eng mit den Daten-Anforderungen (Art. 10), der technischen Dokumentation (Annex IV, Art. 11) und der menschlichen Aufsicht (Art. 14). Mit der Enforcement-Wirksamkeit zum 02.12.2027 muss dieser Prozess belegbar etabliert sein — nicht erst geplant.
Das Artefakt selbst
# AI Risk Assessment — <System-Name>
## 0. Metadaten
- System / Version:
- Verantwortliche Rolle (Provider / Deployer):
- Erstellt am / Letzte Revision:
- Verknüpfte Annex-IV-Doku:
- Risikoklasse (Verweis auf Klassifizierung):
## 1. System- und Zweckbeschreibung
- Bestimmungsgemäße Verwendung:
- Bekannter, vorhersehbarer Fehlgebrauch:
- Betroffene Personen / Gruppen:
- Einsatz-Rechtsraum (DE / EU27-Rest / UK / CH):
## 2. Risiko-Register
| ID | Risiko | Quelle | Betroffene | Eintritt (1-5) | Schwere (1-5) | Brutto-Score | Maßnahme | Rest-Score | Status |
|----|--------|--------|-----------|----------------|----------------|--------------|----------|-----------|--------|
| R-01 | | | | | | | | | |
## 3. Maßnahmen-Logik
- Eliminierung / Reduktion durch Design:
- Schutzmaßnahmen + Tests (Verweis):
- Information an Deployer (Verweis Art. 13):
## 4. Restrisiko-Bewertung
- Verbleibende Restrisiken (vertretbar? Begründung):
- Freigabe-Entscheidung + Verantwortliche:
## 5. Review-Zyklus
- Auslöser für Re-Assessment:
- Nächster geplanter Review:
Ausfüll-Anleitung
- Metadaten zuerst füllen — ohne Versions- und Revisionsstand ist jedes Risk Assessment im Audit wertlos. Verknüpfe die Annex-IV-Dokumentation explizit.
- Bestimmungsgemäße Verwendung eng fassen. Je präziser der Zweck, desto schärfer lässt sich vorhersehbarer Fehlgebrauch abgrenzen.
- Fehlgebrauch ernst nehmen. Art. 9 verlangt ausdrücklich die Betrachtung vernünftigerweise vorhersehbaren Fehlgebrauchs, nicht nur des Idealfalls.
- Risiken aus Sicht betroffener Personen denken, nicht nur aus technischer Systemperspektive — Grundrechte, Sicherheit, Gesundheit.
- Brutto vor Maßnahme, Netto nach Maßnahme. Beide Scores dokumentieren, damit die Wirkung jeder Maßnahme nachvollziehbar ist.
- Jede Maßnahme mit Evidenz verknüpfen (Testbericht, Datenqualitäts-Statement, Oversight-Konzept) statt sie nur zu behaupten.
- Restrisiko begründen, nicht verschweigen. Auditoren erwarten eine dokumentierte Abwägung, warum ein Restrisiko vertretbar ist.
- Review-Auslöser konkret benennen (Modell-Update, Datendrift, neuer Einsatzkontext, Vorfall) — das macht den iterativen Charakter nach Art. 9 belegbar.
Audit-Erwartung
Auditoren prüfen bei diesem Artefakt vor allem die Lebendigkeit des Prozesses: Gibt es eine Revisionshistorie, oder wirkt das Dokument wie einmalig erstellt? Sie gleichen das Risiko-Register gegen die technische Dokumentation und die Testberichte ab — behauptete Maßnahmen ohne hinterlegte Evidenz fallen auf. Geprüft wird außerdem, ob vorhersehbarer Fehlgebrauch ernsthaft behandelt wurde und ob die Restrisiko-Freigabe von einer benannten, dafür zuständigen Rolle getragen ist. Ein konsistenter Bezug zwischen Risikoklasse, Maßnahmen und Evidenz ist hier wichtiger als die Anzahl gelisteter Risiken.
Verwandte Artefakte
- Vorgelagert: die korrekte Risikoklassifizierung — siehe Risikostufen im Detail auf ki-risikostufe.de.
- Eng verzahnt: Datenqualitäts-Statement nach Art. 10 und Human-Oversight-Konzept nach Art. 14 (eigene Toolkit-Pages).
- Für den größeren regulatorischen Kontext und die Systematik der Provider-Pflichten: Leitfaden auf eu-ai-verordnung.de.
AEGIRA AI Guardian operationalisiert diese Artefakte als laufende Trust-Infrastructure — aegira.ai.