Human-in-the-loop: der Mensch im System

Dritter und letzter Beitrag der Reihe über das Testen von KI-Systemen. Im ersten haben wir den Massstab gebaut, im zweiten haben wir ihn einem Modell in die Hand gegeben. Es bleibt der Mensch.

Das unscharfe Paket ist bereits durch. Diese Qualitätskontrolle ist gut entworfen: es gibt eine Person, sie hat die Befugnis, das Band anzuhalten, sie weiss, wonach sie sucht. Die Frage dieses Beitrags ist, was mit dieser Person im dritten Monat geschieht, wenn das Band nie stehen geblieben ist.

Es gibt einen Satz, den man oft in den Sitzungen hört, in denen entschieden wird, ob eine LLM-gestützte Funktion in Produktion geht: «vorerst setzen wir einen Menschen dazwischen». So gesagt klingt es nach einer Lösung. Tatsächlich ist es der Anfang eines Designproblems, denn «einen Menschen dazwischensetzen» kann fünf verschiedene Dinge heissen, mit völlig unterschiedlichen Kosten, Garantien und Fehlerarten.

Dieser Beitrag versucht, Ordnung zu schaffen: was Human-in-the-loop wirklich bedeutet, welche Varianten es gibt, wann es sinnvoll ist, wann es Theater ist, und vor allem, woran Sie erkennen, ob Ihres funktioniert.

Die Definition, und warum sie nicht reicht

Human-in-the-loop (HITL) bezeichnet jede Architektur, in der ein Mensch ein verbindlicher Knoten im Entscheidungskreis eines automatischen Systems ist. Ohne sein Zutun läuft der Vorgang nicht weiter.

Das Schlüsselwort ist «verbindlich». Kann das System von allein weitermachen, ist man nicht in-the-loop. Dann macht man etwas anderes — was völlig in Ordnung sein kann, aber beim Namen genannt gehört.

Die drei Varianten, plus eine

Human-in-the-loop. Die KI erzeugt einen Output oder schlägt eine Aktion vor. Ein Mensch gibt frei, bearbeitet oder lehnt ab. Erst danach wird die Aktion wirksam. Es ist ein blockierendes Gate: der Preis sind Latenz und menschliche Arbeit, die Garantie ist, dass kein Output die Welt erreicht, ohne unter ein zweites Augenpaar gekommen zu sein.

Human-on-the-loop. Das System handelt eigenständig, ein Mensch beaufsichtigt und kann eingreifen, korrigieren oder alles stoppen. Es gibt keine vorherige Freigabe, es gibt Beobachtung. Die Kosten sind weit geringer, die Garantie ist aber probabilistisch: manche Fehler kommen an und werden nachträglich korrigiert.

Human-out-of-the-loop. Volle Autonomie. Kontrolle gibt es nur im Nachhinein: Logs, Kennzahlen, Alarme, regelmässige Audits und einen Meldekanal. Es ist nicht die Abwesenheit von Kontrolle, es ist Kontrolle, verschoben auf die statistische Ebene statt auf den Einzelfall.

Eine vierte lohnt die Ergänzung, seltener zitiert, in der Praxis aber viel genutzt:

Human-in-the-loop-by-exception. Das System ist standardmässig autonom, aber bestimmte Bedingungen lösen das Gate aus: geringe Konfidenz, Betrag über Schwelle, Kundin in einer bestimmten Kategorie, unumkehrbare Aktion, Eingabe ausserhalb der Verteilung. Es ist der Kompromiss, der sich in der Produktion am besten hält, und zugleich der am schwersten sauber einzustellende.

Das sind nicht vier gleichwertige Etiketten, unter denen man nach Geschmack wählt: es sind vier Punkte auf einer Skala von vollständiger Kontrolle bis zu statistischer Kontrolle, und jeder kostet und garantiert etwas anderes.

Eine weitere, oft verwechselte Unterscheidung: wo im Lebenszyklus

«Human-in-the-loop» wird je nach Punkt im Lebenszyklus für drei verschiedene Dinge verwendet:

Es sind unterschiedliche Tätigkeiten, mit unterschiedlichen Personen und unterschiedlichen Zielen. Sagt jemand im Unternehmen «wir haben HITL», lautet die erste nützliche Frage: in welcher der drei Phasen? Oft stellt sich heraus, dass es eines im Training gibt, keines zur Laufzeit, und in der Bewertung nur dem Namen nach.

