Autonom ja, verlässlich nein: Was KI-Agenten heute leisten

Das Wichtigste in Kürze

• Agenten lösen nur kurze Aufgaben verlässlich; bessere Modelle verschieben diese Grenze, sie heben sie nicht auf.
• Ein Agent, der sich selbst prüft, besteht nur die Tests, die er kennt – nötig ist eine Prüfung außerhalb des Modells, die ablehnen darf und zurück in die Korrektur schickt.
• Gerechnet wird über die Häufigkeit des Vorgangs, gemessen wird im Dauerbetrieb.

Früher hat man seine Reports etwa in Power BI programmiert. Kam die Revision, konnte man an den Daten und am Programm nachvollziehen, wie ein Ergebnis zustande gekommen war. Wenn jetzt aber mehrere KI-Agenten am Werk sind, also Sprachmodelle, die mit Werkzeugen selbständig Aufgaben abarbeiten und sich diese Werkzeuge unterwegs auch selbst schreiben, was bleibt dem Prüfer dann noch, außer das Protokoll plausibel zu finden?

Was ihm bleibt, hängt davon ab, wo die Verifikation von KI-Agenten stattfindet. Prüft der Agent sich selbst, bleibt dem Prüfer nur dessen Wort. Gibt es eine Prüfung außerhalb des Modells, die das Ergebnis ablehnen darf, hat er wieder etwas Nachvollziehbares: die Prüfung und ihre Regel. Von derselben Prüfung hängt ab, wie viel Arbeit du KI-Agenten überlassen darfst, und das entscheidet die Person, die für das Ergebnis geradesteht, nicht der Anbieter.

Verlässliche Ergebnisse liefern KI-Agenten nur bei kurzen Aufgaben, auch mit besseren Modellen.

Die genaueste öffentliche Messung dazu stammt von der Forschungsorganisation METR. METR misst einen Zeithorizont: die Länge einer Aufgabe, bemessen daran, wie lange ein menschlicher Profi dafür braucht, nicht daran, wie lange der Agent läuft. Gemessen wird an Software-Aufgaben, mit den jeweils stärksten verfügbaren Modellen und getrennt nach der verlangten Trefferquote.

Zwölf Stunden bei jeder zweiten Aufgabe, gut eine Stunde bei vier von fünf

Für das im Februar 2026 erschienene Modell Claude Opus 4.6 weist METR beim 50-Prozent-Horizont zwölf Stunden aus: Aufgaben dieser Länge löst ein Agent mit diesem Modell in jedem zweiten Fall. Sollen vier von fünf Aufgaben richtig gelöst sein (80-Prozent-Horizont), dürfen sie nur eine Stunde und zehn Minuten lang sein. METR nennt für diesen Wert eine Unsicherheitsspanne von 27 Minuten bis zwei Stunden und fünfzig Minuten; selbst an deren oberem Ende bleibt zwischen beiden Horizonten ein Faktor von mehr als vier.

Dabei ist 80 Prozent nur die oberste Schwelle, die METR ausweist. In einem regulierten Prozess dürfte eine Fehlerquote von einem Fünftel eher als Vorfall gelten denn als Ergebnis. Wer mehr verlangt, landet bei einem noch kürzeren Horizont, das heißt bei noch kleineren Arbeitspaketen, die der Agent verlässlich bewältigt.

Auf jede beliebige Aufgabe lassen sich diese Werte nicht eins zu eins übertragen; eine Vertragsprüfung bei einem Versicherer ist keine Software-Aufgabe. In jedem Fachgebiet gilt aber, dass eine Aufgabe dem Agenten umso seltener gelingt, je länger sie ist, und METR erwartet, dass echte Aufgaben schwerer sind als seine Testaufgaben. Wie viel kürzer die Aufgaben in eurem Prozess sein müssen, zeigt erst eure eigene Messung.

Bessere Modelle verschieben die Lücke, sie schließen sie nicht

