Kapitel 11 — Observability, Logging und Incident Response

Elfter Beitrag im Kapitel-für-Kapitel-Walkthrough zu LLM Primer VII: KI-Sicherheit. Das Kapitel behandelt Logging, Alerting und Incident Response als die Schicht, die architektonische Abwehr in ein System verwandelt, das Betreiber tatsächlich fahren können.

Warum es dieses Kapitel gibt

Ein System mit der richtigen Struktur, aber ohne Sichtbarkeit versagt unsichtbar. Kapitel 11 walkt die Observability-Schicht für LLM-Systeme — was zu loggen ist, wie Missbrauch und Anomalie zu erkennen sind, wie ohne Rauschen zu alarmieren ist, wie ein Incident-Response-Playbook läuft, wenn etwas schiefgeht, und wie man aus dem Vorfall lernt. Die allgemeinen Disziplinen übertragen sich vom operativen Engineering anderswo, mit LLM-spezifischen Erweiterungen: probabilistische Ausgaben bedeuten, dass die Reproduktion eines Vorfalls mehr Zustand erfordert als in deterministischen Systemen; die OpenTelemetry-GenAI-Semantik-Konventionen, seit 2024 entwickelt, liefern das anbieterneutrale Vokabular für diesen Zustand.

11.1 Was zu loggen ist, ist eine Policy-Entscheidung, kein Default

Zu wenig zu loggen lässt das Team ohne Untersuchungsgrundlage. Zu viel zu loggen schafft Compliance-, Kosten- und Datenschutzprobleme, die schließlich zu Reduktion zwingen. Die vertretbare Position ist das Minimum, das die vom Team identifizierten operativen Anwendungsfälle stützt, in einer strukturierten Form, die jeden davon bedient. Die Zwecke umfassen typischerweise Echtzeit-Alerting auf Missbrauch oder Anomalie, nachträgliche Untersuchung von Vorfällen, Kapazitätsplanung und Kostenanalyse, Compliance-Berichte und kontinuierliche Evaluation des Modellverhaltens. Jeder Zweck stellt andere Anforderungen ans Schema; ein Log, das für einen entworfen wurde, ist für die anderen unzureichend. Die OpenTelemetry-GenAI-Semantik-Konventionen definieren Spans und Attribute für den LLM-Aufruf — Modellname, Anbieter, Anfrageparameter, Prompt-Inhalt, Antwort-Inhalt, Token-Zahlen, Latenz, Kosten —, die nachgelagerte Werkzeuge die gleiche Telemetrie unabhängig vom konkreten SDK parsen lassen. Langfuse, Helicone, Arize Phoenix und Datadog LLM Observability konsumieren alle diese Form. Ein produktiver Log-Eintrag enthält typischerweise die Request-ID, den authentifizierten Principal, den Mandanten, die Modellversion und den Anbieter, den vollständig zusammengebauten Prompt (mit abgerufenem Kontext und dessen Provenienz), die Werkzeugaufrufe und ihre Ausgaben, den Antwortinhalt, die Sicherheitsklassifiziererwerte am Input und Output sowie Latenz und Token-Bilanz. Dies verantwortungsvoll zu speichern heißt, explizit über Aufbewahrungsfenster, PII-Behandlung und Zugriffssteuerung auf den Log-Store selbst zu sein.

11.2 Erkennung komponiert Signatur-, statistische und Verhaltenssignale

Ist die Telemetrie strukturiert, ist die nächste Frage, welche Muster darauf hinweisen, dass etwas falsch läuft. Signatur-Matching ist die billigste erste Linie — bekannte Prompt-Injection-Phrasen, DAN-artige Präambel, base64-codierte Nutzlasten, Rollenspiel-Setups, die schon zuvor beobachtet wurden. Die Liste wird aus öffentlicher Forschung, interner Red-Team-Arbeit und vergangenen Vorfällen gebaut. Signaturen fangen bekannte Varianten; Angreifer passen sich an, sobald sie erfahren, welche Phrasen markiert werden. Statistische Anomalieerkennung achtet auf Abweichung von einer Grundlinie: ungewöhnliche Token-Verteilungen, atypische Latenz-zu-Länge-Verhältnisse, plötzliche Spitzen in Verweigerungsraten oder in der Rate spezifischer Werkzeugaufrufe. Grundlinien driften unter normalen Bedingungen langsam und verschieben sich abrupt unter anormalen. Verhaltensmusterkennung matcht Missbrauchsprofile auch dann, wenn einzelne Anfragen nicht offen bösartig sind — ein einzelner Principal, der Tausende paraphrasierter Varianten derselben restringierten Anfrage stellt; eine Spitze bei Anfragen, die legitimen Inhalt mit einem spezifischen Suffix kombinieren; ein schleichender Drift in Antwortverteilungen pro Nutzer. Erkennung ist nur nützlich, wenn sie zu Alerts führt, auf die Betreiber tatsächlich reagieren. Die Taxonomie unterscheidet typischerweise critical (aktiver Missbrauch in Größenordnung, Piepser für Bereitschafts-Engineer), high (bemerkenswertes Muster mit begrenztem Schaden, Benachrichtigung zu Bürozeiten) und medium/low (Dashboards und wöchentlicher Review). Alert-Ermüdung ist der Fehlermodus; strenge Severity-Disziplin verhindert ihn.

