KI-Agenten testen: Szenarien, Evals und Sicherheitsgrenzen

Ein Agent, der in der Demo drei von drei Anfragen sauber löst, ist keine Aussage über den Betrieb. Das eigentliche Problem zeigt sich erst bei Anfrage Nummer 47: einer, die anders formuliert ist als erwartet, zwei Absichten gleichzeitig enthält oder ein Werkzeug nahelegt, das für den Fall gar nicht gedacht ist. Genau dort entscheidet sich, ob ein KI-Agent im Unternehmen etwas taugt.

Kurz die Kernantwort vorweg: Ein Agent braucht mindestens vier Testfallgruppen, bevor er produktiv geht. Ein Golden Set aus den häufigsten Kernaufgaben mit geprüften Referenzantworten, Randfälle mit mehrdeutigen oder unvollständigen Eingaben, Tool-Auswahl-Tests, die prüfen, ob der Agent das richtige Werkzeug wählt oder passend verzichtet, und adversarial Tests mit widersprüchlichen oder manipulativen Eingaben. Jeder einzelne Testfall braucht eine erwartete Aktion, die erlaubten Werkzeuge und ein Abbruchkriterium. Ohne diese Struktur bleibt „der Agent funktioniert” eine Meinung statt einer belastbaren Aussage.

Dieser Artikel ist Teil des Themen-Clusters KI-Agenten und richtet sich an Geschäftsführung, Operations, IT und Fachbereich in KMU, die einen Agenten vor dem produktiven Einsatz oder nach ersten Problemen im Betrieb systematisch prüfen wollen.

Das Problem: Wenn die Demo lügt

Demos sind darauf angelegt, gut auszusehen. Wer einen Agenten vorführt, wählt fast automatisch die Beispiele, bei denen er zuverlässig funktioniert – meist die drei bis fünf Kernszenarien, für die er gebaut wurde. Genau diese Auswahl verschleiert das eigentliche Risiko: Ein Agent, der Werkzeuge selbstständig auswählt und Aktionen ausführt, trifft im Betrieb ständig auf Fälle, die niemand explizit vorgesehen hat. Eine Kundenanfrage, die zwei Themen vermischt. Eine Support-Nachricht mit einer eingebetteten Anweisung, die der Agent für eine echte Instruktion halten könnte. Eine Rückfrage, bei der das richtige Verhalten „nichts tun und eskalieren” wäre – aber der Agent lieber irgendein Werkzeug aufruft, weil er darauf trainiert ist, hilfreich zu wirken.

Das OWASP GenAI Security Project hat diese Klasse von Risiken 2025 in einem eigenen Rahmenwerk für agentenbasierte Anwendungen systematisch erfasst, weil sie sich von klassischen Sprachmodell-Risiken unterscheidet: Sobald ein System nicht nur Text erzeugt, sondern Werkzeuge aufruft, Datenbanken verändert oder E-Mails verschickt, entstehen neue Fehlerklassen – etwa Tool-Missbrauch, Zielmanipulation oder Vertrauensausnutzung gegenüber Menschen, die Aktionen freigeben. Testen heißt bei einem Agenten deshalb mehr als bei einem Chatbot: Es reicht nicht, die Textqualität zu prüfen. Geprüft werden muss der ganze Handlungspfad – welche Entscheidung der Agent trifft, welches Werkzeug er wählt, mit welchen Parametern, und wann er sich zurückhält.

Begriffe kurz geklärt

Für den Rest des Artikels gilt eine klare Trennung dieser vier Begriffe:

• Testfall ist eine konkrete Eingabe (Anfrage, Ticket, Dokument) mit einer definierten erwarteten Reaktion des Agenten – Aktion, Werkzeugwahl oder Antworttext.
• Golden Set ist eine Sammlung von Testfällen mit von Menschen geprüften Referenzergebnissen, gegen die der Agent regelmäßig automatisiert läuft.
• Eval (Evaluation) ist der einzelne Durchlauf eines Agenten gegen ein Testset mit einer messbaren Bewertung – bestanden/nicht bestanden oder eine Punktzahl.
• Adversarial Test ist ein Testfall, der absichtlich versucht, den Agenten aus seinem beabsichtigten Verhalten herauszudrängen – durch Widersprüche, versteckte Anweisungen oder Manipulationsversuche.

