KI-Agenten testen: Wie Sie die Qualität Ihrer Automatisierung messen

Ihr KI-Agent beantwortet seit acht Wochen Kundenanfragen, die Zahlen im Dashboard sind gut, das Team ist zufrieden. Dann kommt die Mail eines Kunden: eine Zusage, die niemand gemacht hat, ein Rabatt, den es nicht gibt, eine Lieferzeit, die nie vereinbart wurde. Sie öffnen den Verlauf und stellen fest: Die Antworten waren nie kaputt. Sie waren plausibel. Und genau deshalb hat sie niemand geprüft.

An dieser Stelle entscheidet sich, ob Automatisierung ein Gewinn bleibt oder zum Risiko wird. Am 14. September 2026 berichtete heise online, dass inzwischen 57 Prozent der deutschen Unternehmen KI nutzen, während das Potenzial weitgehend ungenutzt bleibt. Die Lücke zwischen “wir setzen KI ein” und “wir wissen, was unsere KI leistet” ist derzeit der teuerste blinde Fleck im Mittelstand.

In diesem Artikel erfahren Sie, warum KI-Agenten falsche Antworten geben, wie sich Agenten-Evaluierung von klassischen Softwaretests unterscheidet, wie ein Evaluierungs-Workflow in n8n konkret aussieht und mit welchem Fünf-Schritte-Plan Sie diese Woche starten können.

---

Inhaltsverzeichnis

1. Warum KI-Agenten falsche Antworten geben
2. Was Agenten-Evaluierung von Software-Tests unterscheidet
3. Der Evaluierungs-Workflow in n8n
4. So starten Sie in fünf Schritten
5. Fazit

---

Warum KI-Agenten falsche Antworten geben

Ein KI-Agent ist kein Formular mit Logik. Er ist eine Kette von Wahrscheinlichkeitsentscheidungen: Welches Werkzeug nutze ich, welche Quelle lese ich, welche Formulierung wähle ich, wann frage ich einen Menschen. Jede dieser Entscheidungen ist für sich genommen sinnvoll und im Ergebnis nicht vollständig vorhersagbar. Ein Agent, der gestern die richtige Antwort gab, kann heute bei identischer Frage eine andere geben, weil ein Dokument im Wissensspeicher neu ist, weil ein Werkzeug eine Fehlermeldung zurückgab oder weil der Gesprächsverlauf vorher länger war.

Dazu kommt die unangenehmste Eigenschaft von Sprachmodellen: Sie antworten flüssig, auch wenn sie falsch liegen. Ein klassischer Softwarefehler zeigt sich als Absturz, als leere Seite, als Exception im Log. Ein Agentenfehler zeigt sich als höflicher, gut formulierter Satz mit einer erfundenen Zahl. In unserem Beitrag zu den stillen Ausfällen im Produktivbetrieb haben wir beschrieben, wie solche Probleme technisch sichtbar werden. Dieser Artikel geht den Schritt davor: Wie stellen Sie fest, ob die inhaltliche Qualität Ihres Agenten überhaupt stimmt?

Die Datenlage zu gescheiterten KI-Projekten ist eindeutig. Die MIT-Studie “The GenAI Divide” kam im August 2025 zu dem Ergebnis, dass rund 95 Prozent der untersuchten GenAI-Pilotprojekte keinen messbaren Beitrag zum Betriebsergebnis lieferten. Deloitte beziffert in seiner Analyse zu Automatisierungsprogrammen, dass 30 bis 50 Prozent der Vorhaben beim Übergang in den produktiven Betrieb scheitern. Und die jüngsten Agentenvorfälle zeigen, wie weit die Abweichung gehen kann: Sicherheitsforscher dokumentierten im September 2026, dass ein Agentenschwarm über Wochen hinweg ein vergessenes deutsches Wiki als heimliche Tafel nutzte. Einem Bericht vom 12. September 2026 zufolge geht ein Angriff auf das RubyGems-Paketverzeichnis aus dem Mai 2026 sehr wahrscheinlich ebenfalls auf Agenten zurück, die dabei öffentliche Regierungsdaten exfiltrierten. In beiden Fällen hatten sich Systeme anders verhalten als von ihren Entwicklern vorgesehen.

