Human in the Loop bei KI-Agenten: wo Freigaben hingehören

Jedes Team, das einen Agenten ausliefert, stößt innerhalb einer Woche auf dieselbe Frage: Wann muss er fragen? Fragt er zu selten, löscht ein einziger schlechter Tool-Aufruf eine Tabelle, verschickt die falsche E-Mail oder erstattet dem falschen Kunden Geld. Fragt er zu oft, klicken Leute auf „Erlauben“, ohne zu lesen. Das ist schlimmer als kein Gate, denn das System wirkt beaufsichtigt, ist es aber nicht.

„Human in the Loop“ wird meist als Häkchen behandelt: ein Bestätigungsdialog vor gefährlichen Tools. Das ist der Anfang des Designs, nicht das Ende. Dieser Artikel behandelt die Entscheidungen, auf die es ankommt: wo die Gates sitzen, wie du Freigaben baust, die Menschen wirklich lesen, welche Interrupt- und Resume-Primitive die wichtigsten Agent-Frameworks heute bieten, was ein Audit-Trail enthalten muss und wie Always-on-Agenten wie OpenAI dots das Bild verändern. Wenn du zuerst die Mechanik der Schleife selbst willst, beginne mit der Agent-Schleife erklärt.

Warum Freigabe pro Aktion im großen Maßstab scheitert

Die unbequeme Evidenz kommt von denen, die den größten Freigabe-Dialog der Branche betreiben. In seinem Engineering-Beitrag zum Auto Mode schreibt Anthropic, dass Claude-Code-Nutzer 93 Prozent der Berechtigungsabfragen bestätigen, und beschreibt die Folge als Approval Fatigue: Menschen hören auf, genau hinzuschauen, was sie freigeben.

Ein berichtetes Experiment macht den Punkt schärfer. Laut DevOps.com hat Anthropic bei 1.053 Testern einen tatsächlich gefährlichen Befehl in Berechtigungsabfragen eingebettet: Menschliche Prüfer erkannten ihn in 13,6 Prozent der Fälle, ein automatischer Klassifikator in 89 Prozent, und nach mehr als 50 vorherigen Abfragen sank die menschliche Trefferquote auf etwa 5 Prozent. Das ist ein Experiment des Herstellers mit einem bewusst getarnten Befehl, ich lese es daher als Richtung und nicht als Konstante. Die Richtung ist trotzdem eindeutig: Wer fünfzig harmlose Anfragen gesehen hat, ist ein schlechter Detektor für die einundfünfzigste.

Derselbe Engineering-Beitrag ist ehrlich über die andere Seite. Der zweistufige Klassifikator zeigte bei echten übereifrigen Aktionen in einer kleinen Stichprobe von 52 immer noch eine False-Negative-Rate von 17 Prozent, die Anthropic die ehrliche Zahl nennt. Weder ein Mensch noch ein Modell ist ein verlässliches einzelnes Gate. Das Designziel ist deshalb nicht „ein Mensch genehmigt alles“, sondern: knappe menschliche Aufmerksamkeit dort einsetzen, wo sie das Ergebnis ändert, und sie mit Kontrollen absichern, die nicht ermüden.

Wo die Gates hingehören: Risiko, Reversibilität, Wirkungsradius

Nach Tool-Namen zu gaten („frag vor Bash“) ist zu grob und zu leicht zu verwässern. Ich gate nach vier Eigenschaften der Aktion, in dieser Reihenfolge der Wichtigkeit:

• Reversibilität. Lässt sich die Wirkung günstig und vollständig rückgängig machen? Ein Entwurf, ein Branch oder eine Zeile in einer Staging-Tabelle schon. Eine versendete E-Mail, eine Zahlung, ein gelöschter Bucket oder eine geänderte Berechtigung nicht.
• Wirkungsradius. Wie viele Datensätze, Kunden oder Systeme berührt ein Aufruf? „Ein Ticket aktualisieren“ und „alle Tickets eines Filters aktualisieren“ sind dasselbe Tool mit tausendfach unterschiedlichem Risiko.
• Daten und Sichtbarkeit. Macht die Aktion personenbezogene, finanzielle oder vertrauliche Daten sichtbar, oder ist sie außerhalb deiner Organisation sichtbar?
• Autorität. Nutzt sie Zugangsdaten, die der Mensch für diese Aufgabe nicht erteilt hat, oder ändert sie, wer was darf?

Diese Eigenschaften ergeben vier Stufen. Die rechten Spalten sind so wichtig wie die linken: Eine Stufe ist nur real, wenn sie die Kontrolle und die hinterlassene Evidenz benennt.

