Audit-Trail und Human-in-the-Loop-Gates für Agenten

Wenn Sie nicht rekonstruieren können, wer welchen Tool-Call freigegeben hat, können Sie den Agenten nicht steuern. HITL ohne Audit-Trail ist Theater; ein Audit-Trail ohne HITL für wirkungsstarke Actions ist Fahrlässigkeit.

Ein Slack-„LGTM“ ohne Call-ID, Timeout wird Auto-Approve, HITL läuft nur in der Demo. Dieser Teil macht Trail und Gate zumselben Betriebsvertrag — auf den Scopes aus Teil 2.

Vorher: Permission Scopes je Tool. Weiter: Cost Caps und Abuse Controls.

In einem Satz: Kein wirkungsstarker Tool-Call ohne Audit-Record und, wo die Matrix es verlangt, menschliche Freigabe vor der Ausführung.

Entscheidung

Für jeden Produktionsagenten:

1. speichert der Audit-Trail Prompt-/Kontext-Hash (soweit Policy erlaubt), Tool-Name, Parameterklasse, Entscheidung, Actor, Zeitstempel und Outcome;
2. gelten HITL-Gates nach Side-Effect-Stufe und Risikoklasse vor der Ausführung;
3. legt der Data Owner fest, welche Actions menschliche Freigabe brauchen; der Steward pflegt die Matrix; der Custodian setzt Hold-and-Resume im Gateway um;
4. sind Freigaben befristet und ohne Re-Auth nicht übertragbar;
5. ist fehlgeschlagenes oder übersprungenes HITL ein Incident, keine Konfigurationsvorliebe.

Kein write-/money-/identity-Call ohne die in der Matrix benannte Freigabe.

Audit- und HITL-Workflow

1. Matrix definieren

Der Data Owner mappt Side-Effect-Stufen auf approve, dual-control oder auto-allow-with-log. Artefakt ist die HITL-Matrix je Tool, nicht ein Slack-Kanal. Der Steward pflegt die Matrix; ohne sie entscheidet der Operator zur Laufzeit, was „schon okay“ ist.

2. Minimale Evidenz erfassen

Der Custodian speichert genug zur Rekonstruktion der Action — Call-ID, Actor, Parameterklasse, Outcome — und redaktiert Secrets sowie unzulässige Inhalte nach Policy. Der Audit-Store selbst braucht Retention und Access Control. Roh-Payloads ohne Redaction erzeugen einen zweiten Leak.

3. Wirkungsstarke Calls halten

Das Gateway parkt write-/money-/identity-Calls, bis eine benannte Person freigibt. Der Freigeber sieht eine Kontext-Summary, gebunden an die Call-ID — kein „LGTM“ in einem privaten Chat. Ohne Hold-and-Resume läuft HITL nur in Demos.

4. Loop schließen

Approve, Reject und Timeout werden geloggt und an die ursprüngliche Call-ID gebunden. Timeout ist Reject oder Incident, nie Auto-Approve. Ein gemeinsames Freigeber-Konto macht den Actor wertlos.

5. Samples reviewen

Der Steward sampelt HITL-Entscheidungen wöchentlich auf Rubber-Stamping und eskaliert Muster an den Data Owner. Artefakt ist der Audit-Export mit Begründung je Sample. Wer nie sampelt, hält ein Gate, das niemand mehr liest.

Handoffs

Anti-Patterns

• Slack-„LGTM“ ohne Bindung an Call-ID
• Auto-Approve nach Timeout
• Secrets im Klartext loggen
• menschliche Freigabe nur für Demos, in Produktion aus
• Ein gemeinsames Freigeber-Konto

Umsetzung im Alltag

Dieser Einstieg ist kein Kalenderzwang und keine Leseliste. Nimm einen echten Fall, an dem sich die Entscheidung prüfen lässt.

Arbeitsweise: Nutze den verlinkten Plan als Arbeitsfläche für Owner, Termine und offene Punkte. Die fachliche Entscheidung muss trotzdem in der Story verständlich bleiben.

• Arbeitsplan — Eingebettete KI-Oberflächen
• Lernpfad — Eingebettete KI-Oberflächen

Starte mit dem kleinsten Fall, der fachlich wichtig genug ist. Prüfe danach, ob die Entscheidung wirklich auffindbar, umsetzbar und auditierbar ist. Rollenklärung: Wer hilft wem an der Quelle.

1. HITL-Matrix für einen Agenten veröffentlichen.
2. Hold-and-Resume für ein write- oder money-Tool aktivieren.
3. Prüfen, dass Audit-Records Call-ID, Actor und Outcome enthalten.
4. Zehn Freigaben auf Rubber-Stamping samplen.