Zuverlässigkeit von KI-Agenten: Warum die endgültige Antwort nicht ausreicht

Korrekte Ausgabe beweist weder korrektes Denken, sichere Ausführung noch ein vertrauenswürdiges System.

Jahrelang wurde die KI-Bewertung von einer trügerisch einfachen Frage dominiert: War die Antwort korrekt? Für einen Chatbot mag das manchmal ausreichen. Für einen Agenten, der Systeme durchsuchen, Daten lesen, Tools aufrufen, Zustände ändern, Workflows ausführen, Dateien schreiben, mit APIs interagieren oder Entscheidungen treffen kann, reicht das nicht.

Ein Agent kann die korrekte endgültige Antwort liefern und dabei auf dem Weg dorthin mehrere Dinge falsch machen. Er kann die falsche Quelle verwenden, eine Anweisung missverstehen und den Fehler später kompensieren, auf unnötige Informationen zugreifen, eine nicht autorisierte Zwischenaktion ausführen, sich stillschweigend von einem Fehler erholen, der eine Eskalation hätte auslösen sollen, oder Nebenwirkungen hinterlassen, die niemand bemerkt.

Das schafft eines der zentralen Probleme agentischer KI: Ein korrektes Ergebnis beweist keinen korrekten Verlauf.

Die Ergebnis-Illusion

Traditionelle Software gibt uns ein intuitives Modell der Korrektheit. Eingaben gelangen in ein deterministisches oder weitgehend deterministisches System, Logik wird ausgeführt, Ausgaben werden erzeugt, und Tests verifizieren das erwartete Verhalten. LLM-basierte Systeme schwächen diese Annahme. Agentische Systeme gehen noch weiter.

• Modellinterpretation
• abgerufener Kontext
• Tool-Auswahl
• Zwischenbeobachtungen
• externer Zustand
• frühere Aktionen
• modellgenerierte Pläne
• Berechtigungsgrenzen
• Wiederholungen und Fallback-Verhalten
• menschliche Interaktion

Zwei Ausführungen, die mit nahezu identischen Eingaben beginnen, können über sehr unterschiedliche Wege zum gleichen Ergebnis gelangen. Wenn die Bewertung nur die endgültige Ausgabe beobachtet, bleibt der größte Teil des Systems unsichtbar.

Stellen Sie sich vor, ein KI-Agent erhält die Anweisung: Aktualisieren Sie die Rechnungsadresse des Kunden. Die Adresse wird letztendlich korrekt aktualisiert. Eine herkömmliche Bewertung könnte die Aufgabe als erfolgreich einstufen.

1. Der Agent durchsucht mehrere nicht zusammenhängende Kundendatensätze.
2. Er ruft mehr persönliche Informationen ab als erforderlich.
3. Er ändert zunächst das falsche Konto.
4. Er bemerkt den Fehler.
5. Er macht die Änderung rückgängig.
6. Er aktualisiert das richtige Konto.
7. Er meldet Erfolg.

Endzustand: korrekt. Systemverhalten: inakzeptabel. Ein reines Ergebnis-Benchmark gibt dieser Ausführung eine Bestehensnote. Ein Produktionssicherungssystem sollte das nicht tun.

Der Verlauf ist Teil des Produkts

Deshalb muss der Verlauf eines KI-Agenten zu einem erstklassigen technischen Objekt werden. Ein Verlauf ist die Sequenz relevanter Zustände und Aktionen zwischen der ursprünglichen Anfrage und dem endgültigen Ergebnis.

Absicht → Kontext → Entscheidung → Werkzeug → Aktion → Beobachtung → Entscheidung → Zustandsänderung → Ergebnis

Zachary J. Stevens entwickelt diese Idee in Der Verlauf ist das System und argumentiert, dass agentische Bewertung über die endgültige Antwort hinausgehen und den vollständigen Aktionspfad durch eine sich verändernde Umgebung untersuchen muss.

Ein korrektes Ergebnis entschuldigt keinen inakzeptablen Verlauf.— Zachary J. Stevens, Der Verlauf ist das System

Der Unterschied ist enorm wichtig. Zuverlässigkeit ist daher nicht einfach korrekte Ausgabe. Sie ist eher akzeptables Ergebnis + akzeptabler Verlauf + Wiederherstellbarkeit + Nachweise.

