Die meisten Mittelständler, die ihren ersten agentischen Prozess produktiv schalten, bauen die Freigabe zuletzt ein — als nachträgliche Bremse für den Fall, dass etwas schiefgeht. Das ist die falsche Reihenfolge. Eine Freigabe ist ein Zustand im Ausführungsgraphen mit eigenen Übergängen, eigener Frist und eigenem Fallback, keine Ausnahmebehandlung. Wer sie erst hinterher anflanscht, bekommt entweder einen Agenten, der bei jeder Rückfrage steckenbleibt, oder eine Freigabeschleife, die niemand mehr ernst nimmt.
Auf unserer Orchestrierungs-Seite ist das der am häufigsten falsch verstandene Baustein der ganzen Plattform: Human-in-the-Loop wird als Poll-Schleife implementiert, die auf eine Antwort wartet, statt als sauberer Haltepunkt in der Runtime. Dieser Artikel zeigt, wie man es richtig macht — technisch, organisatorisch und mit einer ehrlichen Grenze, wo eine Freigabe aufhört, etwas wert zu sein.
Kernaussage vorab: Eine Freigabe darf den Lauf nicht abbrechen. Sie muss ihn in einen Wartezustand versetzen, der Stunden bis Tage überdauert, ohne Rechenzeit zu kosten, und der nach der Entscheidung an exakt der Stelle weiterläuft, an der er angehalten hat.
Human-in-the-Loop ist ein Konstruktionsprinzip, kein Sicherheitsnetz
„Ein Mensch schaut noch mal drüber" klingt nach einer Zusatzsicherung, die man später ergänzen kann. In der Praxis ist es das Gegenteil: Die Stelle, an der ein Mensch entscheidet, bestimmt maßgeblich die Architektur des Agenten — welche Daten bis dahin gesammelt sein müssen, welchen Zustand der Lauf hält, welche Rechte der Agent vor und nach der Freigabe hat. Das muss im Graphen von Anfang an als eigener Knoten existieren, nicht als Try-Catch um eine riskante Aktion.
Der Unterschied zeigt sich bei der ersten Störung. Läuft die Freigabe als nachträglicher Zusatz, hängt der ganze Prozess an einem Callback, der bei einem Neustart des Dienstes verschwindet. Ist sie ein modellierter Zustand — vergleichbar mit den Checkpoints, die wir im Artikel zur Durable Execution für KI-Agenten beschreiben — übersteht sie Deployments, Neustarts und mehrtägige Wartezeiten unbeschadet. Genau das ist der Grund, warum Human-in-the-Loop und Durable Execution in der Praxis dasselbe technische Fundament brauchen.
Warum eine Freigabe den Lauf nicht abbrechen darf
Der verbreitetste Baufehler: Der Agent stellt eine Anfrage, wartet in einer Schleife oder einem offenen Prozess auf die Antwort und bricht bei einem Timeout, einem Deployment oder einem Neustart des Servers einfach ab. Der bis dahin erarbeitete Kontext — Retrieval-Ergebnisse, Zwischenentscheidungen, die genaue Begründung, warum diese Aktion überhaupt vorgeschlagen wurde — ist weg. Nach der Freigabe muss der Prozess neu starten, wiederholt Schritte, die schon erledigt waren, und riskiert bei Aktionen mit Seiteneffekten eine doppelte Ausführung.
Richtig gebaut ist die Freigabe ein Wartezustand mit Frist. Der Lauf wird nicht in einem Prozessspeicher gehalten, sondern als Datensatz mit vollständigem Zustand — Schrittzähler, gesammelte Fakten, formulierter Vorschlag — persistiert. Das kostet keine Rechenzeit, während es wartet: Es liegt einfach in einer Warteschlange, bis eine Person entscheidet oder die Frist abläuft. Danach setzt der Lauf exakt an der Stelle fort, an der er angehalten hat, mit demselben Kontext und demselben Idempotenz-Schlüssel für die eigentliche Aktion.
Auf der Runtime-Seite ist dieser Zustand als eigenes Ereignis run.awaiting_approval im Event-Log dokumentiert — technisch nichts anderes als ein Checkpoint mit offenem Ausgang. Wer diesen Mechanismus selbst bauen will, muss mindestens drei Dinge lösen: persistente Zwischenzustände, eine Frist mit Fallback und Idempotenz für die anschließende Aktion. Das ist der Punkt, an dem viele Eigenbau-Projekte scheitern, weil sie den Agenten wie eine synchrone Funktion behandeln statt wie einen langlebigen Prozess.
Wo die Grenze verläuft: vier Kriterien für Freigabepflicht
Nicht jede Aktion braucht eine Freigabe — und eine, die zu viele braucht, verliert ihren Wert (dazu mehr im Abschnitt zu Anti-Mustern). Vier Kriterien haben sich in unseren Projekten als tragfähig erwiesen, um zu entscheiden, was grundsätzlich freigabepflichtig bleibt:
- Betragsgrenze: Jede Aktion mit einem Geldbetrag oberhalb der Kompetenzgrenze, die auch für menschliche Sachbearbeiter gilt — keine separate, laxere Agenten-Schwelle.
- Außenwirkung: Kommunikation, die das Unternehmen nach außen bindet — Verträge, verbindliche Zusagen, öffentliche Antworten, alles, was Dritte als Erklärung des Unternehmens werten.
- Unumkehrbarkeit: Löschungen, endgültige Stornos, das Zurücksetzen von Zugängen — Aktionen, die sich nicht oder nur mit hohem Aufwand rückgängig machen lassen.
- Datenkategorie: Zugriff auf oder Weitergabe von besonders schützenswerten Daten nach Art. 9 DSGVO oder vergleichbar sensiblen Geschäftsgeheimnissen.
Entscheidungshilfe: Trifft mindestens eines der vier Kriterien zu, bleibt die Aktion freigabepflichtig — unabhängig davon, wie sicher sich der Agent ist. Trifft keines zu und liegt die Aktion innerhalb der policy-definierten Grenzen, ist eine Freigabe in der Regel Overhead ohne Sicherheitsgewinn. Details zur technischen Durchsetzung solcher Grenzen stehen auf der Security-Seite unter Policy Engine.
Diese vier Kriterien lassen sich als Regel in der Policy Engine hinterlegen, nicht im Prompt — im Sinne eines Zero-Trust-Grundsatzes: erlaubt ist nur, was explizit freigegeben wurde, nicht, was der Prompt behauptet. Der Agent schlägt vor, die Policy entscheidet, ob eine Freigabe nötig ist — genau wie beim Betragslimit im Beispiel weiter unten. Das verhindert, dass ein manipulierter Kontext oder ein ungeschickt formulierter Prompt eine eigentlich freigabepflichtige Aktion an der Prüfung vorbeischleust.
Freigabe-Ergonomie: entscheidbar in 30 Sekunden
Eine Freigabe-Ansicht, die länger als 30 Sekunden zum Entscheiden braucht, wird entweder ignoriert oder blind bestätigt. Beides ist schlimmer als keine Freigabe. Vier Elemente müssen in der Ansicht stehen, damit eine sachkundige Person tatsächlich prüfen statt nur abnicken kann:
- Begründung: Ein Satz, warum der Agent genau diese Aktion vorschlägt — nicht ein Log-Auszug, sondern eine für Menschen geschriebene Zusammenfassung.
- Beleg: Der Datensatz, das Ticket oder die Rechnung, auf die sich die Begründung stützt, direkt verlinkt oder eingebettet — kein zweiter Systemwechsel zum Nachschlagen.
- Geprüfte Alternative: Was der Agent stattdessen hätte tun können und warum er sich dagegen entschieden hat. Das zeigt, ob wirklich abgewogen wurde oder nur ein Pfad verfolgt wurde.
- Kosten oder Konsequenz: Der konkrete Betrag, die betroffene Anzahl an Datensätzen oder die Reichweite der Aktion in Zahlen — nicht in Adjektiven.
Fehlt eines dieser vier Elemente, verlagert sich die eigentliche Prüfarbeit auf die freigebende Person: Sie muss selbst recherchieren, ob die Begründung stimmt. Das dauert länger als 30 Sekunden, und genau dann beginnt die Alarmmüdigkeit, die im Abschnitt zu den Anti-Mustern beschrieben wird.
Ablauffristen, Eskalation und Vertretung
Eine Freigabe ohne Frist ist ein Prozess, der ewig hängen bleiben kann. In unseren Graphen bekommt jede Freigabe-Kante eine ttl_h — Standardwert 24 Stunden, konfigurierbar je nach Prozess. Läuft die Frist ab, greift ein definierter Fallback, kein manuelles Nachfassen:
- Eskalationsstufe: Nach Ablauf der ersten Frist wandert der Vorgang in eine zweite, meist höher besetzte Warteschlange — etwa von der Sachbearbeitung zur Teamleitung.
- Vertretungsregel: Ist die zuständige Person abwesend, übernimmt eine hinterlegte Vertretung automatisch dieselbe Warteschlange, ohne dass der Agent das wissen oder verwalten muss — das ist Aufgabe des Identity-Systems, nicht des Agenten.
- Harter Fallback: Bleibt auch die Eskalation unbeantwortet, wird die Aktion abgelehnt und der Vorgang mit Begründung geschlossen, statt unbegrenzt offen zu bleiben.
Wichtig dabei: Die Wartezeit selbst kostet in einer sauber gebauten Runtime nichts, weil kein Prozess offengehalten wird — nur ein Datensatz mit Zeitstempel. Das erlaubt großzügige Fristen, ohne dass sich das in der Rechnung niederschlägt. Eine Freigabefrist ist damit organisatorisch vergleichbar mit einer internen SLA-Reaktionszeit — nur dass sie zwischen Mensch und Agent statt zwischen Dienstleister und Kunde gilt. Mehr zur Kostenstruktur je Lauf und je wartendem Zustand steht im Artikel zu den Kosten je erfolgreichem Task.
Drei Anti-Muster, die eine Freigabe wertlos machen
Freigaben scheitern selten an der Technik und fast immer an der Ausgestaltung. Drei Muster sehen wir immer wieder:
Freigabe für alles
Wer aus Vorsicht jede Aktion freigabepflichtig macht, erzeugt Alarmmüdigkeit: Bei zehn Freigaben am Tag wird noch geprüft, bei fünfzig wird durchgeklickt. Die Sorgfalt sinkt mit der Menge, nicht mit der Wichtigkeit. Die Gegenmaßnahme ist keine bessere Oberfläche, sondern eine engere Freigabepflicht nach den vier Kriterien von oben — lieber wenige, aber ernstgemeinte Freigaben als viele reflexhafte.
Freigabe pro forma
Ein Klick auf „Bestätigen", ohne dass die freigebende Person die Begründung tatsächlich liest, ist rechtlich und praktisch keine Freigabe — nur eine verzögerte Automatisierung mit zusätzlichem Log-Eintrag. Das wird besonders bei Art. 22 DSGVO relevant, dazu mehr im nächsten Abschnitt. Wenn Freigaben systematisch in unter fünf Sekunden bestätigt werden, ist das ein verlässliches Signal, dass die Schwelle falsch gesetzt ist oder die Ansicht keine echte Prüfung erlaubt.
Freigabe ohne Protokoll
Wer freigibt, wann, mit welcher Begründung angezeigt und ob die Frist eingehalten wurde — das muss vollständig im Audit-Log stehen, nicht nur „genehmigt: ja/nein". Ohne dieses Protokoll lässt sich im Nachgang weder nachweisen, dass eine Freigabe stattgefunden hat, noch feststellen, ob die Freigabe-Ergonomie überhaupt funktioniert. Wie ein solches Log aufgebaut ist und was hineingehört, beschreibt die Observability-Seite der Plattform.
Bezug zu Art. 22 DSGVO
Art. 22 DSGVO untersagt grundsätzlich vollautomatisierte Entscheidungen mit rechtlicher Wirkung oder ähnlich erheblicher Beeinträchtigung für betroffene Personen, sofern keine der zulässigen Ausnahmen greift. Eine Freigabestufe ist genau der Mechanismus, mit dem viele Unternehmen diese Anforderung praktisch umsetzen — aber nur, wenn sie echte menschliche Beteiligung darstellt: Zugriff auf die relevanten Fakten, tatsächliche Entscheidungsmöglichkeit und keine pro-forma-Bestätigung. Das deckt sich mit den Anforderungen des EU AI Act an „Human Oversight" für Hochrisiko-Anwendungsfälle.
Diese Einordnung ist keine Rechtsberatung im Einzelfall — ob ein konkreter Prozess unter Art. 22 fällt und welche Ausnahme greift, hängt von der jeweiligen Verarbeitung und den betroffenen Personen ab und sollte mit der eigenen Rechtsabteilung oder einem spezialisierten Berater geklärt werden. Eine tiefere Einordnung von KI-Agenten zu EU AI Act und DSGVO liefert der Artikel EU AI Act und DSGVO für KI-Agenten.
Praxisbeispiel: Erstattung 412 € über dem Limit von 250 €
Ein Kunde meldet ein defektes Bauteil und fordert eine Erstattung von 412 Euro. Der Support-Agent aus unserem Anwendungsfall Support-Deflection arbeitet den Vorgang wie folgt ab — die Policy-Grenze für automatische Erstattungen liegt bei 250 Euro:
| Zeit | Schritt | Ausführender |
|---|---|---|
| t + 0:00 | Ticket eingegangen, Triage-Agent klassifiziert als Erstattungsanfrage | Agent |
| t + 0:04 | Retrieval-Agent lädt Bestellung, Zahlungsstatus und Foto des Defekts | Agent |
| t + 0:07 | Policy-Prüfung: 412 € > 250 € Grenze → Freigabe erforderlich | Policy Engine |
| t + 0:08 | Lauf pausiert, Vorschlag mit Begründung, Beleg und Betrag in Warteschlange „Finance" | Runtime (Wartezustand) |
| t + 3:40 Std. | Sachbearbeiterin prüft Foto und Bestellhistorie, bestätigt die Erstattung | Mensch |
| t + 3:41 Std. | Lauf setzt fort, Action-Agent führt Erstattung und CRM-Update aus | Agent |
| t + 3:42 Std. | Audit-Eintrag: Entscheidung, Zeitstempel, Begründung, ausführende Identität | Observability |
Zwischen dem Erkennen der Freigabepflicht (t + 0:07) und der eigentlichen Entscheidung (t + 3:40 Std.) liegt der Wartezustand, der in dieser Zeit keine Rechenkosten erzeugt — der Lauf liegt als Datensatz in der Warteschlange, nicht als offener Prozess im Speicher. Wäre die Frist von 24 Stunden ohne Reaktion verstrichen, hätte der definierte Fallback gegriffen: Eskalation an die Teamleitung. Dasselbe Muster mit Rollback statt Erstattung zeigt der Anwendungsfall Incident Response, wo die Freigabe zwischen Diagnose und Ausführung der Rollback-Maßnahme sitzt.
Vollautomatisch, Freigabe über Schwelle oder Vorschlagsmodus
Nicht jeder Prozessschritt braucht dasselbe Maß an menschlicher Beteiligung. Drei Betriebsarten decken die meisten Fälle ab:
| Betriebsart | Wie es funktioniert | Geeignet für | Risiko |
|---|---|---|---|
| Vollautomatisch | Agent führt Aktion innerhalb der Policy-Grenzen ohne Rückfrage aus | Hohes Volumen, geringer Einzelwert, gut getestete Regeln | Fehler wirken sofort und in der Breite, bis sie auffallen |
| Freigabe über Schwelle | Automatisch bis zur Grenze, darüber Wartezustand mit menschlicher Entscheidung | Prozesse mit seltenen, aber teuren Ausreißern (siehe Praxisbeispiel oben) | Bei zu niedriger Schwelle: Alarmmüdigkeit; bei zu hoher: blinder Fleck |
| Vorschlagsmodus | Agent bereitet jede Aktion vor, Mensch führt sie aktiv selbst aus | Neue, unsichere Prozesse, hohe Fehlerkosten, Lernphase des Teams | Geringster Automatisierungsgewinn, hoher Personalaufwand pro Vorgang |
In der Praxis kombinieren die meisten Prozesse alle drei Formen über die Zeit: Ein neuer Anwendungsfall startet im Vorschlagsmodus, wandert nach ausreichend geprüften Läufen in die Freigabe-über-Schwelle-Stufe und wird für die risikoarmen Fälle darunter irgendwann vollautomatisch — nie aber für die Fälle, die eines der vier Kriterien aus dem Abschnitt zur Grenzziehung erfüllen.
Wann volle Automatisierung ehrlicher ist als eine Alibi-Freigabe
Eine Freigabestufe, die praktisch immer bestätigt wird, ohne dass die freigebende Person eigene Fachkompetenz einbringt, ist keine Kontrolle — sie ist eine Latenzstrafe mit Compliance-Anstrich. Wenn die Bestätigungsquote bei über 98 Prozent liegt und die durchschnittliche Bearbeitungszeit unter fünf Sekunden, ist das ein verlässliches Signal: Entweder ist die Schwelle zu niedrig angesetzt, oder die freigebende Person hat gar keine Möglichkeit, sachlich zu widersprechen.
In diesen Fällen ist es ehrlicher, die Aktion innerhalb eng gefasster Policy-Grenzen vollautomatisch laufen zu lassen — mit engeren Betragsgrenzen als bei der Freigabevariante, dafür ohne die Illusion einer Prüfung, die keine ist — und stattdessen im Nachgang stichprobenartig zu auditieren. Das verlagert die menschliche Aufmerksamkeit von einer Pro-forma-Bestätigung auf eine echte Stichprobenkontrolle, die tatsächlich Fehler findet. Wo genau diese Linie verläuft, unterscheidet sich je Branche und Risikoprofil; eine pauschale Antwort gibt es nicht, nur die in diesem Artikel beschriebenen Kriterien als Ausgangspunkt für die eigene Entscheidung.
Häufige Fragen zu Human-in-the-Loop
Was bedeutet Human-in-the-Loop bei KI-Agenten konkret?
Ein definierter Punkt im Ablauf, an dem der Agent seine Aktion nicht selbst auslöst, sondern einem Menschen zur Entscheidung vorlegt. Technisch ist das ein Wartezustand mit Frist, kein Abbruch — der Lauf existiert als Datensatz weiter und wird nach der Entscheidung an derselben Stelle fortgesetzt.
Warum darf eine Freigabe den Lauf nicht einfach beenden?
Weil dann der gesamte bis dahin erarbeitete Kontext verloren geht — Retrieval-Ergebnisse, Zwischenentscheidungen, Begründungen. Ein Neustart nach der Freigabe würde alles wiederholen, teils mit anderem Ergebnis, und bei Aktionen mit Seiteneffekten im schlimmsten Fall doppelt buchen. Die Runtime muss den Zustand halten, nicht den Prozess.
Ab welchem Betrag sollte eine Aktion freigabepflichtig sein?
Es gibt keine universelle Zahl — die Schwelle ergibt sich aus Ihrer bestehenden Kompetenzordnung für Mitarbeiter, nicht aus einer Agenten-spezifischen Neuerfindung. Üblich sind 150 bis 500 Euro je Einzelvorgang in Support- und Finance-Prozessen (Rechenbeispiel, keine Preisliste). Wichtiger als der genaue Betrag ist, dass die Grenze dieselbe ist wie für einen menschlichen Sachbearbeiter in vergleichbarer Position.
Was gehört zwingend in eine Freigabe-Ansicht?
Vier Elemente: die Begründung des Agenten in einem Satz, der Beleg dafür, die geprüfte Alternative samt Grund für die Ablehnung, und die Kosten oder Konsequenz der Aktion in Zahlen. Fehlt eines davon, braucht der Mensch länger als 30 Sekunden oder klickt ungeprüft durch.
Was ist Alarmmüdigkeit bei Freigaben?
Der Effekt, dass bei zu vielen Freigabeanfragen die Sorgfalt der Prüfung sinkt, bis am Ende reflexhaft bestätigt wird. Er tritt ein, wenn zu viele risikoarme Aktionen zur Freigabe vorgelegt werden, statt nur die wirklich grenzwertigen. Die Gegenmaßnahme ist eine enger gefasste Freigabepflicht, nicht eine bessere Benutzeroberfläche.
Was passiert, wenn niemand innerhalb der Frist entscheidet?
Nach Ablauf der Frist greift ein definierter Fallback — in der Regel Eskalation an eine zweite Warteschlange oder an eine Vertretung. Ein Lauf darf nicht unbegrenzt offen bleiben, weil dann weder die Aktion ausgeführt noch der Vorgang für den Kunden sichtbar abgeschlossen wird.
Ist eine Freigabe automatisch DSGVO-konform, weil ein Mensch entscheidet?
Nicht automatisch. Für Art. 22 DSGVO zählt eine pro forma bestätigte Vorlage nicht als echte menschliche Beteiligung — die Freigabe muss eine reale Entscheidungsmöglichkeit mit Zugriff auf die relevanten Fakten sein. Diese Einschätzung ersetzt keine Rechtsberatung im Einzelfall.
Wann ist volle Automatisierung ehrlicher als eine Freigabestufe?
Wenn die Freigabe ohnehin fast immer bestätigt wird und keine Fachkompetenz einbringt, die der Agent nicht auch hätte — dann ist sie eine Alibi-Stufe, die nur Latenz kostet. Ehrlicher ist dann, den Prozess innerhalb enger Policy-Grenzen vollautomatisch laufen zu lassen und stattdessen stichprobenartig im Nachgang zu prüfen.
Human-in-the-Loop lohnt sich, wenn die Freigabestelle echten Wert stiftet — Fachkompetenz, Haftungsverteilung, regulatorische Anforderung. Als reflexhafte Zusatzsicherung kostet sie nur Zeit, ohne Risiko zu senken. Wer seinen ersten agentischen Prozess mit klar gezogenen Freigabegrenzen, sauberer Ergonomie und einem nachvollziehbaren Systemaufbau startet, spart sich genau die Nacharbeit, die sonst nach dem ersten Vorfall fällig wird.