KI-Agenten-Evaluierungs-Harness: Agenten vor dem Zugriff auf Produktionsdaten testen

Dieser Leitfaden richtet sich an CTOs, Engineering Leads sowie Delivery- und QA-Leads, die die Entscheidung treffen, ob ein KI-Agent eines mittelständischen Unternehmens auf ein CRM, ein ERP, ein Postfach oder ein Zahlungssystem zugreifen darf. Unser KI-Automatisierungsleitfaden für Geschäftsprozesse legt fest, wie viel Autonomie ein Prozess erhält; diese Seite zeigt, wie Sie nachweisen, dass der Agent diese Autonomie verdient, bevor er live geht. Nach bestandener Prüfung behandelt KI-Agenten-Sicherheit und Freigabekontrollen die Maßnahmen, die ihn im Betrieb sicher halten, und der Agentic-AI-Automatisierungsservice deckt die Lieferung ab. Der 90-Tage-Betriebsplan ordnet diesen Harness-Gate in die übergeordnete 90-Tage-Pilotsequenz ein.

Inhalt dieses Leitfadens

• Warum Unit-Tests für einen Agenten nicht ausreichen
• Impact-Tier × Grader-Typ: Das Harness-Framework
• Aufbau des Harness
• Der Go/No-Go-Gate: Wo der Zugriff auf Produktionsdaten beginnt
• Wo KI passt
• Alternativen und Auswahlkriterien
• Was als Liefernachweis vorliegt und was nicht
• Grenzen dieses Leitfadens
• Häufig gestellte Fragen
• Nächster Schritt

Warum Unit-Tests für einen Agenten nicht ausreichen

Eine herkömmliche Test-Suite prüft eine Funktion gegen eine erwartete Ausgabe. Ein Agent verkettet mehrere Modellaufrufe, wählt aus, welche Tools er in welcher Reihenfolge aufruft, und reagiert auf das, was ein Tool zurückgibt – einschließlich eines Stack-Trace, eines leeren Ergebnisses oder einer Textseite, mit der er nicht gerechnet hat. Zwei Läufe mit demselben Input können unterschiedliche Tool-Sequenzen erzeugen und dennoch beide korrekt oder beide auf unterschiedliche Weise falsch sein. Das NIST Generative AI Profile hält dies ausdrücklich fest: Organisationen sollten Test, Evaluation, Validation and Verification (TEVV) durchführen, um die Fähigkeiten eines generativen KI-Systems vor dem Einsatz zu verstehen, und nicht davon ausgehen, dass eine bestandene Demo verallgemeinerbar ist. Bei einem Agenten ist das eigentliche Testobjekt die gesamte Trajektorie – nicht eine einzelne Antwort: welche Tools aufgerufen wurden, mit welchen Argumenten, in welcher Reihenfolge und was der Agent mit dem Zurückgegebenen gemacht hat.

Die OWASP Top 10 für Agentic Applications beleuchtet dieselbe Lücke aus der Perspektive des Angreifers: Ein Agent, der sich bei den Fällen korrekt verhält, die seine Entwickler sich vorgestellt haben, kann dennoch durch ein manipuliertes Dokument gekapert werden, ein legitimes Tool auf unsichere Weise missbrauchen oder einen einzelnen fehlerhaften Input in ein mehrstufiges Versagen überführen. Ein Harness soll beide Arten von Fehlern abfangen – gewöhnliche wie adversarielle –, bevor dem Agenten Daten anvertraut werden, die ein Kunde oder das Unternehmen sich nicht leisten kann zu verlieren.

Impact-Tier × Grader-Typ: Das Harness-Framework

Klassifizieren Sie jeden Testfall danach, was der Agent tun darf – dieselben Impact-Tiers, die festlegen, welche Aktionen eine menschliche Freigabe erfordern –, und ordnen Sie jedem Tier die Bewertungsmethode zu, die seine Fehler tatsächlich erkennt. Deterministische Prüfungen sind günstig, exakt und gut darin, Format- und Tool-Auswahlfehler aufzudecken; ein Modell, das die Ausgabe eines anderen Modells bewertet (LLM-as-judge), ist langsamer und benötigt eine eigene Kalibrierung, ist aber der einzig praktikable Weg, eine offene Antwort auf Korrektheit oder Ton zu bewerten.

Ein Testfall, der nur die finale Antwort prüft, verfehlt die meisten Agentenfehler. Bewerten Sie die Trajektorie: welche Tools aufgerufen wurden, mit welchen Argumenten, in welcher Reihenfolge, verglichen mit einem genehmigten Referenzpfad, sowie den Endzustand, den der Test behauptet (der Datensatz, die Nachricht, das Hauptbuch) – nicht eine Zusammenfassung, die das Modell über sich selbst geschrieben hat.

Der Go/No-Go-Gate: Wo der Zugriff auf Produktionsdaten beginnt

