KI-Monitoring nach Go-live: Alarmwege praktisch prüfen

Überwachen Sie nach dem Go-live sowohl den technischen Ablauf als auch das fachliche Ergebnis Ihrer KI-Anwendung. Prüfen Sie anschließend den vollständigen Alarmweg: Wird ein Fehler erkannt, erreicht die Meldung die zuständige Stelle, und ist die nächste Maßnahme eindeutig?

Ein Dashboard beantwortet diese Fragen nicht automatisch. Auch fehlende Messdaten müssen sichtbar werden, damit ein ausgefallener Prüflauf keinen gesunden Zustand vortäuscht.

Die folgenden Tabellen und Beispiele sind eigene technische Empfehlungen. Die Konfiguration und die Zahlenbeispiele sind fiktiv; dafür wurden keine Tests an einem realen System durchgeführt.

Erreichbarkeit und fachlicher Erfolg getrennt messen

Ein erfolgreicher HTTP-Aufruf belegt nicht, dass die Anwendung die richtige Quelle verwendet oder eine Aufgabe korrekt erledigt hat. Googles SRE-Kapitel über Monitoring zählt ausdrücklich auch Antworten mit HTTP 200 und falschem Inhalt zu möglichen Fehlern. Es unterscheidet interne Messungen von Prüfungen des von außen sichtbaren Verhaltens.

Prüfebene	Beispiel	Was damit noch nicht belegt ist
Technischer Ablauf	Modellaufruf und Datenbankzugriff funktionieren.	Die Antwort ist fachlich richtig.
Ausführungsregeln	Erlaubte Werkzeuge und Parameter wurden verwendet.	Das Ergebnis löst die Aufgabe.
Fachliches Ergebnis	Erwarteter Wert und Quellenbeleg stimmen.	Alle übrigen Anfragen sind ebenfalls korrekt.
Überwachung selbst	Prüfläufe und Meldungen kommen an.	Die gewählten Prüfungen decken alle relevanten Fehler ab.

Die technische Bewertung einzelner Handlungspfade vertieft die Anleitung zur AI Agent Evaluation.

Mit einem Fehler beginnen, auf den jemand reagieren kann

Wählen Sie einen wichtigen Workflow und einen konkreten Fehlerzustand. „Antwortqualität sinkt“ ist als Alarmbeschreibung zu unbestimmt. Besser wäre:

Die Referenzfrage zur freigegebenen Produktklassifikation wird mit einer falschen Klasse oder ohne die erwartete Quelle beantwortet.

Damit können Sie festlegen, welche Daten zur Diagnose benötigt werden und welche Funktion vorübergehend eingeschränkt werden soll.

Sofortige Begrenzung: Eine verbotene Aktion wurde zugelassen oder eine kritische Schutzgrenze versagt.
Zeitnahe Untersuchung: Eine wiederholbare Fachprüfung schlägt fehl.
Geplanter Review: Eine Qualitätsstichprobe verschlechtert sich oder neue Fehlerarten treten auf.

Welche Reaktion erforderlich ist, hängt vom Prozess ab. Bei einem internen Entwurfsassistenten können feste Betreuungszeiten passen. Benötigt ein Workflow eine sofortige Reaktion außerhalb dieser Zeiten, müssen Zuständigkeit und technische Begrenzung vor dem Betrieb geklärt sein. Ein Alarm ersetzt keine vorbeugende Zugriffskontrolle und kann bereits ausgelieferte Daten oder ausgeführte Aktionen nicht zurückholen.

Eine vollständige Alarmregel festlegen

Das folgende Beispiel beschreibt eine fiktive Testkonfiguration. Intervalle und Schwellen sind keine allgemeinen Empfehlungen.

Ein RAG-Assistent beantwortet eine Referenzfrage zum künstlichen Demodatensatz D-47. Erwartet werden die Testklasse B und die freigegebene Quelle Q-17 in Revision 3.

