Monitoring im Betrieb (Drift, Qualität, Kosten)

Lernziele

Sie erklären die drei Ursachen für Qualitätsverschlechterungen bei KI-Systemen im Betrieb (Modell-Updates, Datendrift, Konzeptdrift) und geben je ein konkretes Beispiel.

Sie unterscheiden Data Drift von Concept Drift und erklären, warum beide mit dem Golden Test-Set (UE 103) erkannt werden können.

Sie beschreiben mindestens vier relevante Qualitätsmetriken für KI-Systeme im Betrieb und deren Messverfahren.

Sie skizzieren ein einfaches Kosten-Dashboard für den Token-Verbrauch eines KI-Systems.

Sie formulieren einen dreistufigen Monitoring-Rhythmus für Ihre Organisation (wöchentlich / monatlich / quartalsweise).

Auf einen Blick

Worum geht es?

Ein KI-System in Betrieb zu nehmen ist der Anfang — nicht das Ende — der Verantwortung. Ein Wasserrohr, das nach dem Einbau nie überprüft wird, kann still vor sich hin lecken, bis der Schaden sichtbar wird. KI-Systeme haben das gleiche Problem: Sie können sich — ohne dass jemand aktiv etwas geändert hat — im Laufe der Zeit verschlechtern.

Die Ursachen sind vielfältig: Der Anbieter aktualisiert das Modell (manchmal ohne Ankündigung), die Art, wie Mitarbeitende das System nutzen, verändert sich, oder die Organisation selbst ändert Prozesse und Informationen, auf die das KI-System zugreift. Das Ergebnis: Ein Assistent, der vor drei Monaten zuverlässig funktionierte, liefert heute subtil schlechtere Ergebnisse — und niemand hat es systematisch erfasst.

Monitoring im Betrieb ist die Antwort auf dieses Problem. Es ist kein Luxus für IT-Konzerne. Es ist die grundlegende Sorgfaltspflicht, die EU AI Act Art. 26 Abs. 5 ausdrücklich für Deployer fordert: die Pflicht, den Betrieb von KI-Systemen zu überwachen.

In dieser Lerneinheit erarbeiten Sie das Konzept und die praktische Umsetzung eines schlanken, aber wirksamen Monitoring-Systems — von der Drift-Erkennung über Qualitätsmetriken bis zum Token-Kosten-Dashboard.

Lerntext — Theorie und Konzepte

Drei Ursachen für Qualitätsverschlechterungen

Ursache 1 — Modell-Updates durch den Anbieter

Anbieter wie OpenAI aktualisieren ihre Modelle kontinuierlich. Manchmal sind diese Updates rückwärtskompatibel, manchmal nicht. Eine neue Version kann sich in Formatierungsverhalten, Ausführlichkeit, Tonalität oder Umgang mit Grenzfällen von ihrer Vorgänger-Version unterscheiden — auch wenn die allgemeine Qualität besser geworden ist, kann der spezifische Anwendungsfall schlechter werden.

Praxis-Beispiel: Ein Angebots-Assistent war auf eine bestimmte Ausgabe-Länge und Struktur optimiert. Nach einem Modell-Update schreibt das Modell ausführlichere Angebote — für das allgemeine Publikum eine Verbesserung, für den spezifischen Kontext ein Problem (zu lang, falsches Format).

Ursache 2 — Datendrift

Die statistischen Eigenschaften der Eingaben verändern sich über die Zeit. Wenn sich die Art, wie Mitarbeitende den Assistenten nutzen, verändert — andere Formulierungen, neue Themen, andere Sprache — kann die Qualität sinken, ohne dass das Modell oder die Systemanweisung sich geändert hat.

Praxis-Beispiel: Ein Ticket-Triaging-Assistent wurde auf deutsch-sprachige Tickets optimiert. Drei Monate nach Einführung beginnen Techniker, Tickets zunehmend mit englischen Fachbegriffen zu verfassen. Die Klassifizierungsqualität des Assistenten sinkt messbar.

Ursache 3 — Konzeptdrift (Concept Drift)

Die Beziehung zwischen Eingabe und „richtigem” Output verändert sich, weil sich das Unternehmen selbst verändert hat — neue Prozesse, neue Preisstrukturen, neue Angebotskategorien. Was 2024 eine korrekte Ausgabe war, ist 2026 falsch — nicht weil das Modell schlechter wurde, sondern weil sich der Kontext verändert hat.

Praxis-Beispiel: Neue Preisstaffelungen wurden eingeführt. Ein Angebots-Assistent, der auf alten Preisdaten basiert, schlägt veraltete Preise vor. Kein technisches Problem — ein Wissensbasis-Problem.

Merksatz

KI-Systeme können schlechter werden, ohne dass jemand etwas geändert hat. Datendrift und Konzeptdrift sind externe Veränderungen, die das System „überrollen” — Monitoring ist der einzige Schutz dagegen.

Data Drift vs. Concept Drift

Qualitätsmetriken für den Betrieb

Abb. 104.1 — Drift-Monitoring über Zeit: Qualitätsscore und Halluzinations-Rate zeigen einen Knick nach dem Modell-Update im Mai

Relevante Qualitätsmetriken für KI-Systeme im Betrieb:

Merksatz

Kein Monitoring-Dashboard der Welt ersetzt den regelmäßigen menschlichen Blick auf die tatsächlichen Ausgaben. Automatische Metriken zeigen Symptome — Human Sampling zeigt Ursachen.

