Human-in-the-Loop ist keine Aufsicht. Es ist eine Designdisziplin.

Die Abnahme, die keine war

Bei Marrowfield Specialty Risk führte das diesjährige Frühjahrs-Audit der Schadentriage zu einem kurzen, unbehaglichen Wortwechsel. Der Makler – rund 150 Beschäftigte in einem behördlich beaufsichtigten Markt – betrieb seit achtzehn Monaten ein KI-gestütztes System zur Fallmarkierung. Mariela Okafor, Claims Operations Lead, saß seit zwölf Jahren auf diesem Posten. Die Sachbearbeiter verarbeiteten mehr als 200 Fälle pro Tag; das Modell markierte etwa 8 %. Das Audit zog zwei Zahlen heran: 96 % Freigaben bei KI-markierten Fällen, 23 Sekunden durchschnittliche Prüfzeit. Der Compliance-Verantwortliche fragte: „Auf welche Schwellenwerte haben Sie getunt?" Die Antwort: „Auf keine. Ich gebe einfach frei, was die KI mir schickt."

Marrowfield Specialty Risk ist ein zusammengesetztes Fallbeispiel, gespeist aus Interviews mit mittelständischen Spezialmaklern sowie aus der Compliance-Literatur von BoE/FCA und KI-Verordnung. Namen sind anonymisiert; die Kennzahlen veranschaulichen Muster aus den zitierten Erhebungen.

Bei Aufsichtsbehörden auf drei Kontinenten liest sich dieser Wortwechsel inzwischen als Beleg fehlender Aufsicht. Der Geltungsbeginn der KI-Verordnung im August 2026 setzt dem Designversagen einen Termin, doch das Versagen ist älter als der Termin.

§1 — Passives Abnicken ist Audit-Theater, keine Aufsicht

Das gängige Denkmodell – „die KI markiert, der Mensch gibt frei" – ist strukturell nicht von fehlender Aufsicht zu unterscheiden. Eine Ein-Knopf-Oberfläche ohne Eingabedaten, ohne Modellbegründung, ohne Konfidenzwert erzeugt genau die Kennzahlen, die bei Marrowfield zutage traten. Die Betriebssignatur entspricht einem vollautomatisierten Ablauf mit einer Person in Bereitschaft.

Aufsichtsdaten belegen das auf Populationsebene. Die BoE/FCA-Erhebung AI in UK Financial Services 2024 stellte fest, dass „55 % aller KI-Anwendungsfälle einen gewissen Grad an automatisierter Entscheidungsfindung aufweisen, wobei 24 % davon halbautonom sind, d. h. sie können zwar eigenständig eine Reihe von Entscheidungen treffen, sind aber so ausgelegt, dass sie bei kritischen oder mehrdeutigen Entscheidungen menschliche Aufsicht einbeziehen" [9]. Die Folgerung – im Einklang mit der Risikoperspektive von NIST AI 600-1 auf die Mensch-KI-Konfiguration: Der überwiegende Teil der automatisiert entscheidenden Population hat keinen wirksamen Eingriffspunkt.

Die Aufsichtsbehörden sind angetreten, diese Lücke zu schließen. Die Position des ICO ist unmissverständlich: Eine Entscheidung fällt nicht schon deshalb aus dem Anwendungsbereich von Article 22 UK GDPR heraus, „weil ein Mensch sie ‚abgenickt' hat" [2]. Dieselbe Leitlinie wird beim Betriebsnachweis noch deutlicher: Prüfer, die „den Outputs des KI-Systems routinemäßig zustimmen und nicht nachweisen können, dass sie diese tatsächlich bewertet haben", können nach UK GDPR als ausschließlich automatisiert eingestuft werden [3]. Die KI-Verordnung formuliert in Art. 14 KI-VO einen parallelen Test und verlangt Systeme, die „so konzipiert und entwickelt werden, … dass sie von natürlichen Personen wirksam beaufsichtigt werden können" [1]. Das Wort wirksam trägt in beiden Rechtstraditionen das Gewicht. Die Designfrage lautet nicht mehr „Ist ein Mensch anwesend?", sondern „Ist das Design so beschaffen, dass ein Mensch erkennen, übersteuern und unterbrechen kann – und würde er es tun?"