Bestandteil	Festlegung im Beispiel
Betroffener Ablauf	Interne Produktauskunft in einem isolierten Testbereich
Prüfung	Antwortklasse und Quellenrevision gegen die Testreferenz vergleichen
Prüfzeit	Alle fünf Minuten während der vereinbarten Betriebszeit
Fachlicher Alarm	Zwei unmittelbar aufeinanderfolgende geplante Prüfungen sind auswertbar und liefern ein falsches Ergebnis
Lücke in der Überwachung	Kein auswertbar abgeschlossener Prüflauf seit mehr als zwölf Minuten innerhalb der Betriebszeit: gesondert „Überwachung unvollständig“ melden. Auch wiederholt nicht auswertbare Läufe setzen diese Frist nicht zurück.
Unterbrochene Folge	Fehlender oder nicht auswertbarer Lauf unterbricht die Folge; er zählt weder als bestanden noch als fachlich falsch
Zuständige Stelle	Benannte technische Verantwortung mit Vertretung
Erste Maßnahme	Betroffene Auskunftsfunktion einschränken und Fehler anhand der Laufkennung untersuchen
Freigabe nach Behebung	Referenzprüfung wiederholen und betroffenen Ablauf ausdrücklich freigeben

Die Lückenprüfung braucht eine eigene, verlässlich ausgeführte Überwachung. Ein angehaltener Prüfdienst kann seinen eigenen Stillstand nicht zuverlässig selbst melden. Geplante Betriebspausen müssen dabei berücksichtigt werden.

Ein ausgefallener Evaluator darf nicht als bestandene Fachprüfung erscheinen. Eine Referenzfrage kontrolliert außerdem nur einen bekannten Pfad. Sie ersetzt keine Bewertung wechselnder Nutzerfragen. Wie ein repräsentatives Testset aufgebaut wird, beschreibt RAG-Evaluation: Metriken und Golden Dataset.

Den Alarmweg mit kontrollierten Fehlern prüfen

Führen Sie die Probe in einer isolierten Umgebung oder einem ausdrücklich vorgesehenen Testbereich durch. Verwenden Sie künstliche Daten und einen Testempfänger. Lösen Sie keine realen Zahlungen, Geschäftsnachrichten oder Änderungen an Produktivdaten aus.

Kontrollierte Veränderung	Erwarteter Nachweis
Die Referenzquelle liefert absichtlich eine falsche Testklasse.	Die Fachprüfung schlägt fehl und löst nach der festgelegten Regel eine Meldung aus.
Eine benötigte Datenquelle ist im Test nicht erreichbar.	Technischer Fehler und fachliche Nichtprüfbarkeit bleiben unterscheidbar.
Der Bewertungsdienst wird angehalten.	Fehlende Bewertungen erscheinen als Lücke statt als fehlerfreie Ergebnisse.
Der reguläre Testmeldekanal fällt aus.	Der vereinbarte Ersatzweg wird geprüft; eine unzugestellte Meldung bleibt erkennbar.
Der Testempfänger bestätigt den Alarm nicht.	Die festgelegte Vertretung oder Eskalation greift im Test.
Die Ursache wird behoben.	Wiederholungsprüfung und Freigabe werden nachvollziehbar dokumentiert.

Ein Eintrag im Alarmprotokoll reicht als Abschluss nicht aus. Halten Sie fest, ob die Meldung tatsächlich angekommen ist und ob sich daraus die richtige Handlung ableiten ließ. Trennen Sie drei Zeitpunkte: Fehler erkannt, Meldung zugestellt, Reaktion begonnen. So lässt sich eine Verzögerung zuordnen.

Fehlende Messwerte als eigenen Zustand behandeln

„Keine Fehler gemessen“ kann bedeuten, dass alles funktioniert. Es kann auch bedeuten, dass niemand mehr misst. Überwachen Sie deshalb zusätzlich:

letzten gestarteten und letzten abgeschlossenen Prüflauf;
erwartete und tatsächlich bewertete Fälle;
ausstehende oder fehlgeschlagene Bewertungen;
letzten bestätigten Test des Meldewegs.

Ein regelmäßiges Lebenszeichen des Prüfprozesses belegt dessen Aktivität, aber noch keine abgeschlossene Fachprüfung.

