RisikoKI-Risiken beurteilen und tragen.
KI-Risiken werden mit der bestehenden Risikomethode beurteilt, ergänzt um KI-typische Schadensarten. Die Seite zeigt Risikoappetit und Schwellen für KI, eine Methode entlang NIST AI RMF, Threat Modeling mit Schichtenmodell, Behandlungsoptionen, Auslöser für die Neubeurteilung und ein Risikoszenario-Blatt als Vorlage.
Rechtsstand: 11. Oktober 2026. AI Act Art. 9 gilt für Hochrisiko-KI-Systeme; EU-Recht, für Schweizer Unternehmen nur bei EU-Bezug nach Art. 2 AI Act anwendbar.
Eine Methode,
mehr Schadensarten.
KI-Risiken gehören ins bestehende Risikoregister und werden mit derselben Skala für Eintrittswahrscheinlichkeit und Schadenausmass bewertet wie andere Informationsrisiken. Neu sind nicht Methode und Gremien, sondern die Szenarien: Ein Modell kann fehlerhaft antworten, ohne dass jemand angreift. Ein Anbieter kann sein Modell wechseln, ohne dass ein Change-Prozess greift. Ein Agent kann Rechte nutzen, die niemand bewusst vergeben hat.
Die Bedrohungen selbst sind auf der Seite Bedrohungslandschaft beschrieben. Diese Seite zeigt, wie daraus bewertete Risiken werden.
Der AI Act verlangt in Art. 9 für Hochrisiko-KI-Systeme ein Risikomanagementsystem als kontinuierlichen, iterativen Prozess über den gesamten Lebenszyklus (Abs. 1, 2). Die Massnahmen sind so zu gestalten, dass das Gesamtrestrisiko als vertretbar beurteilt wird (Abs. 5). Pflichtadressat der Anforderung ist der Anbieter (Art. 16 Bst. a). Für alle anderen Systeme ist die Methode eine Empfehlung, die sich an Art. 9 anlehnen kann.
Das NIST AI RMF versteht sich als Ergänzung bestehender Risikopraktiken. Es schreibt keine Risikotoleranz vor, empfiehlt aber, dass Organisationen ohne sektorale Vorgaben eine angemessene Toleranz selbst festlegen (AI 100-1, Abschn. 1.2.2).
Das Risikoregister
erweitern.
NIST AI 600-1 beschreibt zwölf Risiken, die durch generative KI entstehen oder verstärkt werden. Sie stehen mit Unternehmensbezug in der Bedrohungslandschaft und werden hier nicht wiederholt. Für das Register genügt eine grobere Sicht. Die folgenden Schadensarten sind eine Empfehlung von STOP.LI und ergänzen die klassischen Schutzziele.
| Schadensart | Typisches Szenario | Üblicher Ort im Register |
|---|---|---|
| Fehlentscheid | Falsche oder erfundene Ausgabe fliesst ungeprüft in einen Geschäftsprozess. | Operationelles Risiko |
| Vertraulichkeitsverlust | Vertrauliche Daten gelangen in Prompts, Modelle oder Protokolle Dritter. | Informationsrisiko |
| Integritätsverlust | Manipulierte Wissensdaten, Modelle oder Anweisungen verändern Ergebnisse. | Informationsrisiko |
| Ausfall und Abhängigkeit | Anbieter stellt Modell ein oder ändert es; es gibt keine Rückfalllösung. | Drittparteien- und Kontinuitätsrisiko |
| Rechts- und Regulierungsverstoss | Einsatz ohne Rechtsgrundlage, ohne Transparenz oder ausserhalb der Zweckbestimmung. | Compliance-Risiko |
| Auswirkung auf Personen | Benachteiligung, Fehlbehandlung oder Eingriff in Grundrechte durch automatisierte Ergebnisse. | Compliance- und Reputationsrisiko, siehe Folgenabschätzungen |
| Kontrollverlust bei Agenten | Agent führt Aktionen mit zu weitreichenden Rechten aus, siehe Agenten und MCP. | Informations- und operationelles Risiko |
NIST weist darauf hin, dass manche GAI-Risiken unbekannt und andere schwer schätzbar sind, auch wegen fehlender Einsicht in Trainingsdaten (AI 600-1, Abschn. 1). Unsicherheit der Schätzung gehört deshalb ins Szenario-Blatt.
Schwellen
für KI festlegen.
Der Risikoappetit für KI wird von der obersten Leitung festgelegt und dokumentiert. Das NIST AI RMF sieht vor, dass organisationsweite Risikotoleranzen bestimmt und dokumentiert sind (MAP 1.5) und dass die Leitung Verantwortung für Risikoentscheide übernimmt (GOVERN 2.3). Wer entscheidet, regelt die RACI-Vorlage auf der Seite Governance und Programm. Das Muster unten ist eine Empfehlung. Zahlenwerte setzt jede Organisation selbst.
| Stufe | Merkmale des Einsatzes (Beispiele) | Entscheidung über Restrisiko |
|---|---|---|
| Niedrig | Interne Entwurfshilfe, keine vertraulichen Daten, Mensch prüft jede Ausgabe. | AI-Owner |
| Mittel | Zugriff auf interne Daten, Ausgaben fliessen in Fachprozesse, Anbieter ausserhalb des eigenen Betriebs. | AI-Owner mit CISO |
| Hoch | Kundendaten oder Personendaten, Wirkung auf Personen, Aktionen durch Agenten, kritische Funktion. | KI-Ausschuss |
| Nicht tragbar | Von der Leitung ausgeschlossene Einsätze, zum Beispiel verbotene Praktiken nach Art. 5 AI Act oder Einsatz ohne mögliche Rückfalllösung bei kritischer Funktion. | Nicht freigebbar, Ausnahme nur durch Leitung |
Die Stufen entsprechen der Einstufung im KI-Inventar. Je Stufe werden Schwellen für Schadenausmass und Eintrittswahrscheinlichkeit festgelegt, ab denen eine Behandlung zwingend ist. Zusätzlich gilt eine Obergrenze für das Gesamtrestrisiko aller KI-Systeme, damit viele kleine Restrisiken nicht unbemerkt summiert werden.
Von Szenario
zu Entscheid.
Das NIST AI RMF liefert die Abfolge: MAP ordnet Kontext und Auswirkungen ein, MEASURE wählt Messmethoden, MANAGE priorisiert und behandelt. Die Schritte lassen sich in den ISMS-Prozess 02 Risiko einhängen.
| Schritt | Inhalt | NIST AI RMF |
|---|---|---|
| 1 Kontext | Zweck, Nutzer, Daten, Komponenten und Drittanbieter aus dem Inventar übernehmen; Risikotoleranz festhalten. | MAP 1.1, 1.5, 4.1 |
| 2 Szenarien | Bedrohungen und Schadensarten zu konkreten Szenarien verbinden (Threat Modeling, nächster Abschnitt). | MAP 4, MAP 5 |
| 3 Bewertung | Wahrscheinlichkeit und Ausmass jeder Auswirkung auf Basis erwarteter Nutzung, früherer Einsätze und öffentlicher Vorfälle schätzen und dokumentieren. | MAP 5.1 |
| 4 Messen | Methoden und Kennzahlen wählen, beginnend mit den bedeutendsten Risiken. Nicht Gemessenes dokumentieren. Sicherheit und Resilienz prüfen. | MEASURE 1.1, 2.6, 2.7 |
| 5 Behandeln | Behandlung nach Auswirkung, Wahrscheinlichkeit und Mitteln priorisieren; Restrisiko dokumentieren und gegen Appetit prüfen. | MANAGE 1.2 bis 1.4 |
Quantitative Analyse als Option. Für Risiken oberhalb der Stufe Mittel lohnt es sich, Häufigkeit und Schadenhöhe als Bandbreiten zu schätzen statt als Ampel. Das macht Entscheide über Massnahmen und Versicherung vergleichbar. Die Schätzungen sind bei KI besonders unsicher und werden mit Quelle und Konfidenz angegeben. Werkzeuge: Cyber Risk Quantification und Integrierte GRC-Plattformen. Die Darstellung für die Leitung zeigt der Management Risk Report.
Szenarien
je Schicht.
Die Cloud Security Alliance beschreibt mit MAESTRO ein Threat-Modeling-Verfahren für agentische KI. Es vergleicht zunächst STRIDE, PASTA, LINDDUN, OCTAVE, Trike und VAST und zeigt, wo sie bei agentischer KI an Grenzen stossen. Klassische Methoden bleiben ein sinnvoller Ausgangspunkt. MAESTRO ergänzt sie um ein Referenzmodell mit sieben Schichten und um schichtübergreifende Bedrohungen. Wahrscheinlichkeit und Auswirkung werden anschliessend mit der vorhandenen Risikomatrix bewertet.
| Schicht (MAESTRO) | Leitfrage fürs Szenario (Empfehlung) |
|---|---|
| 1 Foundation Models | Welches Modell, welche Version, wer kann es ändern? |
| 2 Data Operations | Woher stammen Trainings-, Wissens- und Kontextdaten, wer kann sie verändern? |
| 3 Agent Frameworks | Welche Bibliotheken, Werkzeuge und Orchestrierung sind eingebunden? |
| 4 Deployment and Infrastructure | Wo läuft das System, welche Netz- und Identitätsgrenzen gelten? |
| 5 Evaluation and Observability | Woran wird eine Fehlfunktion erkannt, wer sieht Protokolle? |
| 6 Security and Compliance | Welche Kontrollen greifen schichtübergreifend, wer prüft sie? |
| 7 Agent Ecosystem | Mit welchen Nutzern, Agenten und Diensten interagiert das System? |
Schichtübergreifend nennt MAESTRO unter anderem Supply-Chain-Angriffe, Lateral Movement, Rechteausweitung, Datenabfluss und sich ausbreitende Zielabweichung. Ein Szenario beschreibt deshalb auch den Weg über mehrere Schichten, nicht nur die Schwachstelle in einer.
Vier Optionen,
konkret.
Das NIST AI RMF nennt als Reaktionen auf hoch priorisierte Risiken Mindern, Übertragen, Vermeiden und Akzeptieren (MANAGE 1.3). Es sieht zudem vor, die Entscheidung zu dokumentieren, ob ein System seinen Zweck erreicht und ob Entwicklung oder Einsatz weitergehen sollen (MANAGE 1.1).
| Option | Beispiele bei KI | Voraussetzung |
|---|---|---|
| Mindern | Rechte des Agenten beschränken, Ausgaben vor Weitergabe prüfen, Wissensquellen freigeben, Modellversion fixieren. | Wirksamkeit nachweisbar, siehe Testing und Red Teaming |
| Übertragen | Vertragliche Zusicherungen und Haftung beim Anbieter, Versicherung prüfen. | Vertrag trägt, Restrisiko bleibt beim Betreiber, siehe Lieferanten und Modelle |
| Vermeiden | Use Case nicht einführen, Funktion abschalten, auf nicht-KI-Alternative ausweichen. | Alternative bewertet (MANAGE 2.1 nennt nicht-KI-Alternativen) |
| Akzeptieren | Restrisiko bewusst tragen, zum Beispiel bei internem Entwurfswerkzeug. | Innerhalb des Appetits, Entscheid der zuständigen Ebene, Wiedervorlage |
Wann das Risiko
neu zu prüfen ist.
Art. 9 Abs. 2 AI Act verlangt eine regelmässige systematische Überprüfung und Aktualisierung. Bei KI genügt ein fester Zyklus nicht, weil sich das Risiko ohne eigenes Zutun ändern kann. Folgende Auslöser sind in den Change- und Vorfallsprozess einzubauen:
- Modellwechsel: neue Version, anderes Modell oder geänderte Konfiguration, auch durch den Anbieter.
- Neuer Zweck: Einsatz in einem anderen Prozess oder für andere Personengruppen.
- Neue Datenquelle: zusätzliche Wissens-, Trainings- oder Kontextdaten, neue Schnittstelle.
- Anbieteränderung: neue Unterauftragnehmer, Standorte, Vertragsbedingungen.
- Vorfall oder Beinahe-Vorfall: beim eigenen System oder bei vergleichbaren Systemen.
- Neue Rechtslage: neuer Rechtsakt oder neue Aufsichtspublikation, Fristen im Fristenkalender.
Risikoszenario-Blatt, ein Blatt je Szenario. Das Blatt steht unter CC BY 4.0 und darf angepasst werden.
| Feld | Inhalt |
|---|---|
| Kennung, System | Eintrag im KI-Inventar, AI-Owner |
| Szenario | Auslöser, Weg (Schichten), betroffener Wert, Ergebnis |
| Schadensart | Aus dem Register oben |
| Wahrscheinlichkeit, Ausmass | Wert oder Bandbreite, Quelle, Unsicherheit |
| Bestehende Kontrollen | Mit Wirksamkeitsnachweis |
| Restrisiko, Stufe | Gegen Appetit und Schwelle geprüft |
| Behandlung | Option, Massnahme, Verantwortliche, Termin |
| Entscheid | Wer, wann, bis wann gültig |
| Auslöser Neubeurteilung | Ereignisse aus der Liste |
Schweiz, FINMA-Aufsichtsmitteilung 08/2024. Die FINMA erwartet, dass sich Beaufsichtigte mit den Auswirkungen von KI auf ihr Risikoprofil auseinandersetzen und Governance, Risikomanagement und Kontrollsysteme danach ausrichten. Zu berücksichtigen sind insbesondere die Wesentlichkeit der Anwendungen und die Eintrittswahrscheinlichkeit der Risiken (Kap. 1). Unter Kap. 2.2 beurteilte sie, ob die Beaufsichtigten KI ausreichend breit definieren, weil klassische Anwendungen ähnliche Risiken aufweisen können und gleiche Risiken gleich zu adressieren sind (Fussnote 7). Sie beurteilte auch Vorhandensein und Vollständigkeit der Inventare sowie die Risikoklassifizierung. Die Kriterien dazu legen die Beaufsichtigten selbst fest (Fussnote 5). KI ist laut FINMA nicht per se hochriskant. Das Risiko hängt von Komplexität, Adaptivität, Autonomie, Anwendungsbereich und Prozessintegration ab (Fussnote 7). Zur Einstufung siehe auch KI-Inventar und Klassifizierung.
Deutschland, BaFin. Die unverbindliche Orientierungshilfe zu IKT-Risiken beim Einsatz von KI (18.12.2025) bewertet KI-Systeme analog zu allgemeinen IKT-Systemen nach Risikoprofil, Komplexität und unterstützten Funktionen (Kap. II.1). Sie sind in den IKT-Risikomanagementrahmen einzubeziehen, einschliesslich der Ermittlung von Schwachstellen in Training, Datenpipelines und Inferenz und der Bewertung quantitativer und qualitativer Risikokriterien (Kap. II.3, Art. 8 DORA). Der Rahmen ist mindestens jährlich zu überprüfen (Art. 6 Abs. 5 DORA). Erkenntnisse aus Vorfällen sind in den Risikobewertungsprozess von KI-Systemen zu übernehmen (Kap. IV.1, Art. 13 Abs. 3 DORA).
Die 4T2 Solutions GmbH, Herausgeberin von STOP.LI, unterstützt bei der Beurteilung von KI-Risiken und beim Festlegen des Risikoappetits. Ausgangspunkt ist eine konkrete Entscheidung oder ein kontrollierter Pilot.
- Verordnung (EU) 2024/1689 (AI Act), Art. 2, 5, 9, 16 (EU, 13.06.2024); Art. 9 unverändert in der konsolidierten Fassung vom 27.07.2026
- NIST AI 100-1, AI Risk Management Framework 1.0, Abschn. 1.2.2, GOVERN 2.3, MAP 1.1, 1.5, 4.1, 5.1, MEASURE 1.1, 2.6, 2.7, MANAGE 1.1 bis 1.4, 2.1 (NIST, 01/2023)
- NIST AI 600-1, Generative AI Profile, Abschn. 1 und 2 (NIST, 07/2024)
- Agentic AI Threat Modeling Framework: MAESTRO (Cloud Security Alliance, 06.02.2025)
- FINMA-Aufsichtsmitteilung 08/2024, Governance und Risikomanagement beim Einsatz Künstlicher Intelligenz, Kap. 1 und 2.2 (FINMA, 18.12.2024)
- Orientierungshilfe zu IKT-Risiken beim Einsatz von KI in Finanzunternehmen, Kap. II.1, II.3, IV.1 (BaFin, 18.12.2025)
- Verordnung (EU) 2022/2554 (DORA), Art. 6 Abs. 5, Art. 8, Art. 13 Abs. 3 (EU, 14.12.2022)
Zitierte Fremdinhalte unterliegen der Lizenz ihrer Herausgeber. Die Seite ist eine Orientierung, keine Rechtsberatung.
© 2026 4T2 Solutions GmbH. Text und eigene Diagramme stehen unter CC BY 4.0.