Der Harness beantwortet eine Ja/Nein-Frage für eine spezifische Änderung (ein neuer Agent, ein neues Tool, ein neues Modell, eine neue Prompt-Version): Erfüllt sie jeden irreversiblen Tier-Schwellenwert im aktuellen adversarialen und Regressions-Set, gemessen gegen die eingefrorene Baseline? Wenn ja, zeichnet eine namentlich genannte Person ab, und die Berechtigungen des Agenten werden vom Sandbox-Scope auf das reale System ausgeweitet – entsprechend dem Least-Privilege-Identitätsdesign in unserem KI-Agenten-Sicherheitsleitfaden. Wenn nein, verbleibt die Änderung unabhängig davon, wie gut sie bei Read-only-Fällen abgeschnitten hat, in der Sandbox. Der Gate wird in der Deployment-Pipeline durchgesetzt – genauso wie ein Code-Reviewer einen Pull Request gatet –, nicht dem Agenten oder dem Urteil eines einzelnen Engineers am Launch-Tag überlassen.

Führen Sie die vollständige Suite bei jeder Prompt-, Modell- oder Tool-Änderung erneut aus, nicht nur beim ersten Launch: OWASPs Agentic Security Initiative behandelt eine geänderte Prompt-Vorlage oder ein ausgetauschtes Modell als neue Angriffsfläche, und NISTʼs Profil betrachtet Messung als kontinuierlich – nicht als einmaligen Stempel vor dem Deployment.

Alternativen und Auswahlkriterien

Vier Faktoren entscheiden, wie weit oben in dieser Tabelle Sie gehen müssen: wie reversibel die schlimmste Aktion ist, wie viel des Inputs von außerhalb des Unternehmens stammt (E-Mail, hochgeladene Dateien, Webseiten), wie viele Fälle pro Tag laufen, und ob eine falsche Antwort direkt einen Kunden oder zunächst eine Person erreicht. Ein Read-only-interner Agent, der von einem Team genutzt wird, kann im ersten Quartal oft bei manuellen Stichprobenprüfungen bleiben; ein Agent, der Geld sendet oder einem Kunden eine Nachricht schickt, kann das nicht.

Was als Liefernachweis vorliegt und was nicht

• Was vorliegt. Netbase hat KI-Projekte für nicht namentlich genannte Kunden geliefert, bei denen eine Test- und Optimierungsphase zu den dokumentierten Meilensteinen gehört, bevor das System sein Review-Dashboard erreichte oder live ging – darunter die oben genannten Moderations- und Chatbot-Nachweise sowie anonymisierte RAG-, Document-AI- und MLOps-Pipelines. Netbase folgt seinen veröffentlichten Sicherheitspraktiken: Secure-Code-Review, TLS im Transit und AES im Ruhezustand, rollenbasierte Zugriffskontrolle, MFA für Admin-Dashboards, Schwachstellenscanning und Penetrationstests. Netbase ist nach ISO 27001 zertifiziert und verfügt über eine SOC 2 Type II Attestierung für den eigenen Betrieb.
• Was nicht vorliegt. Kein veröffentlichter Netbase-Nachweis nennt ein eigenständiges Evaluierungs-Harness-Produkt, eine Testfallanzahl, eine Bestehensquote, ein Ergebnis adversarialer Tests oder eine Vorfallsanzahl für einen Agenten. Kein Nachweis beschreibt einen autonomen Agenten mit unbeaufsichtigtem Schreibzugriff auf ein Zahlungs- oder ERP-System. Die Zertifizierungen von Netbase betreffen den eigenen Betrieb von Netbase; sie zertifizieren nicht den Agenten eines Kunden oder dessen Evaluierungsergebnisse.

Grenzen dieses Leitfadens

• Dies ist eine allgemeine technische Orientierung, keine Zertifizierung, kein Audit und keine Garantie, dass ein bestimmter Agent sicher ist; die oben genannten Schwellenwerte und Tiers sind eine Ausgangsstruktur, die an die tatsächlichen Aktionen anzupassen ist, die ein Agent ausführen kann.
• Evaluierungsmethoden für generative KI sind noch ein unreifes Feld: NISTʼs eigenes Profil stellt fest, dass viele nützliche Tests noch keine vereinbarten, veröffentlichten Benchmarks haben; rechnen Sie damit, Testfälle anzupassen, wenn neue Fehlermodi in der Produktion auftreten.

Nächster Schritt

Schildern Sie uns den Agenten, den Sie aufbauen oder erweitern möchten, sowie die Systeme, auf die er zugreifen soll, und wir vereinbaren ein Lösungsreview, um seine Testfall-Tiers, Sandbox und den Go/No-Go-Gate zu entwerfen, bevor er Produktionsdaten berührt. Sie können auch KI-Automatisierung und Agenten oder weitere Netbase-Insights ansehen.

Verwandte Leistungen und Lösungen