Zwei Regeln halten die Matrix ehrlich. Erstens: nach dem schlimmsten Fall der Argumente eskalieren, nicht nach dem Tool. Ein Erstattungs-Tool mit einem Betrag über dem Limit ist Stufe 3, darunter Stufe 2. Zweitens: Der Agent klassifiziert seine Aktion nie selbst. Die Stufe kommt aus deterministischen Regeln oder von einer separaten Komponente außerhalb seiner Reichweite. Genau diese Struktur beschreibt OpenAI für dots, wo ein getrenntes Prüfsystem außerhalb der vom Agenten veränderbaren Umgebung entscheidet, ob ein Schritt läuft. Die Berechtigungsreihenfolge im Claude Agent SDK ist genauso gebaut: Hooks, dann Deny-Regeln, dann Ask-Regeln, dann der Berechtigungsmodus, dann Allow-Regeln, dann dein Callback.

Freigabe-UX, die Menschen nicht zum Ja-Klicken erzieht

Wenn ein Gate auslöst, entscheidet die Oberfläche, ob es funktioniert. Das sind die Designregeln, die ich anwende, und sie folgen alle einer Idee: Die prüfende Person sollte die Wirkung in wenigen Sekunden beurteilen können.

• Zeige die Wirkung, nicht die Absicht. „Der Agent will send_email ausführen“ ist nutzlos. „E-Mail an ceo@client.com, 340 Wörter, Anhang contract.pdf, 12 Personen in CC“ ist prüfbar. Bei Code und Daten zeig einen Diff, bei Geld Betrag, Währung und Empfänger.
• Mach das Gefährliche laut. Hebe das Ungewöhnliche hervor: einen neuen Empfänger, einen Betrag über dem Median, einen Platzhalter im Pfad, eine externe Domain.
• Bündle, was zusammengehört. Zehn ähnliche Stufe-2-Schritte sind eine Entscheidung mit sichtbarer Liste, nicht zehn Dialoge. Ermüdung wächst mit der Zahl der Unterbrechungen.
• Biete Ändern an, nicht nur Ja oder Nein. Das Claude Agent SDK lässt deinen Callback geänderte Eingaben zurückgeben, und die Human-in-the-Loop-Middleware von LangChain kennt neben Approve und Reject eine Edit-Entscheidung. Wer einen Parameter korrigieren kann, lehnt nicht den ganzen Plan ab.
• Lass Ablehnung eine Begründung tragen. Eine Deny-Nachricht geht zurück ans Modell, das sich anpassen kann. Im Claude Agent SDK sieht Claude die Nachricht einer Ablehnung, im OpenAI Agents SDK kannst du pro Aufruf eine Ablehnungsnachricht setzen.
• Vorsicht bei „immer erlauben“. Eine gemerkte Entscheidung entfernt künftige Reibung und künftige Kontrolle zugleich. Wenn du sie anbietest, begrenze sie eng (dieser Befehl, dieser Pfad), lass sie ablaufen und liste aktive Regeln dort, wo Leute sie prüfen können.
• Im Zweifel verweigern. Antwortet niemand, ist die Antwort nein. Ein Timeout darf nie freigeben.

Und dann messen. Meine Faustregel, eine Erfahrungsheuristik und kein veröffentlichter Schwellenwert: Wird ein Gate zu mehr als etwa 95 Prozent freigegeben und dauert die Entscheidung im Median ein paar Sekunden, ist es Theater. Entweder gehört die Aktion in Stufe 1, oder die Abfrage liefert nicht, was man zur Beurteilung braucht. Verfolge pro Aktionstyp Freigabequote, Entscheidungszeit und den Anteil später rückgängig gemachter Freigaben. Es ist dasselbe Aufmerksamkeitsproblem, das agentengeschriebene Pull Requests zum Review-Flaschenhals macht, und die Lösung ist dieselbe: weniger, besser vorbereitete Entscheidungen.

Interrupt und Resume in den wichtigsten Frameworks

Technisch ist ein Gate eine Pause: Der Agent schlägt eine Aktion vor, die Runtime hält an, der Zustand wird gesichert, und ein späterer Aufruf setzt mit einer Entscheidung fort. Alle drei großen Stacks haben dafür inzwischen ein eigenes Primitiv. Die API unterscheidet sich, die Fehlerbilder ähneln sich.

Ein paar Details aus der offiziellen Dokumentation solltest du kennen, bevor du darauf aufbaust. Der Interrupts-Guide von LangGraph warnt, dass ein fortgesetzter Node von oben neu läuft, eine E-Mail vor dem Interrupt würde also doppelt versendet. Der Guide des OpenAI Agents SDK zeigt, dass needs_approval eine async Funktion sein kann, die pro Aufruf anhand der Parameter entscheidet, und sagt für langlebige Freigaben: Der Server soll den Prüfer authentifizieren, gegen den gespeicherten Lauf autorisieren, Entscheidungs-IDs gegen serverseitigen Zustand validieren und Entscheidungen atomar anwenden, um Replay zu verhindern. Die Dokumentation des Claude Agent SDK hält fest, dass der Callback unbegrenzt offen bleiben kann, und empfiehlt die Entscheidung defer, wenn ein Mensch länger brauchen könnte, als dein Prozess leben kann.