In einer Reihe über das Testen interessiert uns vor allem die dritte Phase — aber die zweite bestimmt, was ein Fehler kostet, also behandeln wir sie zusammen.

Die konkreten Muster

In der Praxis nimmt HITL eine Handvoll wiederkehrender Muster an. Sie zu erkennen hilft, das Rad nicht schlecht neu zu erfinden.

Approval Gate

Jede Aktion mit Nebenwirkungen verlangt ausdrückliche Bestätigung. Es ist das typische Agentenmuster: E-Mails senden, Befehle ausführen, in Datenbanken schreiben, Zahlungen, Deployments.

Die entscheidende Entwurfsgrösse ist die Granularität. Jeden einzelnen Schritt eines Agenten zu bestätigen, der vierzig davon macht, ist das perfekte Rezept für den automatischen Klick. Den Plan einmal zu bestätigen und die Ausführung dann laufen zu lassen ist tragfähiger, setzt einen aber aus, wenn der Agent auf halbem Weg vom Plan abweicht. Der Mittelweg, der funktioniert: Freigabe des Plans plus verbindliches Gate ausschliesslich auf unumkehrbaren Aktionen.

Confidence Routing

Unterhalb einer bestimmten Konfidenzschwelle geht der Fall in eine menschliche Warteschlange, darüber läuft er automatisch durch. Es ist das verbreitetste Muster, weil es Kosten und Risiko mit einem einzigen Parameter ausbalanciert.

Der ganze Haken liegt darin, dass die von einem LLM angegebene Konfidenz nicht kalibriert ist. Ein Modell, das «ich bin zu 90% sicher» sagt, hat nicht neun von zehn Malen recht. Verwendet man eine Schwelle, muss sie auf einem kalibrierten Signal beruhen: der Wahrscheinlichkeit eines eigens trainierten Klassifikators, der Streuung über mehrere Ziehungen, der Uneinigkeit zwischen verschiedenen Modellen, dem Vorhandensein oder Fehlen von Belegen im Kontext. Nicht auf dem Satz «confidence: high», den man das Modell hat erzeugen lassen.

Stichprobenreview (Audit)

Alles läuft automatisch durch, aber ein Prozentsatz der Ausgaben wird nachträglich geprüft, um die tatsächliche Qualität zu schätzen.

Reine Zufallsstichproben sind fast immer die schlechteste Verschwendung: liegt die Fehlerquote bei 2%, findet man in hundert Fällen zwei. Besser eine geschichtete Stichprobe: ein Zufallsanteil (für eine unverzerrte Schätzung), plus ein Anteil gezielt auf die Fälle, die das System selbst als zweifelhaft markiert, plus ein Anteil auf seltene oder folgenschwere Fälle. Die drei Anteile beantworten verschiedene Fragen und gehören auch in den Berichten getrennt.

Vorschlag statt Ausführung

Die KI entscheidet nicht: sie füllt vor. Der Mensch bleibt formal Urheber des Akts. Es ist das vorherrschende Muster in Medizin, Recht und Personalwesen, und nicht nur aus Vorsicht: es verschiebt die Verantwortung juristisch sauber.

Vorsicht allerdings, denn es ist auch das Muster, das den meisten Automation Bias erzeugt (dazu gleich). Ein vorausgefülltes Feld ist ein äusserst starker kognitiver Anker: die Person entscheidet nicht mehr, sie sucht nach Gründen, das bereits Geschriebene nicht zu ändern.

Eskalation / Schlichtung

Das System bearbeitet den Normalfall, der Mensch die Ausnahme. Das geht gut, wenn «Ausnahme» sich mit ausdrücklichen Regeln definieren lässt, deutlich schlechter, wenn die Definition «wenn die KI sich geirrt hat» lautet — denn genau diese Information hat man nicht.

Feedback Loop

Jede menschliche Korrektur wird erfasst und wiederverwendet: als Few-Shot-Beispiel, als Fall im Golden Dataset, als Fine-Tuning-Daten, als zusätzliche Regel im Prompt.

