Human in the Loop

Ziel

Die Gestaltung von Human in the Loop setzt einen menschlichen Entscheid in einen Prozess, in dem ein KI-System liest, einordnet, vorschlägt oder handelt. Für jede Funktion eines Entscheids legt sie fest, ob und in welchem Modus sie automatisiert wird. Das geschieht, bevor das Team die Lösungsanforderungen schreibt. Sie benennt ausserdem die Person, die für das Ergebnis einsteht, wenn ein Fehler der Kontrolle entgeht.

Das Ergebnis ist ein Entscheidungsregister. Jede Zeile beschreibt eine Funktion eines Entscheids im Prozess. Die Spalten nennen die Kosten eines Fehlers, die gemessene Zuverlässigkeit, den Kontrollmodus, die Zeit pro Fall, den Prüfer und den Rechenschaftspflichtigen. Das Register speist die Lösungsanforderungen und die RACI-Matrix des Prozesses. Ein Testplan für die Aufsicht und eine Liste von Kennzahlen der menschlichen Prüfung begleiten es.

Die Technik ersetzt einen gängigen Satz aus Pflichtenheften: "Eine Person validiert das Ergebnis." Der Satz lässt offen, welche Fälle, womit und in welcher Zeit. Er erzeugt zwei bekannte Mängel. Der Prüfer genehmigt aus Gewohnheit, was ihm ein zuverlässiges System vorlegt. Die menschliche Unterschrift macht ein fehlerhaftes System annehmbar und schiebt die Schuld auf die Person, die unterschreibt. Das Register macht aus dem Satz einen Entwurf, den das Team testen kann.

Einsatz

Wann einsetzen

• Neuer KI-gestützter Prozess: festlegen, wo eine Person entscheidet, bevor das Team die Lösungsanforderungen spezifiziert.
• Agent, der in einem System handelt: die Freigabe vor das Schreiben, das Senden oder die Zahlung setzen, die der Agent auslöst.
• Entscheid, der eine Person betrifft: Rückerstattung, Bewerbung, Kredit; die Überprüfung vorsehen, die die Person verlangen kann.
• Als hochriskant eingestuftes System: die menschliche Aufsicht gestalten, die der AI Act vom Betreiber verlangt.
• Menschliche Prüfung, die fast alles genehmigt: prüfen, ob sie noch etwas entscheidet.
• Modell-Update oder Anbieterwechsel: die Aufsicht am neuen System erneut testen.
• Steigendes Volumen ohne zusätzliche Prüfer: die verfügbare Zeit pro Fall neu berechnen und den Modus überprüfen.

Wann nicht einsetzen

• Persönlicher Assistent ohne Wirkung über seinen Nutzer hinaus: Der Autor liest seinen Entwurf selbst; eine Nutzungsrichtlinie genügt.

Beschreibung

Der Entscheid und seine vier Funktionen

Parasuraman, Sheridan und Wickens (2000) beschreiben Automatisierung nach Funktion statt nach System. Ihr Modell unterscheidet vier Klassen von Funktionen. Das Beispiel folgt einer Krankenkasse, die eine Physiotherapie-Rechnung bearbeitet.

• Informationsaufnahme: Das System liest die Rechnung und entnimmt ihr die Tarifpositionen, die Zahl der Sitzungen und das Datum der Verordnung.
• Informationsanalyse: Es vergleicht diese Daten mit der Verordnung und der Vorgeschichte der versicherten Person und schätzt dann die Wahrscheinlichkeit eines Fehlers.
• Entscheidungs- und Handlungsauswahl: Es entscheidet, die Rechnung zu zahlen oder kontrollieren zu lassen.
• Handlungsausführung: Es löst die Zahlung aus oder versendet das Schreiben, das einen Teil des Betrags ablehnt.

Jede Funktion liegt auf einem Kontinuum von manuell bis automatisch. Ein und dasselbe System kann die vier Funktionen unterschiedlich stark automatisieren. Die Zerlegung zeigt, wo der Fehler entsteht und wo eine Person ihn am günstigsten abfängt. Ein Lesefehler fällt in einer Stichprobe auf. Ein unbegründetes Ablehnungsschreiben lässt sich vor dem Versand korrigieren.

Die Kontrollmodi

