ki-engineeering/05-wann-llms-und-wann-nicht.md

Wann LLMs — und wann nicht

Das Ticket heißt „KI-Feature“. Die Lösung steht oft fest, bevor das Problem spezifiziert ist: LLM dran, Prompt, Demo, Applaus. Sechs Wochen später pflegt ihr ein System, das teurer und unzuverlässiger ist als die Regelengine, die niemand bauen wollte — oder ihr steckt ein echtes Sprachproblem in eine Lookup-Tabelle und wundert euch über die Support-Tickets.

Die teuerste Architekturentscheidung ist häufig nicht welches Modell, sondern ob ein Foundation Model überhaupt der richtige Baustein ist.

Kern in einem Satz: Ein LLM lohnt, wo unstrukturierte Varianz auf ein prüfbares Ziel trifft und ihr Qualität, Kosten und Risiko tragen könnt — und lohnt nicht, wo Determinismus, harte Korrektheit oder reine Lookups den Job allein erledigen.

Lebende Kurzform zum Abhaken: checklists/wann-llm.md. Dieses Kapitel liefert Begründung, Grenzfälle und den Realitätscheck vor dem Build.

---

Bridge: Klassisches SE → AI Engineering

In klassischem SE wählt ihr Technologien nach Fit: relationale DB vs. Queue vs. Batch-Job. Dieselbe Disziplin gilt für LLMs — nur dass der Baustein probabilistisch, kontextabhängig und variabel teuer ist (Kapitel 04).

Klassische Frage	Frage mit LLM-Option
Welcher Algorithmus / welche Lib?	Brauchen wir Generation/Verstehen von Sprache — oder Regeln, Suche, Formulare?
Kann ich es testen?	Habe ich ein Eval-Set oder Review-Pfad — oder nur Bauchgefühl?
Was kostet der Request?	Was kostet p50/p95 an Tokens, Tools und Retries bei Ziel-Last?
Was passiert bei Fehler?	Ist „überzeugend falsch“ schlimmer als „hart fehlschlagen“?
Wer owned den Service?	Wer owned Prompt, Eval, Model-Change und Incidents?

Technikwahl vor Tool-Hype. „Alle machen AI“ ist kein Anforderungsdokument. Wenn die Ampel rot ist, ist kein LLM eine valide, professionelle Entscheidung — und oft die mutigere.

---

Die Ampel: Grün, Gelb, Rot

Die Ampel ist eine konservative Heuristik für Produktentscheidungen, kein Naturgesetz. Frontier-Modelle und eure Domäne verschieben Grenzfälle; die strukturellen Gründe (fehlende Wahrheitsgarantie, variable Kosten, Eval-Bedarf) bleiben. Mechanik-Tiefe: Next Token. Für Coding-Agents als Dev-Tool gilt eine andere Nutzungslogik (ki-praxis) — hier geht es um Features im Produkt.

Grün — oft sinnvoll

Merkmale: unstrukturierte oder stark variabel formulierte Eingaben; Ziel trotzdem operationalisierbar; Fehler tolerierbar oder abfangbar; Nutzen klar größer als Runtime-Komplexität.

Aufgabe (Beispiele)	Warum grün	Was ihr trotzdem braucht
Freitext klassifizieren / routen (Intent, Dringlichkeit)	hohe Formulierungsvarianz, endliches Label-Set	Golden Set, Schwellen, Fallback-Klasse
Informationen aus Dokumenten extrahieren	Layout und Sprache variieren	Schema, Validierung, Stichproben-Eval
Entwürfe generieren (Mail, Zusammenfassung, UI-Copy)	Mensch oder Policy prüft vor Wirkung	Review-UX oder automatische Checks
Semantische Suche / Fragen über euren Korpus (RAG)	Sprache als Interface zu Wissen	Retrieval-Qualität, Citations, Ablehnung ohne Treffer
Natürlichsprachliche → strukturierte Form (leichtes Parsing)	Bridging in APIs	Structured Output, Reject/Repair
Interne Assistenz mit klaren Tools und Stopps	beschleunigt Workflows	Permissions, Audit, Loop-Caps

Grün heißt nicht „ohne Nachdenken shippen“. Es heißt: der Baustein passt zum Problem und ihr könnt die Runtime-Eigenschaften tragen.

Gelb — nur mit Guardrails und ehrlichem Scope

Merkmale: Nutzen da, aber Faktenrisiko, Seitenwirkungen, Kosten bei Volumen oder semi-autonome Tools machen blinde Delegation teuer.

