> Wo Freigabe-Gates in einem KI-Agenten sitzen, wie du Durchwinken vermeidest und wie Interrupt und Resume in LangGraph sowie den OpenAI- und Claude-Agent-SDKs funktionieren.
>
> Web page: https://balazscsorba.com/de/blog/human-in-the-loop-ai-agents · Language: Deutsch · Also available in: [English](https://balazscsorba.com/blog/human-in-the-loop-ai-agents.md) · [Magyar](https://balazscsorba.com/hu/blog/human-in-the-loop-ai-agents.md)
> Author: Balázs Csorba · Published: 2026-10-02 · Keywords: human in the loop AI agents, human in the loop KI-Agent, Mensch im Loop KI, AI agent approval gates, agent approval fatigue, LangGraph interrupt human in the loop, OpenAI Agents SDK needs_approval, Claude Agent SDK canUseTool, AI agent audit trail, risk tiers for AI agent actions

[Blog](https://balazscsorba.com/de/blog)/KI-Agenten

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

Wo Freigabe-Gates in einem KI-Agenten sitzen, wie du Durchwinken vermeidest und wie Interrupt und Resume in LangGraph sowie den OpenAI- und Claude-Agent-SDKs funktionieren.

[Balázs Csorba](https://balazscsorba.com/de/about)·2\. Oktober 2026·13 Min. Lesezeit

-   Human in the loop
-   AI agents
-   Approval gates
-   Agent safety

![Diagramm: Ein Agent schlägt eine Aktion vor, ein Risiko-Gate leitet sie an automatische Ausführung, menschliche Freigabe oder Sperre, und jede Entscheidung landet im Audit-Log.](https://balazscsorba.com/images/blog/human-in-the-loop-ai-agents/cover.webp?v=66ffffa4d3)

## Das Wichtigste in Kürze

-   Gate Aktionen nach Risiko, nicht nach Tool: Reversibilität, Wirkungsradius, Datensensibilität und Sichtbarkeit entscheiden, ob eine Aktion läuft, einen Menschen fragt oder gesperrt wird.
-   Freigabe pro Aktion hält dem Volumen nicht stand. Anthropic berichtet, dass Nutzer 93 Prozent der Claude-Code-Rückfragen bestätigen und dass menschliche Prüfer in einem Experiment nur 13,6 Prozent eines getarnten gefährlichen Befehls erkannten.
-   Interrupt und Resume sind inzwischen Standard: LangGraph interrupt mit Command(resume), needs\_approval und RunState im OpenAI Agents SDK, canUseTool und die PreToolUse-Entscheidung defer im Claude Agent SDK.
-   Eine Freigabe ist nur etwas wert, wenn sie an die exakte Aktion gebunden ist, von einer authentifizierten Person kommt, protokolliert wird und ablaufen kann. Alles andere ist ein Ritual.
-   Always-on-Agenten wie OpenAI dots verschieben den Menschen vom Anfang ans Ende der Kette. Das Design wechselt von häufiger fragen zu besser fragen: mit Regeln, einem Reviewer-Modell und Stichproben-Audits.

Auf dieser Seite

1.  [Warum Freigabe pro Aktion im großen Maßstab scheitert](https://balazscsorba.com/#why-approval-fails)
2.  [Wo die Gates hingehören: Risiko, Reversibilität, Wirkungsradius](https://balazscsorba.com/#where-to-gate)
3.  [Freigabe-UX, die Menschen nicht zum Ja-Klicken erzieht](https://balazscsorba.com/#approval-ux)
4.  [Interrupt und Resume in den wichtigsten Frameworks](https://balazscsorba.com/#interrupt-resume)
5.  [Audit-Trails und Eskalation](https://balazscsorba.com/#audit-escalation)
6.  [Was Always-on-Agenten ändern](https://balazscsorba.com/#always-on-agents)
7.  [Eine Checkliste für deinen nächsten Agenten](https://balazscsorba.com/#checklist)
8.  [Das größere Bild](https://balazscsorba.com/#the-bigger-picture)
9.  [Quellen](https://balazscsorba.com/#sources)

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](https://balazscsorba.com/de/blog/openai-dots-always-on-agents-impact) das Bild verändern. Wenn du zuerst die Mechanik der Schleife selbst willst, beginne mit [der Agent-Schleife erklärt](https://balazscsorba.com/de/blog/agent-loop-explained).

## 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](https://anthropic.com/engineering/claude-code-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](https://devops.com/anthropic-makes-claude-codes-auto-mode-the-default-betting-automation-beats-manual-review/) 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.

Stufe

Typische Aktionen

Kontrolle

Evidenz

**0: beobachten**

Lesen im Agenten-Scope, Suchen, Zusammenfassen, Entwurf in einem Scratch-Bereich

Läuft automatisch, Lesezugriff nach Least Privilege

Log der Aufrufe

**1: reversible Änderung**

Commit auf einen Branch, Entwurf bearbeiten, Ticket anlegen, in einen Staging-Speicher schreiben

Läuft automatisch mit Undo; Reviewer-Modell oder Regeln obendrauf

Log plus Zustand vorher und nachher

**2: sichtbar oder teuer**

E-Mail an einen Kunden, Beitrag in einem geteilten Kanal, Massenänderung innerhalb eines Limits, Ausgabe unter Budget

Menschliche Freigabe mit der echten Wirkung; ähnliche Schritte bündeln

Freigebender, exakter Payload, Zeitstempel

**3: irreversibel oder privilegiert**

Zahlungen, Löschungen, Produktiv-Deployments, Berechtigungsänderungen, Massenexport personenbezogener Daten

Harte Sperre oder verpflichtende Übergabe; zwei Personen in den schlimmsten Fällen; der Agent kann die Stufe nicht senken

Freigebender, Payload, Begründung, zweiter Freigebender

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](https://code.claude.com/docs/en/agent-sdk/permissions).

Die Stufe wird außerhalb des Agenten entschieden. Der Mensch sieht nur die Fälle, die einen Menschen brauchen.

## 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](https://balazscsorba.com/de/blog/ai-generated-pr-review-bottleneck) 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.

Framework

Pause

Resume

Persistenz und Fallstricke

**LangGraph**

`interrupt(payload)` in einem Node aufrufen; der Payload muss JSON-serialisierbar sein

Erneut aufrufen mit `Command(resume=value)` auf demselben `thread_id`; der Wert wird zur Rückgabe von `interrupt`

Braucht einen Checkpointer. Der Node startet von vorn, daher müssen Seiteneffekte vor dem Interrupt idempotent sein. `interrupt` nie in try/except wickeln. Zuordnung per Index, Aufrufreihenfolge stabil halten

**LangChain Agents**

`HumanInTheLoopMiddleware` mit `interrupt_on` pro Tool

`Command(resume={"decisions": [...]})` mit approve, edit, reject (oder respond)

Braucht Checkpointer und `thread_id`; Entscheidungen müssen zur Reihenfolge der pausierten Aktionen passen

**OpenAI Agents SDK**

Ein Tool setzt `needs_approval` (true oder eine async Funktion der Argumente); der Lauf endet mit offenen `interruptions`

`state.approve(item)` oder `state.reject(item, rejection_message=...)`, dann mit dem `RunState` erneut ausführen

Der Zustand serialisiert mit `to_json` und `from_json`. Nur aus vertrauenswürdigem Speicher deserialisieren. `always_approve` macht eine Entscheidung dauerhaft

**Claude Agent SDK**

`canUseTool` feuert für Aufrufe, die kein Hook, keine Regel und kein Modus entschieden hat; für langsame Prüfer kann ein `PreToolUse`\-Hook `defer` zurückgeben

`allow` (optional mit `updatedInput`) oder `deny` mit Nachricht zurückgeben; ein zurückgestellter Aufruf läuft mit `--resume` weiter und der Hook feuert erneut

Automatisch freigegebene Tools erreichen `canUseTool` nie; für Prüfungen, die jeden Aufruf sehen müssen, einen `PreToolUse`\-Hook nutzen. Im Modus `dontAsk` werden Abfragen zu Ablehnungen

Ein paar Details aus der offiziellen Dokumentation solltest du kennen, bevor du darauf aufbaust. Der [Interrupts-Guide](https://docs.langchain.com/oss/python/langgraph/interrupts) 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](https://github.com/openai/openai-agents-python/blob/main/docs/human_in_the_loop.md) 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](https://code.claude.com/docs/en/agent-sdk/user-input) 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](https://balazscsorba.com/de/blog/mcp-server-security-checklist) 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](https://artificialintelligenceact.eu/article/14/), 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](https://balazscsorba.com/de/blog/eu-ai-act-article-50-developer-checklist) 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](https://balazscsorba.com/de/blog/openai-dots-always-on-agents-impact) 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](https://balazscsorba.com/de/blog/prompt-injection-lethal-trifecta-patterns).

**Besser fragen, nicht mehr**

Wenn der Agent rund um die Uhr läuft, ist die Zahl der Fragen ein Preis, den du in menschlicher Aufmerksamkeit zahlst. Verlagere Volumen mit Regeln und einem Reviewer-Modell aus der Warteschlange des Menschen und setze den Menschen für Stufe-2- und Stufe-3-Entscheidungen ein, präsentiert mit ihrer echten Wirkung.

## 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](https://balazscsorba.com/de/expertise/ai-engineer) 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](https://docs.langchain.com/oss/python/langgraph/interrupts)
2.  [LangChain docs: Human-in-the-loop (HumanInTheLoopMiddleware)](https://docs.langchain.com/oss/python/langchain/human-in-the-loop)
3.  [OpenAI Agents SDK (Python): Human in the loop](https://github.com/openai/openai-agents-python/blob/main/docs/human_in_the_loop.md)
4.  [Claude Agent SDK: Handle approvals and user input](https://code.claude.com/docs/en/agent-sdk/user-input)
5.  [Claude Agent SDK: Configure permissions](https://code.claude.com/docs/en/agent-sdk/permissions)
6.  [Claude Code docs: Hooks (PreToolUse defer, PermissionRequest)](https://code.claude.com/docs/en/hooks)
7.  [Anthropic Engineering: Claude Code auto mode](https://anthropic.com/engineering/claude-code-auto-mode)
8.  [DevOps.com: Anthropic makes Claude Code auto mode the default](https://devops.com/anthropic-makes-claude-codes-auto-mode-the-default-betting-automation-beats-manual-review/)
9.  [EU AI Act, Article 14: Human oversight](https://artificialintelligenceact.eu/article/14/)
10.  [OpenAI: How we build safety, security and privacy into dots](https://openai.com/index/how-we-build-safety-security-and-privacy-into-dots/)

## Häufige Fragen

Was bedeutet Human in the Loop bei KI-Agenten?

Eine Person kann an definierten Punkten eingreifen, während ein Agent arbeitet: eine geplante Aktion freigeben oder ändern, eine Frage beantworten oder den Lauf stoppen. Praktisch ist es ein Gate in der Agent-Schleife. Der Agent pausiert, zeigt, was er vorhat, wartet auf eine Entscheidung und macht mit dem Ergebnis weiter.

Welche Agenten-Aktionen sollten eine menschliche Freigabe brauchen?

Aktionen, die schwer rückgängig zu machen sind, Geld, Berechtigungen oder personenbezogene Daten betreffen, deine Organisation verlassen oder viele Datensätze auf einmal ändern. Lesezugriffe im Agenten-Scope und reversible Änderungen in einer Sandbox können meist automatisch laufen, mit Logging.

Wie vermeidet man Approval Fatigue?

Seltener fragen und dafür mehr zeigen. Risikoarme Aktionen automatisch freigeben, zusammengehörige Schritte in einer Entscheidung bündeln, die Wirkung und einen Diff statt eines Tool-Namens zeigen, gefährliche Fälle per Regel statt per Rückfrage sperren und eine Stichprobe der ungefragt gelaufenen Aktionen prüfen.

Wie funktionieren Interrupt und Resume in LangGraph?

Ein Node ruft interrupt mit einem JSON-serialisierbaren Payload auf. LangGraph sichert den Zustand über einen Checkpointer und hält an. Du setzt auf demselben thread\_id mit Command(resume=value) fort, und dieser Wert wird zum Rückgabewert von interrupt. Der Node startet von vorn, deshalb müssen Seiteneffekte vor dem Interrupt idempotent sein.

Wie behandeln das OpenAI- und das Claude-Agent-SDK Tool-Freigaben?

Im OpenAI Agents SDK deklariert ein Tool needs\_approval, der Lauf liefert die offenen Aufrufe als interruptions zurück, und du genehmigst oder lehnst sie auf einem serialisierbaren RunState ab und startest erneut. Im Claude Agent SDK erhält ein canUseTool-Callback jeden Aufruf, den keine Regel und kein Modus entschieden hat, und gibt allow oder deny zurück.

Verlangt der EU AI Act menschliche Aufsicht über KI-Agenten?

Artikel 14 verlangt wirksame menschliche Aufsicht für Hochrisiko-KI-Systeme, einschließlich des Bewusstseins für Automation Bias und der Möglichkeit, einzugreifen oder das System zu stoppen. Ob dein Agent ein Hochrisiko-System ist, hängt vom Anwendungsfall ab. Auch sonst sind dieselben Designprinzipien eine solide Basis.

Geschrieben von Balázs Csorba

Senior Fullstack & AI Engineer in der Steiermark – über 10 Jahre Vue, Nuxt, Node.js und PHP, heute baue ich Werkzeuge für KI-Agenten.

[KI-Entwicklung & MCP-Server →](https://balazscsorba.com/de/expertise/ai-engineer)[Über mich →](https://balazscsorba.com/de/about)

## Weitere Artikel

-   [OpenAI dots: Was Always-on-Agenten verändern werden, und was nicht](https://balazscsorba.com/de/blog/openai-dots-always-on-agents-impact)
-   [Memory für KI-Agenten entwerfen: Ebenen, Schreibregeln, Poisoning und DSGVO](https://balazscsorba.com/de/blog/ai-agent-memory-design)
-   [Multi-Agent-Systeme: wann sie einen Agenten schlagen und wann nicht](https://balazscsorba.com/de/blog/multi-agent-systems-when-worth-it)
-   [Voice Agents bauen: Realtime Speech-to-Speech oder STT, LLM und TTS?](https://balazscsorba.com/de/blog/voice-agents-realtime-latency)

## Klingt nach dem, was du suchst?

Erzähl mir von deinem Projekt oder deiner Stelle – ich freue mich, von dir zu hören.

[Gespräch buchen](mailto:contact@balazscsorba.com) [Auf LinkedIn vernetzen](https://www.linkedin.com/in/balazs-csorba)