0 Fork 0

Files

T

grok-bot 63589e684a Faktencheck-P1/P2: Legal, Framing, Konsistenz und Hyperref

AI Act/OWASP und Residenz/Log-TTL in Kap. 19–20, Framing- und
Taxonomie-Fixes quer durch Manuskript und Templates, Kap.-10-Anker
im Assembler; Handoff fortgeschrieben.

2026-08-02 23:40:48 +02:00

24 KiB

Raw Permalink Blame History

Anhang D: Entscheidungsmatrizen

Schnell-Referenz der zentralen Decision Frames aus dem Buch — zum Ausdrucken, Whiteboard und Workshop. Kein Ersatz für die Kapitel: Begründung, Anti-Patterns und Production Notes stehen dort. Hier zählt Handlungsfähigkeit: Welche Tendenz gilt unter welcher Bedingung?

Lebende Vorlagen und Checklisten (kopierbar, oft ausführlicher):

Artefakt	Zweck
checklists/wann-llm.md	Ampel pro Teilproblem
templates/adr-adaptation.md	Adaptation Ladder festhalten
checklists/agent-readiness.md	Agent vs. Pipeline
templates/adr-model-hosting.md	Tier, Routing, Hosting
templates/model-change-checklist.md	Shadow / Canary / Promote
templates/incident-runbook-ai.md	Stabilize, Rollback, Fix-Forward

Nutzungshinweis

Diese Matrizen sind Trade-off-Rahmen, keine Binär-Dogmen und keine Naturgesetze.

Pro Capability / Schnitt entscheiden, nicht pro Epic („KI-Support“ enthält grüne, gelbe und rote Teile).
Tendenz ≠ Pflicht. Frontier-Modelle, Domäne und Reife verschieben Grenzfälle — die strukturellen Gründe (Eval, Varianz, Kosten, Ownership) bleiben.
Unklar → konservativer Default (kein LLM / niedrigere Ladder-Stufe / Pipeline / API / Canary / HITL).
Evidenz vor Aufstieg. Ohne Messlatte (Golden Set, Online-Signale, €/Task) ist „wir brauchen Agent/FT/Strong“ eine Meinung.
Abstieg ist Engineering. Zurück auf eine leichtere Stufe ist oft die richtige Antwort — kein Gesichtsverlust.

Workshop-Modus: eine Matrix pro Entscheidung, eine Zeile begründen, verworfene Alternative nennen, Owner und Review-Trigger notieren.

1. Wann LLM? (Ampel)

Bezug: Kapitel 05, Checkliste wann-llm.md.

Die erste Entscheidung ist ob und wo ein Foundation Model — nicht welches Modell und welcher Prompt. Ampel pro Teilproblem. Hybrid ist der professionelle Normalfall: Sprache/Varianz am Rand, harte Wirkung im deterministischen Kern.

Ampel	Typische Signale	Entscheidung	Mindest-Disziplin
Grün	unstrukturierte / stark variable Eingaben; prüfbares Ziel (Labels, Schema, Review); Fehler tolerierbar oder abfangbar; Nutzen > Runtime-Komplexität	LLM sinnvoll (`ja` oder hybrid mit klarem LLM-Anteil)	Spec, Eval/Stichprobe, Prompt-Version
Gelb	nutzer-sichtbare Fakten; Tools/Seitenwirkungen; Volumen/Kosten heikel; Produkt-Agent; PII im Context	Hybrid + Guardrails — nicht blind shippen	Grounding/Citations oder Policy im Code; Caps; oft HITL; Privacy-Grenzen
Rot	klare if/else-Policies; Geld/Bestand allein durchs Modell; Lookups/Kataloge; AuthZ/Krypto; kein Eval/Owner; asymmetrisches Risiko	kein LLM (oder nur kosmetisch nach Fakten aus Code/DB)	deterministischer Baustein; Feature stoppen oder Scope auf Entwurf-ohne-Wirkung

Realitätscheck (alle müssen tragbar sein): Job-to-be-done · Orakel-Test (5 % überzeugend falsch?) · Eval in ~2 Wochen · Budget €/p95 · Ownership (Prompt/Model + On-Call).

Wenn …	dann …
endliche Regeln, stabile Inputs	Rot — Code/Regeln
Sprache/Varianz, prüfbares Ziel, Eval möglich	Grün — LLM mit Spec/Eval
Fakten + Wirkung oder Volumen heikel	Gelb — hybrid + Guardrails
kein Eval, kein Owner	Stopp — nicht bauen