§2 — HITL ist ein Schwellenwertsystem, kein Prüfschritt

Ernst genommen ist Human-in-the-Loop ein System: explizite Konfidenzschwellen, drei Entscheidungswege, ein risikogewichtetes Raster und eine Warteschlangenrichtlinie. Das Modell liefert einen Konfidenzwert im Bereich 0,0–1,0, und drei Grenzwerte greifen – Auto-Ablehnung unterhalb der Untergrenze, menschliche Prüfung im mittleren Band, Auto-Freigabe oberhalb der Obergrenze. Konservative Startpunkte für regulierte Workflows liegen bei etwa 0,3 / 0,95; der moderate Betrieb bei rund 0,5 / 0,9; die risikoarme Klassifizierung bei 0,7 / 0,95. Die Grenzwerte sind bewusst asymmetrisch: Falsch-Positive und Falsch-Negative tragen unterschiedliche Kosten, und das Schwellenwertsystem bildet diese Asymmetrie ab, statt sie in einer einzigen Zahl zu verbergen. NIST AI RMF 1.0 kommt zum selben Schluss – seine Funktion MANAGE „umfasst die regelmäßige Zuweisung von Risikoressourcen zu den abgebildeten und gemessenen Risiken" [5], und die Schwellenwerte sind der Zuweisungsmechanismus, bemessen am Risiko statt an der Bequemlichkeit.

Darüber liegt ein risikogewichtetes Raster. Die Konfidenz wird mit einem geschäftlichen Risikoschwere-Wert multipliziert – Schadenhöhe, Unumkehrbarkeit der Entscheidung, regulatorische Exposition – und ergibt eine 3×3-Routing-Matrix. Ein Fall mit hohem Risiko und geringer Konfidenz eskaliert an den Vorgesetzten; ein Fall mit hohem Risiko und hoher Konfidenz geht dennoch in die reguläre HITL-Prüfung statt in die Auto-Freigabe. Die Wahl zwischen zwei und drei Stufen ist entscheidend: Ein zweistufiges System trichtert jeden unsicheren Fall in eine einzige Warteschlange, diese läuft über, und die Sachbearbeiter weichen auf Massenfreigabe aus – genau das Muster, das die 96-%-Quote bei Marrowfield erzeugte. Ein dreistufiges System gibt der Auto-Ablehnung eine produktive Rolle. Das Routing setzt eine zentralisierte KI-Strategie^EN mit einem freigegebenen Technologie-Stack voraus, der konsistente Konfidenzwerte erzeugt; ein wildwüchsiger Werkzeug-Flickenteppich macht Schwellenwertdisziplin unmöglich, weil Werte aus verschiedenen Modellen nicht vergleichbar sind.

§3 — Fallback-Pfade werden konzipiert, nicht stillschweigend vorausgesetzt

„Fallback" ist keine Fehlerbehandlung. Es ist der explizite Pfad, den das System einschlägt, wenn die KI unsicher ist – und er braucht einen Weg, eine zuständige Person und ein SLA. Drei Designs decken das Feld ab.

Design A – Human-in-the-Loop, synchron: Die KI hält an und gibt den Fall mit Eingabedatensatz, Begründung und Konfidenz an eine Warteschlange zurück, gegen ein SLA von 2 bis 4 Stunden; geeignet für annähernd echtzeitnahe Entscheidungen. Design B – Warteschlange im Batch, asynchron: Die KI liefert eine vorläufige Antwort und legt sie dann in einem täglichen oder wöchentlichen Stapel mit nachträglichem Override-Fenster vor; geeignet für nicht zeitkritische Arbeit. Design C – Eskalation an Experten, hierarchisch: Das System routet anhand der KI-Unsicherheit plus Risikoschwere in einen mehrstufigen Prüferpool (Standard → Experte → Vorgesetzter) mit SLAs von 4 h / 24 h / 72 h; geeignet für reguliertes Entscheiden – Underwriting-Verweisungen, medizinische Triage, Compliance-Markierungen.

