HITL: Wo KI-Agenten menschliche Freigaben brauchen

Wenn ein Fehler teuer wäre oder sich nur schwer rückgängig machen ließe, gehört vor die KI-Aktion eine menschliche Entscheidung. Human in the Loop (HITL) bietet dafür 3 Ansatzpunkte: Freigabe vor der Ausführung, Stichprobenkontrolle abgeschlossener Arbeit oder Übernahme bei einer Eskalation. Welche Form passt, entscheidet sich für jede Aktion einzeln. Routinemäßige Freigaben sollten erst dann entfallen, wenn belastbare Erkenntnisse genau diesen Schritt rechtfertigen.

Was bedeutet HITL bei KI-Systemen?

Menschliche Kontrolle ist eine Frage der Befugnisse: Welche Aktionen darf das System ausführen, ohne vorher die Zustimmung eines Menschen einzuholen? Ein Supportagent kann im selben Gespräch eine Bestellung abrufen, eine Antwort entwerfen, einen Datensatz ändern und eine Erstattung auslösen. Für diese Aktionen sind unterschiedliche Berechtigungen nötig.

Ein Garten mit einem besetzten Eingangstor veranschaulicht das Prinzip. Die Gärtnerin kontrolliert nicht jeden Schritt. Sie regelt den Zugang dort, wo Schäden schwer zu beheben wären, prüft Routinearbeiten im Nachhinein und reagiert auf die Klingel, wenn etwas Ungewöhnliches passiert. Entscheidend ist, an welcher Stelle das Tor steht.

Was heißt Human in the Loop?

Human in the Loop, meist mit HITL abgekürzt, bedeutet, dass Menschen durch Rückmeldungen, Eingriffe oder Entscheidungen am Betrieb eines KI-Systems beteiligt sind. Diese breite Definition umfasst mehr als eine Freigabeschaltfläche. Im Unternehmensalltag sollte dahinter eine konkrete Verantwortung stehen: Jemand genehmigt eine vorgeschlagene Aktion, prüft erledigte Arbeit oder klärt einen Ausnahmefall. Die Definition von Stanford HAI.

Der Begriff umfasst auch das Annotieren von Trainingsdaten, das Korrigieren von Modellausgaben und die Begleitung des Lernprozesses durch Menschen. Das sind berechtigte Verwendungen. Wer heute eine Erstattung freigibt, trainiert damit aber nicht automatisch das Modell von morgen nach. Die Kontrolle im laufenden Betrieb liefert Erkenntnisse; um ein Modell oder einen Workflow zu verbessern, braucht es einen eigenen, gezielten Prozess. Die Erläuterung von Google Cloud.

Wie funktioniert Human in the Loop bei KI-Agenten?

Ein KI-Agent ist Software, die mithilfe eines Modells Arbeitsschritte auswählt und Tools aufruft, etwa um eine Bestellung abzurufen oder eine Nachricht zu versenden. Die menschliche Prüfung gehört unmittelbar vor den Toolaufruf mit weitreichenden Folgen. Eine Freigabe des anfänglichen Plans sagt noch nichts darüber aus, welchen Empfänger, Betrag oder Datensatz der Agent später auswählt.

Auch die Koordination dieser Schritte braucht klare Regeln. Der Beitrag zur Orchestrierung von KI-Agenten erklärt, wie gespeicherte Zustände, Zuständigkeiten und Übergaben die Arbeit eines Agenten begleiten.

An welchen Stellen Menschen eingreifen können

Eine Freigabe soll eine bestimmte Aktion verhindern können, eine Stichprobe soll Muster in abgeschlossener Arbeit aufdecken, und eine Eskalation soll Fälle außerhalb der Befugnisse des Agenten klären. Diese Kontrollformen lassen sich im selben Workflow kombinieren.

Vor der Aktion: Freigabe

Das System bereitet eine exakt beschriebene Aktion vor und wartet. Die prüfende Person sieht den Empfänger oder Datensatz, die geplante Änderung, die relevanten Belege und die Regel, die die Prüfung ausgelöst hat. Eine Freigabe erlaubt genau diese Aktion; eine Ablehnung verhindert sie.

Das eignet sich etwa für Erstattungen, sensible Kundenantworten oder unwiderrufliche Löschungen. Eine Prüfmaske mit der bloßen Frage „Support-Tool erlauben?“ verdeckt die eigentliche geschäftliche Entscheidung. „Diese Bestellung aus diesem Grund über die ursprüngliche Zahlungsart erstatten“ liefert dagegen eine konkrete Grundlage für die Prüfung.