Default-Tendenz: Ampel pro Schnitt; bei Zweifel Gelb/hybrid oder Rot, nicht „Strong-Modell und Hoffnung“. Entscheidungssprache: ja / nein / hybrid plus ein Satz Begründung und Hybrid-Schnitt.

2. Adaptation Ladder — welche Stufe?

Bezug: Kapitel 08, ADR adr-adaptation.md.

Von unten starten (Lowest Competent Rung), nur mit Climb Signals steigen, Abstieg erlaubt. Stufen kombinieren ist normal — primäre Stufe im ADR festhalten.

Stufe	Was	Wann typisch	Braucht mindestens
1 Prompt-only	System/User, Few-Shots, Freitext	Entwürfe, niedrige Wirkung, Mensch liest mit	Prompt-Version, Stichproben-Eval
2 Structured	Schema + Validate/Repair	Extraktion, Routing, alles was Code konsumiert	Schema-Contract, Golden Set Feldebene
3 RAG / Grounding	Retrieval + Citations / Refuse	Antworten über euren Korpus; Halluzination = P0	Korpus-Owner, Index-Version, Retrieval-Eval
4 Tools + Workflow	fester Graph im Code, LLM an Knoten	bekannter Fachprozess, kontrollierte Wirkung	Tool-Contracts, least privilege, Idempotenz
5 Produkt-Agent	Modell wählt Schritte in der Schleife	Pfad echt offen, Tool-Wahl dynamisch	agent-readiness, Caps, Trajectory-Eval, Kill-Switch
6 FT / Distill	Gewichte / kleines Modell	Plateau auf 1–5 belegt; Format/Stil/€/Latenz	Daten-Owner, Train+Serve+Rollback, Paritäts-Eval
7 Custom Train	eigenes Foundation / massives Continue-Pretrain	extrem selten (strategisch, Residenz/IP)	ML-Engineering-Track — kein Sprint-Backlog

Schnellwahl nach Problemtyp

Problemtyp	Startstufe	Erst steigen, wenn …
Entwurf / Umformulieren	1	Struktur downstream → 2
Extraktion / Routing	2	Fakten aus Korpus → 3
Fragen über interne Docs	3	Live-Systeme lesen/schreiben → 4
Bekannter Fachprozess	4	Pfad unmöglich vorab zu modellieren → 5
Offene Multi-Tool-Aufgabe	5 eng	sonst zurück zu 4; nur mit Readiness
Format/Latenz/Kosten-Plateau	2–4 stabil	Messungen zwingen 6
Eigenes Foundation Model	—	fast nie; separat begründen

Climb Signals (mind. eines, messbar)

Signal	Richtung
Halluzination trotz Prompt	→ 3 Grounding, nicht „längerer Prompt“
Freitext unbrauchbar für Code	→ 2 Structured
Wissen ändert sich / fehlt im Modell	→ 3 RAG (nicht FT als Wiki)
Wirkung in Systemen nötig	→ 4 Tools
State-Machine explodiert (viele Sonderfälle)	→ 5 oder Scope schneiden
Unit Economics / Latenz bei stabilem Task	→ 6 Distill/FT mit Eval-Parität

Default-Tendenz: Stufe 2 an Code-Grenzen; 3 für Fakten; 4 vor 5; 6 meist nicht bis Plateau belegt ist. Ohne Eval kein Aufstieg.

3. RAG vs. Fine-Tuning vs. besseres Prompt/Retrieval

Bezug: Kapitel 08, 12, 15; RAG-Checkliste rag-production-ready.md.

Drei Hebel werden oft vermischt. Default der ehrlichen Praxis: zuerst Prompt/Context und Retrieval, dann RAG-System reifen — Fine-Tuning nur nach nachgewiesenem Plateau und nicht als Dokumentenspeicher.

