Die Demo hat drei Wochen gedauert. Das Produkt elf Monate. Dieses Verhältnis — nicht die Modellwahl, nicht cleveres Prompting — ist die Zahl, die die meisten Teams falsch einschätzen, wenn sie ein KI-Feature freigeben. Eine beeindruckende Demo ist ungefähr 20 % der Arbeit. Die restlichen 80 % sind weder Magie noch mehr Prompting, sondern messbares Engineering, und sie haben Namen: Eval-Harness, Observability, Guardrails, Fallbacks und Budgets.
Die Statistik dazu ist unmissverständlich. MITs Project NANDA hat 300 öffentliche Enterprise-Deployments untersucht und kommt zu dem Schluss, dass rund 95 % der GenAI-Piloten wenig bis keinen messbaren Effekt auf die GuV haben — die Forscher nennen es den „GenAI Divide" und verorten die Ursache nicht in der Modellqualität, sondern in einer Lernlücke: Tools, die sich nicht an echte Workflows anpassen, und Organisationen, die nicht erkennen können, ob das Tool überhaupt funktioniert. RAND schätzt nach strukturierten Interviews mit 65 erfahrenen AI Engineers und Data Scientists, dass mehr als 80 % der KI-Projekte scheitern — doppelt so oft wie IT-Projekte ohne KI. Die Hauptursachen: missverstandene Problemstellungen, fehlende Daten und unterfinanzierte Infrastruktur — nicht schwache Modelle.
Beide Berichte beschreiben dieselbe Lücke aus unterschiedlicher Flughöhe. So sieht es aus, wenn man sie von innen, aus der Codebase heraus, überquert.
Demos optimieren den Happy Path — die Produktion bestraft ihn
Eine Demo ist ein kuratiertes Gespräch. Produktion ist euer wütendster Kunde, der um zwei Uhr nachts ein 40-seitiges PDF auf Türkisch einfügt. Die Verteilung echter Eingaben ist breiter, seltsamer und feindseliger als alles, was das Team im Sprint Review ausprobiert hat — und LLMs scheitern nicht-deterministisch: Dasselbe Feature, das hundertmal korrekt geantwortet hat, antwortet beim hundertersten Mal anders.
Klassisches Software-Engineering hat eine Antwort auf Nicht-Determinismus: Man vertraut keinem Verhalten, das man nicht gemessen hat. Trotzdem gehen die meisten KI-Features mit weniger Tests live als ein Datepicker. Jede Prompt-Änderung, jeder Modellwechsel, jede Anpassung am Retrieval ist ein Deploy auf gut Glück. Ein Muster, das wir immer wieder sehen: Ein Assistent, der Support-Antworten entwirft, funktioniert monatelang gut, der Anbieter aktualisiert das zugrunde liegende Modell, und die Antwortqualität verschiebt sich leise — kürzere Antworten, neues Herumdrucksen, ein anderer Ton. Wochenlang merkt es niemand, weil nichts einen Fehler wirft. Es gab keinen Harness, der aus „die Vibes haben sich geändert" eine rote Zahl auf einem Dashboard gemacht hätte.
Evals sind die Testsuite, die euer KI-Feature nie hatte
Der stärkste Prädiktor, den wir dafür kennen, ob ein KI-Feature sein erstes Jahr überlebt, ist, ob das Team Eval-driven Development praktiziert: das erwartete Verhalten zuerst als Evaluation definieren und dann dagegen iterieren — dieselbe Schleife, die OpenAIs Engineering-Guide als Analogie zum Behavior-driven Development beschreibt, mit Gradern, versionierten Testdatensätzen und Regressions-Erkennung bei jeder Prompt-Iteration.
Ein minimaler Eval-Harness ist unglamourös und in Tagen gebaut, nicht in Monaten. Er enthält:
- Ein Golden Set: 100–500 echte Eingaben aus dem tatsächlichen Traffic (oder ehrliche synthetische Fälle vor dem Launch), jede mit erwarteter Ausgabe oder Bewertungsrubrik. Keine Marketing-Beispiele — die hässlichen, mehrdeutigen, kaputten Fälle gehören dazu.
- Grader: Exact-Match- oder String-Checks, wo Antworten kategorisch sind, Code-Grading, wo Struktur zählt (valides JSON, korrektes Zitierformat), und LLM-bewertete Rubriken für subjektive Qualitäten wie Tonalität.
- Einen Baseline-Score und eine Diff-Ansicht: Jede Änderung an Prompt, Modell, Retrieval oder Tools lässt das Set neu laufen und zeigt die Bewegung pro Fall, nicht nur im Aggregat.
- Ein CI-Gate: Regressionen blockieren den Merge — genau wie fehlschlagende Unit-Tests.
Anthropics Evaluations-Guide macht einen kontraintuitiven Punkt, der sich mit unserer Erfahrung deckt: Volumen schlägt Perfektion — mehr Fragen mit automatischem Grading und etwas schwächerem Signal sind besser als wenige, aufwendig von Hand bewertete. Hunderte automatisch bewertete Fälle fangen Regressionen, die zwanzig handkuratierte übersehen.
Eine einzelne Zahl reicht allerdings nie. Stanfords HELM-Benchmark existiert, weil einzelne Accuracy-Scores Trade-offs verstecken: HELM bewertet Modelle über Accuracy, Kalibrierung, Robustheit, Fairness, Bias, Toxizität und Effizienz hinweg — gerade weil ein Modell sich auf einer Achse verbessern und auf einer anderen verschlechtern kann. Eure Produkt-Evals brauchen dieselbe multimetrische Ehrlichkeit: Ein Summarizer, der 4 % genauer und 60 % teurer geworden ist, hat sich nicht einfach „verbessert".
LLM-as-Judge funktioniert — wenn ihr den Judge auditiert
Für subjektive Qualitäten ist der pragmatische Grader ein zweites LLM. Die grundlegende Studie dazu, „Judging LLM-as-a-Judge" von Zheng et al., zeigt: Starke LLM-Judges stimmen in über 80 % der Fälle mit menschlichen Präferenzen überein — derselbe Wert, den Menschen untereinander erreichen. Das macht LLM-Grading zu einem legitimen, skalierbaren Ersatz für menschliches Review.
Dieselbe Arbeit dokumentiert, warum ihr einen Judge nicht blind einsetzen könnt. LLM-Judges zeigen Position Bias (sie bevorzugen die Antwort, die im Paarvergleich zuerst steht), Verbosity Bias (sie bevorzugen längere Antworten unabhängig von der Qualität) und Self-Enhancement Bias (sie bevorzugen Ausgaben im eigenen Stil — besonders heikel, wenn Judge-Modell und Produkt-Modell verwandt sind). Die Gegenmaßnahmen sind mechanisch: Antwortpositionen tauschen und mitteln, gegen explizite Rubriken statt offener Präferenz bewerten, einen Judge aus einer anderen Modellfamilie nehmen als das bewertete Modell — und, nicht verhandelbar, den Judge kalibrieren: 50–100 Fälle von Hand labeln und die Übereinstimmung zwischen Judge und Mensch messen, bevor ihr den Zahlen des Judges vertraut. Ein unkalibrierter Judge ist ein Zufallszahlengenerator mit guter Grammatik.
Menschen dort einsetzen, wo das Modell am schwächsten ist — nicht überall
Die erfolgreichen 5 % im MIT-Report teilen ein Designmuster: KI, die mit Feedback-Schleifen in einen Workflow eingebettet ist, statt eines seitlich angeschraubten Chatbots. In der Praxis ist die Entscheidung mit dem größten Hebel, wo der menschliche Checkpoint sitzt. Pauschales Review jeder Ausgabe verbrennt die Effizienz, die ihr gerade einkauft; gar kein Review ist der Weg, auf dem KI-Features nach einem einzigen Vorfall per Vorstandsbeschluss verboten werden.
Unsere Platzierungsregel: Menschen reviewen dort, wo Fehler teuer und irreversibel sind; Modelle handeln allein, wo Fehler billig und erkennbar sind. Konkret heißt das Confidence-Routing — das System entwirft alles, verschickt die 70 % mit hoher Konfidenz automatisch und legt den Rest in eine Review-Queue. Jede menschliche Korrektur fließt zurück ins Golden Set. So verstärken sich Eval-Harness und Human-in-the-Loop gegenseitig: Reviewer sind kein Kostenfaktor mehr, sondern erzeugen die Trainings- und Testdaten des nächsten Quartals.
Alles tracen, denn die Fehler sind lautlos
Klassisches Monitoring achtet auf Errors und Latenz. LLM-Systeme scheitern, während sie HTTP 200 zurückgeben. Die kanonische Geschichte — wir haben Varianten davon inzwischen bei drei verschiedenen Kunden gesehen — ist Retrieval-Fäulnis: Die Antworten eines RAG-Assistenten werden langsam schlechter, weil das Firmen-Wiki umgezogen ist, die Hälfte der ingestierten URLs jetzt per 301 auf eine Login-Seite zeigt und die Pipeline brav Redirect-Stubs embeddet. Keine Exception, kein Alert — nur Antworten, die Woche für Woche vager werden, bis sich ein Kunde beschwert.
Die Lösung ist Tracing auf Schritt-Ebene, nicht auf Request-Ebene: pro Request die Query loggen, die abgerufenen Chunks samt Scores, den zusammengebauten Prompt, die Modellversion, die Rohausgabe, Token-Zahlen und Kosten. Das standardisiert sich gerade schnell: Die GenAI Semantic Conventions von OpenTelemetry definieren herstellerneutrale Spans für Agent-Aufrufe, Modell-Calls und Tool-Ausführungen, mit Token-Verbrauch und Kosten als First-Class-Attributen — LLM-Traces landen damit im selben Observability-Stack wie der Rest eures Systems statt in einem proprietären Silo. Produktions-Traces füttern außerdem die Schleife aus den vorigen Abschnitten: Die seltsame echte Anfrage von gestern ist der Golden-Set-Fall von morgen.
Guardrails, Fallbacks und Budgets sind Produkt-Features
Die letzte Disziplin besteht darin, das Modell nicht zum Single Point of Failure werden zu lassen. Input-Guardrails fangen Prompt Injection und themenfremden Missbrauch ab, bevor das Modell sie sieht; Output-Guardrails validieren die Struktur, prüfen, ob zitierte Quellen wirklich existieren, und screenen auf personenbezogene Daten — was für unsere EU-Kunden keine optionale Hygiene ist, sondern ein DSGVO-Pflichtposten. Dahinter sitzen Fallback-Ketten: Läuft das primäre Modell in einen Timeout oder scheitert die Ausgabe an der Validierung, einmal retrien, dann auf ein einfacheres Modell oder ein Template degradieren, dann an einen Menschen übergeben. Der Nutzer sieht eine langsamere Antwort, kein kaputtes Feature.
Budgets gehören in dieselbe Kategorie. Kosten und Latenz sind Produktentscheidungen, die das Engineering nur durchsetzt: ein Token-Budget pro Request, ein p95-Latenzziel, eine Alert-Schwelle für Kosten pro gelöstem Ticket. Agentische Features machen das dringend — eine Retry-Schleife, die im Test harmlos ist, kann unter Produktionslast den Token-Verbrauch verdreifachen, und ohne Kosten-Tracing pro Request erfahrt ihr das erst auf der Rechnung. Ausgerollt wird das Ganze wie jede riskante Änderung: Canary auf 5 % des Traffics, Eval-Metriken und Kosten gegen die Kontrollgruppe vergleichen, dann aufdrehen.
Nichts davon ist exotisch. Es ist dieselbe Disziplin, die gewöhnliche Software verlässlich gemacht hat — Tests, Monitoring, schrittweise Rollouts — übersetzt für Systeme, die probabilistisch statt deterministisch sind. Die Teams auf der richtigen Seite der 95 % sind nicht die mit den spektakulärsten Demos. Es sind die, die die Frage, die jeder Stakeholder irgendwann stellt, mit einer Zahl beantworten können: Funktioniert es wirklich?