Situation	Risiko	Mindest-Guardrails
Nutzer-sichtbare Fakten (Preise, Policies, Medizin-/Rechts-adjacent)	Halluzination als Vertrauen	Grounding, Citations, „keine Evidenz → keine Behauptung“, oft HITL
Semi-strukturierte Workflows mit Tools	falsche Tool-Wahl, Teilausführung	least privilege, Bestätigung bei Side Effects, State-Machine
Hohes Request-Volumen	Unit Economics	Routing, Cache, kurze Contexts, Budget-Alerts
Mehrstufige Produkt-Agents	Kosten × Varianz × Latency	agent-readiness, harte Stopps, Eval pro Schritt-Typ
Personalisierte Antworten aus CRM/Tickets	Privacy, Data Leakage	Redaction, Residenz, Zweckbindung (Kap. 20)
„Der Bot entscheidet“ in Fachprozessen	stille Policy-Verstöße	Policy im Code, nicht nur im Prompt; Eskalation

Gelb defaultet zu hybrid: Regeln/APIs für den harten Kern, LLM für Sprache und Varianz am Rand.

Rot — besser ohne LLM (oder nur kosmetisch am Rand)

Merkmale: Determinismus gefordert; Korrektheit ohne Toleranz; reine Lookups; kein Weg zu Eval oder Review; Risiko asymmetric (ein Fehler zerstört mehr als hundert Erfolge nutzen).

Anti-LLM-Case	Besserer Baustein
Business Rules mit klaren if/else (Rabattstaffeln, Feature-Flags, ACL)	Rule Engine, Policy-as-Code, ordinary services
Geld bewegen, Bestände buchen, Idempotenz-kritische Transaktionen allein durchs Modell	Transaktionssystem; LLM höchstens Erklärung nach Fakten aus der DB
Stabile Schemas, Lookup-Tabellen, Kataloge	DB/Search/API
Kryptographie, AuthZ-Entscheidungen, Signaturprüfung	bewährte Libs und Identity-Stack
Harte Echtzeit mit engen Millisekunden-Budgets und hoher QPS, ohne Batch-Puffer	klassische Pfade; LLM async/offline wenn überhaupt
Kein Owner, kein Eval, kein Incident-Pfad	Feature stoppen oder Scope auf Entwurf-ohne-Wirkung reduzieren
Regulatorisch finale Entscheidung ohne menschliche/regelbasierte Instanz	Mensch + nachweisbare Regeln; LLM nicht als alleinige Autorität

Rot ist kein Kulturkampf gegen AI. Rot ist Ingenieursanstand: den falschen Abstraktionsgrad ablehnen.

---

Realitätscheck: fünf Fragen vor dem Build

Bevor Architektur und Vendor-Wahl: schriftlich beantworten (eine Seite reicht).

1. Job-to-be-done — Welchen Nutzerjob erledigen wir messbar besser? (Nicht: „Wir wollen AI.“)
2. Orakel-Test — Wenn das Modell in 5 % der Fälle überzeugend falsch liegt: ist der Schaden akzeptabel, abfangbar oder inakzeptabel?
3. Eval-Test — Können wir in zwei Wochen ein kleines Golden Set oder einen Review-Prozess definieren? Wenn nein → rot/gelb mit Stopp.
4. Budget-Test — Was darf ein Request an € und p95-Latenz kosten bei erwarteter Last — inkl. Retries/Tools?
5. Ownership-Test — Wer freigibt Prompt/Model-Änderungen und wer ist on-call, wenn Qualität oder Kosten kippen?

Fällt eine Antwort aus, ist das kein Detail für später — das ist die Ampel-Entscheidung.

Kopiervorlage für die formelle Spec: templates/ai-feature-spec.md (nächstes Kapitel vertieft). Kurz-Checkliste: wann-llm.md.

---

Hybrid ist der Normalfall

Viele gute Systeme sind nicht „alles LLM“ und nicht „kein LLM“:

Unstrukturierter Eingang (LLM oder Formular+)
    → Struktur / Intent (LLM + Schema)
    → Harte Entscheidung (Regeln, DB, Policy-Engine)
    → Optional: Erklärung / Entwurf in Sprache (LLM)
    → Wirkung nur über kontrollierte APIs

Beispiele:

Bedarf	Hybrid-Schnitt
Support-Assistent	LLM triagiert und entwirft; Erstattung nur über bestehende APIs mit Rechten
Suche im Handbuch	Retrieval rankt; LLM fasst nur Treffer zusammen und zitiert
Datenpflege	LLM schlägt Feldmapping vor; Commit erst nach Validierung und ggf. Mensch
Reporting	Zahlen aus Warehouse; LLM nur Narrativ mit gebundenen Zahlen

Entscheidungssprache: ja / nein / hybrid — plus ein Satz Begründung. „Hybrid“ ohne Schnittbeschreibung ist Gelb im Selbstbetrug.

---

Patterns und Trade-offs

Pattern: Ampel pro Teilproblem, nicht pro Epics