Kriterium	Besseres Prompt / Context	RAG (besser Retrieval)	Fine-Tune / Distill
Primäres Ziel	Verhalten, Format light, Scope	Fakten aus eurem Korpus, zitierbar	Format/Stil, Domänenton, €/Latenz bei Parität
Wissen ändert sich oft	begrenzt (Prompt-Pflege)	stark (Index/Version)	schwach (Retrain-Last)
Zitierpflicht / Refuse	schwach	Kernfeature	nein (Gewichte ≠ Quelle)
Reversibilität	hoch (Flag, Prompt-Pin)	hoch–mittel (Index-Pin)	niedriger (Checkpoint, Re-FT)
Ops-Last	niedrig	Index, Chunking, Privacy	Train, Serve, Base-Model-Updates
Wann zuerst	immer Baseline	Halluzination / Domänenfakten P0	nach Plateau auf 1–5

Wenn …	eher …
Policies/Docs wöchentlich neu, müssen belegbar sein	RAG
Format bricht, Stil inkonsistent, Task stabil, Fakten extern ok	FT/Distill nach Plateau
Antwort falsch, obwohl Quellen existieren	Retrieval/Korpus, nicht Stronger-Model oder FT
unsicher / Team früh	Prompt + Structured → RAG; meist nicht FT
beides (Form + frische Fakten)	FT für Form + RAG für Fakten

FT-Gate (alle „ja“ nötig, sonst nicht starten): Plateau mit Zahlen · Golden Set + held-out · Daten legal/privacy-klar · Owner für Train+Serve+Rollback · Ziel ≠ „Faktenwissen einbrennen“.

Default-Tendenz: Meist nicht Fine-Tuning. RAG für Wissen; Prompt/Schema/Retrieval zuerst optimieren; Distill/FT für Unit Economics oder hartes Format nach Evidenz.

4. Agent vs. Pipeline (Tool-Workflow)

Bezug: Kapitel 14, 07, Checkliste agent-readiness.md.

Pipeline: Code besitzt den Graphen; LLM an benannten Stationen.
Produkt-Agent: Modell wählt in einer Schleife Tools/Schritte — Code besitzt Caps und Policy.
Produkt-Agent ≠ Coding-Agent (ki-praxis).

Signal	Tendenz
„Wir kennen die 5 Schritte“	Pipeline
Ablauf bekannt, Audit pro Schritt kritisch	Pipeline
strenge p95 / €-SLOs	Pipeline oder Single-Shot
Team ohne Trajectory-Eval / Agent-Ops	kein Agent in Prod
Schritte nicht a priori festlegbar, Tool-Wahl stark kontextabhängig	Agent eng + Caps
„40 Sonderfälle in if/else“	Scope schneiden oder Agent eng — nicht beides halb
hohe Write-Risiken	Pipeline + HITL; Agent nur mit Gates
unklar	Pipeline

Vor Agent-Go-Live (Pflichtgefühl)

Check	Ja?
Tool-Contracts + Allowlist
max steps + max cost + Timeout
Abbruch / Degraded / Kill-Switch
State außerhalb des Chat-Transcripts
Observability pro Step (Trajectory)
Trajectory-Eval oder verbindlicher Plan
HITL vor money / external / irreversible

Default-Tendenz: Pipeline. Agent ist die teurere Runtime (Varianz × Steps × Tokens) — nur bei echtem offenem Pfad und Readiness.

5. Model-Tier und Routing

Bezug: Kapitel 09, ADR adr-model-hosting.md.

Ein Model-Tier ist eine Rolle in der Architektur, keine Vendor-Hitliste. Erst Ladder/Pattern, dann Tier. Strong-by-Default ist selten optimal.

Tier	Typische Aufgabe	Optimiert für	Risiko bei Fehlwahl
Fast/Cheap	Klassifikation, Routing, simple Extraktion, Vorfilter, High-QPS	Latenz, €/Request	zu schwach → stille Fehler
Balanced	Default vieler Produkt-Tasks (Schema, RAG)	Preis-Leistung	ohne Messung: zu teuer oder zu schwach
Strong	hartes Reasoning, schwierige Tool-Wahl, Eskalation	Task Success auf schweren Cases	100 % Traffic → Kosten/Latency-Explosion
Specialized	Embeddings, Code, Vision, Speech, Rerank, Domain/FT	Modalität/Aufgabe	General-LLM missbrauchen

Tier-Tendenz nach Adaptation

Pattern / Stufe	Start-Tendenz
Structured Extraktion, endliche Labels	Fast/Cheap → Balanced
Grounded Answer (RAG)	Balanced; Strong bei harten Queries (oft Retrieval zuerst)
Tool-Workflow	Balanced; Strong nur an kritischen Knoten
Produkt-Agent	Balanced Default, Strong on escalate
Entwurf, niedrige Wirkung	Fast/Cheap oder Balanced