Jeder Fallback braucht einen benannten Verantwortlichen und ein dokumentiertes SLA. Das AI Playbook des UK DSIT formuliert es operativ – „klar dokumentierte Prüf- und Eskalationsprozesse … sowie ein KI-Prüfgremium oder ein Gremium auf Programmebene" [4] –, und NIST AI RMF MANAGE trägt dieselbe Anweisung aus einem anderen Blickwinkel, indem es eine Überwachung nach dem Einsatz mit benannten Feedback-Kanälen verlangt. Das Audit-Antimuster ist stets dasselbe: eine Sammel-Warteschlange „menschliche Prüfung" ohne SLA und ohne Verantwortlichen, in der die Schlange wächst und die KI-Empfehlung zur faktischen Entscheidung wird. Bei Marrowfield wies die Neugestaltung jeden Fallback gezielt zu: Kleinschäden unterhalb eines Wesentlichkeitsbands laufen automatisch durch; Fälle im mittleren Band laufen über Design A mit einem 4-Stunden-SLA; Fälle im oberen Band und unterhalb der Schwelle laufen über Design C mit benannten Underwritern. Die Warteschlangen waren nicht länger ein einziger Überlaufkanal, sondern wurden zu drei Fertigungslinien mit eigenen Kennzahlen und Verantwortlichen.

§4 — Der Override-Audit-Trail ist das Compliance-Artefakt

Was die Prüfer tatsächlich begutachten, ist das Override-Protokoll. Kein Protokoll – oder ein Protokoll ohne strukturierte Begründung – fällt durch den Test, bevor irgendeine erzählerische Verteidigung Gehör findet. Das Mindestartefakt je HITL-Entscheidung ist ein festes Schema: case_id, KI-Konfidenz, KI-Empfehlung, Prüfer-ID, Prüfdauer in Sekunden, menschliche Entscheidung, Override-Begründung, Zeitstempel, policy_version. Ohne policy_version ist der Trail ein Jahr später nicht mehr zu deuten, weil sich die Schwellenwerte verschoben haben werden. Art. 14 Abs. 4 KI-VO verlangt, dass Prüfer „in den Betrieb … eingreifen oder das System unterbrechen" können [1] – und das operative Korollar lautet: Die Fähigkeit muss eine Spur hinterlassen, sonst hat es sie nie gegeben. NIST AI 600-1 formuliert es auf Handlungsebene: „Überwachen und dokumentieren Sie Fälle, in denen menschliche Bediener oder andere Systeme die Entscheidungen der GAI übersteuern" [6]. Das Protokoll ist der zentrale Nachweis wirksamer Prüfung.

Die Rechenschaftspflicht liegt dem Protokoll vorgelagert. Das AI Update der FCA gibt das Prinzip vor: „klare Verantwortungslinien, die über den gesamten KI-Lebenszyklus hinweg etabliert sind" [10]. Firmen unter dem UK SM&CR ordnen den KI- und Betriebs-Stack der Chief-Operations-Funktion zu; US-Firmen führen KI-Ausschüsse auf Vorstandsebene; EU-Firmen folgen den Leitlinien von EBA und EZB zur Rechenschaftspflicht des oberen Managements. Das Prinzip ist über die drei Traditionen hinweg übertragbar, was den Aufbau einer KI-Governance vom ersten Tag an günstiger macht als die nachträgliche Anpassung. ISO/IEC 42001:2023 fasst das weitere Kontrollset als „einen integrierten Ansatz zur Steuerung von KI-Projekten, von der Risikobewertung bis zur wirksamen Behandlung dieser Risiken" [8].

Prüfer achten auf Gegensignale. Eine Prüfdauer unter 10 Sekunden liest sich als Abnicken. Eine Freigabequote über 98 % liest sich als keine Prüfung. Ein leeres Begründungsfeld liest sich als undokumentierte Substanz. Mehr als 200 Entscheidungen pro Tag und Prüfer lesen sich als Ermüdung. Jedes für sich ist ein eigener Befund.

§5 — Wie hält vierteljährliches Tuning HITL ehrlich?