Eine richtige Antwort kann ein kaputtes System verbergen

Die meisten benchmarkbasierten Bewertungen belohnen stark A und B und bestrafen C und D. Operativ kann jedoch B gefährlicher sein als C. Agent C könnte Unsicherheit erkennen, die Ausführung stoppen und eine menschliche Überprüfung anfordern. Agent B könnte selbstbewusst korrekte Ergebnisse liefern, während er Annahmen verletzt, die niemand überwacht.

erfolgreiche Ausgabe → erhöhtes Vertrauen → breitere Berechtigungen → mehr Automatisierung → größerer Schadensradius

Wir brauchen Beweise, nicht Vertrauen

Einer der größten Fehler bei der Einführung von KI ist es, Modellvertrauen, Benutzerzufriedenheit oder historische Erfolgsraten als Beweis für die Zuverlässigkeit des Systems zu behandeln. Sie sind nicht gleichwertig.

• Was hat der Agent erhalten?
• Welchen Kontext hat er abgerufen?
• Welche Werkzeuge hat er aufgerufen?
• Warum war die Aktion erlaubt?
• Welcher Zustand bestand vor der Aktion?
• Was hat sich geändert?
• Welche Zwischenfehler sind aufgetreten?
• Wurde etwas wiederholt?
• War eine menschliche Genehmigung erforderlich?
• Hätte die Ausführung gestoppt werden können?
• Kann die Aktion rückgängig gemacht werden?
• Welche Modell-, Prompt- und Tool-Versionen waren beteiligt?

Ohne diese Antworten gibt es keine ernsthafte operative Sicherheit. Es gibt nur eine Ausgabe. Beobachtbarkeit und Beweise müssen daher in die Agentenarchitektur eingebaut werden, anstatt nach der Bereitstellung hinzugefügt zu werden.

Protokollierung ist nicht dasselbe wie Kontrolle

Organisationen antworten oft: Alles wird protokolliert. Gut. Aber Protokollierung allein kontrolliert nichts. Ein Protokoll sagt Ihnen, was passiert ist. Eine Kontrolle bestimmt, ob etwas passieren darf.

Agent fordert DELETE /customer/123 an ↓
Aktion protokolliert ↓
DELETE ausgeführt

Das bietet Beobachtbarkeit. Vergleichen Sie das mit:

Agent fordert DELETE /customer/123 an ↓
Richtlinienbewertung ↓
Aktuelle Identität verifiziert ↓
Aktuelle Aktionsparameter geprüft ↓
Risikoschwelle bewertet ↓
Menschliche Genehmigung falls erforderlich ↓
Aktion ausgeführt ↓
Ergebnis verifiziert ↓
Beweise gespeichert

Jetzt nähern wir uns einem Kontrollsystem. Der Unterschied ist architektonisch, nicht kosmetisch.

Berechtigung ist notwendig – aber sie ist keine Sicherheit

Angenommen, ein Agent hat die Berechtigung, E-Mails zu senden. Zugriffskontrolle beantwortet: Kann dieser Agent E-Mails senden? Sie beantwortet nicht: Sollte diese bestimmte E-Mail an diese bestimmte Person mit diesem bestimmten Anhang jetzt gesendet werden?

FÄHIGKEITSKONTROLLE
Was darf der Agent technisch tun? + AKTIONSSICHERHEIT
Ist diese spezifische Aktion im aktuellen Zustand angemessen?

RBAC, OAuth-Bereiche, API-Berechtigungen und Agentenidentitäten definieren den Raum möglicher Aktionen. Sie beweisen nicht, dass eine Aktion innerhalb dieses Raums angemessen ist. Eine starke Agentenarchitektur benötigt beide Ebenen.

Der erste falsche Schritt ist entscheidend

Wenn ein Agent scheitert, liegt der Ursprung des Fehlers oft nicht in der letzten falschen Aktion. Der eigentliche Fehler kann viel früher passiert sein.

Falscher Abruf ↓
Falsche Annahme ↓
Plausible Argumentation ↓
Gültiger Tool-Aufruf ↓
Falsche Aktion