Keine Norm benennt die Kontrollmodi. Sie reichen von der Freigabe jedes Falls bis zu keinem menschlichen Schritt pro Fall. Die Person, die die ganze Arbeit macht, bleibt eine Option: Das System erhält dann keine Funktion.

Die Modi lassen sich an einem Entscheid kombinieren. Die Weiterleitung markierter Fälle verlangt fast immer eine Stichprobenprüfung unter den nicht markierten Fällen. Ohne sie sieht niemand die Fehler, die das System nicht markiert. Ein Beispiel dieses Mangels finden Sie in der Technik AI Canvas.

Den Modus wählen: Kosten eines Fehlers und Zuverlässigkeit

Parasuraman und seine Mitautoren geben zwei Ebenen von Kriterien an. Das primäre Kriterium ist die Wirkung der Automatisierung auf die Arbeit der Person. Die sekundären Kriterien sind die Zuverlässigkeit der Automatisierung und die Kosten der Folgen eines Entscheids oder einer Handlung.

Die Kosten eines Fehlers beziffern, was ein falscher Fall kostet, wenn er der Kontrolle entgeht: einen Betrag in CHF, eine Verzögerung, einen Schaden für eine Person. Die Analystin fragt auch, ob sich die Wirkung rückgängig machen lässt, bevor sie schadet. Ein Dokument in der falschen Warteschlange ist in zwei Minuten umgeleitet. Ein Ablehnungsschreiben an eine versicherte Person lässt sich nicht zurücknehmen.

Die Zuverlässigkeit wird an einer Stichprobe echter Fälle gemessen. Muss die Schwelle für jede Sprache, Region oder Dokumentart gelten, wird sie für jede einzeln gemessen. Eine Zuverlässigkeit, die niemand gemessen hat, zählt nicht. Der Entscheid bleibt dann bis zur Messung in der Freigabe vor der Aktion. Wie Sie diese Zahlen erheben, finden Sie auf der Seite Den Erfolg einer KI-Lösung messen.

Das primäre Kriterium prüft, ob die Person die Arbeit in diesem Modus in der verfügbaren Zeit leisten kann. Die Berechnung multipliziert die Zahl der Fälle pro Tag mit der Lesezeit eines Falls und vergleicht das Ergebnis mit der Zeit der Prüfer. Eine Krankenkasse erhält 5'000 Dokumente pro Tag. Bei 30 Sekunden pro Dokument verlangt die Freigabe jeder Zuordnung fast 42 Stunden pro Tag. Die drei Mitarbeitenden des Posteingangs haben 24 Stunden Prüfzeit pro Tag. Die Berechnung schliesst diesen Modus vor der Inbetriebnahme aus. Können die Prüfer die Arbeit in keinem Modus in der verfügbaren Zeit leisten, geht der Entscheid über die Automatisierung an die Risikoanalyse zurück.

Das Risikoniveau des ganzen Systems setzt eine Untergrenze. Das Register wählt die Modi Funktion für Funktion oberhalb dieser Untergrenze. Wie Sie dieses Niveau bestimmen, finden Sie auf der Seite KI-Risiken bewerten. Wann das Gesetz eine menschliche Aufsicht vorschreibt, finden Sie auf der Seite AI Act: das Risiko einstufen.

Der Prüfer und der Rechenschaftspflichtige

Die Unterkategorie GOVERN 3.2 des NIST AI RMF verlangt Richtlinien, die die Rollen in Konfigurationen aus Menschen und KI festlegen und voneinander abgrenzen. Das Playbook des NIST trennt die Personen, die das System beaufsichtigen, von denen, die es nutzen. Einen Überblick über das Rahmenwerk finden Sie auf der Seite ISO/IEC 42001 und NIST AI RMF. Der Begriff Aufsicht übersetzt das oversight des NIST. Die deutsche Fassung des AI Act spricht ebenfalls von menschlicher Aufsicht. Das Register nennt zwei Rollen pro Zeile.

Der Prüfer untersucht einen Fall oder eine Stichprobe und entscheidet: Er nimmt an, korrigiert oder lehnt ab. MAP 3.4 nennt als Beispiel Ärztinnen und Ärzte. Diese Fachleute arbeiten mit KI, ohne maschinelles Lernen zu kennen. Der Prüfer beurteilt den Inhalt des Falls. Das Modell beurteilt er nicht.

