Kurz zusammengefasst
- Monitoring braucht vorab definierte Normalwerte, Grenzwerte und Verantwortliche für Reaktionen.
- Ein vollständiger Fall verbindet Nutzerkontext, Modell- und Promptversion, Quellen, Tools, Guardrails und Ergebnis.
- Prompts und Antworten können sensible Daten enthalten und dürfen nicht ungeprüft in Logs landen.
- Produktionssignale ergänzen feste Evals, ersetzen sie aber nicht.
Was sollte überwacht werden?
Eine KI-Anwendung ist mehr als ein Modellaufruf. Gute Beobachtbarkeit verbindet Infrastruktur, Kosten, Retrieval, Modellantworten, Guardrails, Tool-Aktionen und die fachliche Wirkung. Die Auswahl richtet sich nach den Risiken des Einsatzfalls.
| Signal | Normalbereich oder Baseline | Alarm und automatische Reaktion | Verantwortung und zulässige Logdaten |
|---|---|---|---|
| Verfügbarkeit, Laufzeit und Fehler | Nach Nutzergruppe und Prozess bekannte Antwortzeit und technische Fehlerrate. | Starker Anstieg: auf sichere Route wechseln, neue Anfragen begrenzen oder Dienst deaktivieren. | Operations; Zeit, Endpunkt, Statuscode und Korrelations-ID statt vollständigem Inhalt. |
| Qualität und fachliche Korrekturen | Freigegebene Eval-Werte sowie erwartete Korrektur- und Ablehnungsquote. | Grenzwert unterschritten: Release stoppen, Modellroute zurücksetzen oder menschliche Prüfung ausweiten. | Product und Fach-Owner; Testfall-ID, Bewertung und Fehlerklasse, sensible Inhalte nur kontrolliert. |
| Retrieval, Quellen und Rechte | Trefferquote, Quellenalter und Rechteentzug innerhalb definierter Fristen. | Veraltete Quelle oder Rechtefehler: betroffene Quelle sperren und Antworten ohne Beleg ablehnen. | Data Owner; Quellen-ID, Version, Rechteentscheid und Zeitstempel. |
| Tool-Aktionen und Freigaben | Erwartete Aktionsarten, Wertebereiche, Empfänger und Ablehnungsquote. | Unbekannte Sequenz oder Grenzwertverletzung: Aufruf blockieren, Berechtigungen einschränken oder Schlüssel sperren und Incident prüfen. | Operations und Security; Tool, validierte Parameterklasse, Freigabe und Resultat ohne unnötige Nutzdaten. |
| Kosten und Nutzung | Budget pro Fall, Team und Modell sowie erwartetes Nutzungsvolumen. | Sprung oder Missbrauchsmuster: Rate Limit, kostengünstigere Route oder Kontosperre. | Service Owner; Token-/Aufrufmenge, Kostenstelle, Modell und aggregierte Nutzergruppe. |
Wie protokolliert man datenschutzgerecht?
Vollständige Eingaben sind für Fehleranalysen nützlich, können aber Personendaten, Geheimnisse oder nicht vertrauenswürdige Inhalte enthalten. Deshalb braucht jede Log-Kategorie einen Zweck, minimale Felder, Zugriffsschutz und eine begrenzte Aufbewahrung.
- Korrelationskennung statt unnötiger direkter Identifikatoren
- Nicht benötigte Werte entfernen oder maskieren; für notwendige Verknüpfungen Tokenisierung oder schlüsselabhängige Pseudonyme verwenden
- Schlüssel beziehungsweise Zuordnung getrennt schützen und pseudonymisierte Werte weiterhin als Personendaten behandeln
- Rollenbasierten Zugriff und manipulationsgeschützte Speicherung verwenden
- Aufbewahrung nach Analyse-, Sicherheits- und Rechtspflicht festlegen
- Nutzende transparent über relevante Protokollierung informieren
Welche Signale brauchen einen Alarm?
Ein Alarm ist nur hilfreich, wenn eine zuständige Person weiss, was zu tun ist. Grenzwerte basieren auf einem erwarteten Normalverhalten und unterscheiden technische Störung, Qualitätsabfall, möglichen Angriff und unzulässige Aktion.
- Schritt 1
Baseline festlegen
Normale Nutzung, Qualität, Laufzeit und Tool-Sequenzen dokumentieren.
- Schritt 2
Schwellen definieren
Warnung, Blockierung und Incident nach Wirkung und Dringlichkeit abstufen.
- Schritt 3
Kontext liefern
Alarm mit betroffener Version, Funktion und sicheren Diagnosedaten anreichern.
- Schritt 4
Reaktion testen
Zuständigkeit, Erreichbarkeit und technische Eindämmung regelmässig üben.
Wie wird Monitoring zur Verbesserung genutzt?
Produktionsdaten zeigen neue Formulierungen und Fehlermuster. Fachlich bestätigte Fälle werden anonymisiert oder synthetisch nachgebildet und in Regressionstests übernommen. So entsteht ein geschlossener Lernprozess ohne jede Nutzerinteraktion ungeprüft als Trainingsdaten zu verwenden.
- Neue Fehlerklassen und betroffene Nutzergruppen analysieren
- Stichproben fachlich prüfen statt nur automatische Scores zu beobachten
- Änderungen mit denselben Evals vor und nach Freigabe vergleichen
- Near-Misses und Übersteuerungen als wichtige Risikosignale behandeln
- Nicht mehr nützliche Kennzahlen und übermässige Logs regelmässig abbauen
Beispiel: Serviceassistent nach einem Modellwechsel
Nach einer neuen Modellversion steigt die Antwortgeschwindigkeit, gleichzeitig nehmen fachliche Korrekturen bei französischen Anfragen zu. Das Dashboard trennt Resultate nach Sprache und Version und löst einen Qualitätsalarm aus. Das Team rollt die betroffene Route auf die vorige Version zurück, ergänzt die Fälle im Eval-Set und prüft die Änderung erneut. Prompts mit Kundendaten bleiben nur stark begrenzt und geschützt zugänglich.
Was Sie mitnehmen sollten
Definieren Sie Monitoring vom Risiko und der Reaktion her. Protokollieren Sie genug für Nachvollziehbarkeit und Vorfälle, aber minimieren und schützen Sie sensible Inhalte konsequent.
Quellen und Vertiefung
Diese Primärquellen vertiefen Definitionen, technische Grundlagen oder verantwortlichen Einsatz.
Inhaltlich geprüft