Das ist der Teil, den fast alle zu bauen vergessen. Ein HITL, das Ausgaben korrigiert, sie aber nicht sammelt, ist ein Pflaster; ein HITL, das sie sammelt, ist ein Verbesserungsmotor. Der Wertunterschied über 12 Monate ist enorm.

Wann es wirklich gebraucht wird

Das leitende Kriterium sind die Kosten des Fehlers, nicht die Schwierigkeit der Aufgabe. Das ist ein häufiger Irrtum: die Review wird auf die komplizierten Aufgaben gelegt, während sie auf die Aufgaben gehörte, deren Folgen teuer rückgängig zu machen sind.

Die Bedingungen, unter denen ein menschliches Gate gerechtfertigt ist:

• Unumkehrbarkeit. Senden, Löschen, Bezahlen, Veröffentlichen, Deployment in Produktion. Kostet das Rückgängigmachen mehr als das Bestätigen, gehört das Gate hin.
• Folgen für Dritte. Ein abgelehnter Kredit, eine aussortierte Bewerbung, eine Diagnose, eine Meldung. Wer die Entscheidung trägt, ist nicht, wer die Software gekauft hat.
• Regulatorische Vorgaben. Die KI-Verordnung (VO (EU) 2024/1689) verlangt in Art. 14, dass Hochrisikosysteme so gestaltet sind, dass eine wirksame menschliche Aufsicht möglich ist, mit der Fähigkeit, den Output zu interpretieren, zu überwachen und zu übersteuern. Die DSGVO beschränkt in Art. 22 Entscheidungen, die ausschliesslich auf automatisierter Verarbeitung beruhen und rechtliche oder ähnlich erhebliche Wirkung entfalten.
• Zurechenbare Verantwortung. Im Streitfall braucht es jemanden, der unterschrieben hat. Das ist keine Bürokratie: es ist die Bedingung dafür, dass die Organisation die Entscheidung verteidigen kann.
• Junges System. In den ersten Wochen der Produktion hat man keine Vorstellung von der tatsächlichen Fehlerquote. Das Gate dient dazu, die Daten zu kaufen, mit denen man es wieder entfernen kann.
• Fälle ausserhalb der Verteilung. Nie gesehene Eingaben, nicht vorgesehene Sprachen, ungewöhnliche Formate, mehrdeutige Anfragen.

Und die Bedingungen, unter denen es kontraproduktiv ist:

• Hohes Volumen, geringer Einzelwert. Fünfzigtausend Tickets kategorisieren. Die Kosten der Review übersteigen den Schaden der Fehler.
• Enge Latenz. Betrugserkennung in Echtzeit, Moderation von Live-Chats, Handel. Das Gate passt nicht hinein.
• Der Mensch ist objektiv schlechter. Das kommt häufiger vor, als zugegeben wird, vor allem bei langweiligen, repetitiven Aufgaben, bei denen die Aufmerksamkeit nach zwanzig Minuten einbricht.
• Keine echte Eingriffsmacht. Kann die prüfende Person nicht Nein sagen — weil ihr die Informationen fehlen oder weil der Prozess sie fürs Bremsen bestraft —, ist das Gate Theater. Und zwar teures Theater, denn es erzeugt die Dokumentation einer Kontrolle, die nicht stattgefunden hat.

Eine praktische Regel, mit der ich entscheide: kann die prüfende Person unter keinen realistischen Umständen den Fluss blockieren, dann ist sie keine prüfende Person. Sie ist ein bürokratischer Schritt und gehört entfernt oder neu entworfen.

Die Vorteile (die echten)

Es fängt die schlimmste Fehlerkategorie ab. Generative Systeme scheitern nicht laut: sie scheitern, indem sie plausible, gut formulierte, falsche Ausgaben erzeugen. Es gibt keine Exception, keinen Stacktrace, keinen Alarm. Ein sachkundiger Mensch beim Lesen ist bis heute der zuverlässigste Detektor für diese Fehlerklasse.

Es erzeugt Rechenschaft. Es gibt eine Person, die hingesehen und Ja gesagt hat. Das verändert das Gespräch vollständig, wenn etwas schiefgeht.