Kosten-Dashboard — Token-Verbrauch verstehen

KI-APIs werden nach Token-Verbrauch abgerechnet. Ein Token entspricht grob ¾ eines englischen Wortes (bei deutschen Texten oft mehr). Kostentreiber:

Systemanweisung: Wird bei jeder Anfrage mitgeschickt — lange Systemanweisungen multiplizieren Kosten erheblich.

RAG-Kontext: Wenn viele Dokument-Fragmente mitgeschickt werden, steigt der Input-Token-Verbrauch massiv.

Ausgabelänge: Je ausführlicher die erwartete Ausgabe, desto mehr Output-Tokens.

Multimodale Eingaben: Bilder verbrauchen deutlich mehr Tokens als Text.

Ein einfaches Kosten-Dashboard (z. B. in Langfuse oder als API-Nutzungsabfrage des Anbieters) zeigt:

Täglicher/wöchentlicher Token-Verbrauch pro Use-Case

Kosten pro Anfrage (Durchschnitt, Maximum, Percentile)

Vergleich Budget vs. Actual

Alerts bei ungewöhnlichem Anstieg (mögliches Anzeichen für Fehlnutzung oder erfolgreiche Injections)

Monitoring-Tools: Langfuse (Open Source, bietet Token-Tracking und Kosten-Dashboard), Helicone (kostenpflichtig, einfache Integration), OpenAI Usage Dashboard (kostenlos, im Account verfügbar), Microsoft Azure Cost Management (für M365 Copilot / Azure OpenAI).

Monitoring-Rhythmus

Vertiefung — Drift-Detection und Token-Economy

Drift-Detection: Technische Methoden

Neben dem regelmäßigen Golden-Test-Set-Lauf gibt es technische Methoden, um Drift früher zu erkennen:

Statistisches Monitoring der Eingaben: Bei API-basierten Systemen können statistische Eigenschaften der Eingaben über Zeit getrackt werden: Durchschnittliche Eingabelänge, Häufigkeit bestimmter Schlüsselwörter, Themenverteilung. Wenn sich diese Eigenschaften signifikant verschieben, ist das ein Indikator für Data Drift.

Ausgabe-Monitoring: Analog für Ausgaben: Verändert sich die Ausgabelänge? Werden neue Formulierungen verwendet? Tauchen plötzlich Themen auf, die vorher nicht vorkamen? Diese Anomalien können auf Drift oder auf erfolgreiche Injections hinweisen.

Embedding-Drift-Detection: Für fortgeschrittenere Setups: Die semantischen Embeddings der Eingaben können über Zeit statistisch analysiert werden. Wenn die durchschnittliche semantische Ähnlichkeit zu den historischen Eingaben sinkt, ist das ein klares Drift-Signal.

Die Token-Economy: KI-Kosten strategisch managen

Das Verständnis der Token-Ökonomie ist für jeden, der KI-Systeme verantwortet, essenziell. Eine vereinfachte Formel:

Monatliche Kosten ≈ (Anfragen/Tag × 30) × (Input-Tokens + Output-Tokens) × (Preis/Token)

Rechenbeispiel für einen typischen internen Assistenten:

20 Anfragen/Tag

Systemanweisung: 500 Tokens, RAG-Kontext: 2.000 Tokens, Nutzereingabe: 200 Tokens → ~2.700 Input-Tokens/Anfrage

Ausgabe durchschnittlich 800 Tokens

Monatlich: 600 Anfragen × 2.700 = 1.620.000 Input-Tokens + 480.000 Output-Tokens

Bei GPT-4o (ca. 2,50 USD / 1M Input, 10 USD / 1M Output): ~4,05 USD + 4,80 USD ≈ ~9 USD/Monat

Das ist relativ günstig. Aber wenn die Systemanweisung auf 2.000 Tokens anwächst, verdoppeln sich annähernd die Kosten. Und wenn 200 Anfragen/Tag statt 20 erwartet werden, multiplizieren sich die Kosten mal zehn.

Optimierungsstrategien:

Systemanweisung kompakt halten (< 500 Tokens)

RAG-Kontext selektiv halten: Nur die relevantesten 3–5 Dokument-Fragmente

Ausgabelänge durch explizite Format-Vorgaben begrenzen

Billigeres Modell für einfache Aufgaben, teureres Modell nur für komplexe Fälle (Routing nach Aufgabentyp)

Dreistufige Budget-Governance

Token-Kosten können bei KI-Systemen schnell aus dem Ruder laufen. Eine einfache aber wirkungsvolle Maßnahme ist das Budget-Alert-System:

Soft Limit (80%): Automatische E-Mail-Benachrichtigung an KI-Beauftragte:r und IT. Kein Eingriff, aber Awareness-Signal.

Hard Limit (100%): API-Key wird temporär gedrosselt oder auf ein günstigeres Modell umgeroutet (Fallback-Strategie).

Emergency Stop (150%): API-Key wird deaktiviert; System offline bis zur manuellen Freigabe nach Budgetprüfung.

Dieses System verhindert unangenehme Überraschungen am Monatsende und ist in allen gängigen Plattformen (OpenAI, Azure OpenAI, Anthropic) als Feature verfügbar.

Anomalie-Erkennung und Kostenspieks verstehen