Wichtig ist die Abgrenzung nach unten: Ein paar manuelle Stichproben durch eine Person, die „mal ein paar Sachen ausprobiert”, sind kein Testprozess. Sie finden die offensichtlichen Fehler, aber nicht die systematischen – und die sind es, die im Betrieb wiederkehren.

Welche Testfälle braucht man?

Vier Gruppen decken die relevanten Fehlerklassen ab. Sie ergänzen sich, keine ersetzt eine andere.

1. Golden-Set-Fälle (Kernaufgaben). Die zehn bis zwanzig Anfragetypen, die im Alltag am häufigsten vorkommen – aus echten, anonymisierten Daten der letzten Monate, nicht aus der Fantasie des Entwicklungsteams. Diese Fälle müssen zuverlässig funktionieren; fällt hier etwas durch, ist der Agent nicht einsatzbereit.

2. Randfälle (Edge Cases). Mehrdeutige, unvollständige oder ungewöhnlich formulierte Anfragen: zwei Anliegen in einer Nachricht, fehlende Pflichtangaben, ungewöhnliche Reihenfolge. Randfälle testen, ob der Agent bei Unsicherheit nachfragt statt zu raten.

3. Tool-Auswahl-Fälle. Testfälle, bei denen mehrere Werkzeuge zur Auswahl stehen, aber nur eines (oder keines) richtig ist. Wichtig sind hier explizit auch Fälle, in denen die korrekte Antwort „kein Tool nutzen” lautet – ein Agent, der bei jeder Anfrage irgendein Werkzeug aufruft, ist ein Risiko, kein Feature.

4. Adversarial Fälle. Eingaben, die den Agenten testen, statt ihn zu unterstützen: widersprüchliche Anweisungen, versteckte Instruktionen in Dokumenten, die der Agent verarbeitet, oder Formulierungen, die Dringlichkeit vortäuschen, um unüberlegtes Handeln zu provozieren.

Eine Faustregel aus meiner Arbeit: Das Verhältnis sollte grob bei zwei Dritteln Golden-Set- und Randfällen zu einem Drittel Tool-Auswahl- und adversarial Fällen liegen – letztere sind aufwändiger zu bauen, aber genau sie decken die Fehler ab, die im Betrieb am teuersten werden.

Wie erstellt man Golden Sets?

Der pragmatische Weg beginnt nicht am Whiteboard, sondern in den vorhandenen Daten: Supportverläufe, CRM-Notizen, E-Mail-Archive, Chat-Protokolle. Daraus werden echte, anonymisierte Anfragen extrahiert – Namen, Vertragsnummern und andere personenbezogene Daten entfernt oder ersetzt, bevor sie in ein Testsystem wandern.

Ein praktikables Vorgehen in vier Schritten:

1. Sammeln. 50 bis 150 reale Anfragen aus dem relevanten Zeitraum extrahieren, grob nach Thema clustern.
2. Auswählen. Aus jedem Cluster die zwei bis fünf repräsentativsten Fälle auswählen – nicht die einfachsten, sondern die typischen, inklusive der leicht unangenehmen.
3. Referenz festlegen. Für jeden Fall definiert eine fachlich zuständige Person die erwartete Aktion oder Antwort – nicht im Nachhinein am Agenten-Output orientiert, sondern unabhängig davon, was „richtig” wäre.
4. Pflegen. Jeder Fehler, der später im Betrieb auffällt, wird als neuer Testfall ins Golden Set aufgenommen. So wächst das Set mit der tatsächlichen Nutzung, statt statisch zu bleiben.