Wenn wir nur die letzte Aktion untersuchen, behandeln wir das Symptom. Wenn wir den Verlauf prüfen, können wir den ersten falschen Schritt identifizieren. Das verwandelt einen nicht zuzuordnenden Fehler in ein konkretes technisches Problem.

Agententests müssen über Prompt-Tests hinausgehen

Prompts sind wichtig, aber das Verhalten eines Agenten in der Produktion entsteht aus einem gesamten System.

MODELL
+
SYSTEM PROMPT
+
KONTEXT
+
SPEICHER
+
ABRUF
+
WERKZEUGE
+
BERECHTIGUNGEN
+
ARBEITSABLAUF
+
EXTERNER ZUSTAND
+
STEUERLOGIK

Die Änderung einer dieser Komponenten kann den Verlauf verändern. Daher reicht es nicht aus, nur den Prompt zu versionieren.

modell_version
prompt_version
werkzeug_version
richtlinien_version
abruf_version
arbeitsablauf_version
umgebungszustand
ausführungs_id

Abnahmekriterien für Agenten müssen Verhalten einschließen

Traditionelle Abnahmekriterien sehen oft so aus: Gegeben X, erzeugt das System Y. Für agentische Systeme ist das unvollständig. Abnahmekriterien sollten auch Einschränkungen für den Verlauf definieren.

Ergebnis

Die Adresse des Kunden wird korrekt aktualisiert.

Autorisierung

Der Agent ändert nur den explizit ausgewählten Kunden.

Datenzugriff

Es wird auf keine nicht zusammenhängenden Kundendatensätze zugegriffen.

Werkzeuge

Es werden nur genehmigte CRM-Operationen verwendet.

Verifizierung

Die neue Adresse wird zurückgelesen und mit dem angeforderten Wert verglichen.

Fehlerfall

Mehrdeutige Identitätsauflösung stoppt die Ausführung.

Menschliche Autorität

Ein Mensch kann die Änderung vor der Ausführung ablehnen, wenn Risikoschwellen eine Genehmigung erfordern.

Nachweis

Die Ausführung hinterlässt eine Spur, die ausreicht, um die Entscheidung und den Zustandsübergang zu rekonstruieren.

Wiederherstellung

Der vorherige Wert bleibt wiederherstellbar.

Human-in-the-Loop ist nicht genug

Das Hinzufügen eines menschlichen Genehmigungsfelds löst das Problem nicht automatisch. Ein Mensch kann einen Agenten nur kontrollieren, wenn die Person Sichtbarkeit, Autorität, Zeit, Kontext und Wiederherstellungsfähigkeit hat.

• Sichtbarkeit: genügend Informationen, um zu verstehen, was passiert.
• Autorität: tatsächliche Fähigkeit, die Aktion zu stoppen oder zu ändern.
• Zeit: Eingreifen, bevor die Konsequenz eintritt.
• Kontext: ausreichende Beweise, um die Entscheidung zu treffen.
• Wiederherstellungsfähigkeit: Fähigkeit, die Aktion rückgängig zu machen oder zu reparieren.

Ein Benutzer, der auf Genehmigen klickt, ohne etwas sinnvoll prüfen zu können, ist keine starke Governance. Es ist Genehmigungstheater.

Rollback muss eine native KI-Fähigkeit werden

Traditionelle Softwarebereitstellung hat uns etwas Wertvolles gelehrt: Stelle niemals etwas bereit, das du nicht zurückrollen kannst. Wir sollten dasselbe Prinzip auf agentische Aktionen anwenden.

REVERSIBEL
Kann automatisch rückgängig gemacht werden. KOMPENSIERBAR
Kann nicht direkt rückgängig gemacht werden, aber eine kompensierende Aktion kann ausgeführt werden. UNUMKEHRBAR
Kann den vorherigen Zustand nicht zuverlässig wiederherstellen.

Je höher die Irreversibilität, desto stärker sollte die Kontrollanforderung werden.

Öffentliches Dokument lesen → geringe Konsequenz
Entwurf erstellen → reversibel
CRM-Datensatz ändern → reversibel, aber folgenreich
Externe E-Mail senden → praktisch irreversibel
Geld überweisen → hohe Konsequenz
Produktionsdaten löschen → potenziell katastrophal