Schwellenwerte sind kein Einmal-Einstellen. Modelle driften, Geschäftsregeln ändern sich, Randfälle treten zutage. Ein vierteljährlicher Zyklus ist die günstigste Disziplin, die ein konzipiertes HITL-System davor bewahrt, in Theater zurückzufallen, und er hat über Rechtsräume hinweg Gewicht: Der Test der „wirksamen" Aufsicht aus Art. 14 KI-VO ist ohne ihn nicht zu erfüllen, und NIST AI RMF MANAGE erwartet vorliegende „Pläne zur Priorisierung von Risiken sowie zur regelmäßigen Überwachung und Verbesserung" [5].

Monat eins – Basislinie messen: HITL-Volumen pro Woche, Override-Rate je Konfidenzband, Verteilung der Zeit bis zur Entscheidung, Eskalationsrate je Stufe. Monat zwei – Driftsignale erkennen: Bänder, in denen die Override-Rate 20 % übersteigt, bedeuten ein unzuverlässiges Modell – das HITL-Band muss erweitert oder das Modell neu trainiert werden; Bänder unter 2 % lassen sich gefahrlos verengen; Design-B-Fälle ohne Prüfung innerhalb des Fensters bedeuten, dass der Batch-Prozess defekt ist. Monat drei – anpassen und dokumentieren: Schwellenwertdefinitionen aktualisieren, policy_version mit dem Änderungsgrund hochzählen, den Betrieb informieren, die Basislinie zurücksetzen.

Der Zyklus setzt eine Prüferkultur voraus, die das Übersteuern trägt. Der ICO ist eindeutig: Wirksame Prüfung verlangt, dass „die Prüfer die Befugnis haben, den vom KI-System erzeugten Output zu übersteuern, und sich sicher sind, dass sie dafür nicht benachteiligt werden" [3]. Dieselbe Erwartung steckt im US-Beschaffungswesen unter dem NIST AI RMF und in den EU-Rechenschaftsregeln unter EBA und EZB – andere Rechtsräume, identischer Betriebstest. Wo die Kultur Abweichung bestraft, brechen die Override-Raten aus kulturellen statt aus technischen Gründen ein, und die Daten, von denen der Zyklus abhängt, werden unbrauchbar. Das UK-DSIT-Playbook benennt die Eigentümerschaft: Ein KI-Prüfgremium oder ein Gremium auf Programmebene verantwortet den Zyklus [4]. Die typische mittelständische Antwort auf „Wer verantwortet das?" ist eine interne Beförderung – siehe das Argument für die beste Besetzung der KI-Leitung^EN aus dem eigenen Haus.

§6 — Welche fünf Antimuster scheitern an einem Audit nach Art. 14 KI-VO?

Dieselben fünf Fehlermuster tauchen in jedem Audit auf.

Ein-Knopf-Oberfläche zum Freigeben/Ablehnen. Der Prüfer sieht nur die Entscheidung. Symptom: Freigabequoten von über 95 %, Prüfungen unter 10 Sekunden. Abhilfe: Konfidenz, Eingabedatensatz und benannte Unsicherheitsfaktoren sichtbar machen. Art. 14 Abs. 4 Buchst. b KI-VO ist beim Automatisierungs-Bias eindeutig – Prüfer müssen „sich der möglichen Neigung bewusst bleiben, sich automatisch oder übermäßig auf den von einem Hochrisiko-KI-System hervorgebrachten Output zu verlassen" [1].

Einzelner Prüfer, keine Rotation. Ein einziger Betriebsleiter prüft jeden HITL-Fall. Symptom: Engpässe am Wochenende, Ermüdungsfehler am späten Tag, eine einzelne Schwachstelle. Abhilfe: ein geschulter Pool aus 3–5 Prüfern nach einem dokumentierten Rotationsplan.

Schwellenwert einmal gesetzt, nie getunt. Die Standardwerte des Anbieters bleiben unverändert. Symptom: HITL-Volumen weit außerhalb des Bands; Override-Raten verdächtig niedrig oder chronisch über 20 %. Abhilfe: der vierteljährliche Zyklus aus §5.