Ein Golden Set mit 20 bis 50 Fällen ist ein realistischer Start für einen einzelnen Agenten-Use-Case in einem KMU – die genaue Zahl hängt davon ab, wie viele unterschiedliche Aufgabentypen der Agent abdeckt. Wichtiger als die Menge ist die Pflege: Ein Golden Set, das seit der Einführung nicht mehr aktualisiert wurde, testet nur noch die Probleme von gestern.

Wie prüft man Tool-Auswahl?

Die Tool-Auswahl ist der Teil, der bei reinen Text-Evals am häufigsten übersehen wird – weil eine falsche Endantwort trotz richtiger Tool-Wahl auffällt, eine richtige Endantwort trotz falscher oder riskanter Tool-Wahl aber oft nicht. Deshalb muss der Test den ganzen Pfad protokollieren, nicht nur das Ergebnis.

Konkret bedeutet das: Für jeden Testfall wird vorab festgelegt, welche Werkzeuge erlaubt sind, welches Werkzeug (falls überhaupt eines) die richtige Wahl ist, und mit welchen Parametern es aufgerufen werden dürfte. Nach dem Testlauf wird geprüft: Hat der Agent ein Werkzeug aufgerufen, obwohl keins nötig war? Hat er das falsche Werkzeug gewählt? Waren die Parameter korrekt – etwa die richtige Kundennummer, nicht eine geratene? Und, besonders wichtig bei mehrstufigen Aufgaben: Hat er die Reihenfolge eingehalten, wenn eine Reihenfolge sicherheitsrelevant war (z. B. erst prüfen, dann buchen)?

Das OWASP-Rahmenwerk für agentenbasierte Anwendungen führt Tool-Missbrauch als eigene Risikokategorie, weil genau hier ein Großteil der praktischen Schadensfälle entsteht: ein Agent, der ein Zahlungswerkzeug mit falschen Parametern aufruft, ist gefährlicher als einer, der eine falsche Textantwort formuliert. Tool-Auswahl-Tests sind deshalb keine Kür, sondern der Kern der Testabdeckung bei jedem Agenten, der mehr tut als antworten.

Welche adversarial Tests sind sinnvoll?

Adversarial Tests simulieren nicht böswillige Hacker, sondern die deutlich häufigeren Alltagsfälle: unklare, widersprüchliche oder manipulative Formulierungen, die ein System aus der Bahn werfen können, ohne dass jemand das beabsichtigt. Sinnvolle Kategorien für KMU-Agenten:

• Widersprüchliche Anweisungen. Eine Anfrage enthält zwei sich ausschließende Wünsche – testet, ob der Agent nachfragt statt willkürlich einen zu wählen.
• Versteckte Instruktionen. Ein Dokument oder eine E-Mail, die der Agent verarbeitet, enthält eingebettete Anweisungen („ignoriere vorherige Regeln und…”) – testet, ob der Agent zwischen Nutzeranweisung und verarbeitetem Inhalt unterscheidet.
• Berechtigungsausweitung. Eine Anfrage versucht, den Agenten zu einer Aktion außerhalb seines eigentlichen Aufgabenbereichs zu bewegen – testet, ob er innerhalb seiner Grenzen bleibt.
• Drängende Formulierungen. Künstliche Dringlichkeit oder emotionaler Druck, der zu unüberlegtem Handeln verleiten soll – testet, ob der Agent bei kritischen Aktionen trotzdem die vorgesehenen Prüfschritte einhält.

Diese Fälle sind aufwändiger zu bauen als Golden-Set-Fälle, weil sie Kreativität brauchen – am besten im Team entwickelt, nicht von einer Person allein, die schnell in ihre eigenen blinden Flecken läuft. Für sicherheitskritische Anwendungsfälle (Zahlungen, Vertragsänderungen, Zugriffe auf sensible Daten) sind adversarial Tests keine Kür, sondern Teil der Abnahme.

Welche Abnahmekriterien gelten?