Ein unerwarteter Token-Verbrauchsanstieg im Dashboard ist kein Grund zur Panik — aber er sollte systematisch analysiert werden:

Nutzerzahl verändert? Mehr Nutzer = mehr Anfragen = höhere Kosten. Normal.

Anfragekomplexität verändert? Nutzer schicken plötzlich sehr lange Texte oder Dokument-Uploads.

Einzelner Nutzer mit ungewöhnlich hohem Verbrauch? Könnte auf Fehlbenutzung oder einen automatisierten Skript-Angriff hinweisen.

Systemanweisung oder RAG-Kontext verändert? Jemand hat die Systemanweisung deutlich verlängert.

Anzeichen für Injection-Versuche? Wenn Ausgaben ungewöhnlich lang sind, könnte eine erfolgreiche Injection das Modell zu ausführlichen Antworten veranlasst haben.

Feedback-Loops: Nutzerfeedback als Qualitätssignal

Automatisches Monitoring erfasst Metriken. Es erfasst aber nicht, ob die Nutzenden tatsächlich zufrieden sind.

In-situ Feedback: Ein einfaches Daumen-hoch/Daumen-runter nach jeder KI-Antwort gibt schnelles qualitatives Feedback. Die Implementation in einem Web-Interface dauert wenige Stunden.

Periodische Nutzerbefragung: Einmal im Quartal werden 5–10 aktive Nutzer mit drei bis fünf Fragen befragt: Was schätzen Sie? Was fehlt? Wann waren Ausgaben enttäuschend?

Eskalationsrate als passiver Feedback-Indikator: In einem Helpdesk-Kontext: Wie oft bittet der Nutzer nach einer KI-Antwort trotzdem noch um menschliche Hilfe? Eine hohe Eskalationsrate zeigt, dass die KI-Antwort das Problem nicht gelöst hat.

Monitoring als EU-AI-Act-Compliance-Nachweis

EU AI Act Art. 26 Abs. 5 verpflichtet Deployer zur Betriebsüberwachung. Was bedeutet das als Compliance-Nachweis?

Wenn eine Aufsichtsbehörde fragt: „Wie überwachen Sie den Betrieb Ihrer KI-Systeme?” — müssen Sie Dokumente und Prozesse vorlegen können:

Monatliche Qualitäts-Sampling-Reports (20 zufällige Ausgaben bewertet)

Golden-Test-Set-Ergebnisse chronologisch (Baseline vs. aktuelle Version)

Kosten-Dashboard-Exports (monatlich, zeigt Nutzungsintensität)

Incident-Log (auch „Keine Vorfälle in Periode X” ist ein Eintrag)

Diese Dokumentation gehört ins KI-Systemverzeichnis (UE 105). Das Verzeichnis ist der zentrale Nachweis für die Sorgfaltspflicht als Deployer.

Branchen-Anwendungen

IT-Dienstleistung & Beratung

IT-Dienstleistungsunternehmen betreiben oft mehrere KI-Systeme parallel — für interne Prozesse (Code-Review, Dokumentation) und für Kundenprojekte. Monitoring muss hier pro System und pro Mandant differenziert werden.

Vignette: Ein IT-Beratungsunternehmen hat für drei verschiedene Kunden KI-Assistenten implementiert. Ein zentrales Langfuse-Dashboard zeigt aggregierte Metriken, gibt aber pro Kunde separate Views. Als bei einem Kunden die Eskalationsrate von 8% auf 24% steigt, wird ein sofortiger Human-Eval-Lauf ausgelöst. Ergebnis: Die Wissensbasis des Assistenten ist mit einer Produktdokumentation aus dem Vorjahr befüllt — Concept Drift nach einer umfangreichen Produkt-Überarbeitung. Die Wissensbasis wird aktualisiert, die Eskalationsrate sinkt innerhalb einer Woche wieder auf 7%.

Industrie & Fertigung

In Fertigungsumgebungen sind Latenzen und Verfügbarkeit besonders kritisch. Ein KI-System, das für die Schichtübergabe oder die Qualitätskontrolle eingesetzt wird, kann keine Ausfallzeiten tolerieren.

Vignette: Ein Maschinenbauunternehmen überwacht seinen KI-gestützten Wartungs-Assistenten mit einem SLA-Monitoring-Dashboard: Verfügbarkeit (Ziel: 99,5%), Latenz (Ziel: < 3 Sekunden), Qualitäts-Score (monatlich durch Wartungstechniker bewertet). Als die Latenz nach einem Anbieter-Update auf durchschnittlich 8 Sekunden steigt, wird das als P2-Incident eingestuft. Der Anbieter wird informiert, ein Fallback auf eine lokale Modell-Version wird aktiviert, bis das Problem behoben ist.

Finanzdienstleistung & Versicherung

Im Finanzsektor sind Monitoring-Berichte Teil der regulatorischen Dokumentation. DORA verlangt von Finanzinstituten, die IT-Drittanbieter nutzen, kontinuierliches Monitoring und regelmäßige Berichte über die Performance dieser Systeme.

Vignette: Eine Versicherungsgesellschaft führt ein KI-System für die automatisierte Erstbewertung von Schadenmeldungen ein. Das Monitoring-Dashboard zeigt monatliche Berichte: Anteil der Fälle, die der KI zur Bewertung vorgelegt wurden, Anteil der Fälle, die an menschliche Sachbearbeiter eskaliert wurden, und Qualitäts-Score der nicht eskalierten Fälle (durch stichprobenweise manuelle Prüfung). Diese Berichte werden vierteljährlich dem Compliance-Ausschuss vorgelegt — als Teil des DORA-Reporting-Pakets.