Keine Erfassung der Override-Begründung. Prüfer können übersteuern, doch das Begründungsfeld ist optional oder leer. Symptom: Die Substanz lässt sich nicht nachweisen. Abhilfe: strukturierte Erfassung – ein Auswahlmenü mit den drei häufigsten Gründen plus ein Freitextfeld, beide verpflichtend.

Fallback-Warteschlange ohne SLA. Fälle werden an die „menschliche Prüfung" geleitet, ohne Verantwortung für die Abarbeitung innerhalb eines definierten Fensters. Symptom: Monat für Monat wachsende Schlangenlänge, Prüfer überspringen ältere Einträge. Abhilfe: ein explizites SLA je Fallback plus ein Dashboard zur Warteschlangenüberwachung mit einem benannten Verantwortlichen. Diffuse Eigentümerschaft ist das strukturelle Risiko; die BoE/FCA-Erhebung vermerkt, dass die Rechenschaft „oft aufgeteilt ist, wobei die meisten Firmen drei oder mehr verantwortliche Personen oder Stellen angeben" [9], und Art. 14 KI-VO legt die Aufsicht auf eine benannte „natürliche Person" [1].

§7 — Art. 14 KI-VO und der Kalender für August 2026

Der Compliance-Rahmen ist kein rechtsraumspezifisches Theater. Mehrere Aufsichtsbehörden laufen auf denselben Betriebstest zu; die KI-Verordnung knüpft daran die öffentlichkeitswirksamste Frist. Art. 113 KI-VO setzt den Geltungsbeginn für die Hochrisiko-Pflichten – einschließlich Art. 14 KI-VO – auf den 2. August 2026 [1]. Ab diesem Datum tragen Firmen, die KI in Hochrisiko-Bereichen nach Anhang III einsetzen (Beschäftigung, Kreditscoring, kritische Infrastruktur, strafverfolgungsrelevante Daten), die Pflicht.

Article 22 UK GDPR ist bereits bindend, und sein Test lautet „wirksame menschliche Mitwirkung" [3] – Befugnis, Fachkompetenz, Würdigung von Eingabedaten und Alternativen, eine tragende Kultur und kein Nachteil für das Übersteuern des Modells. Wo Article 22 greift – überall dort, wo eine Entscheidung rechtliche oder ähnlich erhebliche Wirkung entfaltet –, scheitert das „Abnicken" am Test [2]. Die US-Position fehlt nicht: bundesstaatliche Gesetze (Colorado AI Act, NYC AEDT, Kaliforniens geplante ADMT-Regeln) und sektorale Durchsetzung (FTC zu automatisiertem Entscheiden, NIST AI RMF als Beschaffungsreferenz für die Bundesverwaltung) treiben dieselbe Disziplin voran. ISO/IEC 23894:2023 standardisiert den zugrunde liegenden Risikomanagement-Ansatz als „Leitlinien dazu, wie Organisationen … speziell auf KI bezogene Risiken steuern können" [7] – der sauberste außerregulatorische Anker für Märkte, deren KI-spezifische Gesetze noch nicht in Kraft sind, und das Rückgrat jeder rechtsraumübergreifenden Betriebsrichtlinie.

Die Sektoraufsicht verstärkt den Punkt: Die FCA ist technologieneutral [10], die EU-Pendants unter EBA und EZB stimmen in der Rechenschaftspflicht des oberen Managements überein, und die BoE/FCA-Erhebung 2024 zeigt, dass die Rechenschaft in den meisten befragten Firmen typischerweise über drei oder mehr verantwortliche Parteien zersplittert ist [9].

Die Designfragen aus §§2–5 sind die Compliance-Fragen über drei Rechtstraditionen hinweg. HITL auf diese Weise aufzubauen, zahlt man einmal; die nachträgliche Anpassung nach einem Audit-Versagen zahlt man jedes Quartal.

§8 — Wie sieht der vierwöchige HITL-Design-Sprint aus?

Die Neugestaltung ist begrenzt: ein Sprint der Operations-Leitung, kein Programm.

