Die meisten Gespräche über KI-Agenten-Evaluation drehen sich ums Entwicklungsteam. Test-Harness aufbauen, Benchmark laufen lassen, deployen wenn alles grün ist. Aber wenn Sie als Business-Verantwortlicher oder Operations-Lead einen Agenten abnehmen, der echte Kundenanfragen bearbeiten, echte Rechnungen verarbeiten oder echte Eskalationen weiterleiten soll — dann gehört die Testfrage auch zu Ihrer Verantwortung.
Dieser Artikel behandelt die KI-Agenten-Evaluation als Werkzeug auf Auftraggeberseite: Welche Abnahmekriterien Sie vor der Freigabe einfordern sollten, und welche Regressionsprüfungen nach dem Go-live kontinuierlich laufen müssen, um die stillen Ausfälle zu erkennen, die sich mit der Zeit einschleichen.
Warum „Hat in der Demo funktioniert” kein Abnahmestandard ist
Eine Demo ist ein kuratierter Durchlauf. Der Agent verarbeitet die zehn Eingaben, von denen jemand bereits weiß, dass er sie gut beherrscht. Produktion ist anders: Eingaben kommen in unerwarteten Formaten, Nutzer formulieren Dinge auf Weisen, die niemand vorhergesehen hat, verbundene APIs liefern Edge-Case-Antworten, und das zugrundeliegende Sprachmodell wird vom Anbieter aktualisiert.
Jedes dieser Ereignisse ist eine potenzielle Regression. Ohne eine formale Eval-Suite ist das erste Signal, das Sie erhalten, eine Beschwerde — oder schlimmer: ein nachgelagerter Fehler, den Sie erst beim Audit entdecken.
Die Lücke zwischen „funktioniert in der Demo” und „verhält sich zuverlässig in der Produktion” ist genau dort, wo die meisten KI-Agenten-Projekte auf ihre ersten ernsthaften Probleme stoßen. Evals schließen diese Lücke systematisch, anstatt darauf zu hoffen, dass sich nichts ändert.
Die drei Ebenen einer verlässlichen Eval-Suite
Ein gut strukturiertes Evaluierungsprogramm deckt drei unterschiedliche Ebenen ab. Sie sind keine Alternativen — Sie brauchen alle drei.
1. Funktionale Korrektheit: Erledigt der Agent, was er tun soll?
Diese Ebene prüft die Kernaufgabe. Bei einem Support-Triage-Agenten bedeutet das: Klassifiziert er die Ticket-Priorität korrekt? Leitet er an das richtige Team weiter? Kommt er ohne Absturz mit einem fehlenden Pflichtfeld zurecht?
Konkrete Abnahmekriterien, die Sie von Ihrem Anbieter einfordern sollten:
- Ein dokumentiertes Test-Set mit mindestens 50–100 repräsentativen Eingaben (mehr bei hochvolumigen Workflows), das Normalfälle, Edge Cases und bekannte Fehlermuster abdeckt
- Eine im Vertrag vereinbarte Zielgenauigkeit — kein „Best Effort”, eine Zahl — z. B. ≥92 % korrekte Klassifikation auf dem Test-Set
- Dokumentiertes Verhalten bei Out-of-Scope-Eingaben: Was tut der Agent, wenn er etwas erhält, für das er nicht ausgelegt ist? Scheitert er kontrolliert oder liefert er eine falsche Antwort mit scheinbarer Sicherheit?
Das Test-Set selbst muss Teil Ihres Lieferumfangs sein. Wenn ein Anbieter Ihnen die Testfälle nicht zeigen kann, haben Sie keine Baseline.
2. Tool- und Integrationstreue: Interagiert der Agent korrekt mit verbundenen Systemen?
Agenten in der Produktion rufen externe Tools auf — CRMs, Kalender, Datenbanken, Zahlungs-APIs. Funktionale Korrektheit in der Isolation garantiert kein korrektes Verhalten, wenn diese Integrationen im Spiel sind.
Diese Ebene prüft:
- Schreibt der Agent Daten in die richtigen Felder, im richtigen Format, unter den richtigen Bedingungen?
- Verarbeitet er API-Fehler, Rate Limits oder unerwartete Response-Schemata, ohne Daten stillschweigend zu verlieren?
- Gibt es Guardrails für Nebenwirkungen — d. h. verweigert der Agent irreversible Aktionen (Datensätze löschen, E-Mails versenden, Karten belasten), wo die Tragweite einen menschlichen Bestätigungsschritt erfordert?
Für komplexe Multi-System-Workflows bitten Sie Ihren Anbieter, einen Failure-Injection-Test zu demonstrieren: Liefern Sie absichtlich eine fehlerhafte API-Antwort und zeigen Sie, was der Agent tut. Ein Agent, der in Panik gerät oder eine halluzinierte Fallback-Antwort produziert, ist nicht produktionsreif.
3. Verhaltenskonsistenz: Verhält sich der Agent vorhersehbar bei unterschiedlichen Formulierungen und Bedingungen?
Sprachmodelle sind probabilistisch. Dieselbe semantische Absicht, auf zehn verschiedene Weisen ausgedrückt, sollte zum selben Ergebnis führen. Ein Support-Agent, der „Ich möchte meinen Auftrag stornieren” korrekt verarbeitet, aber „Bitte kündigen Sie mein Abonnement” falsch weiterleitet, hat ein Konsistenzproblem, das sich erst im großen Maßstab zeigt.
Diese Ebene umfasst typischerweise:
- Paraphrase-Testing: mehrere Formulierungen derselben Absicht
- Adversarielle Eingaben: Versuche, den Agenten zu Out-of-Scope-Aktionen zu verleiten
- Persona-Boundary-Testing: Bleibt der Agent in seiner definierten Rolle, oder kann ein Nutzer ihn in fremdes Terrain führen?
Das ist eng mit dem Sicherheits- und Prompt-Injection-Risikoprofil des Agenten verknüpft — beide Anliegen teilen die Test-Infrastruktur und sollten gemeinsam adressiert werden.
So sieht eine minimale Abnahme-Checkliste aus
Bevor Sie ein neues Agent-Deployment freigeben, sollten Sie auf jede der folgenden Fragen mit Ja antworten können:
- Ein dokumentiertes Test-Set existiert und wurde uns als Projektlieferung übergeben
- Genauigkeitsziele für Kernaufgaben sind definiert und wurden auf dem Test-Set erreicht
- Edge-Case- und Fehlerbehandlung wurde demonstriert, nicht nur beschrieben
- Tool-Integrationen wurden mit echten (oder realistischen Sandbox-)Verbindungen getestet
- Das Verhalten des Agenten bei Out-of-Scope-Eingaben ist definiert und getestet
- Ein Baseline-Performance-Snapshot wurde festgehalten, damit Regressionen erkennbar sind
Diese Liste ist bewusst kurz gehalten. Es geht nicht darum, ein Doktorandenprogramm in ML-Evaluation zu starten — sondern darum, eine vertretbare Baseline zu etablieren, die Sie schützt und Ihren Anbieter in die Pflicht nimmt. Ein Anbieter, dem diese Liste unangenehm ist, ist ein Anbieter, dem gegenüber Vorsicht angebracht ist.
Eine umfassendere Sicht darauf, was Sie bei der Partnerwahl fragen sollten, bietet der Leitfaden zu KI-Agenten-Entwicklungsunternehmen, der die Anbieter-Due-Diligence vertieft.
Regressionsprüfungen: Stille Degradation nach dem Go-live erkennen
Akzeptanztests beim Launch zu bestehen ist notwendig, aber nicht hinreichend. Agenten degradieren stillschweigend. Die Gründe sind strukturell:
Modell-Updates. Das Sprachmodell, das Ihren Agenten antreibt, wird vom Anbieter aktualisiert — formale Deprecations kündigen sich meist an, aber Fähigkeitsänderungen innerhalb einer laufenden benannten Version und Updates von Default-Aliasen können mit begrenzter oder keiner Benachrichtigung pro Kunde erfolgen. Ein Modell-Update, das die Leistung bei den meisten Aufgaben verbessert, kann bei Ihren Aufgaben regrediieren. Ohne eine Regressions-Suite, die in fester Kadenz läuft, erfahren Sie es erst, wenn Nutzer Ihnen melden, dass etwas nicht stimmt.
Data Drift. Vokabular und Kontext echter Nutzeranfragen verschieben sich über die Zeit. Ein Customer-Support-Agent, der auf dem Produktkatalog des letzten Jahres trainiert und getestet wurde, kann nach einer Produktlinienänderung anfangen, Anfragen falsch zu routen — obwohl das zugrundeliegende Modell unverändert ist.
Integrations-Änderungen. Eine API, von der Ihr Agent abhängt, aktualisiert ihr Schema. Ein Feldname ändert sich. Ein neuer Pflichtparameter erscheint. Der Agent schlägt entweder fehl oder fällt auf ein unbeabsichtigtes Verhalten zurück.
Illustratives Szenario: Stellen Sie sich einen Dokumentenverarbeitungs-Agenten vor, der eingehende Lieferantenrechnungen bearbeitet. Beim Launch extrahiert er Positionen korrekt und leitet mit 94 % Erfolgsquote auf dem Test-Set zur Freigabe weiter. Sechs Monate später ändert ein wichtiger Lieferant sein Rechnungstemplate. Ohne wöchentliche Regressionsprüfung gegen einen festen Stichprobenbestand echter Rechnungen könnte diese Genauigkeit still auf 70 % sinken, bevor es jemand bemerkt — das bedeutet etwa jede dritte Rechnung landet in einer manuellen Fallback-Queue, die eigentlich automatisiert sein sollte. Die Monitoring-Kosten, um das früh zu erkennen, sind verschwindend gering im Vergleich zum nachgelagerten Abstimmungsaufwand.
Das minimale viables Monitoring-Setup ist nicht komplex:
- Ein festes Golden Dataset — eine kuratierte Stichprobe von 20–50 Produktionseingaben mit bekannten korrekten Ausgaben, die aus jedem Training- oder Fine-Tuning-Prozess herausgehalten wird
- Ein geplanter Regressionslauf — wöchentlich oder nach jeder Infrastrukturänderung: lassen Sie den Agenten gegen das Golden Dataset laufen und vergleichen Sie die Ausgaben mit der Baseline
- Ein Alerting-Schwellenwert — fällt die Genauigkeit auf dem Golden Set um mehr als X Prozentpunkte gegenüber der Baseline, lösen Sie eine menschliche Überprüfung aus, bevor sich das Problem ausweitet
Das knüpft direkt an die übergeordnete Frage an, welche KPIs tatsächlich belegen, dass ein Agent funktioniert — Regressionsmetriken sollten in dasselbe operative Dashboard wie Ihre Business-KPIs einfließen und nicht in einem separaten Engineering-Silo leben.
Wer für Evals verantwortlich ist — und was vertraglich zu regeln ist
Der Anbieter erstellt und betreibt die initiale Eval-Suite. Das Unternehmen besitzt die Abnahmekriterien und das Recht, die Ergebnisse einzusehen. Nach dem Go-live ist das laufende Regressionsmonitoring eine gemeinsame Verantwortung, die in Ihrem Vertrag oder Ihrer Service-Vereinbarung explizit geregelt sein sollte.
Klären Sie konkret:
- Wer führt Regressionsprüfungen durch, und in welcher Kadenz?
- Wer wird benachrichtigt, wenn ein Regressionsschwellenwert überschritten wird?
- Welches SLA gilt für Untersuchung und Behebung nach einer erkannten Regression?
- Erhalten Sie einen zusammenfassenden Report oder nur einen Alert?
Das sind keine konfrontativen Fragen. Ein Anbieter mit reifen KI-Agenten-Entwicklungspraktiken wird Antworten bereit haben, weil er diese Prüfungen für die eigene Qualitätssicherung selbst durchführt. Das Gespräch sagt Ihnen sehr viel über die operative Reife aus.
Governance-bewusste Organisationen möchten Eval-Ergebnisse möglicherweise als Teil eines übergeordneten AI-Governance-Audit-Trails protokollieren — besonders relevant für regulierte Branchen oder wo der EU AI Act Anwendung findet. Es sei darauf hingewiesen, dass die meisten B2B-Automatisierungsagenten (Support-Triage, Rechnungsverarbeitung, Scheduling) unter die Minimal- oder Eingeschränkt-Risiko-Kategorie des Gesetzes fallen, nicht unter die Hochrisiko-Kategorie des Anhangs III, die die schwersten Dokumentationspflichten mit sich bringt. Für diese Hochrisiko-Pflichten wird die ursprüngliche Frist August 2026 im Rahmen des vorläufigen Digital-Omnibus-Abkommens voraussichtlich auf Dezember 2027 verschoben — die formale Annahme stand zum Zeitpunkt der Veröffentlichung jedoch noch aus.
Evals sind ein Vertrauensmechanismus, keine Formalie
Der tiefere Punkt ist dieser: Eine Eval-Suite ist kein bürokratischer Overhead. Sie ist die Evidenzbasis, die es Ihnen erlaubt, einem automatisierten System zu vertrauen, das in Ihrem Unternehmen im großen Maßstab operiert. Ohne sie verlassen Sie sich auf Intuition und hoffen, dass kein Edge Case zum falschen Zeitpunkt auftaucht.
Auftraggeber, die Evals einfordern, erhalten bessere Agenten. Der Prozess der Abnahmekriterien-Definition erzwingt Präzision — darüber, was der Agent tun soll, was er nicht tun soll, und wie Leistung gemessen wird. Diese Präzision bringt Erwartungsdiskrepanzen früh ans Licht, wenn sie noch günstig zu korrigieren sind.
Wenn Sie gerade ein Anbieterangebot evaluieren, Abnahmekriterien für einen neuen Agenten definieren oder Monitoring für einen bereits laufenden Agenten etablieren möchten — ein fokussierter 30-Minuten-Call mit unserem Team hilft Ihnen dabei, die spezifischen Prüfungen und Kriterien für Ihren Anwendungsfall zu identifizieren. Nehmen Sie Kontakt mit Orange ITS auf und wir strukturieren das Gespräch rund um Ihre Situation.