Öffentliche Verwaltung

Behörden müssen die Qualität und Neutralität von KI-Ausgaben besonders sorgfältig überwachen. Entscheidungsunterstützende KI-Systeme müssen nachweislich konsistent und nicht diskriminierend arbeiten.

Vignette: Eine Bundesbehörde setzt einen KI-Assistenten für die Priorisierung eingehender Fördermittelanträge ein. Das Monitoring-System umfasst neben Standard-Qualitätsmetriken ein Fairness-Monitoring: Werden Anträge aus bestimmten Regionen oder von bestimmten Antragstellertypen systematisch anders bewertet? Quartalsweise Fairness-Analysen werden von einem unabhängigen Prüfer durchgeführt und deren Ergebnisse öffentlich im Jahresbericht der Behörde dokumentiert. Das schafft Transparenz und Vertrauen.

Warnung — Sicherheitsrisiken

OWASP LLM Top 10 — Relevanz für Monitoring:

LLM04 — Model Denial of Service: Ungewöhnlicher Token-Verbrauch-Spike kann auf einen Denial-of-Service-Angriff hinweisen — massenhafte Anfragen, die das System überlasten und gleichzeitig hohe Kosten verursachen. Budget-Alerts und Rate-Limiting sind Gegenmaßnahmen.

LLM02 — Insecure Output Handling: Monitoring von Ausgaben kann helfen, Muster zu erkennen, die auf manipulierte Outputs hinweisen (z. B. ungewöhnlich lange Ausgaben, die strukturell anders aussehen als normale Ausgaben — ein Indikator für erfolgreiche Prompt Injection).

Data Leakage durch Monitoring-Systeme: Wenn Monitoring-Tools (z. B. Langfuse Cloud) alle Eingaben und Ausgaben tracken, werden sensible Daten an einen Drittanbieter übermittelt. Das muss datenschutzrechtlich bewertet werden — entweder durch Self-Hosting des Monitoring-Tools oder durch Anonymisierung/Pseudonymisierung der getracken Daten (kein Tracking von personenbezogenen Daten in Cloud-Monitoring-Systemen ohne expliziten AVV).

Handlungsprinzip: Monitoring schafft nicht nur Sicherheit — Monitoring-Tools selbst können Sicherheitsrisiken sein, wenn sie unsachgemäß konfiguriert sind. Datenklassifizierung (UE 100) bestimmt, welche Daten in welches Monitoring-System fließen dürfen.

Übung 1 — Kosten-Dashboard konzipieren

Aufgabe: Sie entwickeln die Konzeption für ein einfaches Token-Kosten-Dashboard für einen KI-Assistenten in Ihrer Organisation.

Material: Laptop, Notizblock oder Tabellenblatt.

Schritt-für-Schritt:

Definieren Sie: Welche Kennzahlen soll das Dashboard anzeigen? (Mindestens 5 KPIs)

Definieren Sie: Welche Alarmierungsschwellen wären sinnvoll?

Überlegen Sie: Wer empfängt das Dashboard oder die Alerts?

Skizzieren Sie das Dashboard-Layout grob (auf Papier oder in einem Tool).

Überlegen Sie: Welches Tool würden Sie für die Implementierung empfehlen — und warum?

Zeitrahmen: 15 Minuten Einzelarbeit, 5 Minuten Plenumsdiskussion

Musterlösung Übung 1:

KPIs: (1) Tageskosten in € absolut, (2) Kosten pro Anfrage (Durchschnitt), (3) Token-Verbrauch Input vs. Output (Verhältnis), (4) Tägliche Anfragenanzahl, (5) Top-5 teuerste Anfragen des Tages (Outlier-Erkennung).

Alarmierungsschwellen: Tageskosten >150% des Wochendurchschnitts → Alert an KI-Beauftragte:r. Einzelanfrage >500% des Durchschnitts → sofort prüfen (mögliche Injection). Null Anfragen über 48h → System-Downtime-Check.

Tool-Empfehlung: Langfuse (Open Source, Self-Hosted oder Cloud, DSGVO-konform konfigurierbar).

Übung 2 — Monitoring-Rhythmus entwerfen

Aufgabe: Sie entwerfen einen vollständigen Monitoring-Rhythmus für einen KI-Wissensassistenten (RAG auf interner Wissensbasis).

Schritt-für-Schritt:

Identifizieren Sie für diesen Use-Case die drei wichtigsten Risiken für Qualitätsverschlechterung.

Definieren Sie für jedes Risiko eine geeignete Monitoring-Maßnahme.

Ordnen Sie jede Maßnahme einem Rhythmus zu (wöchentlich / monatlich / quartalsweise / bei Trigger).

Schätzen Sie den Zeitaufwand pro Monitoring-Zyklus ab.

Diskutieren Sie in der Gruppe oder allein: Welche Maßnahme hat das beste Kosten-Nutzen-Verhältnis?

Zeitrahmen: 12 Minuten Gruppenarbeit (2–3 Personen), 8 Minuten Plenum

Musterlösung Übung 2:

Cheat-Sheet — Monitoring Kurzreferenz