Routing-Strategie

Situation	Eher …
Ein Feature, Start	Single + Pin; später Fallback
Mehrere Task-Typen	Statisches Task-Routing
80 % easy, 20 % hard	Cascade mit harten Escalation-Signals
SLO Availability hoch	Fallback-Kette (Modell/Provider/degraded)
Model-Update bevorsteht	Shadow/Canary vor 100 %

Harte Escalation-Signals (Beispiele): Schema-Fail nach Repair-Cap · Retrieval-miss · Policy-Hit · explizites User-„nochmal genauer“ — nicht weiches „Modell ist unsicher“.

Default-Tendenz: Balanced + statisches Routing; Cascade bei Volumen; Strong nur für Schwanz der Verteilung. model_id pinnen — kein latest in Prod.

6. API vs. Self-Hosting

Bezug: Kapitel 09, 20, 21; ADR adr-model-hosting.md.

Entscheidung nach Betriebs- und Risikoprofil, nicht Ideologie. Häufig reif: hybrid.

Kriterium	Managed API	Self-Host (eigene/infra GPU o. ä.)
Time-to-value	schnell	langsam (Serving, Scale, Upgrades)
Ops-Last	niedrig–mittel	hoch (GPU, Batching, On-Call Infra)
Variable Kosten	Tokens/Requests transparent	CapEx/GPU-Stunden; Idle teuer
Residenz / Kontrolle	Provider-Region, DPA, Policies prüfen	mehr Kontrolle, mehr eigene Verantwortung
Peaks	Provider-Limits, 429-Handling	skalieren müsst ihr
Model-Katalog	Provider-Angebot	was ihr serven und lizenzieren könnt
Quality-Updates	oft Breaking Change von außen (T9)	Timing bei euch; Patch-Last bei euch

Wenn dominant …	Hosting-Tendenz
kleines Platform-Team, unklare Last, schnelle Eval-Iteration	API
harte Residenz / Luftspalt	Self-Host oder region-fix dedizierte Instanz
stabil hohes Volumen, GPU-€/Task nach Rechnung besser	Self-Host prüfen (inkl. Personen-Kosten)
Strong nur selten / Eskalation	API für Strong, ggf. self für Fast-Path
Ops dünn + Compliance lösbar	API + gutes Fallback
Compliance unlösbar mit API	Hosting der Datenklasse anpassen — nicht „hoffen“

Hybrid-Skizze (häufig)

Pfad	Hosting-Idee
Fast/Cheap High-QPS	Self-Host oder günstige API
Strong / seltene Eskalation	API
Embeddings / Spezial	Specialized Serving (API oder self)
Degraded	Cache / Template / Mensch — ohne Modell

Default-Tendenz: API zuerst, es sei denn Residenz, Lastprofil oder Spezial-Serving erzwingen Self-Host — und dann mit Owner für Capacity, Patch und Rollback. Im ADR: € pro erfolgreichem Task grob, inkl. Menschen und Idle.

7. Shadow vs. Canary vs. Big-bang

Bezug: Kapitel 18, 24; model-change-checklist.md.

Model-, Prompt- und Index-Änderungen sind Release-Objekte. Silent Degradation ist der Default-Failure-Mode — HTTP 200 genügt nicht.

Strategie	Was	User-Impact	Stärken	Kosten / Risiken
Offline-Gate	Golden Set, Safety, Cost/Latency-Estimate	keiner	Compiler-Ersatz vor Traffic	Verteilung ≠ Prod
Shadow	Kandidat parallel, User sieht Control	keiner	reale Verteilung, Vergleich	doppelte €; Side Effects nicht doppelt; Privacy
Canary	kleiner Live-Anteil (z. B. 1→5→25→100 %)	ja, begrenzt	Quality/Cost-Stopps live	braucht Stop-Regeln und schnellen Rollback
Big-bang	100 % auf einmal	voll	schnell bei Notfall	hohes Delta-Risiko; Wochenend-Klassiker

Wann was

Situation	Tendenz
Hohes Risiko / starker User-Impact	Offline → Shadow → Canary
Kleiner Prompt-Fix, Offline grün	Canary oft ausreichend
Nur Cost-Opt, Quality-Parität nötig	Shadow stark nutzen
Tool-Writes im Pfad	Shadow read-only / dry-run
Provider-Notfall-Sunset	beschleunigt: Mini-Eval + Canary/Rollback, kein reines Big-bang aus Komfort
Freitag 17:00, großes Delta	nicht Big-bang

