ki-engineeering/25-incident-response.md

Incident Response

03:00, Pager: Cost-Spike 4×, parallel Tickets „Antworten plötzlich nutzlos“, ein Safety-Report im Trust-Channel. HTTP-Dashboards: unauffällig. Der On-Call kennt das DB-Failover-Runbook auswendig — für „Model-Alias hat rotiert und Repair-Loop frisst Tokens“ gibt es drei widersprüchliche Slack-Threads und keinen Kill-Switch.

AI-Incidents sind oft keine klassischen Outages. Das System antwortet, nur falsch, teuer, unsicher oder zu langsam. Ohne spezielles Runbook verlängert sich die Mean-Time-to-Mitigate in Schuldzuweisungen an „die KI“.

Kern in einem Satz: Incident Response für AI-Capabilities heißt stabilisieren (Flag, Cap, Fallback, Rollback), Evidence sichern, spez-gekoppelt diagnostizieren und nachbereiten — mit Runbooks für Cost, Quality, Latency, Safety und Tool-Abuse (T8, T9, T10).

Lebende Vorlage: templates/incident-runbook-ai.md. Messung → Kapitel 22; Quality-Drops → Kapitel 18; Lifecycle/Rollback → Kapitel 24; Security → Kapitel 19.

---

Bridge: Klassisches SE → AI Engineering

Klassisches SE	AI-Incident …
SEV / Pager / IC	dasselbe Rollenmodell; zusätzlich Prompt/Model/Eval-Owner
Mitigate: rollback deploy, scale, failover	plus Model/Prompt-Pin zurück, Tier-down, Tool disable, Budget cap
Error budget burn	Quality- und Cost-Budget burn
Blameless postmortem	inkl. fehlender Signals, unpinned deps, Gate-Lücken
Status page „degraded“	ehrliche UX: Entwurf/Mensch/Read-only — nicht „AI denkt nach“ ewig
Forensics: logs, metrics	Traces mit Versionen, redacted samples, Golden repro
Security incident process	Safety/Leakage/Tool-Abuse sofort in denselben Schweregrad-Kanon

Die Brücke: Incident Command bleibt SE. Die Mitigations- und Evidence-Werkzeuge erweitern sich um Harness- und Model-Hebeln.

---

Incident-Klassen

Mehrere Klassen können gleichzeitig brennen — priorisiert Safety vor Cost vor Quality vor Komfort.

Klasse	Symptome	Erste Stabilisierung
Safety / Security	Policy-Violation, Leakage, Injection-Erfolg, Tool-Abuse	Feature flag off / deny tools / block egress; Security-Pfad
Cost spike	€/h, Tokens/h, ein Tenant dominiert	Caps, rate limit, tier-down, disable heavy path
Quality drop	Feedback, task success, repair_rate, human reject	Canary halt, pin rollback, degrade
Latency / timeouts	TTFT/Total, 504, queue depth	timeout/caps, async offload, provider failover
Provider outage	5xx/429-Sturm, circuit open	Fallback-Provider/Model, degraded mode
Data / Index	plötzlich falsche Citations, leere Hits	index pin/rollback, retrieval disable → safe refuse

Schweregrade (Beispiel-Schema — an eure Org anpassen):

SEV	Beispiel
1	bestätigte Data-Leakage, missbräuchliche Writes, Safety-Rot in Prod
2	starker Quality-Collapse auf Kern-Feature, Cost-Bleed ungebremst
3	begrenzter Slice, Workaround möglich, Canary gestoppt
4	lokal, kein User-Bleed, Prozessverbesserung

---

Ablauf: Stabilize → Evidence → Diagnose → Resolve

1. Stabilisieren (Minuten)

Ziel: Bleed stoppen, nicht Root Cause finden.

Checkliste (Reihenfolge situationsabhängig):

1. Traffic drosseln / Feature-Flag / Kill-Switch der Capability
2. Budget Caps enger; Strong-Tier und Agent-Pfade aus
3. Tools mit Side Effects disable oder read-only
4. Model/Prompt-Pin auf last-known-good
5. Provider failover oder degrade (Cache, Template, Human-Queue)
6. Status intern (+ extern wenn user-facing)

Stop the bleed → safe degraded service > perfect root cause under fire

2. Evidence sichern

Bevor jemand „kurz den Prompt ändert“:

Evidence	Inhalt
Zeitfenster	start, detect, mitigate
Versionen	model_id, prompt, index, config, deploy
Traces	Sample Request-IDs (redacted)
Metrics	error, latency, cost, quality, fallback
Provider	status page, 429/5xx, changelog
Repro	Golden Case oder anonymisiertes Sample offline

Retention und Redaction beachten (Kapitel 20) — Incident ist kein Freifahrtschein für PII-Exports in private Disks.

3. Diagnostizieren

Fragen aus dem Runbook:

• Was hat sich seit last green geändert? (Deploy, Pin, Index, Policy, Traffic-Mix, Provider)
• Ist es global oder Slice (Tenant, Locale, Channel, Intent)?
• Primary vs. Fallback-Pfad?
• Validation/Repair-Loop? (Cost × Quality)
• Retrieval leer/korrupt?
• Abuse / eval-poisoning / prompt flood?

Eine Hypothese nach der anderen testen. Drei gleichzeitige Hotfixes zerstören Kausalität.

4. Resolve & kommunizieren

Pfad	Wann
Rollback	nach Change, Safety, unklare Regression
Fix-Forward	Ursache klar, Fix klein, Canary möglich, Rollback bleibt warm
Degraded longer	Provider/Daten brauchen Zeit; UX ehrlich

Kommunikation: was betroffen, was Nutzer tun sollen (neu versuchen / Mensch / Feature offline), nächstes Update-Zeitfenster. Keine Garantie-Rhetorik („AI halluziniert nie wieder“).

---

Runbook-Bausteine (pro Capability)

Mindestinhalt — Vorlage: incident-runbook-ai.md.

Abschnitt	Inhalt
Symptome	Hakenliste Klassen
Dashboards	Links, welche Panels
Kill-Switches	Flags, Config-Keys, wer darf
Rollback	exakte Pins / Commands / PR-template
Fallback	degraded behavior spezifiziert
Kontakte	Capability-Owner, Platform, Security, Legal (bei Leak)
Evidence pack	was exportieren, wohin (ACL)
Eskalation	SEV-Matrix

Üben: einmal pro Quartal Tabletop oder Game Day (Cost-Spike simulieren, Pin rollback dry-run). Ungeübte Runbooks sind Wiki-Fiction.

---

Spezielle Playbooks (kurz)

Cost Spike

1. Top feature_key / Tenant / model_id nach €/h
2. Caps + rate limits sofort
3. Suche: Repair-Loop, Agent ohne Cap, Cache cold, Abuse, Shadow 100 %, neues Strong default
4. Mitigate → dann Root Cause

Quality Drop

1. Seit wann? Welcher Pin/Deploy?
2. Canary stop / rollback pin
3. Offline Golden repro
4. Slice-Analyse (nicht nur Global-Durchschnitt)
5. Kein Prompt-Hotfix ohne Version und Mini-Gate

Safety / Leakage / Tool-Abuse

1. Isolate (flag, tool deny, token revoke)
2. Security-Incident-Prozess parallel
3. Samples unter ACL; ggf. Nutzer-/Behördenpfad laut Org-Policy
4. Gates und Guardrails als Follow-up, nicht als einzige Sofortmaßnahme

Latency / Provider

1. Circuit / failover
2. Heavy paths async oder off
3. Queue-Backlog drain policy
4. TTFT vs. Total vs. Queue-Wait trennen (Kapitel 21, 23)

---

Postmortem: AI-spezifische Fragen

Blameless, mit Action Items (Owner, Datum):

Frage	Warum
Welches Signal fehlte oder war zu spät?	Obs-Lücken
War etwas unpinned / undokumentiert?	T9
Hätten Offline-Gates das fangen müssen?	Eval-Schuld
War Rollback zu langsam?	Release-Design
Multiplikatoren (Repair/Agent) bekannt?	Caps
Privacy bei Evidence eingehalten?	T8/Trust
Runbook unbrauchbar/fehlend?	Prozess

Action Items priorisieren: Mitigate-faster > Detect-earlier > Prevent. Ein Postmortem ohne Config-/Gate-Änderung ist ein Blogpost.

---

Patterns und Trade-offs

Pattern: One-click degrade

Feature-Flag-Matrix: full → no_tools → template_only → off.

Trade-off: UX-Arbeit im Voraus; Incident-Minuten gespart.

Pattern: Incident roles include model owner

IC + Ops + Capability/Model-Owner in der ersten Eskalationszeile.

Trade-off: mehr Personen on-call-fähig machen; kürzere MTTM.