Drei Drift-Ursachen: 1. Modell-Update (Anbieter ändert Modell still) 2. Data Drift (Eingaben der Nutzer verändern sich) 3. Concept Drift (Unternehmenskontext ändert sich)

Kernmetriken: CSAT, Halluzinations-Rate, Aufgaben-Abschlussrate, Latenz, Eskalationsrate

Token = Geld: - Systemanweisung × Anfragen/Tag = größter Kostentreiber - RAG-Kontext selektiv halten - Ausgabelänge begrenzen

Monitoring-Rhythmus: - Wöchentlich → Kosten-Dashboard - Monatlich → Qualitäts-Sampling + Golden Test-Set - Quartalsweise → vollständiger Review - Bei Trigger → Modell-Update, Kosten-Spike, Incident

Budget-Governance: Soft Limit (80%) → Hard Limit (100%) → Emergency Stop (150%)

EU AI Act Art. 26 Abs. 5: Deployer überwachen den Betrieb ihrer KI-Systeme — Monitoring ist gesetzlich gefordert, nicht optional.

Prompt-Vorlage — Monitoring-Konzept für einen produktiven KI-Assistenten entwickeln

Prompt für einen KI-Assistenten:

„Unser KI-Assistent ist seit drei Monaten in Produktion. Bisher haben wir kein systematisches Monitoring. Ich möchte ein einfaches, aber wirkungsvolles Monitoring-Konzept einführen, das wir mit begrenzten Ressourcen (ca. 4 Stunden pro Woche) umsetzen können.

Entwirf ein dreistufiges Monitoring-Konzept mit:

Stufe 1 — Tägliches Basismonitoring (15 Min/Tag): Welche drei bis fünf Kennzahlen sollte ich täglich prüfen? Beschreibe für jede Kennzahl: Was messe ich? Welcher Schwellenwert löst einen Alarm aus? Wie erkenne ich den Drift?

Stufe 2 — Wöchentliche Qualitätskontrolle (60 Min/Woche): Welche strukturierten Auswertungen führe ich wöchentlich durch? Wie nutze ich das Golden Test-Set (aus UE 103) als Referenz?

Stufe 3 — Monatlicher Governance-Report (2 Stunden/Monat): Was gehört in einen monatlichen Governance-Report für die Geschäftsführung? Welche KPIs sind entscheidend?

Ergänze für jede Stufe ein konkretes Beispiel-Dashboard (Texttabelle reicht), das zeigt, wie die Daten dargestellt werden könnten. Beachte dabei sowohl technische Aspekte (Antwortqualität, Latenz, Kosten) als auch Compliance-Aspekte (Datenzugriffe, anomale Nutzungsmuster, potenzielle Injection-Versuche).”

Erwartetes Ergebnis: Ein praxistaugliches, dreistufiges Monitoring-Konzept, das direkt als Vorlage für das interne KI-Betriebshandbuch übernommen werden kann.

Reflexionsfragen

Ein Mitarbeiter sagt: „Das System läuft gut, ich benutze es jeden Tag — ich würde sofort merken, wenn etwas nicht stimmt.” Warum ist das kein ausreichendes Monitoring-Konzept?

Was ist der Unterschied zwischen Data Drift und Concept Drift? Geben Sie je ein Beispiel aus Ihrer eigenen Branche.

Ein unerwarteter Token-Verbrauchsanstieg von 300% erscheint im Kosten-Dashboard. Was sind die drei wahrscheinlichsten Ursachen?

Wie balancieren Sie Monitoring-Aufwand gegen den operativen Nutzen — was ist das absolute Minimum an Monitoring für ein KI-System im produktiven Einsatz?

EU AI Act Art. 26 Abs. 5 verpflichtet Deployer zur Betriebsüberwachung. Was würde bei einer Überprüfung durch eine Behörde als Nachweis akzeptiert werden?

Quellen & Weiterlesen

Hinweise für AI Champions — So vermitteln Sie das Thema

Timing: 45 Min — Empfohlene Aufteilung: 15 Min Input (Drift-Typen + Metriken + Rhythmus), 20 Min Übungen (1 oder 2 je nach Gruppe), 10 Min Auswertung und Plenumsdiskussion.

Methodische Empfehlung: Das Wasserrohr-Analogon aus dem Einstieg resoniert gut mit technisch und nicht-technisch gemischten Gruppen. Nach dem Einstieg: Direkte Frage an die Gruppe — „Hat jemand schon erlebt, dass ein KI-Tool plötzlich schlechter wurde als erwartet?” Erfahrungsgemäß gibt es in jeder Gruppe mindestens eine solche Geschichte. Diese aufgreifen und in die Drill-Down-Analyse der drei Drift-Ursachen einbauen.

Stolpersteine: - „Monitoring ist Aufgabe der IT, nicht von mir”: Klar betonen, dass EU AI Act Art. 26 Abs. 5 den Deployer — also das Unternehmen, nicht den Anbieter — zur Überwachung verpflichtet. IT kann unterstützen, die Verantwortung liegt bei der Fachseite. - Verwechslung Monitoring mit Evaluation: Monitoring ist kontinuierlich (immer aktiv), Evaluation ist periodisch (gezielt ausgelöst). Beide ergänzen sich. - Kosten werden unterschätzt: Das Rechenbeispiel (9 USD/Monat für einen kleinen Use-Case) klingt günstig — aber bei 200 Anfragen/Tag und langer Systemanweisung kann dasselbe System 500+ USD/Monat kosten. Das Budget-Alert-System ist daher wichtig.

