Monitoring und Incident Response | STOP.LI

STOP.LI · AI Security · Technik und Betrieb

VorfälleKI-Vorfälle erkennen und bewältigen.

KI-Vorfälle beginnen selten mit einem Alarm, sondern mit einer Abweichung. Diese Checkliste zeigt Schwellen für probabilistisches Verhalten, Signale und Protokolle, Detection-Use-Cases nach MITRE ATLAS, Rollen im IR-Team, vier Kurz-Playbooks, eine Meldepflichten-Matrix für EU, Deutschland und Schweiz sowie Fallback und Rollback.

Rechtsstand: 12. Oktober 2026. AI Act in der Fassung der Verordnung (EU) 2026/1744. EU-Recht, für Schweizer Unternehmen nur bei EU-Bezug nach Art. 2 AI Act anwendbar.

ISMS-Prozess: 19 Monitoring · 20 Incident · 22 Kontinuität · 23 Wiederanlauf · 25 Verbesserung
Begriff

Wann ist es
ein Vorfall?

Ein KI-System liefert nie exakt dieselbe Antwort. Ein einzelner Fehler ist deshalb noch kein Vorfall. Ein KI-Vorfall liegt vor, wenn ein Angriff, eine Fehlfunktion oder ein Fehlgebrauch Vertraulichkeit, Integrität, Verfügbarkeit, Rechte von Personen oder Geschäftsentscheide beeinträchtigt oder beeinträchtigen kann. Der AI Act definiert zusätzlich den «schwerwiegenden Vorfall» (Art. 3 Nr. 49): Tod oder schwere Gesundheitsschädigung, schwere und unumkehrbare Störung kritischer Infrastruktur, Verletzung von Grundrechtspflichten sowie schwere Sach- oder Umweltschäden.

Schwellen festlegen

Je KI-System vor Inbetriebnahme schriftlich festhalten: Basislinie (Qualität, Ablehnungsquote, Kosten, Latenz), tolerierte Abweichung, Schwelle für Ticket, Schwelle für Vorfall. Sicherheitsereignisse wie erfolgreiche Prompt Injection, Abfluss vertraulicher Daten oder unautorisierte Agentenaktionen sind immer Vorfälle, unabhängig von Häufigkeit.

Beobachtbarkeit

Signale, Basislinien,
Protokolle.

Art. 12 AI Act verlangt, dass Hochrisiko-KI-Systeme Ereignisse über den Lebenszyklus automatisch protokollieren können. Für alle anderen KI-Systeme ist dieselbe Protokollierung gute Praxis. Ohne Protokolle lässt sich ein Vorfall weder eingrenzen noch melden.

Signal Quelle Basislinie und Auffälligkeit
Eingaben und Systemprompt LLM Gateway Muster bekannter Injection-Varianten, ungewöhnlich lange oder kodierte Eingaben, Treffer der Guardrails
Ausgaben Gateway, Ausgabefilter Personendaten, Geheimnisse, interne URLs, Abweichung vom Antwortformat
Abrufe aus Wissensquellen (RAG) Vektordatenbank, Retrieval-Protokoll Zugriff auf Dokumente ausserhalb der Berechtigung, neu eingespielte Dokumente mit hoher Trefferquote
Agenten- und Tool-Aufrufe Agenten-Laufzeit, MCP-Gateway Neue Tools, Aufrufe ausserhalb der Freigabe, Ketten ohne menschliche Bestätigung
Modellqualität und Drift Evaluations-Pipeline Sinkende Trefferquote auf Referenzfragen, veränderte Verteilung der Eingaben, Wechsel der Modellversion (Details im nächsten Abschnitt)
Nutzung und Kosten Gateway, Abrechnung Abfragespitzen pro Schlüssel, systematische Abfragen über den ganzen Eingaberaum

Protokolle enthalten oft Personendaten. Aufbewahrung, Zugriff und Maskierung gehören in die Datenkontrollen. Die Signale fliessen ins SIEM; der Gateway-Kontrollpunkt ist in der Architektur-Referenz beschrieben. Werkzeugklassen: SIEM, Detection Engineering, Incident Response, Digital Forensics, Business Continuity Management; die Klasse AI Runtime Security liefert die Laufzeitdaten.

Drift

Veränderung
über die Zeit.

Drift entsteht schleichend: Ein KI-System, das bei der Abnahme gut entschieden hat, kann Monate später schlechter entscheiden, obwohl am eigenen Code nichts geändert wurde. Die Welt um das System ändert sich, oder der Anbieter ändert das Modell. Das NIST AI RMF verlangt deshalb, Funktion und Verhalten eines KI-Systems im Betrieb zu überwachen (MEASURE 2.4); die FINMA beurteilt bei Beaufsichtigten, ob Veränderungen der Eingabedaten überwacht werden (Aufsichtsmitteilung 08/2024, Kap. 2.4).

