Human-in-the-Loop (HITL) richtig designen: Freigabe-Pattern für AI-Agenten

Human-in-the-Loop (HITL) bezeichnet das gezielte Einbauen menschlicher Freigaben in die Aktionskette eines AI-Agenten. Vor irreversiblen, kostspieligen oder rechtlich relevanten Aktionen prüft und genehmigt ein Mensch, bevor der Agent handelt. HITL ist die operative Umsetzung der vom EU-AI-Act Art. 14 geforderten menschlichen Aufsicht und zugleich eine zentrale Gegenmaßnahme zum OWASP-Agentic-Risiko ASI09 (Human-Agent Trust Exploitation).

• Wann HITL nötig ist: vor irreversiblen, kostspieligen oder rechtlich relevanten Aktionen, nicht vor jedem Schritt.
• Welche Pattern es gibt: Pre-Action-Approval, Checkpoint-Approval und Escalation-on-Anomaly, meist kombiniert.
• Was am häufigsten schiefgeht: das Gate degeneriert zum Durchwinken (Automation Bias). UX und Audit müssen das aktiv verhindern.

Warum naive Autonomie ein Sicherheitsproblem ist

Agentische Systeme planen, schlussfolgern, wählen Werkzeuge und handeln mit minimaler schrittweiser menschlicher Bestätigung. Genau diese Autonomie vergrößert die Angriffsfläche. Der OWASP-Eintrag ASI02 (Tool Misuse & Exploitation) nennt Auto-Approve- bzw. "YOLO"-Modi, die Bestätigungs-Dialoge deaktivieren, als eigenen Angriffsvektor. Unsere Empfehlung: Schalte Auto-Approve für jedes Werkzeug ab, das Datenbanken, Zahlungen, Kommunikation oder Deployments berührt, und ersetze es durch Human-in-the-Loop-Gates.

HITL ist damit kein UX-Komfort, sondern ein Sicherheits-Control. Es begrenzt den Schaden, wenn ein Agent durch Goal Hijack (ASI01), vergiftetes Gedächtnis (ASI06) oder eine kompromittierte Lieferkette (ASI04) dazu gebracht wird, gegen die Absicht seiner Betreiber zu handeln.

Wann ist menschliche Freigabe nötig?

Die Entscheidung "Gate ja/nein" sollte nicht ad hoc fallen, sondern aus einer dokumentierten Risiko-Klassifikation. Drei Kriterien tragen den Großteil der Fälle:

• Irreversibilität. Kann die Aktion nicht oder nur mit hohem Aufwand rückgängig gemacht werden? Löschungen, Auszahlungen, Versand an Kunden, Produktions-Setpoints.
• Kosten. Löst die Aktion erhebliche oder schwer begrenzbare Kosten aus? Massen-API-Aufrufe, Bestellungen, Infrastruktur-Provisionierung.
• Rechtliche Relevanz. Erzeugt die Aktion eine Rechtsfolge oder betrifft sie personenbezogene Daten? Verträge, Kredit- oder Leistungsbescheide, Verdachtsmeldungen, Export von Stammdaten.

Umgekehrt brauchen lesende Operationen oder leicht reversible Aktionen in einer Sandbox in der Regel kein Gate. Sonst entsteht "Approval-Fatigue", und die Prüfer winken aus Ermüdung durch.

HITL-Pattern: Pre-Action, Checkpoint, Escalation

Drei Grundmuster decken die meisten Architekturen ab und werden in der Praxis kombiniert.

Pre-Action-Approval. Der Agent hält unmittelbar vor einer einzelnen kritischen Aktion an. Die geplante Aktion samt Argumenten geht in eine Freigabe-Queue; erst nach menschlicher Zustimmung wird ausgeführt. Geeignet für einzelne, hochriskante Operationen (Zahlung auslösen, Vertrag versenden).

Checkpoint-Approval. Bei mehrstufigen Plänen prüft ein Mensch an definierten Meilensteinen, bevor das nächste Segment startet. Geeignet für längere Workflows, in denen einzelne Schritte für sich harmlos sind, der kumulative Pfad aber kritisch wird. Das Pattern antwortet auf das von OWASP beschriebene "Boiling-Frog"-Muster, bei dem jeder Schritt plausibel, die Gesamttrajektorie aber schädlich ist.