11.3 Incident Response ist ein Playbook, keine Improvisation

NIST SP 800-61 Revision 2 gibt das Rahmenwerk — Vorbereitung, Erkennung und Analyse, Eindämmung, Beseitigung, Wiederherstellung, Nach-Vorfall-Aktivitäten —, das das LLM-spezifische Playbook erweitert. Vorbereitung bedeutet, dass Runbooks, Bereitschaftsrotationen und Zugriff auf das relevante Werkzeug existieren, bevor der Vorfall passiert. Erkennung und Analyse ist der Punkt, an dem die Observability aus 11.1 sich auszahlt. Eindämmung eines LLM-Vorfalls kann heißen, ein Feature-Flag zu setzen, um ein Werkzeug zu deaktivieren, auf eine konservativere Modellversion herunterzustufen, Rate Limits auf einen spezifischen Principal oder Mandanten zu verschärfen oder Traffic auf einen alternativen Stack umzuleiten. Beseitigung hängt vom Vorfalltyp ab: ein Jailbreak braucht vielleicht eine zusätzliche Filterregel, ein kompromittiertes RAG-Dokument muss aus dem Index entfernt werden, ein geleaktes Credential muss rotiert werden. Wiederherstellung ist, wenn das System zur Normalität zurückkehrt, mit umgekehrter Eindämmung und verifizierter Beseitigung. Nach-Vorfall-Aktivitäten sind, wo sich die modellspezifische Arbeit konzentriert: das Verhalten wenn möglich reproduzieren, die Fehlergrenze charakterisieren, entscheiden, ob der Vorfall etwas über das Modell aussagt, das ändern sollte, wie es genutzt wird, und das Ergebnis in die Evaluationssuite einspeisen, damit künftige Regressionen vor Deployment gefangen werden. Reproduktion ist unter Sampling mit Nicht-Null-Temperatur nicht immer möglich, aber das Ziel ist, zu definieren, wann das unerwünschte Verhalten auftritt.

Was Kapitel 11 vorbereitet

Kapitel 12 schließt Teil IV mit der Identitäts- und Zugriffsschicht ab — wer mit dem System interagieren darf, zu welchen Bedingungen und wie die Durchsetzung über Komponenten strukturiert ist. Die klassischen Disziplinen gelten: Authentifizierung mit API-Schlüsseln, OAuth und mTLS; Autorisierung mit RBAC und ABAC; mandantenweise Isolation; Rate Limits und Kontingente; Enterprise-Governance-Overlays. Die LLM-spezifischen Erweiterungen betreffen das Modell als Principal — ein Agent, der im Namen eines Nutzers handelt, hat eine eigene Identität und eigene Berechtigungen —, die Rolle von Capability-Tokens für Werkzeugaufrufe und die mandantenspezifische Konfiguration des Modellverhaltens, die multi-mandantenfähige LLM-Plattformen unterstützen müssen. Kapitel 13 eröffnet dann Teil V mit der regulatorischen Landschaft, wo die technischen Kontrollen dieses Buches auf den AI Act, die DSGVO, US-Bundesstaatsgesetze und die umgebenden Frameworks abgebildet werden müssen.

Als Nächstes — Kapitel 12: Zugriffssteuerung und Identität. Authentifizierung, RBAC gegen ABAC, mandantenweise Isolation, Rate Limits und das Enterprise-Governance-Overlay, das LLM-Systeme in regulierten Umgebungen nutzbar macht.