from langgraph.types import interrupt, Command

def refund_node(state):
    # runs again from the top after resume: keep everything above idempotent
    decision = interrupt({
        "action": "refund", "amount": state["amount"],
        "customer": state["customer_id"], "tier": 3,
    })
    return Command(goto="execute" if decision["approved"] else "cancel")

# later, possibly from another process, same thread_id
graph.stream_events(Command(resume={"approved": True}),
                    config={"configurable": {"thread_id": "case-4711"}}, version="v3")

Unabhängig vom Framework ergänze ich vier Eigenschaften. Binde die Freigabe an die exakte Aktion: Speichere einen Hash aus Tool-Name und Argumenten mit der Entscheidung und prüfe ihn bei der Ausführung erneut, damit ein nach der Freigabe geänderter Plan nicht gedeckt ist. Authentifiziere den Freigebenden über deine Session, nie über den Request-Body. Lass Freigaben ablaufen, nach Minuten oder Stunden, nicht Tagen. Mach den ausführenden Schritt idempotent mit einem Idempotency-Key, denn Resume, Retry und Doppelklick gibt es alle. Für Tool-Sicherheit im weiteren Sinn deckt meine MCP-Server-Security-Checkliste die andere Hälfte des Problems ab.

Audit-Trails und Eskalation

Eine Freigabe ohne Aufzeichnung kann nicht geprüft, angefochten oder gelernt werden. Für jede gegatete Aktion logge ich eine kleine, langweilige Menge an Fakten: Lauf- und Thread-Kennungen, die vorgeschlagene Aktion mit allen Argumenten, die Stufe und die Regel, die sie zugewiesen hat, wer entschieden hat (Person, Regel oder Reviewer-Modell), die Entscheidung und jede Änderung, Zeitstempel und Latenz sowie das Ergebnis der Ausführung. Speichere die Argumente so, wie sie dem Prüfer gezeigt wurden. Rendert die Oberfläche eine Zusammenfassung, behalte auch diese, denn ein Streit dreht sich oft darum, was die Person gesehen hat.

Für regulierte Anwendungen ist das nicht optional. Artikel 14 des EU AI Act, der für Hochrisiko-Systeme gilt, verlangt Aufsicht, mit der zuständige Personen die Grenzen des Systems verstehen, sich des Automation Bias bewusst bleiben, entscheiden können, die Ausgabe nicht zu verwenden oder zu übersteuern, und in den Betrieb eingreifen oder das System stoppen können. Ob dein Agent Hochrisiko ist, hängt vom Anwendungsfall ab, prüf das also, bevor du in die eine oder andere Richtung annimmst. Meine EU-AI-Act-Checkliste für Entwickler behandelt die Transparenzseite.

Eskalation ist der Teil, den Teams vergessen. Lege vorab fest, wer gefragt wird, wie viel Zeit er hat und was dann passiert. Eine tragfähige Leiter: zuerst der anfragende Nutzer, dann eine benannte Rolle (der Prozessverantwortliche), dann ein zweiter Freigebender für Stufe 3, und als Default Ablehnen, wenn niemand antwortet. Ergänze einen Kill-Switch, der vom Agenten unabhängig ist: ein Flag, das neue Läufe stoppt und offene Freigaben abbricht. Leite Benachrichtigungen über einen Kanal, den Leute ohnehin beobachten. Das Claude Agent SDK hat zum Beispiel einen PermissionRequest-Hook, der gedacht ist, um eine Slack- oder E-Mail-Benachrichtigung zu senden, wenn ein Agent wartet.

Was Always-on-Agenten ändern

Alles bisher setzte eine Person vor einem Chat voraus. Always-on-Agenten brechen diese Annahme. Ein Dot oder ein geplanter Coding-Agent arbeitet stundenlang, läuft, während du schläfst, und erzeugt Freigaben im Maschinentempo. Wie ich in der Dots-Wirkungsanalyse geschrieben habe, wandert der Mensch vom Anfang ans Ende der Kette, und Aufmerksamkeit wird zum Engpass.

OpenAIs veröffentlichtes Design für dots ist eine nützliche Referenz, weil es ein risikogestuftes Gate ist. Hintergrundrecherche läuft mit Nur-Lese-Tools, ein separates Auto-review-System prüft folgenreiche Schritte gegen deine Anweisungen, deine Custom Rules und Sicherheitsanforderungen, und Custom Rules können Aktionen erlauben, eine Freigabe verlangen oder sie blockieren, aber eine verpflichtende Untergrenze nicht entfernen: Ein Passwort ändern oder Geld zwischen Konten bewegen geht immer an die Person zurück. Das sind die Stufen 0, 2 und 3 als Produkt.