Art Was sich ändert Erkennung Reaktion
Datendrift Die Eingaben verschieben sich: neue Themen, Sprachen, Formate oder Kundengruppen Eingabeverteilung mit der Basislinie vergleichen, bei strukturierten Daten etwa mit dem Population Stability Index, bei Texten über Themen- oder Embedding-Verteilungen Ursache klären, Referenzfragen ergänzen, Qualität nachmessen
Konzeptdrift Die richtige Antwort auf dieselbe Eingabe ändert sich: neue Produkte, Regeln, Betrugsmuster oder Rechtslage Trefferquote gegen geprüfte Ergebnisse, Anteil manueller Korrekturen, Beschwerden Nachtrainieren, Regeln oder Wissensquelle anpassen, erneute Abnahme
Modellwechsel beim Anbieter Ein gehostetes Modell wird aktualisiert, ersetzt oder abgekündigt; bei gleichem Prompt ändert sich das Verhalten Modellversion je Aufruf protokollieren; Referenztest nach jeder Änderung und in festen Abständen Version fest vorgeben, wo möglich; Wechsel wie ein eigenes Release abnehmen
Wissensdrift (RAG) Dokumente in den Wissensquellen veralten oder widersprechen sich Alter und Herkunft der abgerufenen Dokumente, Trefferquote auf Referenzfragen Pflegeprozess mit Verantwortlichen und Ablaufdatum je Dokument

Voraussetzung ist eine Basislinie aus der Abnahme: Referenzfragen mit erwarteten Antworten, die Eingabeverteilung und die Qualitätsmasse. Gemessen wird in festen Abständen und nach jeder Änderung. Eine Abweichung über der tolerierten Grenze löst ein Ticket aus, eine Abweichung über der Vorfallschwelle einen Vorfall mit Fallback oder Rollback. Schwellen und Kennzahlen stehen in Kennzahlen und Reporting, die Regressionstests in Testing und Red Teaming.

Detection

Use Cases
nach MITRE ATLAS.

Die Technik-IDs stammen aus MITRE ATLAS (Datenstand v2026.09). Die vollständige Zuordnung von Bedrohungen steht in der Bedrohungslandschaft.

Use Case ATLAS Erkennungslogik
Direkte und indirekte Prompt Injection AML.T0051, AML.T0051.001 Guardrail-Treffer, Anweisungsmuster in Dokumenten oder Webinhalten, Wechsel der Rolle in der Antwort
Jailbreak AML.T0054 Wiederholte Ablehnungen gefolgt von Erfolg im selben Kontext
Vergiftung von Trainings- oder Wissensdaten AML.T0020, AML.T0070 Änderungen an Datenquellen ohne Change, Qualitätsabfall nach Datenimport
Datenabfluss über Ausgaben AML.T0057 DLP-Treffer auf Modellausgaben, Ausgaben mit Inhalten aus fremden Mandanten
Abfluss über Agenten-Tools AML.T0086 Tool-Aufrufe an externe Ziele mit Daten aus dem Kontext
Modell-Extraktion AML.T0024.002 Hohe, gleichmässig verteilte Abfragevolumen pro Konto, Abfrage von Wahrscheinlichkeitswerten
Dienstverweigerung und Kostenmissbrauch AML.T0029, AML.T0034 Token- und Kostenspitzen, lange Antwortketten
Rollen

Das IR-Team
um KI ergänzen.

NIST SP 800-61 Rev. 3 (April 2025) richtet Incident Response an den sechs Funktionen des CSF 2.0 aus. Govern, Identify und Protect bereiten vor, sind aber nicht Teil der Vorfallbehandlung selbst. Detect, Respond und Recover bilden die Vorfallbehandlung. Erkenntnisse fliessen jederzeit über die Kategorie Improvement (ID.IM) zurück, nicht erst nach Abschluss.

  • Leitung: entscheidet über einschneidende Massnahmen, etwa das Abschalten eines KI-Dienstes.
  • Incident Handler: bestätigen den Vorfall, sichern Beweise, priorisieren, grenzen ein.
  • Technik: Plattform, Cloud, Entwicklung, Gateway-Betrieb.
  • Recht, Kommunikation, HR: Meldepflichten, Medien, Mitarbeitende.
  • Asset Owner: setzen Prioritäten für Wiederherstellung. Für KI ergänzt um AI-Owner (Use Case, Abschaltentscheid), Modellverantwortung (Version, Evaluation, Rollback) und Datenverantwortung (Trainings- und Wissensdaten, Bereinigung).
  • Dritte: Modellanbieter und Dienstleister; Pflichten und Befugnisse vertraglich regeln, siehe Lieferanten und Modelle.