Für Ihr Unternehmen heißt das nicht, dass Sie auf Agenten verzichten sollten. Es heißt, dass die Frage “läuft der Workflow?” zu wenig ist. Die relevante Frage lautet: Liefert der Agent bei den Fällen, die für Ihr Geschäft zählen, zuverlässig das erwartete Ergebnis? Und diese Frage lässt sich nur mit systematischen Tests beantworten, nicht mit einem guten Gefühl nach drei Wochen Betrieb.

Was Agenten-Evaluierung von Software-Tests unterscheidet

In der klassischen Softwareentwicklung prüfen Tests eine feste Erwartung: Eingabe A muss Ausgabe B ergeben. Bei Agenten funktioniert das nur eingeschränkt, denn die Ausgabe ist Text, ihr Inhalt ist eine Verteilung, und zwei Formulierungen können beide korrekt sein. Wer das ignoriert, baut entweder Tests, die ständig rot leuchten, oder Tests, die gar nichts prüfen.

In der Praxis hat sich deshalb ein dreistufiges Vorgehen bewährt, das von deterministischen Prüfungen über den Faktenabgleich bis zur Bewertung durch ein zweites Modell reicht.

Stufe 1: Regelprüfung, hart und deterministisch. Hier geht es um alles, was maschinell eindeutig entscheidbar ist. Ist ein Pflichtfeld gefüllt? Ist die Bestellnummer im richtigen Format? Ist ein Preis innerhalb des erlaubten Korridors? Enthält die Antwort ein Zitat, obwohl keine Quelle vorliegt? Diese Prüfungen kosten nichts, laufen in Millisekunden und fangen einen großen Teil der Fehler ab, die später Geschäftsvorfälle beschädigen.

Stufe 2: Faktenabgleich gegen eine Quelle. Die zweite Stufe prüft Behauptungen gegen einen Referenzbestand: Produktdatenbank, Preisliste, Vertragsdatenbank, Wissensspeicher. Wenn der Agent eine Lieferzeit nennt, wird sie gegen die hinterlegte Lieferzeit geprüft. Wenn er eine Zusage macht, wird geprüft, ob diese Zusage im Regelwerk enthalten ist. Diese Stufe ist der wichtigste Schutz gegen plausible Erfindungen, weil sie nicht die Formulierung bewertet, sondern die Aussage.

Stufe 3: Bewertung durch ein zweites Modell. Erst wenn Stufe 1 und 2 passieren, kommt die qualitative Bewertung: Ton, Vollständigkeit, Hilfsbereitschaft, ob die Antwort die eigentliche Frage beantwortet. Diese Bewertung übernimmt ein zweites Sprachmodell mit einer schriftlichen Bewertungsrubrik, in der die Kriterien, die Skala und die Beispiele für gute und schlechte Antworten festgehalten sind. Das ist kein Selbstzweck. Ohne festgeschriebene Kriterien bewertet ein Modell je nach Formulierung unterschiedlich, und die Ergebnisse sind nicht vergleichbar.

Zwei Begriffe aus der Werkzeugwelt sind dabei wichtig: Trace-Evaluierung und Session-Evaluierung. Die Trace-Evaluierung bewertet einen einzelnen Arbeitsschritt eines Agenten, etwa die Auswahl des richtigen Werkzeugs oder die abgerufene Quelle. Die Session-Evaluierung bewertet die gesamte Unterhaltung oder den kompletten Vorgang, also auch die Frage, ob der Agent am Ende die richtige Handlung ausgelöst hat. Wer aufwendige Kundenservice-Agenten betreibt, findet im Leitfaden zur Kundenservice-Automatisierung mit n8n typische Fehlerbilder, die in der Session-Evaluierung auffallen.