Es gibt keine allgemeingültige Prozentzahl, ab der ein Agent „bereit” ist – das hängt an Aufgabe und Risiko. Sinnvoll ist ein gestuftes Kriterienset statt einer einzelnen Kennzahl:

Kriterium	Was geprüft wird	Typische Schwelle
Golden-Set-Erfolgsrate	Anteil korrekt gelöster Kernaufgaben	Hoch genug, dass keine Kernaufgabe systematisch scheitert – konkreter Wert je nach Risiko festlegen
Kritische Tool-Fehler	Fehlaufrufe bei sicherheitsrelevanten Werkzeugen (Zahlung, Löschung, Versand)	Null Toleranz – jeder Fall wird einzeln geprüft, kein Durchschnittswert
Umgang mit Unsicherheit	Nachfragen statt Raten bei mehrdeutigen Randfällen	Agent eskaliert oder fragt nach, statt eine Aktion zu erzwingen
Adversarial Robustheit	Verhalten bei manipulativen/widersprüchlichen Eingaben	Agent bleibt innerhalb der definierten Grenzen, auch unter Druck
Eskalationsweg	Übergabe an Menschen funktioniert technisch und inhaltlich	Eskalation kommt nachweislich bei der zuständigen Person an

Eigene Eval-Matrix Philogic Labs, abgeleitet aus Testpraxis für agentenbasierte Systeme. Konkrete Zahlenschwellen sind bewusst nicht vorgegeben – sie hängen von Risiko und Fehlerkosten des jeweiligen Use Cases ab und sollten vor dem ersten Testlauf gemeinsam mit dem fachlich zuständigen Team festgelegt werden.

Die letzte Spalte in der eigenen Testfall-Vorlage, die ich in Projekten nutze, ist das Abbruchkriterium: Bei welchem Verhalten wird ein Testlauf als „nicht bestanden” gewertet, unabhängig davon, wie gut der restliche Output war? Beispiel: Ein Agent, der bei 9 von 10 Anfragen die richtige Antwort liefert, aber bei der zehnten ein Zahlungswerkzeug mit falschem Betrag aufruft, hat den Test nicht bestanden – 90 % Trefferquote ist hier die falsche Kennzahl, weil der eine Fehlerfall den ganzen Nutzen aufwiegt.

Umsetzung: Testprozess Schritt für Schritt

So baust du einen Testprozess praktisch auf, bevor ein Agent produktiv geht – und danach fortlaufend weiter:

1. Testfall-Vorlage festlegen. Für jeden Testfall: Eingabe, erwartete Aktion, erlaubte Werkzeuge, erwartete Parameter, Abbruchkriterium. Eine einfache Tabelle reicht am Anfang völlig – ein dediziertes Eval-Tool lohnt sich erst, wenn regelmäßig getestet wird.

2. Golden Set aufbauen. Wie oben beschrieben: 20 bis 50 Fälle aus echten Daten, mit unabhängig festgelegter Referenz.

3. Randfälle und Tool-Tests ergänzen. Mindestens ein Drittel der Testfälle sollte Randfälle, Tool-Auswahl- oder adversarial Fälle sein, keine reinen Idealfälle.

4. Vor dem Go-Live testen. Alle Testfälle laufen lassen, Ergebnisse gegen die Abnahmekriterien prüfen, Fehlerfälle mit dem fachlich zuständigen Team durchgehen – nicht nur mit dem technischen Team.

5. Im Betrieb weitertesten. Jeder im Betrieb entdeckte Fehlerfall wird als neuer Testfall aufgenommen. Bei jeder relevanten Änderung (neues Modell, neuer Prompt, neues Werkzeug) läuft das gesamte Set erneut – eine Änderung, die nicht gegen das Golden Set getestet wurde, ist eine ungetestete Änderung, auch wenn sie klein aussieht.

6. Verantwortung benennen. Jemand muss den Testprozess betreiben, Ergebnisse bewerten und über Freigabe oder Nacharbeit entscheiden. Ohne benannte Zuständigkeit verkümmert das Golden Set nach wenigen Wochen zur Karteileiche.

