Human-in-the-Loop

📋 Auf einen Blick

Human-in-the-Loop (HITL) bedeutet: Ein Mensch ist in den Entscheidungsprozess des AI-Systems eingebunden. Nicht bei jeder Kleinigkeit — sondern bei kritischen, irreversiblen oder unsicheren Entscheidungen. Der EU AI Act macht Human Oversight für Hochrisiko-Systeme zur Pflicht (Art. 14). Aber auch ohne Regulierung ist HITL der Unterschied zwischen einem nützlichen Tool und einer Haftungsfalle.

Warum automatische KI-Entscheidungen gefährlich sind

LLMs sind beeindruckend gut im Generieren plausibler Antworten. Aber "plausibel" ist nicht "korrekt". Wenn ein LLM automatisch Entscheidungen trifft — E-Mails beantwortet, Rechnungen freigibt, Kundendaten ändert — kann ein einzelner Fehler erheblichen Schaden anrichten.

Die drei Hauptrisiken vollautomatischer KI-Entscheidungen:

Halluzinationen in Aktion: Das LLM erfindet eine Kundennummer und ändert den falschen Datensatz.
Irreversible Aktionen: Eine gelöschte Datei, eine gesendete E-Mail, eine freigegebene Zahlung kann nicht rückgängig gemacht werden.
Haftung: Wer haftet, wenn ein AI-Agent eine falsche Entscheidung trifft? Ohne dokumentierte menschliche Aufsicht: das Unternehmen.

⚠️ Praxis-Beispiel

Ein AI-Agent beantwortet Support-Tickets automatisch. Ein Kunde schreibt: "Bitte stornieren Sie mein Abo." Der Agent storniert — aber es war ein Enterprise-Vertrag mit 12 Monaten Laufzeit und Kündigungsfrist. Ohne Human Approval wäre das ein teurer Fehler.

Approval Workflows

Ein Approval Workflow unterbricht den automatischen Ablauf und wartet auf menschliche Freigabe. Der Agent bereitet die Entscheidung vor, aber ein Mensch trifft sie.

Muster	Wann einsetzen	Beispiel
Pre-Approval	Vor jeder kritischen Aktion	Agent zeigt E-Mail-Entwurf, Mensch klickt 'Senden'
Batch Approval	Mehrere Entscheidungen zusammen	Agent sammelt 10 Support-Antworten, Mensch reviewed alle auf einmal
Exception-Only	Nur bei Abweichungen vom Standard	Agent bearbeitet Standard-Tickets selbst, eskaliert nur Sonderfälle
Time-Delayed	Verzögerung vor Ausführung	Agent plant Aktion, 30 Min Wartezeit, automatische Ausführung wenn kein Veto

ℹ️ Balance finden

Zu viele Approvals machen den Agent nutzlos — wenn jede Aktion genehmigt werden muss, kann man es gleich selbst machen. Die Kunst ist, die richtigen Schwellenwerte zu finden: Was kann der Agent allein, was braucht Freigabe?

Escalation Patterns

Escalation bedeutet: Der Agent erkennt selbst, dass er eine Situation nicht sicher bewältigen kann und übergibt an einen Menschen. Das ist kein Fehler — das ist intelligentes Verhalten.

Trigger	Beschreibung	Implementierung
Low Confidence	Agent ist unsicher über die richtige Aktion	Confidence Score < Threshold → Eskalation
Wiederholter Fehler	Agent hat dieselbe Aufgabe bereits falsch bearbeitet	Error Counter pro Task-Typ > 1 → Eskalation
Out of Scope	Anfrage liegt außerhalb des Agent-Mandats	Topic Classification → kein Match → Eskalation
High Impact	Aktion hat potenziell große Auswirkungen	Aktions-Klassifikation: delete, payment, contract → Eskalation
Adversarial Input	Verdacht auf Manipulation oder Injection	Injection Detection Score > Threshold → Eskalation

Escalation-Logik (Pseudocode):

function shouldEscalate(task, confidence, context):
  // Regel 1: Niedrige Confidence
  if confidence < 0.7:
    return { escalate: true, reason: "Low confidence" }

  // Regel 2: Kritische Aktion
  if task.action in ["delete", "payment", "contract_change"]:
    return { escalate: true, reason: "High impact action" }

  // Regel 3: Wiederholter Fehler
  if getErrorCount(task.type, last_24h) > 1:
    return { escalate: true, reason: "Repeated failures" }

  // Regel 4: Injection-Verdacht
  if injectionScore(context.userInput) > 0.8:
    return { escalate: true, reason: "Possible injection" }

  return { escalate: false }

Confidence Thresholds

Confidence Thresholds definieren, ab welchem Sicherheitsgrad der Agent autonom handeln darf. Es gibt drei Zonen:

Zone	Confidence	Verhalten
Grün (Autonom)	> 0.85	Agent führt Aktion aus, loggt Ergebnis
Gelb (Review)	0.6 - 0.85	Agent schlägt Aktion vor, wartet auf Approval
Rot (Eskalation)	< 0.6	Agent stoppt, eskaliert an Menschen mit Kontext

⚠️ LLM Confidence ist unzuverlässig

LLMs sind notorisch schlecht kalibriert — ein LLM kann 95% sicher sein und trotzdem falsch liegen. Confidence Scores sollten deshalb nie die einzige Entscheidungsgrundlage sein. Kombiniere sie mit regelbasierten Checks (z.B. "ist dies eine irreversible Aktion?") und historischen Fehlerraten pro Task-Typ.