Pattern: Frozen window after promote

Nach Model-Promote: erhöhte Wachsamkeit, keine parallelen Prompt-Experimente.

Trade-off: Geschwindigkeit; klarere Kausalität.

Pattern: Cost circuit breaker

Automatisch tier-down oder flag bei €/h-Schwelle.

Trade-off: False positive möglich; gegen Ruin trotzdem oft richtig — mit Alert an Menschen.

Decision Frame: Rollback vs. Fix-Forward unter Feuer

Lage	Wahl
SEV-1 Safety	isolate + rollback/off
Regression klar an Pin-Change	rollback
Provider partial out	failover, nicht Prompt-Tuning
Ein Edge-Case viral	sample + gezielter Fix; nicht global panic ohne Daten
Unklar	stabilize + evidence; keine Multi-Hotfixes

Trade-off: aggressive auto-mitigation vs. manuell

Auto (caps, circuit)	Nur manuell
schneller Bleed-Stop	weniger Überraschung
kann UX hart degradieren	langsamer nachts

Hybrid: Auto für Cost/Rate/Provider; Quality-Rollback oft mit Menschen-Augen auf Canary-Schwellen.

---

Anti-Patterns

Anti-Pattern	Symptom	Besser
„Modell schuld“ ohne Trace	keine Versionen	Evidence first
Hotfix ohne Pin	zweites Incident	versioniert + mini-canary
Nur HTTP-Runbook	Quality-Bleed unadressiert	AI-Runbook-Klassen
Debug with full PII in Slack	Folge-Incident	redacted channels
Three changes at once	unklar was half	eine Variable
No kill switch	Bleed bis Deploy-Pipeline	flags vor Launch
Ignore cost as incident	Monatsende-Schock	Cost-SEV + breaker
Postmortem without owners	Wiederholung	Action Items datiert
Status: all good bei Degrade	Trust-Schaden	ehrlich kommunizieren
Skip security on „quality“ ticket	Tool-Abuse übersehen	Klassen-Checkliste

---

Production Notes

Cost. Incidents fressen Tokens (Shadow, Repro, Retry-Stürme) und Menschenzeit. Cost-Spike ist ein Incident-Typ mit eigenem SEV (T7). Automatische Caps sind billiger als forensische Buchhaltung hinterher.

Latency. Mitigate kann Latency opfern (Queue) oder verbessern (strip steps). In der Status-Komm. sagen, was Nutzer spüren.

Observability. Ohne Versionen und Cost/Quality-Panels verlängert sich jeder AI-Incident (Kapitel 22). Evidence-Pack-Pfade vor dem Ernstfall testen.

Security. Safety- und Privacy-Incidents folgen dem strengeren Prozess; Engineering-Mitigation (flag/tools) parallel, nicht statt Security (Kapitel 19, 20).

Lifecycle. Viele AI-Incidents sind Lifecycle-Incidents in Zeitlupe: unpinned Updates, ungecanaried Swaps (T9). Nach dem Löschen der Flammen: Checklist und Pin-Registry härten (Kapitel 24). Mensch bleibt Owner der Entscheidung Rollback/Off (T10).

---

Key Takeaways

• AI-Incidents: oft grünes HTTP, rotes Verhalten — Klassen Cost, Quality, Latency, Safety, Tools, Index.
• Stabilize first: Flag, Cap, Tool-Deny, Pin-Rollback, Degrade.
• Evidence mit Versionen und redacted Traces vor Multi-Hotfixes.
• Runbooks pro Capability üben; Vorlage: incident-runbook-ai.md.
• Postmortems schließen Gate-, Pin- und Signal-Lücken — mit Owner und Datum.
• Safety vor Cost vor Komfort; Mensch entscheidet Eskalation und Kommunikation (T10).

Praktische nächste Schritte

1. Kopiert templates/incident-runbook-ai.md für eure Top-Capability; füllt Kill-Switches und Dashboard-Links.
2. Verifiziert: Feature-Flag und last-known-good Pins sind in <5 Minuten aktivierbar.
3. Richtet Cost-Spike- und Quality-Drop-Alerts mit Runbook-Link ein (Kapitel 22).
4. Plant einen 60-Minuten-Tabletop: „Repair-Loop × Strong-Tier“.
5. Klärt Eskalation Security bei Leakage/Tool-Abuse schriftlich.
6. Teil V schließt hier; Organisation und Reife: Team, Ownership, Review.