Es liefert die besten Daten, die Sie je bekommen. Eine menschliche Korrektur ist ein gelabelter Datenpunkt im echten Kontext, in Ihrer Domäne, an einem Fall, den das System tatsächlich falsch gemacht hat. Sie ist zehnmal mehr wert als eine kalt auf einem synthetischen Datensatz erstellte Annotation. Sie ist Rohstoff für das Golden Dataset — das Thema des ersten Beitrags dieser Reihe.

Es erlaubt einen früheren Start. Mit einem Gate kann man mit einem System in Produktion gehen, dem man frei laufend nicht trauen würde, und die ersten Monate nutzen, um die Belege zu sammeln, mit denen man es lockern kann.

Es deckt Compliance-Anforderungen nachprüfbar ab, sofern dokumentiert.

Die Nachteile (die, die niemand auf die Folien schreibt)

Es skaliert nicht

Die Kosten wachsen linear mit dem Volumen. Sieht der Geschäftsplan 10x Traffic vor, sieht HITL mit vollem Gate 10x Prüfende vor. Das trägt nicht, und früher oder später «löst» jemand das, indem er die geforderte Durchsatzmenge pro prüfender Person erhöht — was die elegante Art ist zu sagen, dass die Review unecht wird.

Automation Bias

Das ist Problem Nummer eins, und es ist eher psychologisch als technisch. Menschen neigen dazu, das anzunehmen, was das System vorschlägt, vor allem wenn das System meistens recht hat. Das Phänomen wird seit Jahrzehnten in der Luftfahrt und in der Medizin untersucht, mit zwei getrennten Ausprägungen: Fehler durch Unterlassung (ich bemerke nicht, was das System nicht markiert hat) und durch Begehung (ich übernehme unkritisch eine falsche Ausgabe). Zeitdruck verstärkt beide.

Die bittere Kehrseite: je besser das Modell, desto wirkungsloser wird die Review. Ein zu 99% korrektes System erzieht die Prüfenden dazu, ohne Hinsehen freizugeben — und genau in diesem 1% wäre die Aufmerksamkeit nötig gewesen. Die KI-Verordnung ist sich dessen so bewusst, dass sie das Risiko übermässigen Vertrauens ausdrücklich unter dem nennt, was der aufsichtsführenden Person bewusst gemacht werden muss.

Eine prüfende Person, die alles freigibt, ist schlimmer als gar keine: sie kostet und erzeugt die dokumentierte Illusion von Kontrolle.

Ein Beispiel, das man vermutlich täglich vor Augen hat. Agentische Coding-Assistenten wie Claude Code sind faktisch ein reines Human-in-the-loop: bevor sie einen Befehl ausführen, eine Datei ändern oder eine Abhängigkeit installieren, fragen sie nach Bestätigung. Auf dem Papier ist das der richtige Entwurf. In der Praxis erkennt jeder, der sie ein paar Tage benutzt hat, die Abfolge: die ersten zwanzig Anfragen werden aufmerksam gelesen, die folgenden zweihundert werden zu y, y, y, Enter, Enter. Nicht aus Nachlässigkeit — aus drei strukturellen Gründen, die sich summieren.

Erstens das Volumen: eine nicht triviale Aufgabe erzeugt Dutzende Anfragen, und niemand hält kritische Wachsamkeit über Dutzende aufeinanderfolgende Entscheidungen. Zweitens das Signal-Rausch-Verhältnis: die überwältigende Mehrheit der Anfragen ist harmlos (eine Datei lesen, die Tests laufen lassen), also lernt das Gehirn statistisch, dass die richtige Antwort immer Ja ist. Drittens, und für Systementwerfende am interessantesten: die Kompetenzasymmetrie. Lautet der vorgeschlagene Befehl sed -i 's/.../.../' $(grep -rl ... src/), hat die durchschnittliche Person nicht die Mittel, ihn in zwei Sekunden zu beurteilen. Sie kann ihn lesen, sie kann ihn nicht beurteilen. Und das ist genau der Fall, für den das Gate da sein sollte.

Das Ergebnis ist ein formal vorhandenes und faktisch abgeschaltetes Gate — weshalb diese Werkzeuge auch feingranulare Berechtigungen und Allowlists nach Befehlskategorie anbieten: nicht der Bequemlichkeit wegen, sondern weil das Entfernen der harmlosen Bestätigungen der einzige Weg ist, die Aufmerksamkeit auf die entscheidenden zurückzuholen. Es ist dasselbe Prinzip wie Regel 5 weiter unten: weniger Gates, dafür ernster genommen.

