Warum Ihr KI-Anbietervertrag eine Evals-Klausel braucht

Wenn Ihr KI-Anbieter Ihnen kein bewertetes Test-Set vorzeigen kann, das belegt, dass sein System auch auf bisher ungesehene Fälle zuverlässig reagiert, kaufen Sie kein Produkt – Sie kaufen eine Demo. Fordern Sie die Evals vor der Vertragsunterzeichnung ein, nicht erst nach der Rechnung.

Gründer und CTOs, die KI-Anbieter evaluieren, haben ein gutes Gespür dafür entwickelt, eine glatte Demo zu erkennen. Was die meisten noch nicht gelernt haben: den Unterschied zu erkennen zwischen einer Demo, die funktioniert, weil sie eingeübt wurde, und einem System, das funktioniert, weil es getestet wurde. Genau diese Lücke schließen Evals – und es ist die eine nützlichste Frage, die Sie im Anbieterauswahlprozess stellen können.

Was ein Eval wirklich ist

Ein Eval ist ein festes Set von Inputs – echte Fragen, echte Dokumente, echte Edge Cases aus Ihrer Domäne – kombiniert mit bewerteten Erwartungsausgaben, das automatisch ausgeführt wird, sobald sich der zugrunde liegende Prompt, das Modell oder die Retrieval-Logik ändert. Statt „es hat funktioniert, als ich es ausprobiert habe" erhalten Sie eine Kennzahl: 87 % der Fälle bestehen den Test, gegenüber 74 % im letzten Sprint.

Das ist kein exotisches Werkzeug. OpenAI hat bereits 2023 ein einfaches Framework genau für diesen Zweck als Open Source veröffentlicht (openai/evals), und jedes seriöse KI-Unternehmen hat seitdem eine eigene Version davon gebaut – ob maßgeschneidert oder von der Stange. Das Konzept existiert schon vor LLMs; es ist schlicht automatisiertes Testen, angewandt auf ein System, dessen Fehlerverhalten probabilistisch statt deterministisch ist.

Warum das bei KI mehr zählt als bei einer typischen Web-App: Ein REST-Endpunkt liefert entweder das richtige JSON oder nicht. Ein LLM-Feature kann in 15 % der Fälle eine plausibel klingende falsche Antwort liefern – und eine Demo mit zehn handverlesenen Prompts wird das niemals aufdecken. Evals sind der einzige Weg, die Fehlerrate zu sehen, bevor es Ihre Kunden tun.

Warum das ein Käufer-Problem ist, nicht nur ein Engineering-Problem

Ob Sie für einen individuellen Chatbot, ein RAG-basiertes Support-System oder einen agentischen Workflow beauftragen: Das Pitch-Deck des Anbieters zeigt Ihnen jedes Mal den Happy Path. Das ist nicht unehrlich – es sind schlicht keine belastbaren Informationen. Die Fragen, die den Kauf wirklich absichern, lauten:

• Wie groß ist Ihr Eval-Set, und woher stammen die Fälle?
• Wie hoch ist die aktuelle Bestehensquote, und wie hat sie sich im letzten Monat entwickelt?
• Was passiert mit dem Eval-Score, wenn Sie das Modell wechseln oder den Prompt ändern?
• Führen Sie Evals vor jedem Deploy aus, oder erst wenn etwas kaputt geht?

Ein Anbieter, der das im Griff hat, antwortet mit Zahlen. Einer, der es nicht hat, antwortet mit Adjektiven – „es ist wirklich solide", „wir haben es ausgiebig getestet". Das ist das verräterische Zeichen.

Was in den Vertrag gehört

Behandeln Sie Evals so, wie Sie Testabdeckung in einem normalen Software-SOW behandeln würden – als Lieferobjekt, nicht als Gefälligkeit:

• Mindestgröße und Zusammensetzung des Eval-Sets. Für die meisten KI-Produkte mit einem einzigen Feature sind 50–150 Fälle aus echten oder realistischen Daten eine vernünftige Untergrenze. Ein Support-Bot braucht Fälle aus tatsächlichen vergangenen Tickets, nicht aus synthetischen Fragen, die der Anbieter selbst erfunden hat.
• Eine vor Projektbeginn vereinbarte Mindestquote. 80 % können für ein internes Tool ausreichen; ein kundengerichtetes Feature oder alles, was Gesundheitsdaten oder compliance-relevante Daten berührt, braucht eine höhere Messlatte und manuelle Prüfung der Fehler – nicht nur den Score.
• Eine Pflicht zur erneuten Ausführung. Jedes Modell-Update, jede Prompt-Änderung und jede Anpassung der Retrieval-Logik sollte denselben Eval-Durchlauf auslösen. Stille Regressionen sind der häufigste Weg, wie aus „es hat in der Demo funktioniert" ein „es ist drei Wochen nach dem Launch in der Produktion kaputtgegangen" wird.
• Eigentumsrechte am Eval-Set bei der Übergabe. Sie sollten das Engagement mit den Test-Cases und der Bewertungslogik in der Hand verlassen – nicht nur mit dem ausgelieferten Feature. Wenn der Anbieter das nicht herausgeben will, ist das ein Punkt, der beim Scoping beachtet werden sollte.

Das muss den Vertrag nicht aufblähen. Ein kurzer Anhang – Größe des Eval-Sets, Mindest-Score, Auslöser für erneute Ausführung und wer die Harness am Ende besitzt – deckt alles ab.

Was es kostet – und warum es sich lohnt

Der Aufbau einer initialen Eval-Suite schlägt typischerweise mit etwa 10–15 % der Kosten des KI-Features selbst zu Buche: Zeit für das Sammeln repräsentativer Fälle, das Schreiben des Bewertungsschemas (oder das Einbinden eines LLM-as-Judge für offene Ausgaben) und das Einbinden der Harness in die CI, damit sie automatisch läuft. Das ist ein realer Posten – und ein Anbieter, der einen verdächtig schnellen, verdächtig günstigen KI-Build anbietet, lässt diesen Schritt häufig stillschweigend weg.

Im Vergleich zur Alternative ist es günstig. Die wahren Kosten eines KI-MVPs bestehen nicht nur aus dem Build – dazu kommen die Kosten, nach dem Launch festzustellen, dass das System bei 1 von 5 echten Kundenfragen versagt, und es dann unter Druck neu zu konzipieren, während Kunden bereits schlechte Antworten zu sehen bekommen. Evals verlagern diese Erkenntnis auf den Zeitpunkt vor dem Launch, wenn sie noch ein Code-Review-Gespräch ist und kein Incident.

Das Warnsignal in einem Satz

Wenn die Antwort eines Anbieters auf „Zeigen Sie mir Ihre Evals" eine Demo ist statt ein Dashboard, haben sie kein getestetes System – sie haben ein System, das noch nicht getestet wurde, und Sie wären derjenige, der herausfindet, wo es bricht. Dasselbe Gespür steckt hinter den meisten anderen Warnsignalen in einem Software-Engagement: Fragen Sie nach Belegen, nicht nach Selbstvertrauen.

KI-Anbieter zu evaluieren unterscheidet sich grundlegend nicht vom Evaluieren anderer Software-Partner – Sie suchen nach Beweisen für Sorgfalt, nicht nur nach Beweisen für Output. Evals sind schlicht der Ort, an dem diese Sorgfalt bei KI-Projekten sichtbar wird; und sie sind günstig genug, dass man sie einfordern kann, ohne dass ein seriöser Anbieter dagegen Einwände haben sollte.

Wenn Sie ein KI-Feature planen und einen Partner suchen, der die Eval-Suite parallel zum Feature entwickelt – und nicht erst dann, wenn etwas kaputt geht –, sprechen Sie uns an.