Der Agent braucht eine Kontrollebene

BENUTZER / SYSTEMABSICHT │ ▼ KI-AGENT │ vorgeschlagene Aktion │ ▼ ┌───────────────────┐ │ KONTROLLEBENE │ ├───────────────────┤ │ Identität │ │ Autorisierung │ │ Richtlinie │ │ Risiko │ │ Zustand │ │ Nachweis │ │ Menschliche Autorität │ │ Rollback │ └───────────────────┘ │ genehmigt? / \ NEIN JA │ │ STOPP ▼ WERKZEUG │ ▼ ZUSTANDSÄNDERUNG │ ▼ VERIFIKATION

Das LLM sollte vorschlagen. Die Kontrollebene sollte regieren. Diese Trennung ist entscheidend. Das Modell sollte nicht die letzte Instanz sein, die bestimmt, ob seine eigene vorgeschlagene Aktion mit hoher Auswirkung sicher ist.

Von Benchmarks zu operativem Vertrauen

Benchmarks bleiben nützlich. Sie sagen uns etwas über die Fähigkeiten, vergleichen Modelle, erkennen Regressionen und helfen, die erwartete Leistung einzuschätzen. Aber Fähigkeitsbewertung und operatives Vertrauen beantworten unterschiedliche Fragen.

Ein Benchmark fragt: Kann das System das tun? Operative Sicherheit fragt: Können wir dem System erlauben, das hier zu tun, unter diesen Bedingungen, mit diesen Berechtigungen und Konsequenzen?

Zuverlässigkeit sollte als Systemeigenschaft gemessen werden

1. Ergebniskorrektheit: Hat das System das erwartete Ergebnis geliefert?
2. Pfadkorrektheit: Hat es einen akzeptablen Weg eingeschlagen?
3. Kontrollintegrität: Wurden Autorisierungs-, Richtlinien- und Interventionsgrenzen eingehalten?
4. Wiederherstellbarkeit: Können Fehler eingedämmt, rückgängig gemacht oder repariert werden?
5. Nachweisvollständigkeit: Kann die Ausführung rekonstruiert und geprüft werden?

Operative Zuverlässigkeit
=
Ergebnis × Pfad × Kontrolle × Wiederherstellbarkeit × Nachweis

Die Multiplikation ist beabsichtigt. Wenn eine kritische Dimension gegen Null geht, sollte eine hohe Punktzahl anderswo das nicht verbergen. Ein perfekt korrektes Ergebnis ohne Autorisierungsintegrität ist kein 80% zuverlässiges System. Es ist eine inakzeptable Ausführung, die zufällig die richtige Antwort hervorgebracht hat.

Erfolg ist manchmal der gefährlichste Fehler

Fehler ziehen Aufmerksamkeit auf sich. Erfolg oft nicht. Das macht erfolgreiche, aber unkontrollierte Agentenpfade besonders gefährlich. Ein offensichtlicher Fehler erzeugt einen Vorfall. Ein versteckter Pfadfehler erzeugt Vertrauen. Und Vertrauen erweitert Autonomie.

Organisationen sollten daher nicht nur untersuchen, Warum hat der Agent versagt? Sie sollten regelmäßig fragen: Warum ist der Agent erfolgreich gewesen? War es, weil die Architektur die Ausführung zuverlässig eingeschränkt und verifiziert hat, oder weil diesmal nichts schiefgegangen ist?

Fazit

Die Branche bewegt sich schnell von KI, die antwortet, zu KI, die handelt. Dieser Übergang verändert, was Zuverlässigkeit bedeutet. Für ein Antwortsystem kann die Bewertung der Antwort oft ausreichen. Für ein Handlungssystem müssen wir den Pfad bewerten.

Eingabeaufforderung ↓
Antwort wird Absicht ↓
Pfad ↓
Aktionen ↓
Zustandsänderungen ↓
Nachweis ↓
Ergebnis

Die endgültige Antwort bleibt wichtig, aber sie ist nur das sichtbare Ende eines viel größeren Systems. Sobald KI die reale Welt beeinflussen darf, wird der Weg zur Antwort Teil der Antwort.