Aus diesem Beispiel lassen sich drei Anforderungen ableiten, die für jedes HITL gelten: das Gate muss selten sein, es muss für die empfangende Person verständlich sein, und es muss zeigen, was sich ändert, nicht nur, was ausgeführt wird.

Review Fatigue

Verwandt, aber verschieden. Das ist keine kognitive Verzerrung, das ist Müdigkeit. Die Qualität der Prüfung bricht mit Häufigkeit und Eintönigkeit ein. Macht eine Person vierhundert Freigaben am Tag, sind die letzten hundert keine Prüfungen.

Moral Crumple Zone

Der Ausdruck stammt von Madeleine Elish und lohnt es, im Kopf behalten zu werden: der Mensch im Kreis droht zur Knautschzone zu werden, die den Aufprall der systemischen Fehler des Modells absorbiert. Formal verantwortlich, materiell ohne Zeit, ohne Informationen oder ohne Befugnis, wirklich zu entscheiden. Geht etwas schief, fällt die Schuld auf ihn — und der strukturelle Mangel des Systems bleibt, wo er ist.

Entwerfen Sie ein HITL, ist das die ethische Frage, die Sie sich stellen sollten: gebe ich dieser Person die Mittel zu entscheiden, oder gebe ich ihr die Verantwortung ohne die Mittel?

Uneinigkeit zwischen Prüfenden

Zwei kompetente Personen entscheiden denselben Fall unterschiedlich. Das ist keine Krankheit, das ist die Norm: in der Annotationsliteratur gilt eine Übereinstimmung zwischen Annotierenden (Cohens Kappa) um 0,6-0,7 als akzeptabel, was heisst, dass ein nicht kleiner Anteil an Uneinigkeit auch unter Fachleuten physiologisch ist. Messen Sie die Übereinstimmung Ihrer Prüfenden nicht, wissen Sie nicht, wie viel Rauschen Sie ins System einspeisen — und in das Golden Dataset, das daraus entsteht.

Reibung und Latenz

Das Gate ist im Produkt sichtbar. Eine nutzende Person, die auf eine menschliche Freigabe wartet, hat ein anderes Erlebnis, und auch das gehört entworfen.

Falsche Sicherheit

Das Metarisiko: das Vorhandensein des HITL wird als Argument benutzt, nicht in automatische Tests, Monitoring und systematische Bewertung zu investieren. «Es gibt ja die Review.» Es ist die Begründung, mit der Systeme jahrelang ungemessen bleiben.

Woran Sie erkennen, ob Ihr HITL funktioniert

Das ist der Teil, der in fast allen Umsetzungen fehlt, die ich gesehen habe. Ein menschliches Gate ist eine Systemkomponente wie jede andere: es gehört gemessen.

Override Rate. Der Anteil der Fälle, in denen die prüfende Person den Vorschlag ändert oder ablehnt. Es ist die aussagekräftigste und die meistmissverstandene Kennzahl.

• Sehr niedrige Override Rate (< 2%): entweder ist das Modell hervorragend, oder die Prüfenden stempeln ab. Die beiden Lagen sind allein aus den Logs nicht unterscheidbar, und um sie zu trennen braucht es anderes (siehe unten).
• Sehr hohe Override Rate (> 30%): das Modell ist für diese Aufgabe nicht bereit, oder der Prompt ist falsch, oder Prüfende und Modell verwenden verschiedene Kriterien — und in diesem letzten Fall liegt das Problem bei der Rubrik, nicht beim Modell.

Blinde Audits. Der Weg, die beiden obigen Fälle zu unterscheiden: speisen Sie regelmässig Fälle mit bekannten Fehlern in den Prüfprozess ein und messen Sie, wie viele davon abgefangen werden. Es ist ein Test der prüfenden Person, nicht des Modells. Er muss den Beteiligten vorher angekündigt werden, sonst wird er zur Überwachung; aber er gehört gemacht, denn er ist das einzige ehrliche Datum über die tatsächliche Wachsamkeit.

