Ein Modell kann einen sauberen Test-Prompt hervorragend beantworten und dennoch für den Workflow, den es verbessern soll, unsicher sein. Genau darin liegt der zentrale Fehler vieler stockender Initiativen mit AI Agents: Das Team bewertet die Gesprächskompetenz und erteilt anschließend operative Handlungsvollmacht.
Die schwierigen Fälle sind nicht die ordentlich strukturierten Rechnungen, Standard-Serviceanfragen oder routinemäßigen Bestellungen. Es sind Fälle mit fehlenden Dokumenten, widersprüchlichen Stammdaten, ungewöhnlichen Vertragsbedingungen, mehrdeutiger Kundensprache, doppelten Datensätzen oder Anfragen, die zunächst gewöhnlich wirken, bis sie eine finanzielle, sicherheitsrelevante oder reputationskritische Grenze berühren. Ein Agent, der solche Fälle mit unbegründeter Sicherheit behandelt, liefert nicht bloß eine schlechte Antwort. Er kann Nacharbeit verursachen, ein Kontrollversagen verdecken oder eine irreversible Änderung in einem Kernsystem auslösen.
Für mittelständische Unternehmen im DACH-Raum lautet die Antwort nicht, auf das perfekte Modell zu warten. Sie müssen ein Evaluation Harness aufbauen, das die Arbeit so abbildet, wie sie tatsächlich eingeht. Bevor ein Agent etwas erstellen, freigeben, ändern oder abschließen darf, sollte er nachweisen müssen, dass er die Grenzen seiner Befugnisse erkennt.
Die Demo misst Sprachgewandtheit, der Workflow verlangt Urteilsvermögen
Eine überzeugende Demonstration beginnt meist mit einem bekannten Dokument, einer sauber formulierten Anfrage und einem erwarteten Ergebnis. Das ist hilfreich, um zu prüfen, ob ein geplanter Use Case technisch plausibel ist. Es ist jedoch kein Test dafür, ob dem Agent in der Produktion vertraut werden kann.
Produktive Arbeit enthält Abweichungen. Eine Ausnahme im Einkauf kann einen Lieferantennamen umfassen, der nicht zum Kreditorenstammsatz passt, eine Bestellung, die eine lokale Freigaberegel überschreitet, oder eine E-Mail, die die kaufmännische Bedeutung eines angehängten Dokuments verändert. Im Kundenservice kann der entscheidende Unterschied zwischen einer gewöhnlichen Lieferanfrage und einer Beschwerde liegen, die auf ein Produktproblem, ein vertragliches Risiko oder einen potenziell schutzbedürftigen Kunden hinweist. Im Finanzbereich kann dieselbe scheinbare Abweichung ein harmloses Rundungsproblem, eine zeitliche Differenz oder ein Hinweis darauf sein, dass ein Vorgang nicht gebucht werden darf.
Der Agent muss nicht jede Ausnahme eigenständig lösen. In vielen Workflows ist das beste Ergebnis eine korrekt strukturierte Eskalation: das Problem erkennen, relevante Belege zusammentragen, die Unsicherheit benennen, einen nächsten Schritt vorschlagen und den Fall an die verantwortliche Person weiterleiten. Ein Agent, der an der richtigen Stelle stoppt, ist oft wertvoller als einer, der eine beeindruckende, aber nicht gerechtfertigte Lösung versucht.
Damit verändert sich die Evaluierungsfrage. Fragen Sie nicht: „Kann der Agent diese Aufgabe abschließen?“ Fragen Sie: „Unter welchen Bedingungen schließt der Agent ab, verschiebt er die Bearbeitung, eskaliert er oder stoppt er?“ Das ist die Grundlage für Quality Assurance von Enterprise AI.
Beginnen Sie mit der Exception Queue, nicht mit der Prompt-Bibliothek
Die wertvollsten Testdaten liegen meist bereits in den operativen Systemen. Finanzteams haben Vorgänge, die geklärt werden mussten. Serviceteams verfügen über Tickets, die wiedereröffnet, weitergeleitet oder manuell korrigiert wurden. Einkaufsteams kennen Anfragen, die den Standardprozess umgingen, eine zusätzliche Prüfung auslösten oder nach einer ersten Bewertung abgelehnt wurden.
Diese Queues zeigen, wo das tatsächliche Urteilsvermögen im Workflow sitzt. Sie enthalten die Sprache, Dokumentenqualität, Systemwidersprüche und Regelungsunklarheiten, die ein synthetischer Testsatz typischerweise glättet. Außerdem zeigen sie, wie „gut“ im jeweiligen Kontext aussieht: nicht nur als endgültige Entscheidung, sondern anhand der berücksichtigten Belege, der zuständigen Rolle, der erlaubten Aktion und des Grundes für menschliches Eingreifen.
Bauen Sie Fälle rund um Entscheidungen auf, nicht rund um Dokumente. Ein brauchbarer Evaluierungsfall sollte den operativen Kontext erfassen, der für eine Entscheidung erforderlich ist. Dazu können die eingehende Anfrage, relevante Auszüge aus Datensätzen, angehängte Unterlagen, die geltende Richtlinie oder Verfahrensanweisung sowie die erwartete Bearbeitung gehören. Entscheidend ist, dass die erwartete Bearbeitung mehr als eine einzige „richtige Antwort“ zulässt. Bei manchen Fällen besteht korrektes Verhalten darin, die Aufgabe abzuschließen. Bei anderen heißt es, fehlende Informationen anzufordern, einen Entwurf zur Prüfung anzulegen, eine nicht belegte Anfrage abzulehnen oder an eine benannte Funktion zu eskalieren.
Hier schwächen viele Teams ihre Tests unbeabsichtigt. Sie versehen jeden historischen Fall mit dem endgültigen menschlichen Ergebnis und erwarten, dass der Agent es reproduziert. Dabei kann der Mensch Informationen genutzt haben, die dem Agent nicht zur Verfügung stehen, Ermessensspielräume ausgeübt haben, die beim Menschen bleiben sollten, oder einen vorgelagerten Fehler außerhalb des dokumentierten Prozesses korrigiert haben. Ein gutes Harness dokumentiert das minimale akzeptable Verhalten des Agent, nicht eine fiktive Erwartung allumfassenden Wissens.
Definieren Sie den Entscheidungsvertrag, bevor Sie das Modell testen
Ein Evaluation Harness ist nicht nur eine Sammlung von Beispielen. Es ist ein versionierter Vertrag zwischen dem Eigentümer des Workflows, dem technischen Team und den Kontrollfunktionen.
Definieren Sie für jede Aktion, die der Agent ausführen darf, seine Befugnisse eindeutig. Er darf Informationen lesen und zusammenfassen, einen Fall klassifizieren, eine Antwort entwerfen, einen Bearbeitungsweg empfehlen, einen vorgeschlagenen Datensatz anlegen oder eine Systemänderung ausführen. Das sind materiell unterschiedliche Berechtigungen. Sie als eine Kategorie namens „Automatisierung“ zu behandeln, ist der Grund, warum Teams zu schnell von nützlicher Unterstützung zu unkontrolliertem Handeln übergehen.
Schreibzugriff muss durch Evidenz verdient werden. Ein Agent, der eine Bestellanforderung entwerfen kann, ist nicht automatisch bereit, sie einzureichen. Ein Agent, der eine Service-Lösung empfehlen kann, ist nicht automatisch bereit, die Kundenkommunikation zu versenden. Die Evaluierung sollte sowohl die Qualität des Ergebnisses als auch die Angemessenheit der ausgeführten Aktion prüfen. Eine gut formulierte Nachricht an den falschen Kunden oder eine korrekte Klassifizierung mit anschließender nicht autorisierter Systemänderung bleibt ein Fehler.
Der Entscheidungsvertrag sollte auch festhalten, was der Agent niemals tun darf. Diese Stop Conditions sind keine Randdetails für die Rechtsprüfung, sondern Produktanforderungen. Eine Stop Condition kann gelten, wenn erforderliche Belege fehlen, Quellsysteme widersprüchliche Angaben liefern, der Fall außerhalb einer genehmigten Richtlinie liegt, ein Sicherheitssignal schwach ist oder die Aktion ohne erforderliche Bestätigung eine finanzielle Verpflichtung oder externe Kommunikation auslösen würde.
Verwenden Sie keine vage Anweisung wie „Sei vorsichtig“. Übersetzen Sie Vorsicht in beobachtbares Verhalten. Der Agent sollte die fehlenden Belege benennen, den ursprünglichen Fallkontext erhalten, erläutern, warum er nicht fortfahren kann, und den Vorgang an die richtige Queue oder Rolle übergeben. Dieses Verhalten lässt sich wiederholt testen.
Machen Sie aus realen Fällen eine versionierte Regression Suite
Sobald ein Team repräsentative Ausnahmefälle ausgewählt hat, braucht das Harness Disziplin. Speichern Sie Eingaben, erwartete Verhaltensweisen, Evaluierungskriterien, Workflow-Konfiguration und Modell-Setup gemeinsam. Pseudonymisieren oder redigieren Sie dabei personenbezogene und vertrauliche Daten, trennen Sie Zugriffsrollen, speichern Sie verschlüsselt, definieren Sie Löschfristen und einen Freigabeprozess für Produktionsdaten und prüfen Sie, ob Modellanbieter Daten verarbeiten oder speichern. Wenn sich der Prompt, der Retrieval-Korpus, die Tools, die Modellversion oder die Routing-Logik ändern, muss das Team dieselben Fälle erneut ausführen und die Ergebnisse vergleichen können.
Das ist LLM Regression Testing in der Praxis. Eine Änderung, die Antworten auf routinemäßige Serviceanfragen verbessert, kann den Agent zugleich eher dazu verleiten, bei mehrdeutigen Anfragen zu handeln. Ein überarbeiteter Retrieval-Prozess kann eine veraltete Richtlinie hervorholen. Eine neue Tool-Integration kann verändern, was geschieht, nachdem das Modell zu einer an sich plausiblen Schlussfolgerung gelangt ist. Ohne Regression Suite werden solche Änderungen zu Produktionsexperimenten, die als Releases getarnt sind.
Testen Sie die gesamte Kette, nicht nur die endgültige Antwort. Agentic-AI-Tests müssen das Zwischenverhalten prüfen, das das Risiko bestimmt. Hat der Agent relevante Belege abgerufen oder sich auf Annahmen gestützt? Hat er ein autorisiertes Tool ausgewählt? Hat er eine Aktion in der richtigen Reihenfolge versucht? Hat er den Unterschied zwischen einer Empfehlung und einer Ausführung gewahrt? Erzeugt die Agentenplattform oder das umgebende System strukturierte, zugriffsgeschützte und manipulationsresistente Logs zu Eingaben, Modell- und Prompt-Versionen, Retrieval, Tool-Aufrufen, Berechtigungsentscheidungen und Ergebnissen, anhand derer ein Prüfer nachvollziehen kann, was passiert ist? Der Agent kann zusätzlich eine menschlich lesbare Fallbegründung erzeugen.
Der Antworttext allein kann irreführend sein. Ein Agent kann eine plausibel klingende Erklärung liefern und dabei irrelevante Quellen nutzen, widersprüchliche Informationen übersehen oder eine verbotene Aktion versuchen, bevor ein nachgelagertes System sie blockiert. Genau solche Fehler sollte das Harness sichtbar machen.
Versionierung macht auch Meinungsverschiedenheiten produktiv. Der operative Bereich kann eine Eskalation für übervorsichtig halten, während Risiko- oder Finanzfunktion sie für notwendig erachtet. Statt diesen Konflikt durch informelle Prompt-Änderungen zu lösen, dokumentieren Sie die akzeptierte Richtlinienentscheidung im Testfall. Die Evaluation Suite wird damit zum lebenden Ausdruck dessen, wie die Organisation den Workflow betreiben will.
Nutzen Sie Bestehensgrenzen, die die Kosten von Fehlern abbilden
Ein einzelner aggregierter Score reicht selten aus. Wenn ein Agent bei Routinefällen gut abschneidet, aber eine kleine Gruppe sensibler Ausnahmen falsch behandelt, kann der Durchschnitt beruhigend wirken, obwohl das Deployment weiterhin unsicher ist.
Trennen Sie die Evaluierungsdimensionen. Messen Sie, ob der Agent zu einem akzeptablen operativen Ergebnis gelangt ist, angemessene Belege verwendet hat, dem vorgeschriebenen Bearbeitungsweg gefolgt ist, seine Berechtigungsgrenze respektiert hat und eskaliert hat, wenn er es sollte. Bei risikoreicheren Aktionen sollten Sie unsichere Ausführung stärker gewichten als harmlose Unvollständigkeit. Es ist meist einfacher, einen Agent zu verbessern, der zu oft menschliche Unterstützung anfordert, als die Folgen eines Agent zu reparieren, der über seine Befugnisse hinaus handelt.
Der Schwellenwert sollte die Aktion widerspiegeln, nicht die Begeisterung rund um den Pilot. Ein interner Assistent für Entwürfe kann andere Fehlermuster tolerieren als ein Agent, der Zahlungsdaten ändert, Bestände zusagt, Kundendaten verändert oder vertragliche Kommunikation versendet. Mit zunehmender Handlungsvollmacht muss die für einen Release erforderliche Evidenz strenger werden.
Das bedeutet nicht, dass jeder Prozess eine große Plattform oder eine spezialisierte Evaluierungsabteilung benötigt. Ein fokussiertes Mittelstandsteam kann mit einer sorgfältig kuratierten Auswahl realer Workflow-Fälle, klaren Kennzeichnungen für akzeptables Verhalten und einem wiederholbaren Review-Prozess beginnen, an dem die Verantwortlichen für Ausnahmen beteiligt sind. Die wichtige Investition ist keine aufwendige Bewertungsinszenierung. Sie besteht darin, sich darauf zu verständigen, was sicheres, nützliches und verantwortbares Verhalten bedeutet, bevor der Druck zum Deployment die Führung übernimmt.
Führen Sie schrittweise ein und halten Sie das Harness mit dem Betrieb verbunden
Das erste produktive Deployment sollte einen menschlichen Kontrollpunkt erhalten. Lassen Sie den Agent eine Empfehlung vorbereiten, einen Datensatz entwerfen oder Belege zusammenstellen, während ein verantwortlicher Kollege die Aktion bestätigt. Vergleichen Sie die vom Agent vorgeschlagene Bearbeitung mit dem tatsächlichen Ergebnis und führen Sie relevante Abweichungen in die Suite zurück.
Mit der Zeit können manche Kategorien eng begrenzte Formen der Automatisierung verdienen. Andere bleiben bewusst unterstützend. Das ist kein Scheitern der Technologie. Es ist eine rationale Zuweisung von Handlungsvollmacht auf Basis von Konsequenzen, Belegqualität und Prozessstabilität.
Die operative Feedback-Schleife ist wichtig, weil sich Workflows verändern. Neue Lieferanten, geänderte Richtlinien, überarbeitete Systeme und veränderte Kundenerwartungen können eine Evaluation Suite entwerten, die zuvor robust erschien. Behandeln Sie das Harness als Teil des Betriebsmodells des Workflows, mit geteilter Verantwortung zwischen der Fachfunktion und dem Team, das für das AI-System zuständig ist.
Ein AI Agent sollte keinen Schreibzugriff erhalten, weil er in einer Demo gut abgeschnitten hat. Er sollte nur die Handlungsvollmacht erhalten, die sein getestetes Verhalten, seine Kontrollen und seine Eskalationsdisziplin rechtfertigen. Dieser Unterschied entscheidet darüber, ob aus einem vielversprechenden AI-Pilot eine verlässliche operative Fähigkeit wird.
Ein Diagnostic hilft Ihnen zu identifizieren, wo ein AI Agent sicher unterstützen kann, wo die Behandlung von Ausnahmen stärkere Kontrollen braucht und welche Evaluation-Evidenz erforderlich ist, bevor Automatisierung operative Risiken schafft.
Hinweis zum Kontext: Dieser Artikel stützt sich auf praxisorientierte Leitlinien für die Konzeption und den Betrieb von Evaluierungen für AI Agents; externe Quellen wurden nicht zitiert.