Der Rechenschaftspflichtige steht für das Ergebnis des Entscheids ein. Er wählt den Modus, legt die Schwellen fest, liest die Kennzahlen der menschlichen Prüfung und kann das System stoppen. Er steht auch für die Fehler in den Fällen ein, die niemand geprüft hat. Der Prüfer verantwortet nur die Fälle, die er gesehen hat. Eine RACI-Matrix hält diese beiden Rollen fest: Der Prüfer ist dort R und der Rechenschaftspflichtige A.

Der Prüfer erhält das Recht abzulehnen. Der Text von GOVERN 1.5 zählt die Anfechtung und die manuelle Übersteuerung eines Systementscheids zu den Prozessen, die eine Person entscheiden lassen. Eine begründete Ablehnung gilt als normale Arbeit. Der Prüfer muss eine Ablehnung nicht ausführlicher begründen als eine Annahme.

Was der Prüfer erhält

MAP 3.5 verlangt eine Dokumentation, mit der das Aufsichtspersonal informiert entscheiden kann. Die Übersichtsarbeit von Goddard, Roudsari und Wyatt (2012) berücksichtigt 74 Studien aus mehreren Bereichen und konzentriert sich auf die klinische Entscheidungsunterstützung. Sie untersucht den Automatisierungsbias: die Neigung, dem Vorschlag eines Systems ohne Prüfung zu folgen. Zu seinen Gegenmassnahmen zählt sie Schulung, die Verantwortlichkeit des Nutzers, die Platzierung der Empfehlung auf dem Bildschirm, ein aktualisiertes Konfidenzniveau und Information anstelle einer Empfehlung. Aus einer kleinen Zahl von Workshops leiten Faas und seine Mitautoren (2025) ab, dass der Prüfer seine Aufgabe verstehen und sehen muss, worauf die KI ihre Ausgabe stützt.

Das Prüfdossier vereint die Eingabe, die vom System daraus gewonnenen Fakten mit ihrer Quelle und den Vorschlag des Systems. Es zeigt die Konfidenz des Systems, wenn sie gemessen ist. Der Prüfer kann mit einer Begründung ablehnen. Die Fakten kommen vor dem Vorschlag: Der Prüfer liest die Rechnung und die Verordnung, bevor er "Kontrollieren lassen" liest. Die Fehler, die er sucht, finden Sie auf den Seiten Halluzinationen und Verzerrungen.

Die Zeit gehört zum Dossier. Goddard und seine Mitautoren zählen Arbeitslast, Komplexität der Aufgabe und Zeitdruck zu den Faktoren, die diesen Bias verstärken. Das Register legt eine Zeit pro Fall fest und die Prüfwarteschlange hält sie ein.

Die Schritte

1. Die Entscheide des Prozesses auflisten. Vom Prozessmodell ausgehen und jeden Punkt markieren, an dem das System liest, einordnet, vorschlägt oder handelt. Jeden Entscheid in vier Funktionen zerlegen. Die Entscheidungsmodellierung liefert die Liste, wenn es sie gibt.
2. Kosten eines Fehlers und Zuverlässigkeit beziffern. Der Fachbereich beziffert die Kosten. Das Datenteam misst die Zuverlässigkeit an einer Stichprobe. Ein fehlender Wert bleibt als "zu messen" markiert.
3. Den Modus jeder Funktion wählen. Die sekundären Kriterien anwenden und dann das primäre Kriterium prüfen: die Prüfzeit berechnen.
4. Prüfer und Rechenschaftspflichtigen benennen. Beide im Register und in der RACI-Matrix des Prozesses eintragen.
5. Das Prüfdossier spezifizieren. Festhalten, was der Prüfer sieht, in welcher Reihenfolge, mit welcher Zeit pro Fall und welchem Ablehnungsgrund.
6. Die Prüfer schulen. GOVERN 3.2 und MAP 3.5 verlangen, die beaufsichtigenden Personen in der Leistung des Systems, dem Nutzungskontext, den bekannten Grenzen und den bekannten negativen Auswirkungen zu schulen. Wie Sie die Teams vorbereiten, finden Sie auf der Seite Change Management.
7. Die Aufsicht vor der Inbetriebnahme testen. MAP 3.5 verlangt, die Aufsicht unter betriebsnahen Bedingungen zu testen und ihre Gültigkeit und Zuverlässigkeit zu bewerten. Für ein kritisches oder hochriskantes System setzt das Playbook diese Bewertung vor den Einsatz.
8. Die menschliche Prüfung im Betrieb verfolgen. GOVERN 1.5 verlangt, das Risikomanagement laufend zu überwachen, es in einem festgelegten Rhythmus zu überprüfen und die Zuständigkeiten dafür festzulegen. Der Rechenschaftspflichtige liest die Kennzahlen jeden Monat. Nach jedem Wechsel von Modell, Daten oder Anbieter lässt er den Test wiederholen.
9. Dokumentieren. Das Register, die Testergebnisse und die Entscheide des Rechenschaftspflichtigen bilden die Dokumentation, die GOVERN 3.2 und MAP 3.5 verlangen.