Übereinstimmung zwischen Prüfenden. Lassen Sie denselben Satz Fälle von zwei Personen prüfen und berechnen Sie das Kappa. Ist es niedrig, haben Sie kein Modellproblem: Sie haben ein Definitionsproblem. Die Rubrik ist mehrdeutig, und solange sie es bleibt, ist jede auf diesen Urteilen gebaute Kennzahl Rauschen.

Mediane Zeit pro Prüfung. Sinkt sie über die Zeit, kann das heissen, dass die Prüfenden geübter geworden sind — oder dass sie aufgehört haben zu lesen. Kreuzen Sie sie mit der Override Rate: Zeit runter und Override runter zugleich ist ein Alarmsignal, kein Effizienzzeichen.

Fehlerquote nach dem Gate. Wie viele Fehler trotzdem durchgekommen sind, gemessen an Beschwerden, nachgelagerten Korrekturen, Vorfällen. Es ist das Mass für den tatsächlichen Wert des Gate. Ist sie gleich der Quote davor, tut das Gate nichts.

Kosten pro Prüfung und Kosten pro vermiedenem Fehler. Die zweite ist die Zahl, die man braucht, um über eine Lockerung des Gate zu entscheiden. Kostet das Vermeiden eines Fehlers mehr als der Schaden, den dieser Fehler anrichtet, gehört das Gate weg — oder nur auf die Fälle verschoben, in denen sich das Verhältnis umkehrt.

Gut entwerfen: sieben praktische Regeln

1. Machen Sie die Prüfung billig. Zeigen Sie das Diff, nicht den ganzen Text. Heben Sie hervor, was sich ändert, welche Quellen verwendet wurden, was bei einer Freigabe geschieht. Jede eingesparte Lesesekunde ist Aufmerksamkeit, die für den schwierigen Fall übrig bleibt.
2. Zeigen Sie Unsicherheit dort, wo sie ist. Ein durchgehend selbstsicherer Output lädt zur durchgehenden Freigabe ein. Weiss das System, dass es bei einem bestimmten Absatz auf glattem Eis steht, muss es das dort sagen, nicht in einer allgemeinen Fussnote.
3. Die Voreinstellung darf nicht «freigeben» sein. Keine vorausgewählte Schaltfläche, keine Bestätigung mit Enter. Das spart Zeit und zerstört den Wert des Gate.
4. Verlangen Sie eine Handlung, kein Einverständnis. Die Begründung der Ablehnung auswählen zu lassen oder die zwei, drei geprüften Punkte abhaken zu lassen, erzeugt eine qualitativ andere Aufmerksamkeit als der einzelne Klick auf «OK». Es kostet ein paar Sekunden mehr und ändert die Natur der Aufgabe.
5. Verringern Sie die Gates, statt sie zu vermehren. Drei ernst genommene Gates sind besser als dreissig abgestempelte. Jedes zusätzliche Gate senkt den Wert aller anderen.
6. Schliessen Sie den Kreis. Jede Korrektur geht irgendwohin: Datensatz, Prompt, Regeln, Backlog. Sterben die Korrekturen in der Datenbank, haben Sie laufende Kosten ohne Ertrag.
7. Behandeln Sie Autonomie als Parameter, nicht als Ja/Nein-Entscheidung. Nach Aktionskategorie, nicht nach System. «Entwürfe laufen automatisch, Versand verlangt Bestätigung, Löschungen verlangen doppelte Bestätigung» ist eine sinnvolle Richtlinie. «Das System ist beaufsichtigt» ist keine.

Zum letzten Punkt ein Fragment, das die Idee vermittelt. Der Autonomiegrad ist eine Eigenschaft der Aktion, nicht des Systems:

from enum import IntEnum


class AutonomyLevel(IntEnum):
    AUTONOMOUS = 0       # executes immediately, logged for sampling
    NOTIFY_AFTER = 1     # executes, then notifies a human (human-on-the-loop)
    REQUIRE_APPROVAL = 2 # blocks until a human approves (human-in-the-loop)
    DUAL_CONTROL = 3     # requires two distinct approvers