Diskussionsfragen: 1. Welche KI-Systeme in Ihrer Organisation haben aktuell kein Monitoring — und welches Risiko ergibt sich daraus? 2. Wer sollte in Ihrer Organisation für das wöchentliche Kosten-Dashboard verantwortlich sein — IT oder Fachbereich? 3. Was passiert, wenn ein Monitoring-Tool selbst Daten in eine Cloud sendet, die nicht DSGVO-konform ist?

Tafelbild:

MONITORING — DREISTUFIGER RHYTHMUS



WÖCHENTLICH MONATLICH QUARTALSWEISE

───────────── ────────────── ─────────────────

Kosten-Dashboard Qualitäts- Vollst. Eval-Lauf

Anomalien? Sampling System-Review

CSAT-Score Golden Test-Set Modell-Version

Halluzinations- prüfen

Rate



BEI TRIGGER

─────────────────

Modell-Update → sofort Test-Set-Lauf

Kosten-Spike → Ursachenanalyse

Incident → UE 106 Playbook

Differenzierung Power-User ↔ Einsteiger: - Einsteiger: Fokus auf Drift-Typen und Monitoring-Rhythmus; Übung 2 ist zugänglich ohne technische Vorkenntnisse. - Power-User: Vertiefen mit technischen Drift-Detection-Methoden (Embedding-Drift, statistische Anomalie-Erkennung), Token-Economy-Kalkulation, Langfuse-Integration.

Materialliste: - Monitoring-Rhythmus-Template (Tabelle, druckbar) - Taschenrechner für Token-Kosten-Rechenbeispiel - Optional: Langfuse-Demo-Account für Dashboard-Visualisierung

Übergang zur nächsten UE: UE 105 behandelt Dokumentationspflichten nach dem EU AI Act. Der Übergang ist direkt: „Das Monitoring liefert die Daten — die Dokumentation hält sie fest. UE 105 zeigt, was genau dokumentiert werden muss und wie das KI-Systemverzeichnis aufgebaut wird, das alle Monitoring-Ergebnisse zusammenführt.”

Tipp zur Branchenauswahl: Für Finanzgruppen: DORA-Reporting als Monitoring-Kontext verwenden — was genau muss dem Regulator gemeldet werden? Für Industriegruppen: Latenz und Verfügbarkeit als kritische Metriken betonen. Für Verwaltungsgruppen: Fairness-Monitoring als zusätzliche Dimension einführen.

Vertiefung II — Drift-Detection in der Praxis und fortgeschrittenes Monitoring

Implementierungsbeispiel: Langfuse Self-Hosted für produktiven KI-Betrieb

Langfuse ist ein Open-Source-LLM-Observability-Tool, das in wenigen Stunden in ein bestehendes KI-System integriert werden kann.

Option 1 — Cloud-Hosting (langfuse.com): Kostenloser Einstiegs-Plan für bis zu 50.000 Traces pro Monat. Integration durch wenige Zeilen Python-Code. Datenschutz-Bedenken: Traces enthalten Eingaben und Ausgaben — diese müssen nach der Datenklassifizierung bewertet werden, bevor Traces an eine externe Plattform gesendet werden.

Option 2 — Self-Hosted (empfohlen für vertrauliche Daten): Docker-Container, ausführbar auf eigenem Server oder in der eigenen Cloud-Umgebung. Vollständige Datenkontrolle. Höherer Setup-Aufwand (~4 Stunden für eine IT-erfahrene Person), danach wartungsarm.

Was getrackt wird: - Input-Tokens und Output-Tokens pro Anfrage - Latenz (End-to-End und LLM-spezifisch) - Modell-Version (wichtig bei Provider-Updates) - Custom-Metadaten (z. B. Nutzer-ID, Use-Case-Typ) - Kosten (automatisch berechnet aus Token-Verbrauch und Modell-Pricing)

Anomalie-Erkennung: Technische Implementierung

Ein reiferes Monitoring-System geht über passive Dashboards hinaus und erkennt Anomalien automatisch:

Statistische Anomalie-Erkennung: Wenn der tägliche Token-Verbrauch mehr als zwei Standardabweichungen über dem gleitenden 30-Tage-Durchschnitt liegt, wird ein Alert ausgelöst. Diese Methode erkennt ungewöhnliches Verhalten auch ohne absolute Schwellenwerte zu definieren — und passt sich automatisch an wachsende Nutzungszahlen an.

Pattern-Erkennung: Wenn eine einzelne Nutzer-ID für mehr als 30% des täglichen Token-Verbrauchs verantwortlich ist, ist das eine Auffälligkeit — möglicherweise ein Nutzer, der das System missbraucht, oder ein Automatisierungs-Skript ohne genehmigten Use-Case.

Zeitliche Muster: Anfragen außerhalb der Geschäftszeiten (z. B. um 3 Uhr morgens) bei einem internen System, das nur von Mitarbeitenden genutzt wird, könnten auf einen Angriff oder ungenehmigte Automatisierung hinweisen.

Verbindung zum EU AI Act: Monitoring als Compliance-Nachweis

EU AI Act Art. 26 Abs. 5 verpflichtet Deployer zur Betriebsüberwachung. Was bedeutet das konkret als Compliance-Nachweis?

