KI Incident Management: Betrieb unter Kontrolle

Ein KI-System kann im Test fachlich überzeugen und im Produktionsbetrieb dennoch zum Risiko werden. Wenn Antworten erkennbar falsche Inhalte liefern, ein Modell bestimmte Vorgänge systematisch anders bewertet oder sich die Qualität von Datenquellen verändert, reicht ein klassischer IT-Störungsprozess nicht aus. KI Incident Management schafft die notwendige Verbindung zwischen Betrieb, Fachbereich, Datenverantwortung, Informationssicherheit und Governance.

Dabei geht es nicht darum, jede unerwünschte Modellausgabe als Incident zu behandeln. Entscheidend ist eine belastbare Einordnung: Welche Auswirkung hat das Ereignis auf Geschäftsprozesse, Kunden, Beschäftigte, regulatorische Pflichten oder Entscheidungen? Wer darf den Betrieb einschränken, eine Datenquelle sperren oder ein Modell zurücksetzen? Und wie wird dokumentiert, dass die Ursache nachvollziehbar untersucht und die Maßnahme wirksam geprüft wurde?

Warum KI-Vorfälle anders gesteuert werden müssen

Klassisches Incident Management fokussiert häufig auf Verfügbarkeit, Performance, Zugriffsprobleme und technische Fehler. Diese Kategorien bleiben auch bei KI-Systemen relevant. Ein nicht erreichbarer Inference-Service, eine fehlerhafte Schnittstelle oder eine unzulässige Berechtigung sind eindeutig betriebliche Vorfälle. KI bringt jedoch zusätzliche Fehlerbilder mit, die sich nicht allein durch Monitoring von Infrastruktur und Anwendungen erkennen lassen.

Ein Modell kann verfügbar sein und dennoch unzutreffende oder nicht nachvollziehbare Ergebnisse erzeugen. Bei einem Prognosemodell kann sich die Datenverteilung schleichend verändern. Ein generatives System kann Informationen aus einer angebundenen Wissensbasis falsch gewichten oder Inhalte ausgeben, die nicht zur vorgesehenen Nutzung passen. Bei automatisierten Priorisierungen kann ein fachlich relevanter Bias sichtbar werden. Solche Ereignisse betreffen Datenqualität, Modellverhalten, Kontextgestaltung, Berechtigungen und Prozesse zugleich.

Die zentrale Frage lautet deshalb nicht nur: Ist das System technisch funktionsfähig? Sie lautet auch: Arbeitet es innerhalb des freigegebenen fachlichen und organisatorischen Rahmens? Dieser Rahmen muss vor dem produktiven Einsatz konkret definiert sein. Ohne Sollwerte, erlaubte Anwendungsfälle, Qualitätskriterien und Eskalationsgrenzen bleibt im Incident unklar, ob tatsächlich ein Fehler vorliegt oder lediglich eine erwartbare Modellunsicherheit.

KI Incident Management beginnt vor dem ersten Vorfall

Ein reaktionsfähiger Prozess entsteht nicht durch ein Ticketformular allein. Er beginnt mit einer Betriebs- und Governance-Struktur, die Zuständigkeiten für das gesamte KI-System festlegt. Dazu gehören nicht nur das Modell, sondern auch Datenquellen, Schnittstellen, Prompt- oder Retrieval-Komponenten, Benutzeroberflächen, Rollenmodelle und angebundene Geschäftsprozesse.

In der Praxis sollten Organisationen zunächst eine nachvollziehbare Servicebeschreibung erstellen. Sie hält fest, welchen Zweck das System erfüllt, welche Entscheidungen es unterstützt oder vorbereitet, welche Nutzergruppen betroffen sind und welche Grenzen für die Nutzung gelten. Ebenso wichtig sind konkrete Qualitäts- und Kontrollindikatoren. Bei einem Dokumentenassistenten können dies etwa die Quote fachlich beanstandeter Antworten, die Nutzung nicht freigegebener Quellen oder die Häufigkeit von Eskalationen sein. Bei einem Prognosemodell stehen eher Prognoseabweichungen, Datenvollständigkeit und Drift-Indikatoren im Vordergrund.