Betreiberpflichten

Was der AI Act
im Betrieb verlangt.

Pflicht Inhalt Grundlage
Überwachen Betrieb anhand der Betriebsanleitung überwachen, Anbieter gegebenenfalls informieren Art. 26 Abs. 5 UAbs. 1 Satz 1
Aussetzen Bei Grund zur Annahme eines Risikos nach Art. 79 Abs. 1 unverzüglich Anbieter oder Händler und Marktüberwachungsbehörde informieren und die Verwendung aussetzen Art. 26 Abs. 5 UAbs. 1 Satz 2
Vorfall weitergeben Schwerwiegenden Vorfall unverzüglich zuerst dem Anbieter, dann Einführer oder Händler und Marktüberwachungsbehörden melden; ist der Anbieter nicht erreichbar, gilt Art. 73 entsprechend Art. 26 Abs. 5 UAbs. 1 Satz 3 und 4
Protokolle aufbewahren Automatisch erzeugte Protokolle, soweit unter eigener Kontrolle, mindestens sechs Monate Art. 26 Abs. 6
Anbieter: Beobachtung nach dem Inverkehrbringen Leistungsdaten über die Lebensdauer systematisch erheben und auswerten, auf Basis eines Plans Art. 72

Die Pflichten gelten für Hochrisiko-KI-Systeme. Nach der Verordnung (EU) 2026/1744 gelten die Hochrisiko-Anforderungen später als ursprünglich vorgesehen; massgebende Daten im Fristenkalender DCH. Für andere KI-Systeme sind die Pflichten ein sinnvoller Massstab.

Playbooks

Vier Szenarien,
vier Abläufe.

Szenario Eindämmen Beheben Prüfen vor Freigabe
Prompt Injection (direkt oder über Dokumente, Mails, Webseiten) Betroffene Quelle sperren, Tool-Rechte des Agenten entziehen, Sitzungen beenden Quelle bereinigen, Guardrail-Regel ergänzen, Rechte nach Minimalprinzip neu setzen Regressionstest mit dem Angriffsmuster, Auswertung ausgeführter Aktionen
Data Poisoning (Training, Feinabstimmung, RAG) Datenimport stoppen, auf letzte geprüfte Modell- oder Indexversion zurück Verunreinigte Daten über Herkunftsnachweis identifizieren und entfernen, Index neu aufbauen oder neu trainieren Evaluation gegen Referenzdaten, Vergleich mit Basislinie
Datenabfluss über Ausgaben Ausgabefilter verschärfen, betroffene Funktion abschalten, Protokolle sichern Berechtigungen im Retrieval korrigieren, Daten aus Wissensquelle oder Kontext entfernen Datenschutzprüfung: betroffene Personen und Daten bestimmen, Meldepflicht prüfen
Modell-Extraktion Verdächtige Schlüssel sperren, Rate Limits senken, Wahrscheinlichkeitswerte nicht mehr ausgeben Zugang an Identität binden, Kontingente pro Konto, Überwachung von Abfragemustern Schadensbewertung: Wert des Modells, mögliche Folgeangriffe mit der Kopie

Vor jeder Änderung Beweise sichern: Prompts, Ausgaben, Modell- und Indexversion, Konfiguration. Für Hochrisiko-KI-Systeme verbietet Art. 73 Abs. 6 dem Anbieter Untersuchungen, die das System so verändern, dass die spätere Ursachenbewertung beeinträchtigt wird, bevor die Behörden unterrichtet sind. Vertiefung für Angriffe mit KI-Beschleunigung im SIGNAL-Beitrag KI verkürzt das Angriffsfenster.

Meldepflichten

Wer wem
wann meldet.