Nach der Aktion: Stichprobenkontrolle

Das System handelt innerhalb bereits genehmigter Grenzen. Anschließend prüft ein Mensch ausgewählte Ergebnisse. Das passt zu Aktionen mit geringen Auswirkungen, deren gelegentliche Fehler sich erkennen und tolerieren lassen, etwa die Kategorisierung von Tickets oder interne Zusammenfassungen.

Eine Stichprobe kann den darin entdeckten Fehler nicht verhindern. Bei einer Kundennachricht lässt sich das Gespräch durch eine Richtigstellung vielleicht wieder in Ordnung bringen. Die ursprüngliche Nachricht hat der Kunde trotzdem gelesen. Dieser verbleibende Schaden gehört in die Entscheidung, ob eine Aktion automatisiert werden soll.

Eine Zufallsstichprobe zeigt die Qualität der Routinearbeit; eine separate, gezielte Stichprobe erfasst ungewöhnliche Fälle. Wer ausschließlich Beschwerden prüft, erfährt etwas über gemeldete Fehler, aber nicht über die Qualität der gesamten erledigten Arbeit.

Bei einer Eskalation: Übergabe

Bei einer Eskalation wird ein Fall übergeben, weil dem Agenten Belege, eine Berechtigung oder eine anwendbare Regel fehlen. Das kann bei widersprüchlichen Angaben zur Kontoinhaberschaft, fehlenden Bestelldaten, einer Ausnahme von den Richtlinien oder dem ausdrücklichen Wunsch nach einem menschlichen Ansprechpartner nötig sein.

Die übernehmende Person braucht die Belege, die bereits versuchten Aktionen, die offene Frage und den aktuellen Stand. Die Aktion, die eine Abwägung verlangt, bleibt angehalten. Andere ausdrücklich unbedenkliche Arbeiten, etwa eine interne Zusammenfassung, können weiterlaufen, sofern die Richtlinie das erlaubt.

Was bedeutet Human over the Loop?

Der Ausdruck Human over the Loop lässt sich, wenn er begegnet, der übergeordneten Steuerung zuordnen: Ein Mensch legt Regeln fest, ändert Berechtigungen und kann das System stoppen. Die Begriffe werden unterschiedlich verwendet. Deshalb sollte die Verantwortung ausdrücklich beschrieben werden, statt sich auf das Schlagwort zu verlassen. Eine Führungskraft, die die Leistung überwacht, prüft damit noch nicht zwangsläufig einzelne Vorgänge.

Aus demselben Grund ist zwischen einer Freigabe in the loop und einer Überwachung on the loop zu unterscheiden. Ein Dashboard kann ein Problem schnell sichtbar machen. Eine Pause vor der nächsten Aktion entsteht dadurch erst, wenn sie ausdrücklich implementiert wurde.

Entscheidend sind die Folgen eines Fehlers und seine Umkehrbarkeit

Eine Freigabe ist nötig, wenn der plausible Schaden größer ist als das, was bis zur Erkennung und Behebung hingenommen werden kann. Die Konfidenz des Modells allein beantwortet diese Frage nicht.

Jede Aktion sollte unter diesen Gesichtspunkten bewertet werden:

• Folgen: Könnte sie vertrauliche Informationen offenlegen, Geld bewegen, eine Verpflichtung eingehen oder den Kontozugriff beeinflussen?
• Wiederherstellung: Lässt sich der vorherige Zustand vollständig und schnell wiederherstellen, ohne dass ein Kunde bei der Fehlerbehebung mithelfen muss?
• Reichweite: Betrifft die Aktion einen internen Entwurf, einen Kunden oder eine ganze Gruppe von Datensätzen?
• Beleglage: Sind Identität, Quelldaten und Richtlinie hinreichend geklärt, um entscheiden zu können?
• Fehlererkennung: Wird ein Fehler bemerkt, bevor sich weitere gleichartige Aktionen häufen?

Auch ein rücksetzbares Datenbankfeld kann ein unumkehrbares Folgeereignis auslösen. Eine geänderte Lieferadresse lässt sich möglicherweise problemlos zurückändern, bis die Auftragsabwicklung beginnt. Maßgeblich sind die gesamten Folgen, nicht nur eine Rückgängig-Funktion in der Datenbank.