def resolve_level(action, context, approval_threshold=0.85):
    # Irreversible actions never run unattended, regardless of confidence
    if action.is_irreversible and action.impact >= Impact.HIGH:
        return AutonomyLevel.DUAL_CONTROL

    if action.is_irreversible:
        return AutonomyLevel.REQUIRE_APPROVAL

    # Calibrated confidence, not the model's self-reported one
    if context.calibrated_confidence < approval_threshold:
        return AutonomyLevel.REQUIRE_APPROVAL

    if context.is_out_of_distribution:
        return AutonomyLevel.REQUIRE_APPROVAL

    if action.impact >= Impact.MEDIUM:
        return AutonomyLevel.NOTIFY_AFTER

    return AutonomyLevel.AUTONOMOUS

Der Code ist nicht der Punkt. Der Punkt ist, dass diese Funktion existieren muss, für Menschen ohne Programmierkenntnisse lesbar sein muss und sich ändern muss, wenn sich die Daten ändern. In den meisten Projekten liegt diese Logik über sechs verschiedene Stellen verstreut, und niemand kann auf einen Blick sagen, was das System allein tun darf.

Drei Geschichten aus der Praxis

Die Review, die alles freigab. Ein Ablauf zur Erzeugung von Antworten auf Supporttickets, mit verbindlicher Freigabe vor dem Versand. In den ersten zwei Wochen lag die Override Rate bei rund 25%: die Mitarbeitenden korrigierten den Ton, ergänzten Details, schrieben hin und wieder neu. Nach zwei Monaten war sie unter 3% gefallen. Die optimistische Lesart lautete «das Modell ist dank des Feedbacks besser geworden». Die richtige Lesart ergab sich, als wir zwanzig absichtlich falsche Antworten in den Ablauf einspeisten: sechs wurden abgefangen. Das Modell war nicht viel besser geworden; die Mitarbeitenden hatten gelernt, dass es meistens passte. Der Fix war nicht technisch: das Gate wurde auf Tickets mit vertraglichen Zusagen oder Rückerstattungen verengt, und dort stieg die Aufmerksamkeit wieder, weil das Volumen handhabbar war.

Die Uneinigkeit, die nicht dem Modell gehörte. Ein Projekt zur Dokumentenklassifikation, in dem das Modell unvorzeigbar wirkte: rund 40% laut den Prüfenden «falsche» Urteile. Bevor wir den Prompt anfassten, liessen wir dieselbe Stichprobe von zweihundert Dokumenten von zwei unabhängigen Prüfenden durchsehen. Sie waren sich untereinander bei 68% der Fälle einig. Das Modell hatte kein Genauigkeitsproblem: es gab keine geteilte Definition dessen, was die richtige Antwort war. Zwei Tage für eine ausdrückliche Rubrik mit Grenzbeispielen brachten mehr als die vorangegangene Woche Prompt Engineering — und machten es endlich sinnvoll, darauf ein Golden Dataset zu bauen.

Das Gate an der falschen Stelle. Ein Agent, der eine Folge von Operationen auf Unternehmensdaten ausführte, fragte bei jedem Schritt nach Bestätigung. Zwölf, fünfzehn Bestätigungen für eine einzige Aufgabe. Nach einer Woche klickten die Nutzenden «freigeben» im Stakkato, ohne zu lesen — das Verhalten war so mechanisch, dass jemand Enter gedrückt hielt. Das Gate war überall und damit nirgends. Neu entworfen: eine einzige Freigabe des zu Beginn vorgeschlagenen Plans, freie Ausführung für rein lesende Operationen, ein verbindliches und nicht umgehbares Gate nur bei Schreib- und Löschvorgängen. Von fünfzehn Bestätigungen auf zwei — und die zwei wurden tatsächlich gelesen.

Der rote Faden aller drei: das Problem war nie das Modell. Es war der Entwurf der Stelle, an der die Person zur Entscheidung gerufen wurde.

Der regulatorische Rahmen, kurz

Zwei Bezugspunkte, die man kennen sollte, auch ohne Compliance zu machen.