Audit Trail & Logging

Ein vollständiger Audit Trail dokumentiert jede Entscheidung des AI-Systems — was wurde entschieden, warum, und wer hat es genehmigt. Das ist nicht nur Best Practice, sondern für Hochrisiko-Systeme unter dem EU AI Act Pflicht.

Was muss geloggt werden?

Audit Trail Entry:
{
  "timestamp": "2026-03-22T14:30:00Z",
  "agent_id": "support-agent-01",
  "task_type": "ticket_response",
  "input": "Kunde fragt nach Vertragskündigung",
  "decision": "escalate_to_human",
  "confidence": 0.62,
  "reason": "High impact action (contract_change) + low confidence",
  "context_chunks": ["vertrag_123.pdf", "kuendigungsfrist.md"],
  "approved_by": "[email protected]",
  "approved_at": "2026-03-22T14:35:00Z",
  "final_action": "manual_response_sent",
  "retention_days": 365
}

Immutability: Logs dürfen nachträglich nicht verändert werden. Append-only Storage.
Retention: DSGVO-konform aufbewahren. Personenbezogene Daten nach definierten Fristen löschen.
Zugänglichkeit: Aufsichtsbehörden müssen Logs einsehen können. Maschinenlesbares Format.

Praxis: n8n Approval Workflow

Ein konkreter Approval-Workflow in n8n für einen Support-Agenten:

n8n Approval Workflow:

1. Trigger: Neues Support-Ticket (Webhook)

2. AI Agent Node (Ollama/OpenAI)
   → Analysiert Ticket: Kategorie, Dringlichkeit, Lösungsvorschlag
   → Output: { category, urgency, confidence, draft_response }

3. Switch Node: Confidence Check
   → confidence > 0.85 UND category == "standard"
     → Direkt senden (mit Disclaimer "KI-generiert")
   → confidence 0.6-0.85 ODER category == "billing"
     → Approval Request (weiter zu Schritt 4)
   → confidence < 0.6 ODER category == "legal"
     → Direkte Eskalation (weiter zu Schritt 5)

4. Approval Request
   → Team-Chat/Slack: Entwurf + Kontext an Support-Team
   → Wait Node: max 4 Stunden
   → Approved? → Senden
   → Rejected? → Manuell bearbeiten
   → Timeout? → Eskalation

5. Eskalation
   → Ticket als "Mensch erforderlich" markieren
   → Assign an nächsten verfügbaren Mitarbeiter
   → AI-Analyse als Kontext anhängen

6. Audit Log (bei jedem Ausgang)
   → Entscheidung, Confidence, Approval-Status loggen

EU AI Act Art. 14: Human Oversight

Artikel 14 des EU AI Act schreibt vor, dass Hochrisiko-AI-Systeme so gestaltet sein müssen, dass sie von natürlichen Personen wirksam beaufsichtigt werden können. Die Kernforderungen:

Anforderung	Was bedeutet das?	Umsetzung
Verstehen	Nutzer muss Fähigkeiten und Grenzen des Systems verstehen	Dokumentation, Training, Confidence-Anzeige
Überwachen	Nutzer muss das System während des Betriebs überwachen können	Dashboard, Alerts, Echtzeit-Logging
Eingreifen	Nutzer muss jederzeit eingreifen oder stoppen können	Kill Switch, Override, Pause-Button
Ignorieren	Nutzer muss AI-Empfehlung ignorieren können	Recommendation statt Automation, Opt-Out

ℹ️ Art. 14 Abs. 4: Angemessene Maßnahmen

Die Überwachungsmaßnahmen müssen dem Risiko angemessen sein. Ein Chatbot, der Öffnungszeiten beantwortet, braucht weniger Oversight als ein System, das Kreditentscheidungen trifft. Die Risikoklasse bestimmt den HITL-Level.

Diagramm wird geladen...

Das Wichtigste

✓Vollautomatische KI-Entscheidungen sind bei kritischen, irreversiblen oder unsicheren Aktionen gefährlich.
✓Approval Workflows: Pre-Approval, Batch, Exception-Only oder Time-Delayed — je nach Risiko und Frequenz.
✓Escalation Patterns: Low Confidence, wiederholter Fehler, Out of Scope, High Impact, Adversarial Input.
✓Drei Confidence-Zonen: Grün (autonom, >0.85), Gelb (Review, 0.6-0.85), Rot (Eskalation, <0.6).
✓Audit Trail ist Pflicht: Timestamp, Decision, Confidence, Approver, Final Action — immutable und DSGVO-konform.
✓EU AI Act Art. 14: Hochrisiko-Systeme müssen verstehbar, überwachbar, unterbrechbar und überstimmbar sein.

Quellen

Verordnung (EU) 2024/1689 — EU AI Act — Artikel 14: Menschliche Aufsicht (Human Oversight)
European Commission — AI Act Regulatory Framework — Übersicht zu Risikoklassen und Pflichten
n8n Documentation — Wait & Approval Nodes — Technische Basis für Approval Workflows
EU AI Act — Wiki-Artikel — Risikoklassen, Verbote, Transparenzpflichten
Safety Hooks Pattern — Guardrails und Output-Validierung
Self-Improving Agents — Self-Eskalation als HITL-Mechanismus

HITL-Workflows implementieren?

Wir helfen beim Design von Approval Workflows und Escalation Patterns — mit n8n, Team-Chat und EU AI Act Compliance.

Beratung anfragen