Der naheliegende Einwand kann lauten, dass die Modelle ja immer besser würden, und METRs Zahlen bestätigen das auch: Claude Opus 4.5 lag im November 2025 beim 50-Prozent-Horizont noch bei 4,9 Stunden. METR beziffert die Zeit, in der sich der Horizont verdoppelt, für 2019 bis 2025 auf etwa sieben Monate und misst seit 2023 eine deutlich kürzere Verdopplungszeit. Nur wächst der 80-Prozent-Horizont dabei im selben Takt wie der 50-Prozent-Horizont: METR misst für beide dieselbe Verdopplungszeit. Ein besseres Modell schließt die Lücke also nicht, es verschiebt sie zu längeren Aufgaben. Verlässliche Ergebnisse gibt es deshalb bei jeder Modellgeneration nur auf zwei Wegen: mit kleineren Arbeitspaketen, oder man lässt dem Agenten die lange Aufgabe und sortiert die falsche Hälfte aus, mit einer Prüfung, die Fehler findet und das Ergebnis zurückweist.

Ein Agent, der sich selbst prüft, besteht nur die Tests, die er kennt

Die einfachste Form einer solchen Prüfung ist, den Agenten gegen Tests prüfen zu lassen, die er kennt oder selbst schreibt. Das unterläuft die Kontrolle, weil der Agent auf die Tests hinarbeitet, die er vor sich hat, und weil er sie selbst schreibt, kennt er sie natürlich. Die Studie SpecBench, ein noch nicht begutachtetes Preprint, zeigt das an Agenten, die über Stunden Software schreiben, mit zwei Arten von Tests. Die sichtbaren Tests sieht der Agent während der Arbeit und darf sie beliebig oft laufen lassen; sie prüfen jede geforderte Funktion einzeln. Die zurückgehaltenen Tests sieht er nie; sie kombinieren dieselben Funktionen so, wie sie im echten Gebrauch zusammenwirken.

Alle geprüften Agenten bestehen die sichtbaren Tests nahezu vollständig. Auf den zurückgehaltenen Tests fällt ihre Quote ab, der Abstand wächst dabei mit der Größe der Aufgabe: Bei kleinen Aufgaben liegt der schlimmste gemessene Abstand bei 21 Prozentpunkten, bei den größten bei 100, also bei einem Programm, das jeden Test besteht, den es kennt, und im Gebrauch nichts leistet. Auch die stärksten Modelle behalten einen Abstand. Der Agent betrügt dabei in der Regel nicht; er baut, was die sichtbaren Tests einzeln abfragen, und lässt das Zusammenspiel aus.

Innere und äußere Schleife: Wer darf das Ergebnis ablehnen?

Deshalb trennen wir eine innere und eine äußere Schleife. Die innere Schleife ist der Agent selbst: Er erledigt die Aufgabe, prüft sich und bessert nach. Die äußere Schleife liegt außerhalb des Modells, das die Arbeit gemacht hat. Sie urteilt unabhängig und endet in einer Entscheidungsregel, die der Agent nicht verhandeln kann: Was die Prüfung nicht besteht, geht zurück in die Korrektur. Ein Anbieter, der dir die Selbstkontrolle des Agenten als Qualitätssicherung verkauft, verkauft dir die Quote auf den sichtbaren Tests; du brauchst die Quote auf den Fällen, die der Agent nicht gesehen hat.

Die äußere Schleife prüft Ergebnisse. Für die einzelnen Handlungen des Agenten gilt dasselbe Prinzip als Freigaberegel für Aktionen: Das Modell schlägt eine Aktion vor, und ein Programm außerhalb des Modells entscheidet, ob sie ausgeführt wird. Diese Regel greift dort, wo die Ergebnisprüfung nichts sieht, etwa bei einer in einem Dokument versteckten Anweisung, die der Agent unterwegs befolgt. Wie weit ein Agent ohne diese Freigaberegel reichen kann, haben wir in der Risiko-Staffel beim Kontrollverlust über KI-Agenten durchdekliniert.

Verifikation von KI-Agenten in der Praxis

Die äußere Schleife hat in unseren Dark Software Factories, in denen Agenten Software ohne menschliche Begleitung der einzelnen Schritte bauen, einen festen Platz in Form einer eigenen Verify-Stufe. Sie startet einen eigenen virtuellen Rechner, prüft die fertige Anwendung im Browser gegen die Akzeptanzkriterien aus der Anforderung, zeichnet den Durchlauf auf und gibt bei Abweichung einen Reparaturauftrag an den Agenten zurück.

