Menschliche Kontrolle muss die Aktion physisch stoppen
Was ich tun würde, wenn die KI ein Angebot entwirft, einen Rabatt setzt und es an den Kunden schickt. Ich würde Vorbereitung und Ausführung trennen: das Modell schlägt vor, ein Mensch bestätigt einen konkreten Payload.
Den Fehler, den ich zuerst entfernen würde: Lebt Approval in einem langlebigen Workflow, können Timeout oder Neustart den Zustand verlieren. Zuverlässiger ist es, das Speichern des Vorschlags vom Fortsetzen nach der Entscheidung zu trennen.
Was vorbereiten und welches Ergebnis erwarten
- Ergebnis: Mitarbeitende prüfen nur Hochrisiko-Fälle, und nach einer Pause läuft der Workflow am selben Punkt weiter.
- Definieren Sie Aktionen, die Approval brauchen: senden, erstatten, löschen, veröffentlichen, Berechtigungen ändern und Finanzoperationen.
- Halten Sie Quelldaten und Zugriffsrechte vom Ergebnis getrennt, damit Sie prüfen können, was der Human-in-the-loop-Workflow getan hat.
- Stoppen Sie das Szenario beim Approval, lehnen Sie die Aktion ab, genehmigen Sie sie Minuten später und prüfen Sie das Log.
Einen prüfbaren Approval-Flow bauen
- Vorschlag von Aktion trennen
Die KI erzeugt ein draft_action, der Workflow zeigt es einem Menschen, und ein separater Execute-Schritt läuft erst nach approve.
Проверьте: Der Approve-Button ändert nicht nur den Status – er ist Ausführungsbedingung.
Если не сработало: Entfernen Sie das Write-Tool aus der KI und lassen Sie es nur im finalen Zweig.
- Zustand persistent speichern
Protokollieren Sie run_id, action, payload, requester, approver, status und expires_at. Für komplexes Approval nutzen Sie einen Wait-Node oder Webhook-Resume.
Проверьте: Nach einer Pause können Sie denselben run_id fortsetzen.
Если не сработало: Teilen Sie den Workflow in Start und Resume, statt einen langen Prozess im Speicher zu halten.
- Zeigen Sie einem Menschen den Kontext
Die Approval-Karte muss Originalanfrage, gefundene Daten, KI-Vorschlag, Risiko und Buttons approve/reject/ask_more enthalten.
Проверьте: Eine Entscheidung ist möglich, ohne in fünf Systemen zu suchen.
Если не сработало: Reduzieren Sie den Screen auf die Daten, die die Entscheidung ändern.
- Ablehnung und Timeout behandeln
Reject schickt die Aufgabe an den Owner oder gibt den Entwurf zur Bearbeitung zurück. Ein abgelaufenes expires_at darf die Aktion nicht auto-ausführen.
Проверьте: Eine abgelehnte Anfrage erreicht den Kunden nie und ist im Log sichtbar.
Если не сработало: Fügen Sie eine tägliche Liste stecken gebliebener Approvals hinzu.
Zustände, die ich einrichten würde
Minimale Zustandsmaschine: received → drafted → waiting_approval → approved/rejected → executed → failed. Speichern Sie am Datensatz input_snapshot, proposed_action, reviewer_id, reviewed_at, rejection_reason und execution_id. Nach approved prüft der Workflow erneut, ob die Eingabe veraltet ist.
Für E-Mail oder eine CRM-Änderung in zwei Operationen teilen: die erste speichert den Entwurf und sendet einen Bestätigungsbutton; die zweite führt per approval_id aus. So überlebt der Prozess einen Neustart und sendet nicht erneut.
- Reject soll den Grund erklären, nicht nur den Status löschen.
- Bei niedriger Confidence setzen Sie review_required statt einer endlosen Klärungsschleife.
Was auf den Approval-Screen gehört
Zeigen Sie Quelltext, vorgeschlagenes Ergebnis, Felder, die sich ändern, einen Link zur Quelle, Risiko und Buttons approve/reject. Kann ein Mensch die Entscheidung in einer Minute nicht verstehen, ist der Screen überladen oder die KI brachte zu wenig Kontext.
Zwei Ketten statt eines hängenden Workflows
Workflow A: `Trigger → Get context → AI draft → Validate → proposal_id → action_hash → Save approval → Slack/Gmail`. Workflow B: `Approval webhook → Verify approver → Get proposal → Compare action_hash → Check expiry → Execute once → Audit log`.
Zustände: `pending → approved/rejected/edited → executed/failed/expired`. Am Datensatz speichern: `proposal_id`, `target_id`, `payload`, `action_hash`, `state_version`, `approver_role`, `expires_at`, `rejection_reason` und `execution_id`.
{
"action": "send_quote",
"target_id": "deal_456",
"payload": {"amount": 150000, "discount": 10},
"requires_approval": true,
"expires_at": "2026-08-05T12:00:00Z"
}Was ein Mensch sehen muss
Empfänger, Betrag, Rabatt, Felder, die sich ändern, Textvorschau, Datenquelle und Ablaufzeit. Der Button darf die Aktion nicht direkt aus der URL ausführen: er übergibt nur `proposal_id`, und der Server prüft erneut Rolle, Hash und Status `executed`.
Wo ein Mensch entscheiden muss und wo eine Regel reicht
| Kriterium | Frage | Gutes Zeichen |
|---|---|---|
| Eingabe | Was genau geht in den Human-in-the-loop-Workflow ein? | Definieren Sie Aktionen, die Approval brauchen: senden, erstatten, löschen, veröffentlichen, Berechtigungen ändern und Finanzoperationen. |
| Aktion | Was darf das System allein tun? | Nur vorab gelistete Aktionen, ohne Zugriff auf das gesamte Konto |
| Prüfung | Woran erkennen Sie, dass das Ergebnis akzeptabel ist? | Stoppen Sie das Szenario beim Approval, lehnen Sie die Aktion ab, genehmigen Sie sie Minuten später und prüfen Sie das Log. |
| Fehlerfall | Wohin gehen unklare Fälle? | Persistieren Sie den Zustand in einer Tabelle oder Datenbank und setzen Sie eine Eskalationsfrist, damit stecken gebliebene Approvals nicht verloren gehen. |
Was sich nach der Einrichtung ändern sollte
Mitarbeitende prüfen nur Hochrisiko-Fälle, und nach einer Pause läuft der Workflow am selben Punkt weiter.
Warum „human in the loop“ oft nur auf dem Papier existiert
Approval als Textanweisung im Prompt behandeln.
Zwischen Start und Bestätigung keinen Zustand speichern.
Mitarbeitenden nur das Ergebnis ohne Originalanfrage zeigen.
Die Aktion nach Timeout automatisch ausführen.
Wann Approval eigenen Zustand braucht
Holen Sie einen Spezialisten, wenn Approval Geld, rechtliche Handlungen, mehrere Rollen oder lange Prozesse mit großem Zustandsumfang betrifft.
Was auf den Bestätigungsbildschirm gehört
Für wen ist dieser Human-in-the-loop-Workflow-Ansatz?
In einem Human-in-the-loop-KI-Szenario ist menschliche Kontrolle keine Prompt-Zeile. Das System muss stoppen, Zustand speichern, Eingabe und KI-Vorschlag zeigen, auf eine Entscheidung warten und erst dann die Aktion ausführen.
Wo fängt man an, wenn noch alles manuell läuft?
Definieren Sie Aktionen, die Approval brauchen: senden, erstatten, löschen, veröffentlichen, Berechtigungen ändern und Finanzoperationen.
Wie prüfen Sie, dass das Setup nicht schadet?
Stoppen Sie das Szenario beim Approval, lehnen Sie die Aktion ab, genehmigen Sie sie Minuten später und prüfen Sie das Log.
Was, wenn das Ergebnis unklar ist?
Persistieren Sie den Zustand in einer Tabelle oder Datenbank und setzen Sie eine Eskalationsfrist, damit stecken gebliebene Approvals nicht verloren gehen.