Diese Vorarbeit macht die Bewertung eines Ereignisses erheblich schneller. Meldet ein Fachbereich eine auffällige Ausgabe, lässt sich prüfen, ob ein definierter Grenzwert überschritten wurde, ob ein bekannter Ausnahmefall vorliegt oder ob eine neue Risikokonstellation entstanden ist. Das reduziert Ad-hoc-Entscheidungen in Situationen, in denen der operative Druck bereits hoch ist.

Meldewege müssen fachliche Beobachtungen aufnehmen

Viele KI-Vorfälle werden nicht zuerst durch technische Überwachung erkannt, sondern durch Anwenderinnen und Anwender. Deshalb brauchen Fachbereiche einfache, eindeutig zuordenbare Meldewege. Eine Meldung sollte mindestens den betroffenen Prozess, den Zeitpunkt, die Eingabekonstellation, die ausgegebene Antwort oder Entscheidung sowie die wahrgenommene Auswirkung enthalten. Bei sensiblen Daten ist dabei sicherzustellen, dass das Incident-Ticket selbst keine unzulässigen Inhalte reproduziert.

Eine strukturierte Meldung ersetzt keine Ursachenanalyse, schafft aber eine verwertbare Ausgangsbasis. Besonders bei nicht deterministischen oder kontextabhängigen Systemen ist die Reproduzierbarkeit entscheidend. Protokolle zu Modellversion, Datenstand, Systemkonfiguration, Zugriffskontext und relevanten Eingaben müssen daher entsprechend der Risikolage verfügbar sein. Fehlen diese Informationen, wird aus einer gezielten Untersuchung schnell eine langwierige Rekonstruktion.

Schweregrad nach Auswirkung statt nach Bauchgefühl bestimmen

Nicht jede Abweichung verlangt dieselbe Reaktion. Ein sinnvoller Schweregrad orientiert sich an der tatsächlichen oder möglichen Auswirkung, nicht allein an der technischen Auffälligkeit. Ein einzelner unpräziser Textvorschlag in einem rein unterstützenden Prozess ist anders zu bewerten als eine fehlerhafte Priorisierung im Kundenservice, eine unzulässige Datenverarbeitung oder eine falsche Empfehlung in einem sicherheitsrelevanten Umfeld.

Für die Einstufung haben sich vier Blickwinkel bewährt: die Auswirkung auf Menschen und Geschäftsprozesse, der Umfang der betroffenen Entscheidungen oder Datensätze, die Dauer beziehungsweise Wiederholbarkeit des Ereignisses sowie die Frage, ob regulatorische oder vertragliche Pflichten berührt sind. Je nach Ergebnis kann eine Beobachtung ausreichen, eine fachliche Korrektur erforderlich sein oder der kontrollierte Rückfall auf einen manuellen Prozess notwendig werden.

Der Rückfallmechanismus ist oft der unterschätzte Teil des KI-Betriebs. Wer ein KI-System abschalten oder einschränken kann, ohne dass ein kritischer Prozess stehen bleibt, gewinnt Zeit für eine saubere Analyse. In SAP-nahen Abläufen kann das beispielsweise bedeuten, dass Vorschläge des Systems nicht mehr automatisch weiterverarbeitet werden und wieder einer definierten manuellen Prüfung unterliegen. Diese Option sollte im Cutover, in Betriebsübergaben und in Notfalltests berücksichtigt werden.

Ursachenanalyse: Modell, Daten oder Prozess?

Nach der Stabilisierung beginnt die Ursachenanalyse. Sie darf nicht vorschnell beim Modell enden. In vielen Fällen liegt die Ursache in einer veränderten Datenquelle, einer fehlerhaften Transformation, einer unklaren fachlichen Regel oder einer Schnittstelle, die Kontextinformationen nicht vollständig übergibt. Auch Rollen- und Berechtigungskonzepte können zu Fehlverhalten führen, wenn Nutzerinnen und Nutzer Informationen sehen oder verarbeiten lassen, die nicht für ihren Aufgabenbereich vorgesehen sind.

Eine belastbare Analyse trennt daher mehrere Ebenen: Datenherkunft und Datenqualität, technische Verarbeitung, Modell- und Konfigurationsstand, fachliche Anforderungen sowie Nutzung im Prozess. Bei generativen KI-Systemen gehören auch Systemanweisungen, Retrieval-Logik, Quellenfreigaben und Sicherheitsfilter dazu. Die Untersuchung muss zeigen, welche Hypothesen geprüft wurden, welche Evidenz vorliegt und warum die gewählte Abhilfemaßnahme angemessen ist.