Stichproben passen zu klar begrenzten Aktionen, wenn die Belege zuverlässig und die verbleibenden Schäden akzeptabel sind. Eine vorherige Freigabe ist sinnvoll, wenn die Aktion weitreichende Folgen hat oder die Wiederherstellung schwierig ist. Fehlt eine erforderliche Information oder Regel, ist eine Eskalation nötig. Verbotene Aktionen müssen blockiert werden; eine Freigabewarteschlange darf nicht zum Umweg um die Richtlinie werden.

KI-Guardrails, also automatisierte Prüfungen von Eingaben, Ausgaben und Toolaufrufen, unterstützen diesen Aufbau. Sie können eine fehlerhaft aufgebaute Anfrage oder ein unzulässiges Ziel abweisen, bevor ein Mensch Zeit in die Prüfung investiert. Menschliches Urteilsvermögen sollte sich mit den berechtigten Zweifelsfällen befassen, die danach übrig bleiben.

Human in the Loop in der Praxis: ein Supportagent

Die Befugnisse des Supportagenten sollten nach Aktionsart getrennt werden. Die folgende Tabelle zeigt eine hypothetische Ausgangsrichtlinie für ein Unternehmen, das einen Agenten im Bestellsupport einführt. Sie ist ein Gestaltungsbeispiel, keine Voreinstellung eines Anbieters und kein Bericht über gemessene Ergebnisse.

Angenommen, ein Kunde meldet eine nicht angekommene Bestellung und verlangt eine Erstattung. Der Agent darf die Bestellung und den Versandstatus abrufen und daraus eine Empfehlung vorbereiten. Widersprechen die Zustellbelege der Darstellung des Kunden, eskaliert er die Entscheidung, statt eine Lösung zu erfinden.

Stützen die Belege eine Erstattung nach der geltenden Richtlinie, legt der Agent die genaue Bestellung, den Betrag, das Zahlungsziel und die Begründung zur Freigabe vor. Die ausführende Komponente prüft die Freigabe und den aktuellen Erstattungsstatus, bevor sie das Zahlungssystem aufruft. Den zurückgegebenen Transaktionsbeleg protokolliert sie. Erst danach darf der Agent behaupten, die Erstattung sei erfolgreich gewesen.

Die Freigabe einer Erstattung und die Freigabe einer Antwort sind getrennte Berechtigungen. Eine genehmigte Zahlung erlaubt kein erfundenes Lieferversprechen in der begleitenden E-Mail. Umgekehrt erlaubt eine freigegebene, beruhigende Nachricht keine Erstattung, die im nächsten Toolaufruf versteckt ist.

Für ausgehende Vertriebs-E-Mails gilt dieselbe Trennung: Texte können automatisch entstehen, während der Versand an eine neue Empfängerliste geprüft werden muss. Bei Datenänderungen zählt der tatsächliche Unterschied zwischen altem und vorgeschlagenem Wert, nicht eine Zusammenfassung wie „Datensätze bereinigt“.

So wird die Freigabewarteschlange praktikabel

Wer prüft, braucht eine vollständige Entscheidungsgrundlage, eine Frist und die Befugnis, Nein zu sagen. Eine Freigabeschaltfläche in einem Chatkanal löst lediglich die Benachrichtigung.

Die Vorlage sollte die exakte Aktion, den betroffenen Kunden oder Datensatz, die vorgesehenen Argumente, die Quellenbelege, die zutreffende Richtlinienregel und ungeklärte Sachverhalte zeigen. Bei einer Änderung gehört der bisherige Wert direkt neben den vorgeschlagenen. Links zu den zugrunde liegenden Belegen ermöglichen es, die Erklärung des Agenten zu überprüfen, ohne das ganze Gespräch rekonstruieren zu müssen.

Es braucht eine primär zuständige Person und eine Vertretung. Dringende Eskalationen sollten von routinemäßigen Freigaben getrennt werden. Läuft die Prüffrist ab, wird die ausstehende Aktion angehalten oder abgebrochen und die Vertretung benachrichtigt. Schweigen darf nicht als Zustimmung gelten.

Die verfügbare Kapazität setzt eine harte Grenze. Für eine hypothetische Warteschlange gilt: 24 Anfragen pro Stunde × 3 Minuten Prüfzeit = 72 Prüfminuten pro Stunde. Einer einzelnen prüfenden Person stehen nur 60 Minuten zur Verfügung, noch bevor andere Aufgaben berücksichtigt sind. Die Warteschlange wächst also selbst dann, wenn jede Entscheidung richtig ist. Bevor eine Antwortzeit zugesagt wird, müssen unnötige Freigaben entfallen, die Befugnisse des Agenten enger gefasst oder zusätzliche Prüfkapazitäten geschaffen werden.