Die Reihenfolge der Schritte ist eine Synthese. Die Schritte 1 bis 3 stammen von Parasuraman und seinen Mitautoren. Die Schritte 4 bis 7 und 9 stammen aus dem Playbook des NIST. Schritt 8 wendet GOVERN 1.5 an. Seine Kennzahlen und der erneute Test nach einem Modellwechsel beruhen auf unserem Urteil. Goddard und seine Mitautoren ergänzen Schritt 5. Wo der Test aus Schritt 7 seinen Platz hat, finden Sie auf der Seite Vom Prototyp zur Produktion.

Die Aufsicht mit bekannten Fehlern testen

Ein Aufsichtstest misst, ob die Prüfer die Fehler abfangen. Der Rechenschaftspflichtige schleust Fälle mit bekanntem Fehler in die Prüfwarteschlange ein: eine Rechnung, die über die Verordnung hinausgeht, ein falsch eingeordnetes Dokument, ein Schreiben, das den falschen Artikel zitiert. Die Prüfer wissen nicht, welche Fälle es sind. Der Anteil dieser Fälle, den die Prüfer ablehnen, misst die Aufsicht. Der Rechenschaftspflichtige legt den Mindestanteil vor dem Test fest. Wie Sie diese Schwelle formulieren, finden Sie in der Technik Akzeptanz- und Bewertungskriterien. Ein kleiner Anteil dieser Fälle bleibt im Betrieb in der Warteschlange.

Die menschliche Prüfung verfolgen

Eine menschliche Prüfung verschlechtert sich lautlos. Die Kennzahlen der menschlichen Prüfung machen das sichtbar. Keine Quelle legt eine Alarmschwelle fest. Der Rechenschaftspflichtige setzt seine eigenen anhand der ersten Betriebswochen.

Woran die Übung scheitert

Freigabe aus Gewohnheit

Bainbridge (1983) beschreibt die Ironie der Automatisierung. Das System existiert, weil es die Arbeit besser macht als der Operateur. Der Operateur muss trotzdem prüfen, ob es funktioniert. Die von ihr zitierten Vigilanzstudien zeigen, dass eine Person ihre Aufmerksamkeit nicht länger als etwa eine halbe Stunde auf eine Quelle richten kann, an der wenig geschieht. Wer jeden Fall eines zuverlässigen Systems freigibt, gibt deshalb Fälle frei, die er nicht gelesen hat. Die Abhilfe verringert die Zahl der Freigabepunkte, behält sie den teuren Fällen vor und fügt Fälle mit bekanntem Fehler hinzu.

Der Mensch als Alibi

Green (2022) untersucht 41 Richtlinien, die eine menschliche Aufsicht über Algorithmen der öffentlichen Hand vorschreiben. Er stellt zwei Mängel fest. Die Daten deuten darauf hin, dass Menschen die erwarteten Aufsichtsfunktionen nicht erfüllen. Die Richtlinien machen fehlerhafte Algorithmen annehmbar und erlauben Anbietern und Verwaltungen, sich ihrer Verantwortung zu entledigen. Die Studie betrifft den öffentlichen Sektor. Der Mechanismus gilt überall, wo eine Person die Ergebnisse eines Systems unterschreibt, dessen Einsatz niemand begründet hat. Das Register weist die Verantwortung für das Ergebnis einem Rechenschaftspflichtigen zu, der nicht der Prüfer ist. Der Test mit bekannten Fehlern misst, ob die Prüfung Fehler abfängt.

Der Verlust an Können