KI-Verordnung (VO (EU) 2024/1689), Art. 14. Sie verlangt, dass Hochrisikosysteme so gestaltet sind, dass natürliche Personen sie wirksam beaufsichtigen können und dabei die Funktionsweise verstehen, den Output interpretieren und ihn übersteuern oder das System anhalten können. Die Massnahmen müssen dem Risiko und der Autonomie des Systems angemessen sein. Für uns relevant: die Norm verlangt ausdrücklich, dass die aufsichtsführende Person in die Lage versetzt wird, sich des Risikos übermässigen Vertrauens in die Ausgaben bewusst zu bleiben — Automation Bias ist also eine Entwurfsanforderung, kein UX-Detail. Für die biometrische Fernidentifizierung ist ein Vier-Augen-Prinzip bei kritischen Entscheidungen vorgesehen, mit abgegrenzten Ausnahmen.

DSGVO (VO (EU) 2016/679), Art. 22. Sie beschränkt Entscheidungen, die ausschliesslich auf automatisierter Verarbeitung beruhen und rechtliche oder ähnlich erhebliche Wirkung für die Person entfalten, mit dem Recht auf menschliches Eingreifen. Achtung auf «ausschliesslich»: eine rein nominelle Aufsicht, bei der die bedienende Person ohne echten Spielraum abnickt, führt die Verarbeitung nicht aus dem Anwendungsbereich der Norm heraus.

Die gemeinsame Botschaft der beiden Normen ist dieselbe, die auch ingenieurmässig gilt: Aufsicht zum Schein zählt nicht. Was praktisch ist, denn es heisst, dass ein HITL gut zu entwerfen und es normkonform zu entwerfen weitgehend dieselbe Arbeit sind.

Wie Sie überleben, während Sie sie aufbauen

• HITL ist nicht eine Sache: unterscheiden Sie in-the-loop, on-the-loop, out-of-the-loop und by-exception, und sagen Sie immer, in welcher Phase (Training, Laufzeit, Bewertung).
• Die Frage ist nicht «wie schwierig ist die Aufgabe», sondern «was kostet der Fehler und wie umkehrbar ist er».
• Der typische Fehlschlag ist nicht die prüfende Person, die sich irrt: es ist die prüfende Person, die ohne Hinsehen freigibt. Entwerfen Sie dagegen.
• Messen Sie das Gate: Override Rate, blinde Audits, Übereinstimmung zwischen Prüfenden, trotzdem durchgekommene Fehler, Kosten pro vermiedenem Fehler.
• Weniger Gates, dafür ernster genommen.
• Jede menschliche Korrektur ist Rohstoff. Sammeln Sie sie nicht, zahlen Sie zweimal.
• Autonomie wird schrittweise und nach Aktionskategorie erhöht, gestützt auf Daten, die das Gate selbst erzeugt hat.

Und vor allem: HITL ist kein Ersatz für die systematische Bewertung. Es ist die Art, zu überleben, während Sie sie aufbauen.

Wo die Reihe schliesst

Skaliert ein Mensch nicht, der alles prüft, ist die naheliegende Versuchung, ihn durch ein weiteres Modell zu ersetzen: das haben wir im zweiten Artikel gesehen, mit den dokumentierten Verzerrungen und der Kalibrierung gegen menschliche Urteile, die es braucht, bevor man es als Kennzahl verwenden kann. Aber ein Richter, automatisch oder menschlich, braucht trotzdem etwas, woran er gemessen wird — und das ist das Golden Dataset aus dem ersten Artikel.

Die drei Dinge sind keine Alternativen zueinander. Sie sind die drei Teile desselben Messapparats, und wer eines auslässt, merkt es spät.

Quellen

• Verordnung (EU) 2024/1689 (KI-Verordnung), Art. 14 — Menschliche Aufsicht: https://eur-lex.europa.eu/legal-content/DE/TXT/PDF/?uri=OJ%3AL_202401689
• AI Act Service Desk, Zusammenfassung zu Art. 14: https://ai-act-service-desk.ec.europa.eu/de/ai-act/article-14
• M. C. Elish, Moral Crumple Zones: Cautionary Tales in Human-Robot Interaction (2019)
• Landis & Koch (1977) und McHugh (2012) zur Auslegung von Cohens Kappa
• Rosbach et al., Automation Bias in AI-Assisted Medical Decision-Making under Time Pressure: https://arxiv.org/abs/2411.00998
• Wu et al., Style Over Substance: Evaluation Biases for Large Language Models: https://arxiv.org/abs/2307.03025