Die Freigabe muss an das exakt geprüfte Arbeitsergebnis und seine Argumente gebunden sein. Ändern sich Empfänger, Erstattungsbetrag, Datensatzversion oder Nachricht, wird die Entscheidung ungültig und eine erneute Prüfung nötig. Unmittelbar vor der Ausführung sind Tatsachen erneut zu prüfen, die sich während der Wartezeit geändert haben könnten, etwa ob jemand anderes die Bestellung inzwischen bereits erstattet hat.

Auch der doppelte Eingang einer Prüfentscheidung muss sicher verarbeitet werden. Dafür braucht es eine stabile Aktionskennung, eine nur einmal verwertbare Entscheidung und einen Schutz vor doppelten externen Schreibvorgängen. Idempotent heißt eine Aktion, wenn ihre wiederholte Ausführung dieselbe Wirkung hat wie die einmalige. Läuft eine Erstattungsanfrage in eine Zeitüberschreitung, muss ihr Status geklärt werden, bevor eine weitere Zahlung versucht wird.

Wie aktuelle Tools KI-Agenten für menschliche Entscheidungen anhalten

Die Tools bieten unterschiedliche Mechanismen zum Pausieren; die Entscheidungsregeln muss das Unternehmen selbst festlegen. Die folgenden Beschreibungen wurden am 21. Oktober 2026 anhand der aktuellen Herstellerdokumentation überprüft. Sie geben das dokumentierte Verhalten wieder und beruhen nicht auf eigenen Produkttests.

OpenAI Agents SDK: ausstehende Toolaufrufe freigeben

OpenAI Agents SDK ist eine Bibliothek, mit der sich Agenten im Anwendungscode entwickeln lassen. Sie unterstützt Toolfreigaben über needs_approval=True in Python beziehungsweise needsApproval: true in JavaScript. Ein freigabepflichtiger Aufruf liefert eine Unterbrechung und einen Zustand, mit dem der Lauf fortgesetzt werden kann. Die Anwendung genehmigt den ausstehenden Aufruf oder lehnt ihn ab und setzt anschließend denselben Lauf fort. Für eine spätere Entscheidung lässt sich der Zustand serialisieren. Die Freigabedokumentation von OpenAI.

In einer Supportanwendung gehört die Freigabe vor das Erstattungs- oder Versandtool. Die Prüfoberfläche muss die ausstehende Aktion abbilden. Das kurze Beispiel in der Dokumentation genehmigt die zurückgegebenen Unterbrechungen im Code. Wer diese bedingungslose Freigabeschleife übernimmt, erhält dadurch noch keine menschliche Prüfung. Die Anwendung muss zuerst die Entscheidung der Person einholen.

LangGraph: gespeicherte Abläufe unterbrechen und fortsetzen

LangGraph ist eine Bibliothek für Agentenworkflows mit gespeichertem Zustand. Mit interrupt() lässt sich ein Ablauf anhalten, um auf eine externe Eingabe zu warten. Dazu werden ein dauerhaft speichernder Checkpointer, also eine Komponente zur Sicherung des Ausführungszustands, und eine stabile thread_id eingerichtet. Mit Command(resume=...) wird derselbe Thread fortgesetzt. Die Dokumentation zu LangGraph-Interrupts.

Für den Produktivbetrieb nennt die Dokumentation einen entscheidenden Punkt: Beim Fortsetzen startet der unterbrochene Knoten erneut von vorn. Code vor der Unterbrechung kann deshalb wieder ausgeführt werden. Seiteneffekte sollten erst nach der Prüfung eintreten, und Operationen müssen sicher wiederholbar sein. Die Dokumentation empfiehlt außerdem, Seiteneffekte in eigene Knoten auszulagern. Eine Unterbrechung kann unbegrenzt warten. Prüffristen und die Behandlung von Eskalationen muss das Unternehmen daher zusätzlich vorsehen.

n8n: ausgewählte Tools mit menschlicher Prüfung versehen

