Ohne Evals fliegt eure KI blind. Das ist keine MLOps-Folklore, sondern das, was wir in jedem zweiten Audit sehen: ein KI-Feature läuft seit Monaten produktiv, niemand misst die Output-Qualität systematisch, Halluzinationen werden nur entdeckt, wenn ein Kunde sich beschwert. Das ist 2026 inakzeptabel — sowohl aus Qualitätsgründen als auch aus EU-AI-Act-Sicht. Dieser Artikel ist die operative Anleitung, wie ein produktives Eval-Setup im DACH-Mittelstand aussieht, mit konkreten Tools, Setup-Beispielen und realistischen Kostenrahmen.
Warum Evals 2026 Pflicht sind — nicht "nice to have"
Drei Gründe, warum Evals von "Engineering-Best-Practice" zur Compliance-Pflicht geworden sind:
Regulatorischer Druck: EU AI Act fordert für Hochrisiko-Systeme "Genauigkeit, Robustheit, Cybersicherheit auf nachweisbarem Stand der Technik". Wer keine Eval-Pipeline hat, kann den Stand der Technik nicht nachweisen.
Modell-Volatilität: OpenAI, Anthropic, Google rollen Modell-Updates in 4-bis-8-Wochen-Zyklen aus. Wer nicht misst, merkt nicht, wenn ein Update euren Use-Case kaputtmacht — bis Kunden anrufen.
Wirtschaftlicher Schaden: Aus eigenen Audit-Daten (2024-2026): Teams ohne strukturierte Evals haben im Median 4,8 schwerwiegende Production-Incidents pro Jahr, Teams mit Eval-Pipeline haben 1,9 — plus deutlich kürzere Recovery-Zeiten, weil die Fehlerquelle schneller identifiziert wird.
Teams mit Eval-Pipeline im ersten Jahr, eigene Audit-Daten 2026
Die 4-Layer-Eval-Strategy
Eine vollständige Eval-Pipeline arbeitet auf vier Schichten parallel. Jede Schicht fängt einen anderen Fehler-Typ ab.
Layer 1 — Deterministic Tests
Was sie tun: Prüfen messbare, eindeutige Eigenschaften des Outputs. Klassisches Software-Testing, übertragen auf LLM-Outputs.
Beispiele:
- JSON-Schema-Validation: wenn euer Output strukturiertes JSON sein soll, ist jeder Output, der das Schema verletzt, ein Fail.
- Regex-Checks: enthält der Output das geforderte Format (z. B. eine IBAN, ein Datum, eine Telefonnummer)?
- Length-Checks: Output muss zwischen 100 und 500 Wörtern sein.
- Forbidden-Phrases: Liste verbotener Begriffe, die nie im Output auftauchen dürfen.
Tools 2026: PromptFoo (Open-Source, EU-hostbar), DeepEval, simpler Python-Test mit Pytest und Pydantic.
Setup-Beispiel:
Ein deutsches Versicherungs-Unternehmen nutzt ein Sprachmodell für strukturierte Schadensmeldungs-Zusammenfassungen. Layer-1-Tests prüfen: Schadensnummer im IBAN-Format-ähnlichen Muster, Schadensbetrag als gültige Zahl, Datum im ISO-Format, Output max 300 Wörter. 14 deterministische Tests, Laufzeit pro Output 200ms, fängt 35 Prozent aller Output-Probleme bevor sie produktiv werden.
Fail-Modes: zu eng definierte Regex bricht bei valider Variation (z. B. "12.05.2026" vs "12. Mai 2026"). Lösung: in Layer-1 nur strukturelle Validierung, semantische Prüfung in Layer 2-3.
Layer 2 — LLM-as-Judge für subjektive Qualität
Was sie tun: Ein zweites Sprachmodell bewertet den Output des ersten — auf Dimensionen wie Tonalität, Vollständigkeit, Hilfreichkeit, Wahrheitsgehalt im gegebenen Kontext.
Wann sinnvoll: Bei Outputs, deren Qualität nicht binär messbar ist — Mail-Entwürfe, Antworten an Kunden, Zusammenfassungen.
Tools 2026: Anthropic's Eval-API, OpenAI Evals, DeepEval mit G-Eval, Langsmith mit Custom-Evaluators, Braintrust.
Setup-Beispiel:
Für einen Kundenservice-Bot bewertet ein Judge-Modell (Claude 4) jeden Output auf drei Dimensionen: "Faktische Korrektheit zur verfügbaren Wissensbasis (0-5)", "Tonalität-Match zur Marken-Stimme (0-5)", "Vollständigkeit der Antwort (0-5)". Die Judge-Prompts sind in einem Git-Repo versioniert, Änderungen am Judge-Prompt sind Pull-Request-fähig.
Wichtig — der häufigste Anfänger-Fehler: Judge-Prompts müssen selbst evaluiert werden. Wenn euer Judge zu lax oder zu streng ist, sind alle Layer-2-Metriken falsch kalibriert. Routine: 50 manuell gelabelte Beispiele, Judge-Score vs Human-Score korrelieren, Korrelation muss über 0,8 liegen, sonst Judge-Prompt nacharbeiten.
Kosten: typisch 0,005 bis 0,02 Dollar pro Judge-Bewertung — bei 1.000 Outputs pro Tag also 5 bis 20 Dollar/Tag. Vernachlässigbar gegen die Kosten eines verpassten Incidents.
Layer 3 — Golden-Dataset mit Human-Reviewed-Standards
Was es ist: Eine kuratierte Sammlung von Input-Output-Paaren, bei denen ein Mensch den "richtigen" Output festgelegt hat. Das Golden-Dataset ist die Wahrheitsbasis, gegen die alle Modell- und Prompt-Änderungen getestet werden.
Beispiel-Aufbau: 30 bis 100 manuell kuratierte Beispiele, breit gestreut über typische Use-Cases, inklusive Edge-Cases (leere Eingaben, Mehrsprachigkeit, lange Eingaben). Pro Beispiel: Input, erwarteter Output (oder eine Liste akzeptabler Outputs), Rationale-Notiz für Reviewer.
Setup-Aufwand: zwei bis vier Wochen für die ersten 30 Tests, inklusive Kuratierung und Reviewer-Workflow. Bei Domain-spezifischen Aufgaben (Recht, Medizin, Finanz) länger, weil Fach-Reviewer Zeit brauchen.
Re-Eval-Frequenz: bei jedem Modell-Switch (Provider, Version), bei jeder Prompt-Änderung, mindestens monatlich für produktive Workflows.
Layer 4 — Production-Monitoring mit Drift-Detection
Was es tut: Misst Output-Eigenschaften in der echten Produktion über Zeit. Erkennt schleichende Veränderungen — Drift — die in den synthetischen Tests nicht sichtbar werden.
Was gemessen wird:
- Output-Länge im Zeitverlauf (plötzlich kürzer? Modell-Update?)
- Anteil von User-Eskalationen (steigt? Qualitäts-Drift?)
- Antwort-Latenz (langsamer? Provider-Problem?)
- Token-Verbrauch pro Request (steigt? Prompt-Inflation?)
- User-Feedback-Score (sinkt? Trend?)
Tools 2026: Langsmith, Langfuse (EU-hostbar, Open-Source), Helicone, selbst gebaut mit Prometheus + Grafana.
Drift-Signale: Statistical Process Control auf die Metriken anwenden — wenn eine Metrik mehr als zwei Standardabweichungen vom laufenden Mittel abweicht, Alert. Nicht jedem Alert nachjagen, aber zumindest wissen.
Konkrete Tool-Empfehlungen 2026 nach Use-Case
| Use-Case | Tool-Empfehlung | Kostenrahmen |
|---|---|---|
| Single Project, Self-Hosted | PromptFoo + Langfuse | ~€100/Monat (Hosting) |
| Multi-Project, managed | Langsmith oder Braintrust | €200-800/Monat |
| Enterprise mit Compliance-Fokus | Langfuse self-hosted + DeepEval | €300-1.000/Monat |
| Anthropic-only Stack | Anthropic Evals + Langfuse | €150-500/Monat |
| Forschungs-Setup, Open-Source | DeepEval + MLflow | €0-200/Monat (Compute) |
Faustregel im Mittelstand: anfangen mit Langfuse + PromptFoo self-hosted, bei mehr als drei produktiven KI-Features upgraden auf managed Tool.
Eval-Kosten in der Praxis
Bandbreite für ein typisches Mittelstand-Setup mit zwei bis drei produktiven KI-Features:
| Komponente | Kosten einmalig | Kosten laufend |
|---|---|---|
| Layer 1 (Deterministic) Setup | €4.000-8.000 | €50-200/Mon (Compute) |
| Layer 2 (LLM-as-Judge) Setup + Kalibrierung | €8.000-15.000 | €200-800/Mon (Judge-Inferenz) |
| Layer 3 (Golden-Dataset, 30-50 Tests) | €6.000-12.000 | €1.000-2.500/Quartal (Updates) |
| Layer 4 (Monitoring + Drift) | €8.000-15.000 | €150-500/Mon (Tool + Hosting) |
| Summe | €26.000-50.000 | €700-2.000/Mon + Quartals-Audits |
Klingt nach viel — gemessen am eingesparten Incident-Schaden (eigener Daten-Schnitt: rund €120.000 pro Jahr bei produktiven KI-Features ohne Evals) amortisiert sich das im ersten Halbjahr.
Was wir in der Praxis sehen — drei häufige Fail-Modes
Fail 1 — "Eval-Theater". Team hat einen Eval-Ordner, aber niemand schaut rein. Tests laufen nicht in CI, Failures werden nicht alarmiert, Reports liest keiner. Lösung: Eval-Run-Failures müssen Deployment blockieren, sonst sind sie wertlos.
Fail 2 — "100 % muss grün sein"-Falle. Team will erst deployen, wenn alle Tests grün sind — landet bei zu engen Tests, die ständig falsche Failures werfen. Lösung: Tests dürfen Toleranzen haben, Failures müssen kategorisiert werden ("muss-pass" vs "soll-pass").
Fail 3 — "Tests gegen ein einzelnes Modell". Setup ist hart auf Claude 4 oder GPT-4o optimiert. Wenn ihr wechselt, ist alles unbrauchbar. Lösung: Tests modell-agnostisch designen, mindestens zwei Backup-Provider laufen lassen können.
Häufige Fragen
Was Tech-Verantwortliche zu Evals fragen.
Wie objektiv ist LLM-as-Judge wirklich — bewertet es konsistent?
Wer im Team schreibt die Golden-Tests?
Was kostet ein Eval-Run pro Durchlauf?
Wie oft sollten wir re-evaluieren?
Was tun wir, wenn der Modell-Vendor sein Modell ändert?
Was als Nächstes?
Wer 2026 Production-KI betreibt und keine Eval-Pipeline hat, sollte diese Woche damit anfangen. Konkrete erste Schritte: einen KI-Use-Case auswählen (am besten den mit dem höchsten Schaden bei Fehlern), 30 Golden-Tests in zwei Wochen sammeln, Layer-1 deterministisch absichern, dann Schritt für Schritt erweitern. Ein Eval-Audit bei uns kostet €4.500 und liefert in zwei Wochen eine Eval-Architektur plus die ersten 30 Golden-Tests für euren wichtigsten Use-Case. Discovery-Call dauert 30 Minuten und kostet nichts.