Woche 1 – Ist-Zustand messen. Inventarisieren Sie jeden Schritt „menschliche Prüfung". Ziehen Sie Freigabequoten, Verteilungen der Prüfdauer, den Stand der Override-Erfassung und die Schlangenlängen heran. Signatur des passiven Abnickens: hohe Freigabequote, niedrige Prüfdauer, keine strukturierte Override-Begründung.

Woche 2 – Entscheidungswege gestalten. Setzen Sie Konfidenzgrenzen je Workflow anhand der Startpunkte aus §2. Gestalten Sie Fallback-Pfade nach §3. Definieren Sie das Override-Audit-Schema nach §4. Dokumentieren Sie policy_version v1.0 mit Schwellenwerten, Verantwortlichen und SLAs.

Woche 3 – Umsetzen, schulen, Daten erheben. Setzen Sie die UI-Änderungen um – machen Sie Modellbegründung und Konfidenz auf dem Prüferbildschirm sichtbar. Schulen Sie den Prüferpool anhand durchgearbeiteter Beispiele. Beginnen Sie den Live-Betrieb mit vollständiger Audit-Protokollierung vom ersten Tag an.

Woche 4 – Erste Tuning-Prüfung und prüfungsfertige Dokumentation. Lassen Sie den Zyklus aus §5 gegen die Daten aus Woche 3 laufen; offensichtliche Driftsignale zeigen sich selbst in einem kurzen Fenster. Stellen Sie das Artefaktpaket zusammen: Schwellenwertdefinitionen, Override-Raten-Dashboard, Inventar der Eskalationspfade, Verantwortungskarte. Das Ergebnis ist die Position, mit der Sie sich an 50 Fragen messen können, die Entscheider vor der KI-Einführung stellen^EN – darunter Q3.10, Q5.4, Q5.5 und Q5.7.

Kostenband: 20–40 Stunden Zeit der Operations-Leitung. Ergebnis: ein nach Art. 14 KI-VO aufsichtsfertiges Protokoll, eine nach Article 22 UK GDPR verteidigungsfähige Position zur „wirksamen Prüfung" und eine am NIST-RMF ausgerichtete MANAGE-Funktion.

Von der Abnahme zur Disziplin

Vier Wochen nach der Neugestaltung hat sich das Betriebsbild verschoben. Das HITL-Volumen im Schaden-Workflow ist um 70 % gesunken, weil die Auto-Ablehnung im Band unterhalb der Schwelle echte Arbeit leistet. Die durchschnittliche Prüfzeit bei Fällen, die tatsächlich in HITL gelangen, ist auf etwa vier Minuten gestiegen – die Zeit, die eine strukturierte Prüfung wirklich braucht. Die Override-Rate hat sich bei 14 % stabilisiert, innerhalb des gesunden Bands von 5–20 %, wobei jeder übersteuerte Fall eine strukturierte Begründung trägt. Die Frage des Compliance-Verantwortlichen hat jetzt eine Antwort – mit Versionsnummern versehen.

Der Unterschied zwischen Audit-Theater und prüfungsfester Aufsicht liegt nicht darin, wie ernsthaft eine Firma über menschliche Prüfung spricht. Er liegt darin, ob die Prüfung ein konzipiertes Schwellenwertsystem ist oder eine Ein-Klick-Freigabe. Das eine besteht das Audit nach Art. 14 KI-VO. Das andere nicht.

Für eine Einordnung, wo das HITL-Design über die regulierten Workflows einer Organisation hinweg steht, kartiert easy-audit.ai es in zwei Stunden strukturierter Fragen.

Zusammenfassung

HITL — designed oversight, not passive sign-off
│
├─ The failure · audit theatre
│   ├─ Passive sign-off — one-click approve, no reasoning shown
│   └─ Rubber-stamp test — >98% approve, <10s review fails it
│
├─ The system · thresholds & routes
│   ├─ Three routes — auto-reject / HITL review / auto-approve
│   ├─ Risk overlay — confidence × severity sets escalation
│   └─ Fallback paths — named owner, SLA, override audit log
│
└─ The discipline · stays honest
    ├─ Healthy band — 5–20% override; outside it, tune or retrain
    └─ Quarterly cycle — measure, spot drift, re-version, document