Bainbridge hält fest, dass manuelle Fertigkeiten verloren gehen, wenn sie nicht mehr gebraucht werden. Der Operateur, der in einer abnormalen Lage übernimmt, braucht mehr Können. Er hat aber die Übung verloren. Ein Prüfer, der kein Dossier mehr vollständig bearbeitet, kann das zweifelhafte Dossier nicht mehr beurteilen. Das Register sieht einen Anteil von Hand bearbeiteter Fälle oder eine Rotation zwischen Prüfung und manueller Bearbeitung vor.

Der Prüfer ohne Mittel zum Urteil

Ein Prüfer, der den Vorschlag ohne die Quelle, ohne die Zeit oder ohne die Schulung sieht, genehmigt, was er nicht prüfen kann. MAP 3.5 und die Bedürfnisse, die Faas und seine Mitautoren auflisten, zielen auf diesen Mangel. Das Prüfdossier und die Zeit pro Fall beheben ihn. Eine Ablehnung, die drei Bildschirme Begründung verlangt, bringt ihn zurück.

Der falsch gesetzte Kontrollpunkt

Anthropic beschreibt Agenten, die an Kontrollpunkten oder bei einem Hindernis für eine menschliche Rückmeldung anhalten. Wer an jedem Schritt eines Agenten eine Freigabe setzt, erzeugt die Freigabe aus Gewohnheit. Wo die Validierung eines Agenten hingehört, finden Sie auf der Seite Chatbot, Assistent, Agent.

KI-Überlegungen

Ein Gesprächsassistent erstellt aus einer Beschreibung des Prozesses eine erste Liste der Entscheide. Er schlägt die Zerlegung jedes Entscheids in vier Funktionen vor und füllt die beschreibenden Spalten des Registers. Er verfasst Fälle mit bekanntem Fehler auf der Grundlage anonymisierter echter Fälle: eine Rechnung, die über die Verordnung hinausgeht, ein Schreiben, das eine falsche Bestimmung zitiert. Er gruppiert die Ablehnungsgründe eines Prüfmonats und markiert die wiederkehrenden.

Die Kosten eines Fehlers bleiben eine Eingabe des Fachbereichs. Warum, finden Sie in der Technik AI Canvas. Der Assistent wählt weder den Prüfer noch den Rechenschaftspflichtigen. Er kennt die Auslastung der Teams und ihre verfügbare Zeit nicht. Die Konfidenz, die ein Sprachmodell über seine eigene Antwort äussert, ersetzt keine an einer Stichprobe gemessene Zuverlässigkeit.

Ein zweites Modell, das das erste prüft, zählen wir zu den automatischen Kontrollen. Das Register führt die Funktion dann unter "Kein menschlicher Schritt pro Fall". Die Erklärung, die ein Modell zu seinem eigenen Vorschlag schreibt, lesen wir ebenfalls als Empfehlung. Nach der Gegenmassnahme von Goddard und seinen Mitautoren zeigt das Prüfdossier die extrahierten Fakten und ihre Quelle statt dieser Begründung. Die echten Fälle und die Ablehnungsgründe enthalten Daten von Versicherten. Die Analystin gibt sie nur einem Assistenten, den ihre Organisation freigegeben hat.

Beispiele

Eine Krankenkasse in der Westschweiz sortiert ihre eingehenden Dokumente und kontrolliert ihre Rechnungen mit Modellen. Das Register zeigt zwei Entscheide desselben Sortiermodells mit zwei verschiedenen Modi. Die Zeilen 3a bis 3d übernehmen die vier Funktionen des Rasters. Die Werte sind erfunden.

Die Leiterin Rechtsdienst steht auch für die Einsprachen ein, die niemand geprüft hat. Die Überprüfung einer automatisierten Einzelentscheidung, die das DSG der versicherten Person gewährt, finden Sie auf der Seite Die Anforderungen an eine KI-Lösung spezifizieren.

Visualisierungen

Das Entscheidungsregister ist eine Tabelle. Jede Zeile beschreibt eine Funktion eines Entscheids. Jede Spalte vergleicht die Modi oder die Rechenschaftspflichtigen. Das Raster der Funktionen braucht eine Zeichnung: Es zeigt, dass ein Entscheid vier verschiedene Positionen auf der Achse von manuell bis automatisch einnimmt. Auch der Bildschirm des Prüfers wird gezeichnet. Die Reihenfolge seiner Blöcke setzt eine Gegenmassnahme gegen den Automatisierungsbias um: die Fakten vor dem Vorschlag.