Wenn eine Aufsichtsbehörde fragt: „Wie überwachen Sie den Betrieb Ihrer KI-Systeme?” — können folgende Dokumente und Prozesse vorgelegt werden:

Monatliche Qualitäts-Sampling-Reports (20 zufällige Ausgaben bewertet, mit Datum und Bewerter:in)

Golden-Test-Set-Ergebnisse chronologisch (Baseline vs. aktuelle Version, mit Datum)

Kosten-Dashboard-Exports (monatlich, zeigt Nutzungsintensität)

Incident-Log (auch wenn keine schwerwiegenden Vorfälle aufgetreten sind: „Keine Vorfälle in Periode X” ist ein valider Eintrag)

Diese Dokumentation sollte im KI-Systemverzeichnis (UE 105) verlinkt oder direkt eingetragen sein. Das Verzeichnis ist der zentrale Nachweis für die Sorgfaltspflicht als Deployer.

Monitoring bei IT-Dienstleistern: Multi-Mandanten-Herausforderung

IT-Dienstleister, die KI-Systeme für mehrere Kunden betreiben, stehen vor einer zusätzlichen Monitoring-Herausforderung: Das Monitoring muss mandantenspezifisch ausgewertet werden, ohne dass Daten zwischen Mandanten vermischt werden.

Empfohlene Architektur: Jedes Kundensystem erhält einen eigenen API-Key. Langfuse trennt die Monitoring-Daten nach API-Key. Separate Dashboards pro Mandant. Monatliche Reports werden pro Mandant erstellt und dem Kunden übergeben. Diese Transparenz ist nicht nur Best Practice — sie ist bei vielen Enterprise-Kunden vertragliche Anforderung.

Vertiefung II — Strategische Ebene — Monitoring-Reife und Automatisierung

Von reaktivem zu proaktivem Monitoring

Die meisten Organisationen beginnen mit reaktivem Monitoring: Ein Vorfall passiert, danach werden Logs analysiert und Alerting eingerichtet. Proaktives Monitoring antizipiert Probleme, bevor sie zu Incidents werden.

Das Reifegradmodell für KI-Monitoring:

Stufe 1 — Kein Monitoring: Probleme werden nur durch Nutzerbeschwerden bekannt.

Stufe 2 — Basismonitoring: Kosten-Monitoring, grundlegende Uptime-Überwachung, manuelle Log-Durchsicht.

Stufe 3 — Alerting: Automatische Benachrichtigungen bei Schwellenwertüberschreitungen (Kosten, Latenz, Fehlerrate).

Stufe 4 — Qualitätsmonitoring: Automatisierte Eval-Runs mit Qualitätskennzahlen, Trend-Analyse über Zeit, Modell-Drift-Erkennung.

Stufe 5 — Prädiktives Monitoring: ML-basierte Anomalie-Erkennung, automatische Root-Cause-Zuordnung, vorausschauende Kapazitätsplanung.

Die meisten Organisationen sollten Stufe 3 als kurzfristiges Ziel anstreben und Stufe 4 als mittelfristiges Ziel setzen. Stufe 5 ist für die meisten KMU weder notwendig noch wirtschaftlich sinnvoll.

LLM-Observability-Plattformen im Vergleich

Seit 2023 hat sich ein eigenes Ökosystem an LLM-Observability-Tools entwickelt. Die wichtigsten Optionen für Unternehmen:

Für europäische Unternehmen mit DSGVO-Anforderungen ist Langfuse mit Self-Hosting-Option die empfohlene Ausgangswahl, da Logs personenbezogene Daten enthalten können und der Verarbeitungsort EU-seitig kontrollierbar sein muss.

Dashboarding und Visualisierung für nicht-technische Stakeholder

Monitoring-Daten sind nur dann wertvoll, wenn sie die richtigen Menschen in einem Format erreichen, das sie verstehen und auf das sie reagieren können. KI-Beauftragten und Geschäftsführung brauchen andere Dashboards als die IT:

Dashboard für KI-Beauftragten (operative Übersicht): - Nutzungsintensität pro System (Anfragen/Tag, Trends) - Qualitäts-Score aus letztem Eval - Offene Alerts und deren Status - Kosten vs. Budget (aktueller Monat)

Dashboard für Geschäftsführung (Executive Summary): - KI-ROI: Gesparte Zeit vs. Kosten (wenn messbar) - Compliance-Status (Ampel: alle Systeme dokumentiert und assessiert?) - Vorfalls-Zusammenfassung des letzten Monats - Nächste anstehende Governance-Aktivitäten

Dashboard für IT-Security: - Sicherheits-Alerts und Anomalien - Fehlgeschlagene Eingaben (potenzielle Injection-Versuche) - Zugriffs-Logs auf sensible Systeme - AVV-Compliance der genutzten Dienste

Diese unterschiedlichen Dashboard-Perspektiven können mit Tools wie Metabase, Grafana oder einem integrierten BI-Tool auf dieselbe Datenquelle (Logging-Datenbank) zugreifen.

Merksatz

Monitoring-Daten haben nur dann Wert, wenn sie die richtigen Menschen im richtigen Format erreichen. Technische Logs für KI-Beauftragten; aggregierte KPI-Dashboards für Geschäftsführung; Sicherheits-Alerts für IT. Dasselbe Monitoring-System kann alle drei bedienen.

Vertiefung IV — KI-Kosten als Governance-Signal

Kostenanomalien als Sicherheitsindikator

