Einer unserer Kunden — ein Fertigungsunternehmen mit einem mittelgroßen ERP-System — hatte einen AI-Agenten für die Auftragsverarbeitung im Einsatz. Die ersten drei Wochen liefen reibungslos: Der Agent bündelte Anfragen, prüfte die Verfügbarkeit und erstellte Vorschläge. Dann kam ein Fall, der in den Trainingsdaten nicht vorhanden war — ein Kunde mit einer unüblichen Zahlungsbedingung. Der Agent schätzte die Situation als Standard ein und bestätigte die Bestellung. Ohne Genehmigung. Ohne Eskalation. Mit falschen Konditionen.
Dem Agenten kam es nicht in den Sinn, innezuhalten und nachzufragen. Er hatte dafür keine Regeln.
Das ist kein Argument gegen AI-Agenten. Es ist ein Argument für ein durchdachtes Human-in-the-Loop (HITL)-Design — einen Satz von Regeln, der festlegt, wann der Agent selbstständig handelt und wann er auf einen Menschen wartet. Dieser Artikel ist ein Entscheidungsrahmen für die Praxis: wo die Grenze zu ziehen ist, wie ein Approval Flow technisch zu implementieren ist und wie die Autonomie des Agenten schrittweise und sicher ausgebaut werden kann.
Warum HITL kein bloßes „Sicherheitspflaster" ist
Der häufigste Fehler beim Agenten-Design: HITL wird nachträglich als Filter hinzugefügt. Die Ausgabe des Agenten — eine Entscheidung, eine Aktion, ein Dokument — durchläuft ein Genehmigungsfenster, und wenn der Mensch auf „OK" klickt, läuft es weiter.
Dieser Ansatz behandelt nur das Symptom. Man sieht nicht, was der Agent vorher getan hat. Man weiß nicht, ob die Entscheidung logisch aus richtigen Schritten folgte oder ob der Agent auf falschem Weg zum richtigen Ergebnis gelangt ist. Und wenn etwas schiefgeht, ist der Audit-Trail leer.
Korrektes HITL ist ein architektonisches Muster, kein Add-on. Es wird vor dem Einsatz definiert, nicht nach dem ersten Vorfall. Es umfasst:
- Klassifizierung der Aktionen nach Risikograd und Irreversibilität
- Explizite Interrupt-Punkte im Agenten-Graphen — nicht nur am Ausgang, sondern direkt im Entscheidungsfluss
- Audit-Trail jedes Schritts: was der Agent gesehen hat, was er entschieden hat, wer genehmigt hat
Der EU AI Act fordert in Artikel 14 Human Oversight für Hochrisiko-KI-Systeme ab dem 2. August 2026. Wenn Ihr System in diese Kategorie fällt — automatisierte Entscheidungen in arbeitsrechtlichen Angelegenheiten, Kredit-Scoring, Steuerung kritischer Infrastruktur — ist HITL keine Empfehlung. Es ist eine Pflicht.
Aktionen, die immer eine Genehmigung erfordern
Nicht jede Agentenaktion ist gleich riskant. Das entscheidende Kriterium ist Irreversibilität: Können Sie die Aktion rückgängig machen? Wenn nicht, ist eine Genehmigung zwingend erforderlich.
Das zweite Kriterium ist der Wirkungsumfang: Wen betrifft die Aktion, wie viel Geld oder Daten stehen auf dem Spiel, wie hoch ist die regulatorische Exposition?
Aktionen, bei denen wir grundsätzlich empfehlen, innezuhalten und eine Genehmigung einzuholen:
- Finanztransaktionen — Zahlungsversand, Rechnungsstellung, Preislistenänderung, Lieferantenbestellung über ein definiertes Limit
- Irreversible Datenoperationen — Löschen von Datensätzen, Backup vor dem Überschreiben, Export in ein externes System
- Externe Kommunikation im Namen des Unternehmens — E-Mail an Kunden, Antwort auf eine Beschwerde, Rechtsdokument
- Änderungen in Drittsystemen — Schreibzugriff auf ERP, CRM, SCADA; Änderung von Produktionskonfigurationen
- Eskalationsentscheidungen mit rechtlicher Exposition — Reklamationsablehnung, Vertragsbeendigung, Akzeptanz einer Verpflichtung
In der Praxis erleben wir, dass Unternehmen diese Kategorien anfangs unterschätzen. Solange der Agent nur in einer internen Sandbox arbeitet, sieht alles sicher aus. Die Probleme kommen in dem Moment, in dem der Agent Zugriff auf Produktions-Tools erhält.
Human-on-the-Loop vs. Human-in-the-Loop
Eine wichtige Unterscheidung, die das gesamte Design beeinflusst:
Human-in-the-Loop (HITL) — der Agent hält an und *wartet* auf eine Genehmigung, bevor er eine Aktion ausführt. Der Fluss ist blockiert. Die Reaktionszeit hängt von der Verfügbarkeit des Operators ab. Geeignet für irreversible oder Hochrisiko-Aktionen.
Human-on-the-Loop (HOTL) — der Agent handelt autonom, protokolliert aber jeden Schritt, und der Operator kann asynchron eingreifen. Der Fluss ist nicht blockiert. Geeignet für Aktionen, die leicht reversibel sind oder geringe Auswirkungen haben.
Die meisten Produktivsysteme benötigen beide Modi. Ein einfacher Entscheidungsbaum:
- 1.Ist die Aktion irreversibel? → HITL zwingend
- 2.Liegt der finanzielle Auswirkung über dem Limit (z. B. 1.000 EUR)? → HITL zwingend
- 3.Besteht regulatorische Exposition (DSGVO, Vertrag, Haftung)? → HITL zwingend
- 4.Ist die Aktion routinemäßig und reversibel? → HOTL genügt
Dies ist keine einmalige Entscheidung. Die Limits verändern sich, während der Agent Verlauf und Vertrauen aufbaut.
Technische Implementierung: LangGraph interrupt()
Die sauberste technische HITL-Implementierung für Stateful-Agenten erfolgt über LangGraph und seinen interrupt()-Mechanismus. Das Prinzip ist einfach: Im Agenten-Graphen definieren Sie Knoten, an denen der Fluss pausiert und auf externe Eingabe wartet — Genehmigung, Korrektur, Ablehnung.
Grundlegendes Muster:
- Der Agent verarbeitet die Eingabe und entscheidet, welche Aktion er ausführen möchte
- Vor der Ausführung erreicht er den Interrupt-Knoten: speichert den aktuellen Zustand (Checkpointing), generiert eine Beschreibung der vorgeschlagenen Aktion für den Operator und wartet
- Der Operator erhält eine Benachrichtigung (E-Mail, Slack, integriertes UI-Panel)
- Bei Genehmigung wird der Fluss genau vom Checkpoint aus fortgesetzt — der Agent erinnert sich an den gesamten Kontext, nicht nur an die letzte Nachricht
- Bei Ablehnung oder Anpassung erhält der Agent Feedback und kann neu planen
Entscheidende Eigenschaft des LangGraph-Checkpointings: Der Agentenzustand wird in einen persistenten Speicher serialisiert. Die Genehmigung kann nach einer Stunde oder am nächsten Tag eintreffen — der Agent „erwacht" mit vollem Kontext. Das ist ein grundlegender Unterschied zum naiven Ansatz, bei dem Sie den Interrupt selbst über eine Datenbank und Redis implementieren müssten.
Für einen verlässlichen Audit-Trail erfasst jeder Interrupt-Knoten: Agenten-Identifier, Zeitstempel, vorgeschlagene Aktion, Tool-Argumente — und später auch die Entscheidung des Operators sowie die Begründung.
Mehr darüber, wie Agenten-Architekturen in der Praxis aussehen, beschreiben wir im Artikel AI-Agenten-Architekturen: ReAct, Plan-and-Execute — wann welche.
Gestaltung des Approval Flows
Ein guter Approval Flow hat drei Eigenschaften: Kontextualität (der Operator sieht, *warum* der Agent diese Aktion vorschlägt, nicht nur *welche*), Reaktionsgeschwindigkeit (je länger der Agent wartet, desto mehr stauen sich blockierte Aufgaben) und Eskalation (reagiert der Operator nicht innerhalb einer definierten Zeit, wird die Aufgabe eskaliert oder sicher beendet).
Empfohlene Benachrichtigungsstruktur für den Operator:
- Kontext: Worauf die Entscheidung basiert — ursprüngliche Anfrage, relevante Daten, Schritte vor der Aktion
- Vorgeschlagene Aktion: Was der Agent genau tun möchte, einschließlich der Argumente (z. B. „500 Stk. SKU-4421 bei Lieferant X zum Preis Y bestellen")
- Begründung: Warum der Agent zu dieser Entscheidung gelangt ist
- Alternativen: Wenn der Agent mehrere Optionen erwogen hat, diese anzeigen (hilft dem Operator bei der Korrektur)
- Aktionen: Genehmigen / Ablehnen / Anpassen mit Kommentar / Eskalieren
Das ist kein reines UX-Detail. Ein Operator, der nur „Aktion bestätigen?" sieht, genehmigt meist reflexartig. Ein Operator, der den gesamten Kontext sieht, trifft eine informierte Entscheidung — und baut zugleich ein Gespür dafür auf, wo der Agent Fehler macht.
Das Thema Sicherheit und Guardrails bei Agenten behandeln wir ausführlicher im Artikel Guardrails für AI-Agenten.
Vertrauen vs. Geschwindigkeit: der zentrale Trade-off
HITL hat seinen Preis. Jeder Interrupt-Punkt erhöht die Latenz — das Warten auf eine menschliche Reaktion kann Minuten oder Stunden dauern. Hat ein Agent zehn Schritte und jeder wartet auf eine Genehmigung, ist das System kein Agent mehr. Es ist ein Formular-Workflow mit KI-Fassade.
Deshalb ist Vertrauen in einen Agenten eine skalierbare Variable, keine binäre Entscheidung.
Ein praktischer Rahmen für die schrittweise Freigabe von Autonomie:
Phase 1 — Shadow Mode (Schattenbetrieb): Der Agent schlägt Aktionen vor, aber ein Mensch führt sie immer aus. Es werden Daten gesammelt: Wie oft hatte der Agent recht, wo lag er falsch, welcher Kontext lag bei Fehlern vor? Dauer: 2–4 Wochen oder 100–200 Aktionen.
Phase 2 — Selektive Autonomie: Auf Basis der Daten aus Phase 1 werden Aktionskategorien definiert, in denen der Agent eine Genauigkeit von > 95 % erreichte — diese werden in den HOTL-Modus überführt. Weiterhin wird überwacht. Hochrisiko-Kategorien bleiben bei HITL.
Phase 3 — Begrenzte Autonomie mit Limits: Autonomie in Niedrigrisiko-Kategorien mit expliziten Limits (z. B. Bestellungen bis 500 EUR ohne Genehmigung). Jedes Limit hat eine Begründung und ein Überprüfungsdatum.
Phase 4 — Adaptive Autonomie: Das System überwacht die Leistung in Echtzeit. Steigt die Fehlerrate über einen Schwellenwert, wechselt es automatisch in einen restriktiveren Modus zurück. Bleibt sie niedrig, kann das Limit erweitert werden.
Das ist kein einmaliges Projekt. Es ist ein kontinuierlicher Prozess der Vertrauenskalibrierung — ähnlich wie bei der Einarbeitung eines neuen Mitarbeiters.
Die Frage der Kosten und der Investitionsrendite aus Agentenperspektive behandeln wir in Kosten eines AI-Agenten im Produktivbetrieb.
Was HITL nicht löst: die Grenzen des Ansatzes
HITL ist notwendig, aber nicht hinreichend. Einige Dinge, die ein Genehmigungsflow allein nicht löst:
Prompt Injection — Ein Angreifer schleust Anweisungen in die Eingabe des Agenten ein (zum Beispiel in ein zu verarbeitendes Dokument), die der Agent ausführt, ohne dass dies im Genehmigungsfenster sichtbar wird. Der Operator sieht eine „normale" Aktion, hinter der ein manipulierter Fluss steckt. OWASP LLM Top 10 führt Prompt Injection als Nummer eins im Produktivbetrieb.
Zu breiter Tool-Scope — Hat der Agent Zugriff auf ein zu breites Tool-Set, schützt HITL nur bei explizit markierten Aktionen. Aktionen außerhalb des explizit überwachten Bereichs können unter dem Radar laufen. Lösung: Prinzip der minimalen Berechtigungen für jedes Tool.
Genehmigungsgeschwindigkeit als Engpass — Wenn ein Operator täglich Dutzende von Anfragen genehmigt, sinkt die Qualität seiner Entscheidungen. Routineanfragen werden reflexartig genehmigt, echte Anomalien passieren unbemerkt. HITL muss durch Triage ergänzt werden: Nicht jede Genehmigung ist gleich wichtig.
Agent Drift — Die Leistung des Agenten verändert sich im Laufe der Zeit, wenn sich die Daten oder der Prompt-Kontext ändern. Eine Aktion, die vor sechs Monaten sicher autonom war, kann heute riskant sein. Deshalb sind Überprüfungsdaten für Limits eine Pflicht, keine Empfehlung.
Observability des Agenten — Überwachung von Traces, Fehlerrate und Latenzen in Echtzeit — ist Voraussetzung für ein funktionsfähiges HITL. Ohne sie merkt man nicht, wann Drift eintritt. Über Tools zur Agenten-Überwachung schreiben wir in Observability für AI-Agenten.
Praktische Empfehlungen für den Einsatz
Aus der Erfahrung aus Dutzenden von Projekten:
- 1.Beginnen Sie mit vollständigem HITL für alle Aktionen. Nicht aus Vorsicht, sondern um Daten zu sammeln. Ohne Verlauf können keine informierten Entscheidungen darüber getroffen werden, wo Autonomie freigegeben werden soll.
- 2.Kategorisieren Sie Aktionen explizit. Die Liste der Kategorien mit definiertem Risikograd und Limit lassen Sie vom Prozesseigentümer genehmigen — nicht nur vom IT-Team.
- 3.Protokollieren Sie alles, nicht nur Vorfälle. Routinemäßige Genehmigungen sind für die Trendanalyse genauso wichtig wie Ablehnungen.
- 4.Richten Sie automatische Eskalation ein. Wenn der Operator nicht innerhalb von X Minuten reagiert, wird die Aufgabe an einen Stellvertreter eskaliert oder sicher mit einer Benachrichtigung beendet. Ein wartender Agent darf einen Produktionsprozess niemals blockieren.
- 5.Testen Sie fehlerhafte Eingaben. Simulieren Sie Eingaben, bei denen der Agent eine problematische Aktion ausführen könnte. Prüfen Sie, ob der Interrupt korrekt funktioniert.
- 6.Überprüfungszyklus alle 3 Monate. Gehen Sie die Genehmigungsstatistiken durch. Wo die Fehlerrate niedrig und die Historie gut ist — erwägen Sie eine Ausweitung der Autonomie. Wo Überraschungen auftreten — verschärfen Sie die Regeln.
Häufige Fragen
Benötigen wir HITL auch für einen internen Chatbot, der nur Fragen beantwortet?
Wenn der Agent nur liest und antwortet — keine Tools mit Schreibzugriff, keine Aktionen nach außen — ist HITL nicht erforderlich. HOTL genügt: Sie überwachen die Ausgaben, richten Content-Guardrails ein und behalten die Möglichkeit einzugreifen. HITL ist relevant, wenn der Agent *handelt*, nicht nur *antwortet*.
Wie verhindert man, dass Operatoren ohne Nachdenken genehmigen?
Zwei bewährte Techniken: Erstens, zeigen Sie den vollständigen Kontext an (warum der Agent die Aktion vorschlägt), nicht nur die Aktion selbst. Zweitens, verlangen Sie bei kritischen Kategorien vom Operator eine kurze Begründung der Genehmigung — mindestens einen Satz. Eine Pflichtbegründung reduziert reflexartiges Genehmigen drastisch.
Kann HITL dazu führen, dass der Agent für den Produktivbetrieb zu langsam ist?
Ja, wenn es schlecht gestaltet ist. Der Schlüssel ist Selektivität: HITL nur für wirklich Hochrisiko-Aktionen, alles andere auf HOTL. In der Praxis macht die Kategorie der wirklich kritischen Aktionen 5–15 % des Gesamtvolumens bei einem typischen Unternehmensagenten aus — der Rest kann autonom mit Monitoring laufen.
Was passiert, wenn der Agent mitten in einer langen Aufgabe eine Genehmigung braucht — verliert er den Kontext?
Genau deshalb ist LangGraph-Checkpointing wichtig. Der Agent serialisiert den Zustand bei jedem Interrupt-Punkt. Kommt die Genehmigung nach einer Stunde oder sogar nach einem Tag, setzt der Agent den Fluss genau von diesem Punkt aus fort — ohne Kontextverlust. Ohne Checkpointing müsste die gesamte Aufgabe neu gestartet werden.
Wie hängt HITL mit dem EU AI Act zusammen?
Artikel 14 des EU AI Act fordert Human Oversight für Hochrisiko-KI-Systeme. Ab dem 2. August 2026 gilt diese Pflicht für Systeme in Bereichen wie Beschäftigung, Bildung, kritische Infrastruktur, Verwaltung des Zugangs zu Grundversorgungsleistungen und weitere. Wenn Ihr Agent in eine dieser Kategorien fällt, ist HITL keine Wahl — es ist eine gesetzliche Anforderung, die Sie auch im Audit nachweisen können müssen.
*Einen HITL-Flow für einen konkreten Agenten zu entwerfen und zu konfigurieren ist kein wochenlanger Projektauftrag — es ist eine architektonische Entscheidung, die den gesamten Lebenszyklus des Systems beeinflusst. Bei MP Industrial Solutions helfen wir Unternehmen, genau abzustecken, wo die Grenze zwischen Autonomie und Aufsicht liegt, einen Approval Flow entsprechend ihrem regulatorischen Umfeld einzurichten und das Vertrauen in die Agentenleistung schrittweise aufzubauen. Wenn Sie einen Einsatz planen oder bereits einen Agenten ohne durchdachtes HITL-Design betreiben — melden Sie sich für eine Beratung.*