Aufwand

Werkzeuge

Für das Register und die Berechnung der Prüfzeit genügt eine Tabellenkalkulation. In einem BPMN-Modellierungswerkzeug wird jede Freigabe zu einer Benutzeraufgabe. Ein Timer-Randereignis an dieser Aufgabe eskaliert den Fall, der über die vom Rechenschaftspflichtigen gesetzte Frist hinaus wartet. Die Zeit pro Fall aus dem Register wird zur Dauer der Aufgabe, wenn das Werkzeug den Prozess simuliert.

Die Prüfwarteschlange ist ein Workflow- oder Ticketwerkzeug. Sie muss den Entscheid, den Ablehnungsgrund und die Zeit pro Fall aufzeichnen. Ohne dieses Protokoll lassen sich die Kennzahlen der menschlichen Prüfung nicht berechnen.

Die Entwicklungskits für Agenten liefern den Freigabemechanismus. Im Agents SDK von OpenAI hält ein freigabepflichtiges Tool die Ausführung an. Der wartende Aufruf zeigt den Agenten, das Tool und seine Argumente. Die Person genehmigt oder verwirft den Aufruf. Eine Ablehnung kann eine Nachricht enthalten. Der Zustand der Ausführung wird gespeichert und später fortgesetzt: Der Prüfer kann Stunden nach der Pause entscheiden.

Quellen

Kein Referenzwerk beschreibt diese Technik unter einem einheitlichen Namen. Das Vorgehen ist eine Synthese aus Primärquellen. Das Modell von Parasuraman, Sheridan und Wickens liefert Ort und Grad der Kontrolle. Das NIST AI RMF und sein Playbook liefern die Rollen, den Test, die Überwachung und die Dokumentation. Die Namen der Kontrollmodi, die Reihenfolge der Schritte, der Test mit bekannten Fehlern, die Überwachungskennzahlen und der erneute Test nach einem Modellwechsel beruhen auf unserem Urteil.

• Parasuraman, R., Sheridan, T. B. und Wickens, C. D. (2000), A model for types and levels of human interaction with automation, IEEE Transactions on Systems, Man, and Cybernetics, Part A, 30(3), S. 286-297: die vier Klassen von Funktionen, das Kontinuum von manuell bis automatisch, das primäre Kriterium und die sekundären Kriterien.
• NIST (2023), Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100-1: das Rahmenwerk, dessen Massnahmen das Playbook ausführt.
• NIST, AI RMF Playbook, GOVERN: GOVERN 3.2 für die Rollen, die Schulung und die Konfigurationen aus Menschen und KI; GOVERN 1.5 für die laufende Überwachung, die periodische Überprüfung und die Anfechtung eines Systementscheids.
• NIST, AI RMF Playbook, MAP: MAP 3.5 für die Festlegung, den Test und die Dokumentation der menschlichen Aufsicht; MAP 3.4 für die Fachleute, die mit KI arbeiten.
• Goddard, K., Roudsari, A. und Wyatt, J. C. (2012), Automation bias: a systematic review of frequency, effect mediators, and mitigators, JAMIA, 19(1), S. 121-127: die Faktoren des Automatisierungsbias und seine Gegenmassnahmen; die Übersicht betrifft vor allem die klinische Entscheidungsunterstützung.
• Bainbridge, L. (1983), Ironies of automation, Automatica, 19(6), S. 775-779: die Überwachung eines zuverlässigen Systems und der Verlust manueller Fertigkeiten in der Prozessindustrie.
• Green, B. (2022), The flaws of policies requiring human oversight of government algorithms, Computer Law & Security Review, 45, 105681: die zwei Mängel von Richtlinien zur menschlichen Aufsicht im öffentlichen Sektor.
• Faas, C., Kerstan, S., Uth, R., Langer, M. und Feit, A. M. (2025), Design considerations for human oversight of AI, arXiv:2510.19512, Preprint: die Bedürfnisse der Prüfer nach vier Co-Design-Workshops.
• Anthropic, Building effective agents: die menschlichen Kontrollpunkte eines Agenten.
• OpenAI, Agents SDK, Human-in-the-loop: die Pause und die Fortsetzung einer Ausführung, die auf Freigabe wartet.