Canary Stop-the-line (Schwellen feature-spezifisch): Task-Success/Human-Reject Δ · Safety-Violation kritischer Klasse · Cost/Latency außerhalb Envelope · Repair-/Fallback-Rate explodiert.

Standardweg: Offline green → Shadow (optional) → Canary mit Stop-Regeln → Promote + Watch window → Changelog / Golden-Set-Update.

Default-Tendenz: Kleine, häufige Wechsel mit Offline-Gate + Canary schlagen seltene Big-bangs. Big-bang nur mit bewusstem Risiko und sofortigem Rollback-Pfad — nie als Gewohnheit.

8. Rollback vs. Fix-Forward

Bezug: Kapitel 24, 25; Runbook incident-runbook-ai.md.

Stabilize first. Eine Variable pro Änderung. Rollback muss im Incident-Zeitbudget liegen — sonst ist das Versionskonzept der Bug (T9).

Rollback-Ziele (First-Class)

vorherige model_id / Adapter
vorherige prompt_version
vorherige index_version / Policy-Flag
Feature-Flag off / degraded mode

Decision Frame

Lage / Signal	Wahl
SEV-1 Safety / Privacy	isolate + rollback/off
Regression klar an Pin-/Prompt-/Index-Change	Rollback zuerst
Provider partial/total out	Failover-Pin / degraded — nicht Prompt-Tuning-Chaos
Kleiner Format-Bug, Offline grün reproduzierbar	Fix-Forward mit Mini-Canary
Ein viraler Edge-Case	sample + gezielter Fix; kein globaler Panic-Hotfix ohne Daten
Unklare Ursache	Traffic runter + Evidence; keine Multi-Hotfixes parallel
Cost-Bleed	Cap / tier-down / flag (Circuit Breaker), dann Root Cause

Fix-Forward lohnt eher	Rollback lohnt eher
eng, reproduzierbar, niedriges Blast-Radius	Safety, breite Quality-Regression, unklarer Diff
Offline-Suite bestätigt den Fix	Rollback in Minuten möglich und getestet
Watch window und Owner klar	unter Feuer, Nacht, dünne Besetzung

Default-Tendenz: Bei Safety und klarem Post-Change-Drop Rollback zuerst; Fix-Forward nur mit engem Scope und Mini-Canary. Mensch bleibt Owner der Entscheidung (T10).

9. Human-in-the-loop vs. Autonomie

Bezug: Kapitel 07 (Pattern HITL), 13 (Side-Effect-Klassen), 14, Ampel 05.

Autonomie skaliert nur, wo Schaden begrenzt und reversibel ist — oder wo eine zweite deterministische Prüfung greift. HITL ist First-Class Pattern, kein Afterthought.

Side-Effect-Klassen → Default-Policy

Klasse	Beispiele	Default
read-only	get, search, quote	Auto (mit ACL)
write-internal	Ticket-Update, Draft speichern	oft Auto + Idempotenz
money / rights	charge, Rolle vergeben	HITL oder zweite Prüfung
external comms	E-Mail, Slack, SMS	HITL / Template-only
irreversible	delete, legal send	Default-Deny + Mensch

Matrix: Risiko × Reversibilität

	Leicht reversibel	Schwer / nicht reversibel
Niedriger Schaden	Autonomie ok (Caps, Audit)	Autonomie nur mit strenger Policy + Monitoring
Mittlerer Schaden	Auto + schnelles Undo / Flag	HITL oder dual control
Hoher Schaden (Geld, Rechte, Außenwirkung, Regulierung)	HITL oder deterministische Freigabe	HITL + Default-Deny; LLM nur Vorschlag/Diff

Wenn …	dann …
Entwurf, interne Zusammenfassung, Klassifikation	Autonomie mit Eval
Fakten nutzer-sichtbar, Gelb-Ampel	Grounding; bei Unsicherheit Refuse oder Mensch
Agent/Workflow mit Writes	Allowlist + Klasse; HITL vor money/external/irreversible
„Der Bot entscheidet final“ regulatorisch	nein — Mensch + nachweisbare Regeln
HITL-Queue überläuft	Scope/Autonomie oder Personal — nicht still auto-promote