Ungewöhnlich hohe Token-Verbräuche oder API-Kosten sind nicht nur ein Budget-Problem — sie können ein Sicherheitssignal sein:

Szenario A — Prompt-Injection-Attacke: Eine gezielte Injection veranlasst das Modell zu extrem langen Ausgaben (sogenannte „Infinity Output”-Attacke, OWASP LLM04). Das erhöht die API-Kosten drastisch und kann zu Rate-Limit-Überschreitungen führen.

Szenario B — Credential-Missbrauch: Ein API-Key, der in einem öffentlichen Repository oder einer Anwendung exponiert wurde, wird von Dritten für eigene Zwecke genutzt. Das Ergebnis: Massive Kostenanfragen auf dem eigenen Account ohne entsprechende Nutzung im eigenen System.

Szenario C — Abuse durch interne Nutzer: Mitarbeitende nutzen den Unternehmens-API-Key für private Zwecke oder für Use-Cases, die nicht vom Einsatzzweck gedeckt sind.

Alle drei Szenarien werden durch konsequentes Kosten-Monitoring frühzeitig erkannt. Ein Budget-Alert bei 150% des Monatsdurchschnitts ist ein robuster Frühwarnmechanismus.

Capacity Planning für KI-Systeme

Wachsende Nutzung führt zu wachsenden Kosten — und irgendwann zu Budget-Überschreitungen. Ein proaktives Capacity-Planning verhindert unangenehme Überraschungen:

Nutzungs-Trend-Analyse: Monatliche Nutzungszahlen werden als Zeitreihe geführt. Wachstumsrate wird berechnet und in Budget-Planungen einbezogen.

Use-Case-Wachstum antizipieren: Wenn ein neuer Use-Case (z. B. Erweiterung des Assistenten auf eine weitere Abteilung) geplant ist, wird der erwartete Nutzungsanstieg vorab geschätzt und budgetiert.

Tier-Management beim Anbieter: Viele Anbieter bieten Volumenrabatte für höhere Nutzung. Wenn die Nutzung einen Schwellenwert überschreitet, ist die Verhandlung eines Volumenvertrags wirtschaftlich sinnvoll.

Diese Kapazitätsplanung ist Teil des monatlichen KI-Status-Reports und wird von den KI-Beauftragten koordiniert.

Vertiefung V — Monitoring in Multi-Tenant- und Multi-System-Umgebungen

Monitoring-Aggregation über mehrere KI-Systeme

Sobald eine Organisation nicht ein, sondern mehrere KI-Systeme parallel betreibt (z. B. Wissensassistent, Angebotsgenerator, Code-Assistent), stellt sich die Frage der Monitoring-Aggregation: Wie behält man den Überblick über alle Systeme gleichzeitig?

Das empfohlene Vorgehen:

Einheitliches Logging-Schema: Alle KI-Systeme schreiben Logs in dasselbe Schema (System-ID, Zeitstempel, Nutzer-ID, Anfrage-Typ, Token-Verbrauch, Latenz, Qualitäts-Score). Das ermöglicht systemübergreifende Analysen und vergleichende Dashboards.

Zentrales Monitoring-Dashboard: Ein Dashboard aggregiert Metriken über alle Systeme — aufgeschlüsselt nach System, Nutzergruppe und Zeitraum. Anomalien bei einem System werden sofort sichtbar, auch wenn das andere System normal läuft.

Portfolio-Qualitätsbericht: Monatlich wird für alle aktiven KI-Systeme ein Portfolio-Bericht erstellt: Qualitäts-Scores im Trend, Kosten-Übersicht, Nutzungsintensität. Dieser Bericht ist die Grundlage für den monatlichen KI-Status-Report an die Geschäftsführung.

Monitoring als Teil der Betriebsübergabe

Wenn ein KI-System in Betrieb genommen wird, muss das Monitoring-Setup Teil der Übergabe an den laufenden Betrieb sein. Eine Übergabe-Checkliste für KI-Systeme:

Logging-Konfiguration validiert (alle relevanten Daten werden erfasst)

Dashboard-Zugang für KI-Beauftragten und IT eingerichtet

Alerting-Schwellenwerte konfiguriert und getestet

Kill-Switch dokumentiert und getestet

Monitoring-Eskalationspfad definiert (wer wird bei Alert kontaktiert?)

Erste Baseline-Metriken erfasst (für spätere Vergleiche)

Diese Checkliste stellt sicher, dass kein System in Produktion geht, bevor das Monitoring operativ ist — ein häufig vernachlässigter Schritt, der im Incident-Fall zum Problem wird.

Abschluss: Monitoring als Vertrauensinfrastruktur

Monitoring ist mehr als Kostenkontrolle und Fehlererkennung — es ist die technische Grundlage des Vertrauens in KI-Systeme. Ohne Monitoring weiß niemand, ob das System heute noch genauso funktioniert wie bei der Einführung. Mit Monitoring ist diese Frage jederzeit beantwortbar: Die Qualitätskennzahlen sind aktuell, die Kosten sind im Rahmen, keine Anomalien im Log. Dieses Wissen ist die Grundlage für das Vertrauen der Geschäftsführung, der Mitarbeitenden und — im Prüfungsfall — der Aufsichtsbehörden.

Quelle: KI-Wissensbasis von MindsMachines, Edition Juni 2026. Vollständige Fassung mit Anhängen und Musterlösungen: als PDF anfordern.