Ein Epic „KI-Support“ enthält grüne (Zusammenfassen), gelbe (Policy erklären) und rote (Gutschrift auslösen) Teile. Ampel pro Schnittstelle.

Trade-off: mehr Architektur-Schnitte; weniger Monolith-Prompts, die alles „irgendwie“ regeln.

Pattern: Wirkungsebenen trennen

Ebene	Beispiel	LLM-Eignung oft
Wahrnehmen / Formulieren	Mail verstehen, Entwurf	grün/gelb
Entscheiden	Genehmigen, buchen	rot → Regeln/Mensch
Erklären	Entscheidung in Prosa	grün, gebunden an Fakten

Pattern: Ersatz-Bausteine zuerst skizzieren

Bevor LLM: reichte bessere Suche, Templates, Formular-Wizard, klassische Klassifikation, RPA auf stabilen UIs? Wenn ja und Risiko/Kosten des LLM hoch sind → rot oder später.

Trade-off: weniger Demo-Glanz; oft bessere SLOs.

Decision Frame: Ampel-Schnellwahl

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/Kosten heikel	Gelb — hybrid + Guardrails
kein Eval, kein Owner	Stopp — nicht bauen

---

Anti-Patterns

Anti-Pattern	Symptom	Besser
Lösung vor Problem	„Wir brauchen GPT/Claude/…“ im Kickoff	Job-to-be-done + Ampel zuerst
LLM als Business-Rule-Engine	Rabatte und ACLs im Prompt	Policy im Code; LLM erklärt höchstens
Grünwaschen	Hohes Risiko, aber „wir prompten vorsichtig“	Gelb/Rot + HITL oder nicht shippen
Rot aus Prinzip	Jede Sprachaufgabe wird mit 200 Regex gelöst	Grün wo Varianz echt weh tut
Demo-Ampel	Stakeholder-Applaus = grün	Orakel-, Eval-, Budget-, Ownership-Test
Ein Prompt für alles	Ein Agent soll triagieren, buchen und juristisch beraten	Schneiden; Ampel pro Schritt
Vendor als Strategie	Roadmap folgt Model-Release-Notes	Problemfit und Unit Economics

---

Production Notes

Cost. Bei Grün/Gelb: Volumen × Tokens × Tier grob rechnen vor dem Build. Hybrid spart oft mehr als Prompt-Feinschliff. Caps und Downgrade sind Teil der Entscheidung „ob LLM“, nicht nur „wie prompten“.

Latency. Interaktive LLM-Pfade brauchen UX-Budget; für harte Echtzeit oft rot oder async. Gelbe Agents mit vielen Tools sprengen p95 — in der Ampel berücksichtigen.

Observability. Schon die Entscheidung dokumentieren: warum grün/gelb/rot/hybrid. Später erklärt das Incidents („warum greift hier kein Regelwerk?“). Traces pro Pfad (LLM vs. deterministic fallback).

Security. Gelb mit Tools = Angriffsfläche (Injection, Exfil, Abuse). Rot für AuthZ und Secrets-Handling bleibt rot: Modell entscheidet keine Berechtigungen. Siehe security-review-ai.md und Kapitel 19.

Lifecycle. Ampel-Reviews bei Model-Updates und bei Last-Sprüngen: was gestern gelb war, kann unter 10× Traffic rot fürs Budget werden.

---

Key Takeaways

• Die erste Entscheidung ist ob (und wo) ein LLM — nicht welches Modell und welcher Prompt.
• Grün: unstrukturierte Varianz + prüfbares Ziel + tragbare Runtime. Gelb: Guardrails und hybrid. Rot: Determinismus, harte Korrektheit, Lookups, kein Eval/Owner.
• Hybrid ist der professionelle Default: Sprache und Varianz am Rand, harte Wirkung im deterministischen Kern.
• Fünf Realitätschecks (Job, Orakel, Eval, Budget, Ownership) schlagen Demo-Euphorie.
• „Kein LLM“ ist eine gültige Engineering-Entscheidung — oft die bessere.

Praktische nächste Schritte

1. Nimm das nächste „KI-“Ticket und zerlege es in Teilprobleme; hänge jedem Grün/Gelb/Rot an.
2. Laufe checklists/wann-llm.md und triff ja / nein / hybrid mit einem Satz Begründung im Ticket oder ADR.
3. Beantworte die fünf Realitätscheck-Fragen schriftlich; eine Lücke = Blocker, kein „später“.
4. Skizziere den deterministischen Kern (APIs, Regeln, DB), den das LLM nicht ersetzen darf.
5. Lies als Nächstes Vom Problem zur Spezifikation — Success Metrics, Failure Modes und Cost Envelope für alles, was nicht rot gestorben ist.