HITL-Runtime-Minimum: State awaiting_approval · Timeout · Default-Deny · Diff/Vorschlag für den Menschen · Audit-Trail.

Default-Tendenz: Lesen und niedrige Wirkung auto; alles mit Geld, Rechten, Außenwirkung oder Irreversibilität Mensch oder Policy im Code. Mehr Autonomie nur mit messbarer Fehlerrate und reversiblem Pfad — nie nur weil der Demo-Loop „flüssig“ wirkte.

10. Platform investieren? (optional)

Bezug: Kapitel 27 (Einführung/Org), ergänzend 09, 22, 26, 28.

„Platform“ hier: gemeinsame Harness-Fähigkeiten (Model-Access, Eval-Gates, Observability, Pin-Registry, Guardrails) — nicht „ein Chatbot für die Firma“. Investition folgt Wiederholung und Risiko, nicht Hype.

Signal	Eher Feature-lokal bleiben	Eher Platform bauen
Anzahl AI-Capabilities	1–2, gleiche Team-Owner	Faustregel: 2+ Teams oder wiederholte Copy-Paste-Harness (nicht starre ≥3/≥5-Pflicht)
Doppelte Arbeit	erträglich	jeder baut eigenes Routing/Logging/Eval
Incidents / Cost	beherrschbar lokal	Querschnitts-Bleed, keine Attribution (`feature_key`)
Compliance / Residenz	ein Pfad	viele Features, eine Policy-Wahrheit nötig
Model-Lifecycle	ein Pin, selten	viele Pins, Provider-Sunset, Canary-Standard
Reife	Pilot, lernen	Productization, SLOs, On-Call

Abgleich mit Kapitel 27: Platform, wenn gemeinsame Ops-Schmerzen messbar sind (Tracing/Routing/Keys copy-paste, wiederholte Cost/Quality-Incidents, zentrale Residenz/Audit) — nicht weil die Strategy-Slide „AI Platform“ verlangt.

Investitions-Stufen (pragmatisch)

Stufe	Inhalt	Wann
0 Shared nothing	Copy-Paste ok	reiner Pilot
1 Thin platform	Keys, Pin-Registry, Trace-Felder, Cost-Tags	Faustregel: ab zweitem Team / wiederholtem Shared Pain (manchmal schon ab Feature #2)
2 Eval & change	Golden-Set-Runner, model-change-checklist, Canary-Hook	sobald Prod-Traffic wehtut
3 Control plane	Routing-Service, Policy/Guardrail-SDKs, HITL-Queue, Runbooks	multi-team, hohe Last/Risiko

Investition zuerst	Später / nur mit Bedarf
`model_id` + Prompt-Version in Traces	eigenes GPU-Cluster „für die Platform“
Cost-Attribution pro `feature_key`	internes Model-Ranking-Portal
ein Canary-/Rollback-Pfad	Framework-Zoo ohne Owner
Security-Review-Checkliste	Agent-Framework als Pflicht für alle

Default-Tendenz: Pilot feature-lokal, aber mit Pin und ein paar Pflicht-Trace-Feldern. Dünne Platform (Registry, Observability, Eval-Gates), sobald Shared Pain real ist — oft beim zweiten Team oder bei messbarem Querschnitts-Bleed; Feature-#2 allein ist nur Faustregel, kein Automatismus. Platform ohne Owner und ohne konsumierende Features ist Theater.

Übersicht: Default-Tendenzen auf einen Blick

Entscheidung	Default-Tendenz
Wann LLM?	Ampel pro Schnitt; hybrid; Rot ist valide
Ladder	unten starten; 2/3/4 vor 5/6
RAG vs. FT	RAG/Prompt/Retrieval; meist nicht FT
Agent vs. Pipeline	Pipeline
Model-Tier	Balanced + Routing; nicht Strong-by-Default
Hosting	API (oft hybrid); Self-Host mit Ops-Beweis
Ausrollen	Offline + Canary; Shadow bei Risiko; selten Big-bang
Incident	Stabilize; bei klarem Change Rollback zuerst
HITL	Writes mit Risiko → Mensch/Policy; lesen eher auto
Platform	dünn bei Shared Pain (oft 2. Team / Feature #2 als Faustregel); nicht vor dem Problem

24 KiB Raw Permalink Blame History Unescape Escape