n8n, eine Plattform zur visuellen Workflowautomatisierung, ermöglicht die menschliche Prüfung ausgewählter Tools, die mit einem AI Agent-Knoten verbunden sind. Der dokumentierte Ablauf pausiert, zeigt das vorgeschlagene Tool samt Parametern und führt bei einer Freigabe den Aufruf mit den von der KI festgelegten Eingaben aus. Bei einer Ablehnung wird die Aktion abgebrochen. Die n8n-Anleitung zur menschlichen Prüfung.

Am Anschluss Tools des Agenten wird unter Human review ein Kanal ausgewählt. Die prüfpflichtigen Tools werden mit diesem Schritt verbunden. Die Anleitung nennt unter anderem n8n Chat und Slack als Kanäle sowie $tool.name und $tool.parameters für den Aufbau der Prüfnachricht.

Diese Nachricht sollte klar zeigen, was die Person freigibt. Die Anleitung beschreibt Freigabe und Ablehnung; ein bearbeitbares Erstattungsformular lässt sich daraus nicht ableiten. Sind Änderungen nötig, muss der Vorschlag zur Überarbeitung und anschließenden erneuten Freigabe zurückgeleitet werden.

Anthropic Claude Code: Berechtigungen regeln den Toolzugriff

Für den Programmieragenten Claude Code dokumentiert Anthropic verschiedene Berechtigungsmodi. default, als Manual bezeichnet, verwendet Berechtigungsabfragen mit Ausnahmen für erlaubte Operationen und hinterlegte Regeln. acceptEdits erlaubt Dateiänderungen und bestimmte Dateisystembefehle in zulässigen Arbeitsverzeichnissen automatisch. plan untersucht den Code, ohne Quelldateien zu verändern. Die Berechtigungsdokumentation von Claude Code.

Der Modus auto verwendet im Hintergrund einen Klassifikator für Aktionen wie Shellbefehle und Netzwerkanfragen. Dabei handelt es sich um eine automatisierte Prüfentscheidung. bypassPermissions überspringt Berechtigungsabfragen, ausgenommen dokumentierte Aktionen, die kein Modus automatisch freigibt. Keiner dieser Modi belegt, dass ein Mensch jede Aktion geprüft hat.

Diese Einstellungen steuern die Laufzeitberechtigungen von Claude Code. Ein Kundensupportdienst braucht weiterhin eigene Regeln für Erstattungen, Empfänger und Datenzugriffe. Der speziellere Leitfaden zu Claude dangerously skip permissions erläutert die betrieblichen Grenzen dieses Modus.

Was gehört ins Protokoll?

Strukturierte Belege müssen nachvollziehbar machen, wer welche Aktion genehmigt hat und was danach geschah. Ein Gesprächsprotokoll allein reicht dafür kaum aus, besonders wenn ein Fall pausiert oder übergeben wird.

Die folgenden Angaben sollten als separate Ereignisse erfasst und über Fall- und Aktionskennungen miteinander verknüpft werden:

• Vorschlag: Aktionsart, Ziel, exakte Argumente, Version oder Hashwert des Arbeitsergebnisses, vorherige Werte und Verweise auf die zugrunde liegenden Quellen. Ein Hashwert dient als Fingerabdruck des geprüften Inhalts.
• Entscheidungsweg: Version der Richtlinie, zutreffende Regel, Freigabe- oder Stichprobenpflicht, Eskalationsgrund und relevante Validierungsergebnisse.
• Menschliche Entscheidung: authentifizierte prüfende Person, ihre Befugnis für diese Aktion, Freigabe oder Ablehnung, verlangte Änderungen, Begründung, Zeitstempel und Ablaufzeitpunkt.
• Ausführung: Kennung der freigegebenen Aktion, Versionen des Workflows und der Modellkonfiguration, Kennung des Ausführungsversuchs, Toolergebnis, externer Beleg und abschließender Status. Fehlgeschlagen, erfolgreich und Ausgang unbekannt müssen unterschieden werden.
• Qualitätsprüfung: Auswahlweg in die Stichprobe, festgestellte Fehlerart, Schweregrad, Korrekturmaßnahme und die Angabe, ob sich die Berechtigungsregel geändert hat.
• Zustand der Warteschlange: Eingangszeit, zugewiesene verantwortliche Person, Wartezeit, aktive Prüfzeit, Fristüberschreitung und Ergebnis der Übergabe.