Regelung Auslöser Empfänger Frist
AI Act Art. 73 (EU) Schwerwiegender Vorfall mit Hochrisiko-KI-System, Pflicht des Anbieters Marktüberwachungsbehörde des Mitgliedstaats, in dem der Vorfall stattfand Spätestens 15 Tage nach Kenntnis; 2 Tage bei weitverbreitetem Verstoss oder kritischer Infrastruktur; 10 Tage bei Todesfall; unvollständiger Erstbericht zulässig
AI Act Art. 75 Abs. 1a (EU) Wie Art. 73, für Hochrisiko-Systeme in der Zuständigkeit des Büros für Künstliche Intelligenz (u. a. Systeme auf Basis eines eigenen KI-Modells mit allgemeinem Verwendungszweck) Büro für Künstliche Intelligenz Art. 73 Abs. 2 bis 9 sinngemäss
NIS2 Art. 23 (EU), in Deutschland § 32 BSIG Erheblicher Sicherheitsvorfall bei wesentlicher (DE: besonders wichtiger) oder wichtiger Einrichtung CSIRT oder Behörde; in Deutschland gemeinsame Meldestelle von BSI und BBK Frühwarnung 24 h, Meldung 72 h, Abschlussbericht einen Monat nach der Meldung
ISG Art. 74b bis 74e (CH) Cyberangriff auf kritische Infrastruktur, u. a. bei Gefährdung der Funktionsfähigkeit oder Abfluss oder Manipulation von Informationen BACS Innert 24 Stunden nach Entdeckung, Ergänzung bei neuen Informationen
DSG Art. 24 (CH) Verletzung der Datensicherheit mit voraussichtlich hohem Risiko für betroffene Personen EDÖB; betroffene Personen, wenn zu ihrem Schutz nötig oder vom EDÖB verlangt So rasch als möglich
DSGVO Art. 33 (EU) Verletzung des Schutzes personenbezogener Daten, ausser voraussichtlich ohne Risiko Zuständige Aufsichtsbehörde Möglichst binnen 72 Stunden nach Bekanntwerden

Ein einzelner KI-Vorfall kann mehrere Pflichten gleichzeitig auslösen. Die Matrix gehört ins Playbook, mit Namen und Erreichbarkeit der Meldenden. Einordnung der Regelwerke auf der Seite Regulierung DCH.

Kontinuität

Betrieb
ohne KI sichern.

Jedes KI-System mit Geschäftsrelevanz braucht einen geprüften Weg, die Arbeit ohne dieses System fortzusetzen. Die Massnahmen gehören in die bestehende Kontinuitäts- und Wiederanlaufplanung.

  • Fallback ohne KI: manueller oder regelbasierter Prozess, dokumentiert und jährlich geübt.
  • Abschaltschalter: KI-Funktion zentral deaktivierbar, ohne die Anwendung zu stoppen.
  • Modell-Rollback: fixierte Modellversionen, letzte geprüfte Version samt Systemprompt, Guardrails und Index wiederherstellbar.
  • Anbieter-Ausfall: Zweitmodell oder Zweitanbieter für kritische Use Cases geprüft, Exit im Vertrag geregelt.
  • Wiederanlaufzeit: RTO und RPO je KI-System festlegen, auch für Vektorindex und Prompt-Konfiguration.
Nach dem Vorfall

Lernen
und nachweisen.

Zusätzlich für Finanzinstitute

EU: DORA (VO (EU) 2022/2554) verlangt einen Prozess zur Erkennung, Behandlung und Meldung IKT-bezogener Vorfälle (Art. 17), deren Klassifizierung (Art. 18) und die Meldung schwerwiegender IKT-bezogener Vorfälle an die zuständige Behörde (Art. 19). KI-Vorfälle fallen darunter, wenn sie IKT-bezogen sind. Für Finanzinstitute als Betreiber gilt die Überwachungspflicht nach Art. 26 Abs. 5 AI Act als erfüllt, wenn die Governance-Vorschriften des Finanzmarktrechts eingehalten werden; Protokolle werden als Teil dieser Dokumentation aufbewahrt (Art. 26 Abs. 6 UAbs. 2). In Deutschland stellt die BaFin-Orientierungshilfe zu IKT-Risiken beim Einsatz von KI (18.12.2025) den DORA-Bezug her.

Schweiz: Nach FINMA-Aufsichtsmitteilung 05/2020 orientieren Beaufsichtigte die FINMA bei einer Cyber-Attacke innert 24 Stunden nach Entdeckung vor, einschliesslich einer Erstbeurteilung der Kritikalität, und reichen die vollständige Meldung innert 72 Stunden ein; die FINMA-Aufsichtsmitteilung 03/2024 präzisiert dieses Vorgehen.

AI Act Framework für Finanzinstitute

Unterstützung

Die 4T2 Solutions GmbH, Herausgeberin von STOP.LI, unterstützt beim Aufbau von Erkennung, Playbooks und Meldewegen für KI-Vorfälle. Ausgangspunkt ist eine konkrete Entscheidung oder ein kontrollierter Pilot.

Einordnung und Quellen

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.

Zurück zur Übersicht AI Security →