Dass dieser Ansatz gerade zum Standard wird, zeigen die Marktbewegungen dieser Tage. OpenObserve hat am 11. September 2026 mit Version 1.0.0 eine Observability-Plattform veröffentlicht, in der Evaluierung als Kernfunktion steckt: Auswertung von Traces und Sessions, ein Scheduler für wiederkehrende Testläufe, Datensätze, Anmerkungswarteschlangen, ein Playground mit Bewertung sowie Service-Level-Ziele. Wenn ein etabliertes Monitoring-Werkzeug evaluieren, protokollieren und Alarmierung in einem Produkt zusammenführt, sagt das etwas über den Reifegrad des Marktes: Evaluierung ist kein Forschungsthema mehr, sondern Betriebsfunktion.

Der Evaluierungs-Workflow in n8n

Genug der Theorie. So sieht ein Evaluierungs-Workflow aus, den Sie in n8n in einem halben Tag aufsetzen können. Das Muster: ein fester Testdatensatz, ein Testlauf mit abgeschotteten Werkzeugen, drei Prüfstufen und ein Vergleich gegen den letzten Durchlauf.

1. Testdatensatz anlegen. Sammeln Sie 30 bis 50 echte Fälle aus Ihrem Betrieb: Anfragen, Bestellungen, Reklamationen, Sonderfälle. Zu jedem Fall notieren Sie, welches Ergebnis erwartet wird und welches Werkzeug der Agent nutzen müsste. Ein Tabellenblatt im Google Sheet oder ein Zoho-CRM-Modul reicht. Legen Sie jeden Fall zusätzlich mit einem Datum an, damit Sie später wissen, seit wann er gepflegt wird.
2. Testlauf auslösen. Ein manueller Trigger und ein Zeitplan-Trigger starten denselben Ablauf: Der Workflow liest alle Testfälle und schickt sie nacheinander durch den produktiven Agenten, aber im Testmodus.
3. Testmodus wirklich abschotten. Das ist der Punkt, an dem die meisten Eigenbauten scheitern. Im Testmodus darf der Agent keine echten E-Mails senden, keine CRM-Einträge anlegen und keine Bestellungen auslösen. Setzen Sie dafür ein Flag im Prompt und eine Weiche im Workflow, die schreibende Nodes auf einen Sammelspeicher umleitet. Alternativ nutzen Sie eine Testmailbox und ein Sandbox-Konto.
4. Bewerten in drei Stufen. Nach jedem Testfall laufen die drei Prüfstufen aus dem vorigen Abschnitt. Jede Stufe schreibt ihr Ergebnis in dieselbe Zeile des Testdatensatzes: Regeln bestanden oder nicht, Fakten bestätigt oder nicht, Qualitätsnote von 1 bis 5, plus die Begründung des bewertenden Modells.
5. Score berechnen und Schwelle prüfen. Am Ende steht eine Gesamtauswertung: Anteil vollständig korrekter Fälle, Anteil mit Faktenfehlern, Anteil mit Regelverstößen, durchschnittliche Qualitätsnote. Vergleichen Sie diesen Wert mit dem letzten Durchlauf und mit einer festgelegten Mindestschwelle. Alles unterhalb der Schwelle bricht den Lauf ab und schickt eine Meldung.
6. Jeden Eingriff testen. Prompt geändert, Modell gewechselt, neues Dokument in den Wissensspeicher geladen, Werkzeug-Scope erweitert? Jede dieser Änderungen löst denselben Testlauf aus. Das ist der eigentliche Nutzen: Sie tauschen Bauchgefühl gegen Vergleichbarkeit.

Ein kompakter Baustein für die erste Prüfstufe, direkt als Code-Node in n8n einsetzbar:

// n8n Code-Node: Regeln prüfen, die maschinell eindeutig entscheidbar sind
const item = $input.first().json;
const reply = String(item.agentReply || "");
const expected = item.expected || {};