Der Zugriff auf sensible Belege muss beschränkt bleiben; Geheimnisse sind zu schwärzen und Aufbewahrungsregeln festzulegen. Wo möglich, sollte auf einen geschützten Quelldatensatz verwiesen werden, statt die Daten jedes Kunden in jedes Protokoll zu kopieren. Knappe Entscheidungsgründe und Belege genügen. Um eine Freigabe zu überprüfen, sind die verborgenen Gedankengänge eines Modells nicht nötig.

Zuständigkeiten, verbotene Aktionen und Verantwortlichkeiten bei Eskalationen gehören in die Richtlinie zur zulässigen KI-Nutzung. Das Protokoll hält fest, ob diese Richtlinie eingehalten wurde. Es ersetzt keine Richtlinie, die niemand formuliert hat.

Menschliche Prüfung schrittweise je Aktionsart reduzieren

Eine eng umrissene, nachweislich beherrschte Aufgabe kann zur automatischen Ausführung übergehen; neue Aktionen und solche mit weitreichenden Folgen bleiben prüfpflichtig. Eine pauschale Kennzahl zur „Genauigkeit des Agenten“ vermischt unterschiedliche Risiken und ist eine schwache Grundlage für geänderte Berechtigungen.

1. 1

   Mit Vorschlägen beginnen

   Der Agent entwirft Aktionen, Menschen entscheiden. Fehler werden nach Art erfasst: falscher Empfänger, unbelegte Behauptung, falscher Betrag, fehlender Beleg oder unnötige Eskalation. Aus diesen Fällen entsteht ein repräsentativer Evaluationsdatensatz mit angemessenen Zugriffsbeschränkungen.

2. 2

   Freigaben auf einen klaren Umfang begrenzen

   Die Ausführung wird erst nach einer Freigabe erlaubt. Zu prüfen ist, ob eine Ablehnung die Aktion verhindert, veränderte Argumente die Freigabe ungültig machen und doppelte Entscheidungen keinen Schreibvorgang wiederholen. Bevor der Zugriff erweitert wird, müssen Zeitüberschreitungen und unklare Ergebnisse externer Aktionen erprobt werden.

3. 3

   Geeignete Aktionen auf Stichproben umstellen

   Dafür wird eine konkrete Kategorie gewählt, etwa routinemäßige Antworten zum Bestellstatus mit verifizierten Daten. Akzeptanzschwelle, Auswahlverfahren für die Stichprobe, Prüfverantwortung und Stoppbedingung stehen fest, bevor die Ergebnisse betrachtet werden. Verbindliche Eskalationsauslöser bleiben aktiv.

4. 4

   Bei veränderten Bedingungen wieder prüfen

   Ändert sich ein Modell, Prompt, Tool, eine Richtlinie oder Datenquelle, ist das ein Anlass, die betroffene Berechtigung neu zu bewerten. Ein schwerwiegender Vorfall oder schlechtere Stichprobenergebnisse sollten dazu führen, dass die betreffende Aktion während der Untersuchung wieder freigabepflichtig wird.

Schädliche Fehler, Korrekturen durch Prüfende, versäumte Eskalationen und Wiederherstellungsaufwand sollten nach Aktionsart erfasst werden. Rein kosmetische Änderungen sind von solchen zu trennen, die Schaden verhindert haben. Zu dokumentieren sind sowohl die Zahl der geprüften Aktionen als auch die vollständige Grundgesamtheit der für die Prüfung infrage kommenden Aktionen. Die Fehlerquote der Stichprobe wird auf die geprüften Aktionen bezogen. Zufällige und gezielte Stichproben bleiben getrennt; eine kleine Menge erfolgreich geprüfter Fälle belegt keine Zuverlässigkeit des gesamten Systems.

Die Freigabequote allein genügt nicht: Eine Person kann zustimmen, weil die Arbeit gut ist, weil die Vorlage zu wenig aussagt oder weil die Warteschlange sie überfordert. Deshalb sollten regelmäßig auch die Prüfentscheidungen selbst untersucht werden. Menschliche Beteiligung schafft die Möglichkeit, Fehler zu erkennen, aber keine Garantie.

Welche Versprechen zu kurz greifen

„Ein Mensch ist eingebunden“ bleibt eine unvollständige Aussage, solange unklar ist, was diese Person sieht und was sie stoppen kann. Wer erst nach einer ausgeführten Erstattung eine Benachrichtigung erhält, übt Aufsicht aus. Eine Freigabe vor der Aktion ist das nicht.