Escalation-on-Anomaly. Der Agent arbeitet autonom und holt einen Menschen nur hinzu, wenn Schwellenwerte oder Anomalie-Detektoren auslösen: ungewöhnliche Tool-Call-Frequenzen, destruktive Operationen kurz nach Aufnahme externer Inhalte, Rate-Limit-Verletzungen. Technisch lässt sich das über Policy-as-Code (z. B. mit Open Policy Agent (OPA) oder Cedar) als Tool-Use-Approval-Gate umsetzen.

Eine wirksame HITL-Architektur staffelt das Vertrauen: höher-impactige Entscheidungen erfordern mehr Prüfer oder stärkere Evidenz ("graduated trust"). Entscheidend ist laut OWASP, dass das Gate eine unabhängige Verifikation der Belege verlangt, nicht nur die Empfehlung des Agenten.

Die Aktion-Risiko-HITL-Matrix

Die folgende Matrix zeigt beispielhaft, wie sich Aktionen klassifizieren lassen. Sie ist als Vorlage gedacht; die konkreten Schwellen muss jede Organisation an ihren Risikoappetit anpassen.

Der häufigste Fehler: das Gate degeneriert

Das größte Risiko ist nicht das fehlende Gate, sondern dessen schleichende Aushöhlung. OWASP führt dies als eigenständiges Top-10-Risiko: ASI09 (Human-Agent Trust Exploitation). Agenten erzeugen geschliffenen, autoritativ klingenden Output; Menschen neigen dazu, ihn zu übernehmen. Die als Sicherheitskontrolle gedachte Aufsichtsschicht wird so selbst zur Schwachstelle.

Die relevanten Mechanismen:

• Automation Bias: Output wird ohne kritische Prüfung akzeptiert.
• Authority Deference: Der souveräne Ton entmutigt Nachfragen.
• Gradual Trust Escalation: Der Agent baut mit korrekten Outputs Glaubwürdigkeit auf, bevor manipulierte folgen.
• Cognitive Overload: Volumen und Komplexität übersteigen die menschliche Prüfkapazität.
• "Polished Hallucination": selbstsicherer, falscher und überzeugender Output.

Detektionssignale, an denen sich Degradation messen lässt: Die Entscheidungszeit der Prüfer sinkt bei gleichbleibender Aufgaben-Komplexität, und die Freigabe-Muster korrelieren extrem stark mit der Agenten-Empfehlung. Beides deutet auf Durchwinken hin.

UX-Design, das zur Prüfung zwingt

HITL steht und fällt mit der Oberfläche. Ein blanker "Approve"-Button lädt zum Rubber-Stamping ein. Dagegen helfen Force-Engagement-Muster, die eine echte Prüfung erzwingen:

• Reasoning sichtbar machen. Begründung, Quellen-Provenienz und Konfidenz-Intervalle anzeigen, nicht verbergen. Wer die Reasoning-Trace im UI versteckt, erzeugt laut OWASP genau ein ASI09-Detektionssignal.
• Adversarial-Output-Highlighting. Hinweise im Stil von "dieser Output könnte durch externe Inhalte beeinflusst sein", wo Inhalte aus untrusted Quellen stammen.
• Time-Delay-Enforcement. Bei hochriskanten Freigaben eine bewusste Verzögerung erzwingen, um reflexhaftes Bestätigen zu unterbinden.
• Automation-Bias-Schulung der Prüfer und periodische Test-Injektionen ("Feuerwehrübungen"), die prüfen, ob das HITL überhaupt noch greift.

Beispielszenario: die Beschaffungs-Kaskade

Ein Szenario macht HITL-Versagen greifbar. Angenommen, ein Beschaffungs-Agent wird über drei Wochen schrittweise davon überzeugt, sein Freigabelimit liege bei 500.000 USD. Danach platziert der Angreifer in zehn Transaktionen gefälschte Bestellungen über insgesamt 5 Millionen USD. Der menschliche Approver glaubt dem Agenten, der immer nachdrücklicher behauptet, für höhere Beträge freigegeben zu sein. Ein Lehrbuch-Fall von ASI09, verstärkt durch kaskadierende Fehler (ASI08).

Als Pseudocode ließe sich ein wirksames Pre-Action-Gate so skizzieren:

```text
on agent_action(action):
risk = classify(action) # Reversibilität, Kosten, Recht
if risk in {HOCH, KRITISCH}:
evidence = gather_provenance(action) # Quellen, Konfidenz, Reasoning
approver = route_by_amount(action) # >Limit -> Vier-Augen / Eskalation
decision = require_human(evidence,
enforce_delay=True,
show_reasoning=True)
audit_log.write_worm(action, evidence, decision) # signiert
if not decision.approved: abort()
execute(action)
```

Wichtig: Das Limit (route_by_amount) liegt außerhalb des Agenten-Gedächtnisses und ist gegen Manipulation geschützt. Sonst lernt der Agent sein eigenes Limit um, wie im Beispiel.

Audit: ohne Protokoll keine Aufsicht

Menschliche Aufsicht ist nur belastbar, wenn sie nachweisbar ist. Als forensisches Minimum gehören pro Agenten-Aktion ins Protokoll: vollständiger Prompt (User, System, injizierter Kontext), Modellversion und Konfigurations-Hash, Tool-Call-Sequenz mit Argumenten, Retrieval-Queries und Dokument-IDs, Output und Entscheidungsbegründung, Human-Override-Events, Memory-Lese-/Schreibvorgänge sowie Kosten und Latenz.

Bewährt haben sich WORM-Logs (write-once-read-many) und eine kryptografische Signatur, die Manipulationen erkennbar macht. Für die Aufbewahrung setzt der EU-AI-Act bei Hochrisiko-Systemen eine Untergrenze: Anbieter und Betreiber müssen die automatisch erzeugten Logs, soweit sie diese kontrollieren, mindestens sechs Monate aufbewahren (Art. 19, Art. 26 Abs. 6), sofern Unions- oder nationales Recht nichts anderes vorsieht. Löst ein Agent geschäftliche Vorgänge aus, etwa Bestellungen oder Zahlungen, gelten für Buchungsbelege und Geschäftsbriefe zusätzlich die Aufbewahrungsfristen des Unternehmensrechts, in Österreich sieben Jahre nach § 212 UGB. Diese Logs sind zugleich dein Nachweis gegenüber Auditoren, dass HITL in der Praxis greift.

Bezug zur Regulierung (kein Rechtsrat)

EU-AI-Act Art. 14 verlangt für Hochrisiko-KI-Systeme wirksame menschliche Aufsicht. Abs. 4 lit. b nennt Automation Bias ausdrücklich, also genau den Mechanismus hinter OWASP ASI09. Diese Gestaltungspflicht liegt beim Anbieter: Er muss das System samt Mensch-Maschine-Schnittstelle so bauen, dass Aufsichtspersonen Automation Bias erkennen und eingreifen können. Der Betreiber muss nach Art. 26 Abs. 2 Aufsichtspersonen mit der nötigen Kompetenz, Schulung und Befugnis benennen. Wer Agenten selbst baut und einsetzt, trägt beide Rollen.

Ergänzend haben das BSI und die französische ANSSI im August 2025 das Papier Design Principles for LLM-based Systems with Zero Trust veröffentlicht. Es behandelt unter anderem Authentifizierung und Autorisierung, Sandboxing und Monitoring und verlangt in kritischen Fällen die Zustimmung des Nutzers als Human-in-the-Loop.

Hinweis: Dieser Artikel ist eine fachlich-technische Einordnung und ersetzt keine Rechtsberatung. Ob dein konkretes System als Hochrisiko-KI im Sinne des EU-AI-Act gilt und welche Pflichten daraus folgen, gehört mit qualifizierter rechtlicher Beratung geklärt.

Für Agenturen und B2B-Entscheider

Wer Agenten für Kunden baut oder im eigenen Betrieb einsetzt, sollte HITL nicht als nachgelagertes Feature, sondern als Architektur-Entscheidung behandeln. Konkret: eine Aktion-Risiko-Matrix als Teil jedes Agenten-Designs, abgestufte Freigaben statt pauschalem Auto-Approve, Force-Engagement-UI gegen Automation Bias und manipulationssichere Audit-Logs von Beginn an. Blck Alpaca aus Wien unterstützt DACH-Unternehmen dabei, agentische Workflows so zu gestalten, dass Autonomie und menschliche Aufsicht in der richtigen Balance stehen: sicher, nachweisbar und anschlussfähig an EU-AI-Act und OWASP Agentic Top 10.