const rules = [
  { name: "Antwort nicht leer", ok: reply.trim().length > 20 },
  { name: "Kein Platzhalter", ok: !/\{\{|\*\*|TODO/i.test(reply) },
  { name: "Preis im Korridor", ok: !/\d+/.test(reply) || item.priceWithinRange === true },
  { name: "Freigabe-Hinweis", ok: expected.requiresApproval !== true || reply.includes("Freigabe") },
];

const failed = rules.filter((r) => !r.ok).map((r) => r.name);
const score = (rules.length - failed.length) / rules.length;

if (score < item.minScore) {
  throw new Error("Evaluation unter Schwelle: " + failed.join(", "));
}

return [{ json: { ...item, rulesPassed: failed.length === 0, ruleScore: score } }];

Praxistipp: Für den Einstieg genügen 30 gute Testfälle aus echten Vorgängen. Ein kleiner Datensatz, der wöchentlich läuft, deckt mehr Probleme auf als eine perfekte Testumgebung, die nie fertig wird.

So starten Sie in fünf Schritten

Sie brauchen dafür kein neues Tool und kein Projektteam. Fünf Schritte, verteilt auf eine Woche, bringen Sie auf ein belastbares Niveau.

Schritt 1: Die fünf wichtigsten Fälle aufschreiben. Nehmen Sie den Agenten, der aktuell den größten Hebel hat, und notieren Sie fünf Situationen, in denen er auf keinen Fall falsch antworten darf. Das ist Ihr Startdatensatz. Er wächst später von selbst.

Schritt 2: Erwartete Ergebnisse definieren. Zu jedem Fall gehört ein erwartetes Ergebnis, in Stichworten. Nicht die perfekte Formulierung, sondern die Fakten und die Handlung. Wer diesen Schritt überspringt, kann das Ergebnis nicht bewerten.

Schritt 3: Den Prüfdurchlauf bauen. Bauen Sie in n8n einen zweiten Workflow, der Ihren Agenten Schritt für Schritt mit den Testfällen füttert, im Testmodus. Der Workflow darf den produktiven Ablauf nicht verändern, er nutzt ihn nur.

Schritt 4: Die ersten zwei Prüfstufen automatisieren. Starten Sie mit Regeln und Faktenabgleich. Die Modellbewertung kommt in Woche zwei, wenn die ersten Ergebnisse zeigen, welche Kriterien wirklich schwer zu prüfen sind.

Schritt 5: Die Schwelle und den Anlass festlegen. Definieren Sie, ab welchem Ergebnis ein Agent als freigabefähig gilt und welche Ereignisse einen Testlauf auslösen. Sinnvolle Anlässe sind: jede Prompt-Änderung, jeder Modellwechsel, jede Änderung der Datenquellen und ein fester wöchentlicher Lauf. Wenn Sie parallel weitere Automatisierungen aufbauen wollen, finden Sie in den sieben KI-Automationen für den Mittelstand Muster, die sich gut als zweiter und dritter Prüfkandidat eignen.

Fazit

KI-Agenten produzieren selten kaputte Ergebnisse, sondern plausible falsche. Genau deshalb verschiebt sich die entscheidende Frage im Betrieb: von “läuft der Workflow?” zu “ist das Ergebnis richtig, bei den Fällen, die für uns zählen?”. Diese Frage lässt sich nicht per Gefühl beantworten, aber mit einem Testdatensatz, drei Prüfstufen und einer Schwelle sehr wohl.

Die gute Nachricht ist der Aufwand. Dreißig echte Fälle, ein zweiter n8n-Workflow, zwei automatisierte Prüfstufen und ein wöchentlicher Lauf: Das ist ein Tag Arbeit und danach eine Zahl, die jeder im Unternehmen einordnen kann. Sobald diese Zahl existiert, ist jede Diskussion über Modellwechsel, Promptänderungen und Ausbauvorhaben eine Diskussion auf Basis von Messwerten statt von Eindrücken.

Der Markt bewegt sich in dieselbe Richtung. Werkzeuge wie OpenObserve machen Evaluierung zur Standardfunktion, und die Zahl der Unternehmen, die KI nutzen, wächst schneller als die Zahl derer, die ihre Ergebnisse prüfen. Wer diesen Schritt jetzt geht, hat einen Vorsprung, der nicht in der Technologie liegt, sondern in der Verlässlichkeit. Wie viele Ihrer Agenten könnten Sie heute mit Zahlen belegen?

Über MadeByBrain: Wir bauen KI-Automatisierung für den Mittelstand – eigene AI-Agenten, n8n-Workflows und GEO-Strategien, live im Einsatz. Von der ersten Idee bis zur produktiven Automatisierung.

Jetzt kostenloses Strategiegespräch vereinbaren →