Prometheus bietet beispielsweise absent_over_time(), um das Fehlen einer Zeitreihe über ein Zeitfenster festzustellen. Eine weiterhin gelieferte Zeitreihe mit einem eingefrorenen fachlichen Zeitstempel benötigt dagegen eine Prüfung dieses Zeitstempels. „Metrik vorhanden“ und „Prüfung aktuell“ sind unterschiedliche Aussagen.

Qualitätswerte mit ihrer Abdeckung zeigen

Ein zweites fiktives Beispiel: 200 Anfragen erhalten eine Antwort mit HTTP 200. Davon werden 20 fachlich geprüft. 18 bestehen die Prüfung, zwei sind falsch. 180 Antworten bleiben fachlich unbewertet.

Kennzahl	Ergebnis
Anteil HTTP-200-Antworten	200 / 200 = 100 %
Bestehensquote der geprüften Antworten	18 / 20 = 90 %
Fachliche Prüfungsabdeckung	20 / 200 = 10 %

Die 90 % beschreiben die geprüften Fälle. Ohne passende Stichprobenauswahl und Unsicherheitsbetrachtung lassen sie sich nicht einfach auf alle Anfragen übertragen. Ergänzen Sie Qualitätsanzeigen um Zeitraum, Fallzahl, Auswahlverfahren und Bewertungsstand. Zeigen Sie wichtige Aufgabenklassen getrennt, damit Fehler einer selten genutzten Funktion nicht im Gesamtdurchschnitt verschwinden.

Auch ein LLM-basierter Bewerter bleibt eine Messkomponente mit eigenen Grenzen. Der am 16. Oktober 2026 eingereichte MOSS-Preprint behandelt wiederkehrende Qualitätsbewertungen in Such- und Empfehlungssystemen. Er beschreibt Bewertungen als Hilfsmittel für Priorisierung und Diagnose, nennt Kalibrierungsunterschiede und mögliche Fehlalarme. Sie ersetzen dort kein menschliches Urteil. Die unter Begutachtung stehende Arbeit ist kein Leistungsnachweis für andere Anwendungen.

Genug Evidenz für die erste Untersuchung aufbewahren

Eine Meldung sollte Workflow und Umgebung, Zeitpunkt und Laufkennung, Regel samt Version, beobachteten Zustand und Vergleichsbasis sowie zuständige Stelle und Erstmaßnahme enthalten. Ergänzen Sie die beteiligte Anwendungs-, Modell- und gegebenenfalls Indexversion.

Vollständige Prompts und Dokumentinhalte müssen dafür nicht standardmäßig in jede Meldung kopiert werden. Verwenden Sie kontrollierte Verweise auf die erforderliche Evidenz und begrenzen Sie deren Zugriff.

Kosten gehören ebenfalls in die Betriebsbeobachtung. Für die wirtschaftliche Bewertung bleibt die vollständige Aufgabe maßgeblich; das Messmodell für KI-Kosten pro erfolgreicher Aufgabe beschreibt diese Bezugsgröße.

Nächster Schritt: einen Alarm vollständig durchspielen

Wählen Sie einen relevanten Workflow, dokumentieren Sie eine Alarmregel und bauen Sie den zugehörigen Fehler kontrolliert ein. Verfolgen Sie den Weg bis zur bestätigten Reaktion. Das Ergebnis sollte beantworten:

Welche Fehler erkennt die Prüfung, welche bleiben außerhalb ihrer Abdeckung?
Wie werden fehlende Bewertungen sichtbar?
Wer handelt innerhalb welcher vereinbarten Zeiten?
Woran wird die Wiederaufnahme des normalen Betriebs festgemacht?

Wenn Sie diese Betriebs- und Abnahmekriterien für einen vorhandenen PoC oder eine KI-Anwendung prüfen möchten, passt der AI Production Readiness & Reliability Sprint. Ein begrenzter Prüfauftrag kann einen Workflow, seine relevanten Fehlerzustände und den zugehörigen Alarmweg umfassen.