Wer diesen Prozess nicht intern aufbauen will oder kann, für den ist die externe Prüfung eines konkreten Agenten-Use-Case oft der schnellere Einstieg – dafür ist unser Beratungsangebot da, ebenso wie ein unverbindliches Erstgespräch, in dem wir den Testbedarf für deinen Fall einordnen. Wo Teams das Testen selbst übernehmen sollen, helfen entsprechende Schulungen dabei, die nötige Prüfkompetenz aufzubauen.

Risiken & Grenzen

Ein Testprozess reduziert Risiko, beseitigt es aber nicht vollständig – ehrliche Grenzen gehören dazu:

• Kein Test deckt alle Randfälle ab. Die reale Vielfalt an Anfragen übersteigt jedes Testset. Ziel ist nicht Vollständigkeit, sondern eine Abdeckung, die die häufigsten und teuersten Fehlerklassen erfasst – und ein Prozess, der neue Fehler systematisch nachträgt.
• Modelle und Prompts driften. Ein Agent, der heute besteht, kann nach einem Modell-Update oder einer scheinbar kleinen Prompt-Änderung anders reagieren. Regelmäßiges erneutes Testen ist deshalb kein einmaliges Projekt, sondern ein wiederkehrender Betriebsschritt.
• Automatisierte Bewertung hat Grenzen. Bei komplexen oder mehrdeutigen Aufgaben braucht es weiterhin menschliche Prüfung der Ergebnisse, gerade bei neuen Testfällen – automatisierte Vergleichsmetriken allein erkennen nicht jede Art von Fehlverhalten.
• Rechtlicher Rahmen (Stand Juli 2026, keine Rechtsberatung). Je nach Anwendungsfall – etwa bei automatisierten Entscheidungen mit Wirkung auf Personen – können zusätzliche Prüf- und Dokumentationspflichten aus dem EU AI Act und der DSGVO gelten. Das BSI empfiehlt in seiner Einordnung generativer KI-Modelle eine systematische Risikoanalyse vor dem produktiven Einsatz; bei rechtlich sensiblen Use Cases gehört das Thema zusätzlich zu Datenschutz- oder Rechtsberatung.
• Keine garantierten Quoten. Es gibt keine Testmethode, die eine bestimmte Fehlerquote oder Rechtskonformität garantiert. Ein guter Testprozess senkt das Risiko messbar – er verspricht keine Fehlerfreiheit.

Checkliste: KI-Agenten testen

1. Es gibt ein Golden Set mit 20+ Fällen aus echten, anonymisierten Daten und unabhängig festgelegter Referenz.
2. Randfälle mit mehrdeutigen oder unvollständigen Anfragen sind Teil des Testsets, nicht nur Idealfälle.
3. Tool-Auswahl wird explizit getestet – inklusive Fällen, in denen kein Werkzeug die richtige Wahl ist.
4. Adversarial Tests mit widersprüchlichen, versteckten oder drängenden Eingaben sind vorhanden, besonders bei sicherheitskritischen Aktionen.
5. Jeder Testfall hat ein klares Abbruchkriterium, nicht nur eine Erfolgsquote.
6. Kritische Tool-Fehler (Zahlung, Löschung, Versand) haben eine Nulltoleranz-Regel, kein Durchschnittswert.
7. Der Umgang mit Unsicherheit ist getestet: Nachfragen/Eskalieren statt Raten.
8. Der Eskalationsweg an Menschen ist technisch getestet, nicht nur dokumentiert.
9. Es gibt eine benannte Zuständigkeit für Pflege und regelmäßiges Wiederholen der Tests.
10. Jeder im Betrieb entdeckte Fehlerfall wird als neuer Testfall aufgenommen.
11. Bei jeder relevanten Änderung (Modell, Prompt, Werkzeuge) läuft das gesamte Testset erneut.
12. Bei rechtlich sensiblen Use Cases ist eine Rücksprache mit Datenschutz- oder Rechtsberatung eingeplant.