Das Ergebnis ist mehr als eine Fehlerbehebung. Es sollte eine dokumentierte Entscheidung sein: Wurde eine Datenquelle korrigiert, eine Regel angepasst, eine Modellversion zurückgenommen, ein Prompt verändert oder ein Prozessschritt ergänzt? Anschließend ist zu prüfen, ob die Maßnahme die festgestellte Ursache adressiert und keine neuen Fehlerbilder erzeugt. Gerade bei Änderungen an produktiven KI-Systemen sind Regressionstests und klar freigegebene Übergaben unverzichtbar.

Reporting schafft Steuerbarkeit und prüfbare Verbesserungen

Ein einzelnes Ticket kann einen Vorfall schließen, aber kein Betriebsmodell verbessern. Erst die Auswertung über mehrere Ereignisse zeigt Muster: Wiederholen sich Fehler bei bestimmten Datenquellen? Sind einzelne Fachbereiche besonders stark betroffen? Dauert die Triage zu lange, weil Entscheidungsrechte ungeklärt sind? Oder entstehen Incidents vor allem nach Releases und Änderungen an Schnittstellen?

Ein revisionssicheres Reporting sollte daher nicht nur Anzahl und Bearbeitungszeit erfassen. Relevant sind auch Ursache, Auswirkung, angewandte Sofortmaßnahme, Eigentümer der dauerhaften Korrektur, Testnachweise und Termin zur Wirksamkeitskontrolle. Für Management und Governance-Gremien braucht es eine verdichtete Sicht auf Risiken und Trends. Operative Teams benötigen hingegen die Detailtiefe, um Datenflüsse, Konfigurationen und fachliche Regeln gezielt zu verbessern.

Wie weit die Dokumentation gehen muss, hängt vom Anwendungsfall, der Kritikalität und den geltenden Anforderungen ab. Bei Fragen zu EU AI Act, Datenschutz, NIS2 oder IT-rechtlicher Einordnung sollte die technische Incident-Dokumentation frühzeitig mit den zuständigen Compliance- und Rechtsfunktionen abgestimmt werden. Falls erforderlich, kann die rechtlich eigenständige Quteco Rechtsanwaltsgesellschaft mbH die rechtliche Bewertung übernehmen. Die operative Verantwortung für Stabilisierung, Analyse und technische Korrektur bleibt dabei klar im Projekt und Betrieb verankert.

KI Incident Management im laufenden Betrieb verankern

Die wirksamste Struktur ist diejenige, die im Arbeitsalltag genutzt wird. Deshalb sollte KI Incident Management an bestehende Service-Management-, Change- und Problem-Management-Prozesse anschließen, statt parallel dazu ein isoliertes Verfahren aufzubauen. Dennoch braucht es eigene Klassifikationen, Rollen und Prüfschritte für KI-spezifische Fehlerbilder.

In Transformationsprojekten empfiehlt sich, diese Anforderungen bereits in Testmanagement und Betriebsübergabe aufzunehmen. Testfälle sollten nicht nur technische Verfügbarkeit prüfen, sondern auch fachliche Grenzfälle, Datenqualität, Berechtigungsszenarien, Logging und Rückfallprozesse abdecken. Vor einem Go-Live muss nachvollziehbar sein, wer den Incident Lead stellt, wer fachliche Freigaben erteilt und wer über Einschränkungen des produktiven Einsatzes entscheidet.

Ein belastbarer Prozess verhindert keine Abweichungen. Er sorgt jedoch dafür, dass Organisationen Abweichungen früh erkennen, kontrolliert begrenzen und nachweisbar in Verbesserungen überführen. Genau darin liegt der Unterschied zwischen einem isolierten KI-Pilotprojekt und einem steuerbaren KI-Betrieb.

KI-Betrieb strukturiert absichern

Quteco unterstützt Unternehmen mit Quick Checks, Workshops und operativer Projektbegleitung dabei, Incident-Prozesse für KI-Anwendungen in bestehende Betriebs-, SAP-, Daten- und Governance-Strukturen einzubetten. Im Fokus stehen klare Verantwortlichkeiten, belastbare Datenflüsse, testbare Rückfallverfahren und eine Dokumentation, die im laufenden Betrieb nutzbar bleibt.