Nach demselben Muster arbeitet die Vertragsprüfung für unsere eigenen Verträge: Vertrag hinein, Dokument mit markierten Änderungsvorschlägen und Risikoeinschätzung heraus, Freigabe mit Begründung, aus der das System lernt. Gemessen wird die Freigabequote, also der Anteil freigegebener Ergebnisse, laufend gegen einen vorab festgelegten Vergleichswert. Für Fälle ohne eindeutiges Richtig oder Falsch braucht die Prüfung einen festen Bewertungsbogen: fünf bis sechs einzeln bewertete Kriterien, ein Gesamtwert und ein Schwellwert, den das Ergebnis erreichen muss. Anhand dieses Bogens bewertet ein zweiter Agent das Ergebnis, mit dem Auftrag, Fehler zu finden, und mit einem Modell aus einer anderen Modellfamilie, also von einem anderen Hersteller oder aus einer anderen Modellreihe.

Macht ein zweiter Agent die Prüfung wirklich verlässlicher?

Ein Enterprise Architect wird hier einwenden: „Ihr ersetzt ein Modell, das bei gleicher Eingabe nicht zweimal dasselbe liefert, durch zwei davon.“ Nur ist der Fehler des Agenten kein Zufall, sondern die Folge seines Ziels: Er baut, was seine Tests abfragen, und übersieht, was daran vorbeigeht. Der zweite Prüfer teilt dieses Ziel nicht: Er misst gegen den Bewertungsbogen und gegen Fälle, auf die der Agent nicht hingearbeitet hat, und er arbeitet mit einem anderen Modell. Seine Messung bleibt unscharf, aber unabhängig von der Arbeit, die sie beurteilt. Festgelegt ist, was bei welchem Messwert passiert: Ein Ergebnis unter dem Schwellwert geht zurück in die Korrektur, und das entscheidet die Regel, nicht eines der beiden Modelle.

Jede Art von Fehler fängt auch diese Prüfung nicht ab; das Preprint „No Silver Bullet“ beschreibt diese Grenze für Coding-Agenten. Die Zielgröße für den Betrieb ist deshalb eine Untergrenze für die Freigabequote, die ihr schrittweise nach oben zieht. Sie ersetzt die Null-Fehler-Zusage, die auch menschliche Mitarbeiter nie einhalten. Vier Fragen prüfen damit jedes Angebot, auch das deines eigenen Teams:

• question_exchange Liegt die Prüfung außerhalb des Modells, das die Arbeit gemacht hat?
• question_exchange Urteilt sie unabhängig, also mit einem Modell aus einer anderen Modellfamilie und mit Fällen, die der Agent nicht gesehen hat?
• question_exchange Endet sie in einem Reparaturauftrag statt in einem Report?
• question_exchange Erzeugt sie ein Protokoll, das eure Revision akzeptiert?

Was der EU AI Act an Protokollierung verlangt

Für Hochrisiko-Systeme verlangt der EU AI Act, was die vierte Frage prüft: die automatische Protokollierung von Ereignissen über den Lebenszyklus und menschliche Aufsicht, bemessen am Autonomiegrad des Systems. Lesbar sind die Protokolle, weil Sprachmodelle ihre Begründungsschritte in natürlicher Sprache mitschreiben können; bei großer Menge sieht eine zweite Instanz sie durch und meldet Auffälligkeiten.

Qualität kann driften, trotz Prüfschleife

Eine solche Schleife ist Dauerbetrieb und kein einmaliges Abnahmeereignis. Anbieter entwickeln ihre Modelle weiter, auch hinter einer unveränderten Versionsbezeichnung; identische Aufrufe liefern dann andere Ergebnisse als beim Start, und die Qualität kann sinken, ohne dass jemand etwas davon mitbekommt, bis der Schaden in Hunderten von Vertragsdokumenten steckt. Ein Preprint zu LLM Output Drift untersucht dieses Abdriften der Ergebnisse für Finanz-Workflows.