Auch „Erst einmal alles freigeben lassen, bis das Vertrauen wächst“ greift zu kurz. Ohne klare Kriterien fördert der Prozess Ermüdung und macht erweiterte Befugnisse zu einer Frage der Ungeduld. Vertrauen sollte auf Belegen für die jeweilige Aktionsart und einer verlässlichen Wiederherstellung beruhen.

Menschliche Rückmeldungen verbessern das System außerdem nicht von selbst. Jemand muss die Korrekturen in bessere Quelldaten, klarere Regeln, überarbeitete Prompts oder evaluierte Modelländerungen übersetzen. Dieser Aufwand gehört zur Verantwortung für den gesamten Prüfprozess.

Was sich am Montag konkret angehen lässt

Verantwortliche für den Betrieb sollten sämtliche Aktionen eines Agenten erfassen und jeder eine Kontrollform zuordnen. Die Supporttabelle bietet einen Ausgangspunkt. Für jede Freigabe muss die tatsächlich zuständige Person feststehen; außerdem braucht die Warteschlange während der zugesagten Servicezeiten eine verantwortliche Besetzung.

Entwicklungsteams sollten die Regel bei der Ausführung durchsetzen. Dazu wird die vorgeschlagene Aktion gespeichert, ihre Freigabe an die konkrete Version gebunden und geprüft, ob Ablehnung, Ablauf, doppelte Entscheidungen und veränderte Argumente korrekt behandelt werden. Das Modell darf sich nicht selbst eine Freigabe erteilen können.

Gründer und Einkaufsverantwortliche sollten sich eine abgelehnte Aktion und eine abgelaufene Prüffrist ohne menschliche Reaktion vorführen lassen. Diese Fälle zeigen, ob das System über wirksame Kontrollen im Betrieb verfügt oder lediglich eine Freigabebenachrichtigung verschickt.

Handlungsbedarf besteht sofort, wenn ein Agent bereits ohne festgelegte Grenzen Nachrichten versenden, Geld bewegen oder Kundendaten ändern kann. Mehr Autonomie sollte warten, solange Richtlinien oder Prüfkapazitäten ungeklärt sind. Bei einem internen Schreibassistenten, der keine externen Aktionen ausführen kann, reicht unter Umständen eine gewöhnliche redaktionelle Prüfung statt eines neuen Freigabesystems.

Häufige Fragen zur menschlichen Kontrolle von KI

Was bedeutet Human in the Loop bei KI?

Menschen wirken durch Prüfung, Rückmeldungen oder Entscheidungen am Betrieb eines KI-Systems mit. Bei Agenten für betriebliche Aufgaben muss klar sein, ob die Person eine Aktion vorab freigibt, abgeschlossene Arbeit stichprobenartig prüft oder Ausnahmefälle übernimmt.

Was macht einen Human-in-the-Loop-Prozess aus?

Menschliches Urteilsvermögen ist ausdrücklich Teil des Prozesses. Eine brauchbare Umsetzung legt fest, wer prüft, welche Entscheidung dieser Person obliegt, welche Belege sie sieht und was das System während der Wartezeit tut.

Ist Human in the Loop dasselbe wie agentische KI?

Human in the Loop lässt sich mit agentischer KI verbinden, doch die Begriffe bezeichnen unterschiedliche Dinge. Ein Agent wählt Schritte aus und nutzt Tools. Human in the Loop beschreibt, an welchen Stellen Menschen diese Arbeit beeinflussen oder genehmigen.

Wie behalten Menschen bei KI die Kontrolle?

Toolaufrufe mit weitreichenden Folgen werden freigabepflichtig, für Eskalationen stehen zuständige Personen bereit, und eine definierte Stichprobe geeigneter abgeschlossener Vorgänge wird geprüft. Entscheidung und Ergebnis werden protokolliert. Auf Basis der Erkenntnisse zu jeder Aktionsart lassen sich anschließend die Berechtigungen anpassen.

Warum bleibt eine KI manchmal in einer Schleife hängen?

In einem Agentenworkflow können wiederholte Versuche, wiederholt gewählte Tools oder ungeklärte Übergaben den Fortschritt verhindern. Deshalb braucht es Abbruchbedingungen und eine verantwortliche Person für Eskalationen. Eine solche Fehlerschleife ist etwas anderes als der hier beschriebene, bewusst eingebaute menschliche Prüfprozess.

Praktische Leitfäden für den Einsatz von KI in betrieblichen Abläufen gibt es im Newsletter.