KI-Agenten im Unternehmen scheitern selten an einem einzelnen schlechten Prompt. Häufiger scheitern sie an Planung, Tool-Nutzung und Verifikation: Der Agent wählt den falschen nächsten Schritt, interpretiert ein Tool-Ergebnis falsch oder erklärt eine Aufgabe für erledigt, obwohl der Zielzustand nicht erreicht ist.
IBM Research und UC Berkeley haben diese Fehlermuster mit ITBench und MAST systematisch untersucht. Der Wert der Arbeit liegt nicht in einem weiteren Score. Sie zeigt, warum klassische Benchmarks für Unternehmensagenten zu wenig erklären und weshalb produktive Teams ihre Agenten anders testen müssen, bevor sie ihnen echte Systeme anvertrauen.
KI-Agenten im Unternehmen brauchen Diagnose statt Score
Viele Agenten-Evaluierungen enden mit einer einfachen Zahl: Aufgabe gelöst oder nicht gelöst. Für Managementfolien reicht das. Für Betrieb, Security und Architektur reicht es nicht. Ein Agent, der 60 Prozent der Aufgaben löst, kann in den übrigen 40 Prozent auf völlig unterschiedliche Weise scheitern. Mal fehlt ein Zwischenschritt, mal wird ein API-Ergebnis falsch gelesen, mal bricht der Agent zu früh ab, mal halluziniert er aus einem fehlerhaften Kontext heraus weiter.
Genau hier setzen ITBench und MAST an. ITBench ist ein Benchmark für IT-Automatisierung in Bereichen wie Site Reliability Engineering, Security und FinOps. MAST steht für Multi-Agent System Failure Taxonomy und liefert eine strukturierte Sprache für Agentenfehler. Statt nur zu fragen, ob ein Lauf erfolgreich war, wird sichtbar, wie der Agent gescheitert ist.
Die untersuchte Datenbasis umfasst 310 annotierte SRE-Traces aus ITBench. Die Aufgaben bestanden aus realistischeren IT-Szenarien als normale Multiple-Choice-Tests: Incident-Triage, Log- und Metrik-Analyse sowie Kubernetes-Operationen in längeren Tool-Schleifen. Das ist näher an dem, was Unternehmen tatsächlich mit Agenten automatisieren wollen.
Der zentrale Befund ist unbequem. Kein Modell besteht solche Aufgaben zuverlässig genug, um ohne zusätzliche Kontrollen als autonomer Operator zu gelten. Die Modelle unterscheiden sich aber stark darin, wie sie scheitern. Genau diese Differenz ist für Unternehmen wichtiger als der reine Erfolgsscore.
Die Anatomie des Scheiterns
Die Analyse zeigt drei wiederkehrende Fehlerklassen.
Erstens: Planungsfehler. Der Agent wählt eine falsche Vorgehensweise, überspringt notwendige Zwischenschritte oder verfolgt eine Spur weiter, obwohl sie keine Evidenz mehr liefert. In langen SRE-Abläufen reicht ein früher Denkfehler, um den Kontext zu vergiften. Danach wirken die folgenden Schritte oft plausibel, hängen aber an der falschen Annahme.
Zweitens: Tool-Fehler. Agenten sind nur so gut wie ihre Fähigkeit, externe Werkzeuge korrekt zu nutzen. In Unternehmensumgebungen heisst das: Logs lesen, APIs aufrufen, Metriken interpretieren, Fehlermeldungen einordnen, Rechte respektieren. Ein falscher Parameter oder ein missverstandenes Tool-Ergebnis kann den ganzen Lauf entwerten.
Drittens: Verifikationsfehler. Das ist der gefährlichste Fall. Der Agent hat die Aufgabe scheinbar gelöst und erklärt den Lauf für abgeschlossen, ohne den Zielzustand hart zu prüfen. IBM und Berkeley fanden, dass fehlerhafte Verifikation über Modelle hinweg einer der stärksten Prädiktoren für gescheiterte Läufe ist. Praktisch heisst das: Agenten neigen dazu, ihren eigenen Erfolg zu glauben.
Frontier-Modelle zeigen dabei oft isoliertere Fehler. Sie scheitern weniger chaotisch, etwa an einem klar erkennbaren Verifikationspunkt. Schwächere oder weniger stabile Modelle erzeugen häufiger Fehlerkaskaden: Ein kleiner Reasoning-Fehler führt zu falscher Tool-Nutzung, daraus entstehen neue Annahmen, und am Ende ist der Lauf falsch und schwer rekonstruierbar.
Warum das für produktive IT-Systeme zählt
In einem Chat-Demo ist ein falsch beendeter Agentenlauf ärgerlich. In einem produktiven IT-System kann er gefährlich werden. Ein SRE-Agent, der ein Kubernetes-Problem falsch diagnostiziert, ein Security-Agent, der einen Alert als erledigt markiert, oder ein FinOps-Agent, der eine Kostenanomalie falsch klassifiziert, verändert reale Abläufe. Der Schaden entsteht nicht erst durch böswilliges Verhalten. Er entsteht durch plausible, schlecht geprüfte Automatisierung.
Das unterscheidet Unternehmensagenten von klassischen Assistenzsystemen. Ein Chatbot gibt eine Antwort. Ein Agent handelt: Er ruft Tools auf, liest Zustände, schreibt Daten, verändert Tickets, startet Workflows oder bereitet Entscheidungen vor. Je mehr Rechte und Persistenz ein Agent erhält, desto weniger reicht ein generischer Modell-Benchmark.
Für Unternehmen folgt daraus eine klare Architekturregel: Verifikation gehört ausserhalb des Modells. Ein Agent sollte nicht selbst entscheiden, ob er seine Aufgabe erfolgreich abgeschlossen hat, wenn harte Evidenz verfügbar ist. Bei Incident-Triage kann das ein Metrikzustand sein, bei Deployment-Automatisierung ein Testresultat, bei Security-Abläufen ein expliziter Kontrollpunkt.
Diese Logik passt zur breiteren Sicherheitsdebatte um Agenten. Wer Agenten in Tool-Ökosysteme einbettet, muss auch Protokoll-, Rechte- und Sandboxfragen klären. Der Artikel zum MCP-Standardkampf in der KI-Agenten-Infrastruktur zeigt, warum Agenten bessere Modelle und bessere Grenzen brauchen.
Signal der Woche abonnieren
Eine Nachricht. Eine Analyse. Jeden Freitag im Newsletter.
Kostenlos als Member. Gratis abonnieren
Was Unternehmen konkret ändern sollten
Der erste Schritt ist eine andere Evaluationsfrage. Nicht: Welches Modell hat den höchsten Score? Sondern: Welche Fehlertypen produziert dieses Modell in unserem Workflow, und welche davon sind fatal?
Ein Agent, der häufiger wiederholt, aber am Ende korrekt verifiziert, ist in manchen Betriebsprozessen besser kontrollierbar als ein Agent, der schnell entscheidet und zu früh abschliesst. Ein Modell mit wenigen isolierten Fehlermodi lässt sich gezielter absichern als ein Modell, das bei Fehlern in Kaskaden kippt. Diese Unterscheidung taucht in normalen Benchmarks kaum auf, ist im Betrieb aber entscheidend.
Der zweite Schritt ist explizite Laufkontrolle. Terminierungsbedingungen, Loop-Detectoren, harte Tool-Evidenz und getrennte Verifikationsschritte sollten nicht dem Modell überlassen werden. In kritischen Abläufen braucht es definierte Stop-Regeln: Wann darf ein Agent abbrechen? Wann muss er nachfragen? Welche Evidenz muss vorliegen, bevor ein Ticket geschlossen oder ein Workflow weitergeführt wird?
Der vierte Schritt ist Testen mit eigenen Daten. Ein allgemeiner Agenten-Benchmark ist nützlich, aber er ersetzt keinen Lauf gegen die eigenen Tickets, Logs, APIs und Freigabeprozesse. Viele Fehler entstehen erst dort, wo ein Agent auf interne Abkürzungen, historisch gewachsene Namenskonventionen oder schlecht dokumentierte Systeme trifft. Genau diese lokale Reibung entscheidet später, ob ein Agent produktiv hilft.
Der dritte Schritt ist menschliche Kontrolle an den richtigen Stellen. Human-in-the-loop bedeutet nicht, dass ein Mensch jeden Zwischenschritt abnickt. Es bedeutet, dass Menschen dort eingebunden werden, wo Fehler teuer, irreversibel oder schwer sichtbar sind. Für unkritische Recherche kann ein Agent mehr Autonomie bekommen. Für Produktionssysteme, Security-Entscheidungen oder Compliance-relevante Aktionen braucht er engere Grenzen.
Für kleinere Unternehmen ist besonders wichtig: Eigenbau von komplexen Agentensystemen ist riskant, wenn kein dediziertes ML- oder Platform-Team vorhanden ist. ITBench, MAST und öffentliche Trajectory-Daten helfen aber dabei, Anbieter und fertige Lösungen realistischer zu prüfen. Wer einen Enterprise-Agenten einkauft, sollte Demo-Funktionen und Failure-Mode-Analysen verlangen.
Governance: Wer trägt die Verantwortung?
Die organisatorische Frage ist fast wichtiger als die technische. Wenn ein Agent eine Aufgabe falsch erledigt, kann sich kein Unternehmen damit herausreden, dass "die KI" es getan hat. Verantwortlich bleibt die Organisation, die den Agenten mit Rechten, Daten und Prozesszugriff ausgestattet hat.
Deshalb brauchen KI-Agenten im Unternehmen klare Ownership. Ein Fachbereich kann den Use Case liefern, aber Betrieb und Risiko gehören in eine gemeinsame Verantwortung von Engineering, Security, Compliance und Produktverantwortlichen. Wer diese Rollen nicht definiert, erzeugt Schattenautomatisierung: Agenten arbeiten irgendwo in der Prozesskette, aber niemand kann sauber erklären, welche Rechte sie haben, welche Daten sie sehen und welche Fehlermodi bekannt sind.
Zur Ownership gehört auch ein Abschaltpfad. Produktive Agenten brauchen nicht nur Onboarding, sondern auch Deaktivierung, Rollback und Incident-Kommunikation. Wenn ein Agent falsche Aktionen auslöst, muss klar sein, wer ihn stoppt, welche Systeme geprüft werden und wie seine letzten Aktionen rekonstruiert werden. Ohne diesen Pfad bleibt Agentenbetrieb ein Experiment mit Produktivdaten.
Ein weiteres Detail wird oft unterschätzt: Agenten-Logs sind Sicherheitsartefakte. Sie zeigen Tool-Aufrufe, Zwischenannahmen, Kontextwechsel und manchmal sensitive Daten. Wer sie zu kurz speichert, verliert Diagnosefähigkeit. Wer sie ungeschützt speichert, schafft ein neues Datenleck. Gute Agenten-Governance definiert deshalb Aufbewahrung, Zugriff und Redaction genauso präzise wie bei klassischen Produktionslogs.
Ebenso wichtig ist ein klarer Degradationspfad. Wenn ein Agent nicht weiterkommt, muss der Prozess wissen, ob er stoppen, nachfragen, an einen Menschen übergeben oder auf einen konservativen Workflow zurückfallen soll.
Das gilt auch für klassische Einführungsszenarien. Der ergänzende Artikel zu KI-Agenten im Unternehmen ordnet ein, welche Aufgaben sich eignen, wie Governance aussehen kann und welche Rolle DSGVO, Kosten und Rechtekonzepte spielen.
Viele Unternehmen messen Agenten noch wie Chatbots: Antwort gut, Aufgabe erledigt, Haken dran. Das ist zu wenig. Ein produktiver Agent braucht eine Fehleranatomie. Erst wenn klar ist, woran er scheitert, lässt sich entscheiden, ob er mit mehr Kontext, besserer Tool-Grenze oder weniger Autonomie arbeiten sollte.
Fazit: Agenten scheitern erklärbar
Die Arbeit von IBM und Berkeley liefert eine Sprache für etwas, das in vielen Unternehmen noch unscharf bleibt: Agenten scheitern nicht zufällig. Sie scheitern an erkennbaren Mustern. Planung, Tool-Nutzung, Terminierung und Verifikation bilden den Kern produktiver Agentensysteme.
Für Unternehmen ist die Konsequenz klar. Wer KI-Agenten produktiv einsetzen will, braucht mehr als Demo-Scores: strukturierte Fehleranalyse. MAST und ITBench sind dafür ein guter Ausgangspunkt. Sie ersetzen keine interne Sicherheitsarchitektur, aber sie verschieben die Diskussion vom Hype zur Diagnose. Genau dort beginnt produktiver Betrieb.
Warum reichen normale Agenten-Benchmarks nicht?
Weil sie oft nur Erfolg oder Misserfolg messen. Für produktive Systeme ist wichtiger, warum ein Lauf scheitert: falscher Plan, falsches Tool, falsche Verifikation oder zu frühe Terminierung.
Was ist MAST?
MAST steht für Multi-Agent System Failure Taxonomy. Das Framework klassifiziert Fehler in Agentenläufen und macht sichtbar, welche Fehlermodi in einem System wiederkehren.
Was ist die wichtigste Schutzmassnahme?
Externe Verifikation. Ein Agent sollte seinen Erfolg nicht allein selbst bewerten. Kritische Schritte brauchen harte Tool-Evidenz, explizite Stop-Regeln oder menschliche Kontrolle.