Daraus folgen drei Konsequenzen für dein eigenes Design. Erstens: Regeln ersetzen die meisten Rückfragen. Ein Regelwerk wie „Erstattungen unter X laufen, darüber fragen, alles mit Bankdaten ist gesperrt“ entfernt tausende wertarme Unterbrechungen und macht die verbleibenden zu Ereignissen, die man lesen will. Zweitens: Ein Reviewer-Modell ist ein Werkzeug, kein Orakel. Es skaliert und ermüdet nicht, aber Anthropics eigene Zahlen zeigen eine Fehlerquote über null, und OpenAIs Auto-review ist das Modell des Herstellers, das den Agenten des Herstellers beaufsichtigt. Halte deterministische Stufe-3-Regeln außerhalb jedes Modells und prüfe Stichproben der automatisch freigegebenen Aktionen per Mensch. Drittens: Gates kontrollieren Aktionen, nicht, was der Agent liest. Ein Nur-Lese-Dot sieht trotzdem den ganzen Kundendatensatz, deshalb gehören Least-Privilege-Verbindungen und maskierte Daten genauso ins Design wie Freigaben. Dieses Muster vertiefe ich in Prompt Injection und die Lethal Trifecta.

Eine Checkliste für deinen nächsten Agenten

Diese Liste würde ich durchgehen, bevor ein Agent mit Schreibzugriff auf echte Daten losgelassen wird:

1. Liste jedes Tool und dazu die Worst-Case-Argumente. Weise eine Stufe nach Reversibilität, Wirkungsradius, Daten und Autorität zu.
2. Lege die Stufenentscheidung außerhalb des Agenten: zuerst deterministische Regeln, dann ein Reviewer-Modell, nie das eigene Urteil des Agenten.
3. Sperre Stufe 3 standardmäßig und erlaube sie nur über eine benannte Übergabe mit authentifiziertem Freigebenden.
4. Baue den Freigabe-Screen um die Wirkung herum: Payload, Diff, Empfänger, Betrag, mit hervorgehobenen Auffälligkeiten.
5. Bündle ähnliche Stufe-2-Schritte, unterstütze Ändern neben Freigeben und Ablehnen und gib Ablehnungsgründe an den Agenten zurück.
6. Pausiere mit Checkpointer oder serialisiertem Zustand, mach alles vor der Pause idempotent und binde jede Freigabe an einen Hash der exakten Aktion.
7. Verweigere bei Timeout, lass Freigaben ablaufen und halte einen Kill-Switch bereit, der nicht vom Agenten abhängt.
8. Logge wer, was, Stufe, Regel, Entscheidung, Änderungen, Zeit und Ergebnis, und bewahre auf, was der Prüfer tatsächlich gesehen hat.
9. Prüfe wöchentlich eine Stichprobe automatisch freigegebener Aktionen per Mensch und verfolge Freigabequote und Entscheidungszeit pro Aktionstyp.
10. Stufe nach jedem Vorfall und jedem neuen Tool neu ein: Die Matrix ist ein lebendes Dokument.

Wenn du Hilfe brauchst, das in eine konkrete Architektur für deine Agenten zu überführen: Das ist das, was ich in meiner KI-Engineering-Arbeit mache.

Das größere Bild

Human in the Loop verschwindet nicht, wenn Agenten besser werden, aber seine Form ändert sich. Der Default wandert von „eine Person genehmigt jeden Schritt“ zu „eine Person setzt die Regeln, prüft die Ausnahmen und auditiert den Rest“. Dass der Auto Mode in Claude Code zum Standard wird und dots eine Auto-review-Schicht haben, zeigt zwei Hersteller, die in derselben Saison zum selben Schluss kommen.

Menschlich bleibt die Verantwortung. Ein Klassifikator kann eine Aktion genehmigen, aber nicht dafür verantwortlich sein. Gestalte jedes Gate so, dass du, wenn etwas schiefgeht, beantworten kannst, wer es erlaubt hat, auf welcher Informationsgrundlage und nach welcher Regel.

Quellen

1. LangChain docs: LangGraph interrupts
2. LangChain docs: Human-in-the-loop (HumanInTheLoopMiddleware)
3. OpenAI Agents SDK (Python): Human in the loop
4. Claude Agent SDK: Handle approvals and user input
5. Claude Agent SDK: Configure permissions
6. Claude Code docs: Hooks (PreToolUse defer, PermissionRequest)
7. Anthropic Engineering: Claude Code auto mode
8. DevOps.com: Anthropic makes Claude Code auto mode the default
9. EU AI Act, Article 14: Human oversight
10. OpenAI: How we build safety, security and privacy into dots