Dagegen hilft nur die laufende Messung gegen die Untergrenze. Lege vor dem ersten produktiven Vorgang fest, welche Unterschreitung den Alarm auslöst und wer die Kapazität vorhält, innerhalb weniger Tage nachzuarbeiten. Wer misst, aber keine Kapazität für die Nacharbeit vorhält, erfährt von dem Schaden nur früher und verhindert ihn nicht.

Rechnet sich die Prüfschleife?

Ob sich eine Prüfschleife rechnet, entscheidet die Häufigkeit des Vorgangs, nicht das nächste Modell.

Eine Prüfregel wird einmal geschrieben und bei jedem Durchlauf genutzt; ob sie sich rechnet, entscheidet deshalb die Häufigkeit des Vorgangs. Wer seinen Wettbewerbsreport wöchentlich erstellt, kommt auf zwölf Durchläufe im Quartal. Übernimmt ein geprüfter Agent den Vorgang täglich, sind es rund neunzig.

Bei vier Durchläufen im Jahr rechnet sich eine vorgangsspezifische Prüfregel nicht, wohl aber die Bausteine, die alle Vorgänge gemeinsam nutzen: die Protokollierung, das Gateway als zentrale Stelle, über die alle Aufrufe der Agenten laufen und mitgeschrieben werden, und die äußere Schleife. Sie werden einmal gebaut und refinanzieren sich über den zweiten und dritten Anwendungsfall. Auch der nächste Modellsprung entwertet sie nicht: Er verschiebt die Lücke nur zu längeren Aufgaben, und deren Ergebnisse laufen durch dieselbe Schleife.

Der Aufwand steckt dabei in der Abstimmung mit dem Fachbereich, nicht im Modell. Ist die äußere Schleife für einen Vorgang gebaut, beginnen unserer Erfahrung nach erst nach etwa vier Wochen die Optimierungsarbeiten, und danach vergehen noch einmal rund zwei Monate, bis die Sache rund läuft. Was in dieser Zeit abzustimmen ist, zeigte ein Anforderungs-Workshop mit einem Verpackungshersteller: Layouts sollten automatisch nach 200-seitigen Markenrichtlinien entstehen, und weil dafür kein Test ein Richtig oder Falsch abfragt, müsste jede Datei visuell gegen einen Bewertungsbogen geprüft und dieser Bogen mit dem Fachbereich Runde für Runde nachgeschärft werden. Wer den Aufbau bis zum nächsten Modell aufschiebt, verschiebt diese Monate, er spart sie nicht.

Was du mitnimmst

Frage die Person, die eure KI-Plattform verantwortet, welches Programm außerhalb des Modells ein Ergebnis ablehnen darf, wer es geschrieben hat und was dann passiert. Lautet die Antwort „das prüft das Modell selbst“, „ein zweiter Prompt“, der dasselbe Modell nur noch einmal fragt, oder „wir bekommen einen Report“, existiert die äußere Schleife nicht. Zwei weitere Schritte schließen sich an:

• Schreibe mit dem Fachbereich eure bestehende Prüfpraxis für einen wiederkehrenden Vorgang auf und markiere, welcher Teil davon maschinell ausführbar ist. Aus diesem Teil entsteht die Prüfregel der äußeren Schleife. In den Auftrag an den Agenten gehört er nicht, sonst prüft der Agent wieder sich selbst.
• Lege, noch bevor gebaut wird, für denselben Vorgang mit eurer Revision fest, welches Protokoll die Prüfer als Nachweis akzeptieren würden. Nachträglich ist das ein Umbau, vorher eine Anforderungszeile.

Fehlt die äußere Schleife nach diesem Selbsttest, zeigen wir dir die Prüfmechanik gerne an einem laufenden System. In unserer KI-Plattform mAIstack laufen das Agent-Gateway, die Freigaben und die lückenlose Protokollierung jedes Schritts; du siehst dort, wie eine Ablehnung aussieht, was danach passiert und welche Spur die Revision bekommt. Neugierig? Dann vereinbare jetzt ein Gespräch.