Human in the Loop bei KI-Prozessen: wirksame Kontrolle gestalten

Human in the Loop bedeutet eine echte Entscheidung vor der Wirkung

Human in the Loop, kurz HITL, bezeichnet einen Prozess, in dem eine Person an einem definierten Kontrollpunkt eine KI-gestützte Einschätzung prüft und die nächste Wirkung freigibt, verändert, ablehnt oder eskaliert. Entscheidend ist nicht, dass irgendwo ein Mensch beteiligt ist. Entscheidend ist, ob diese Person die konkrete Aktion noch verhindern oder korrigieren kann.

Ein Beispiel: Ein Modell erkennt eine mögliche Änderung von Lieferantenstammdaten. Die Person prüft Originalanfrage, bestehenden Datensatz, erkannte Abweichung und Zielaktion, bevor ein Workflow das ERP verändert. Eine nachträgliche Sichtung einer bereits ausgeführten Änderung wäre dagegen Überwachung, aber keine Freigabe im engeren Sinn.

Stand 6. Oktober 2026 verlangt Artikel 14 des AI Act für Hochrisiko-KI-Systeme wirksame menschliche Aufsicht. Artikel 26 verpflichtet Betreiber unter anderem dazu, die Aufsicht Personen mit Kompetenz, Schulung, Befugnis und Unterstützung zu übertragen. Ob ein konkretes System in diesen Anwendungsbereich fällt, muss gesondert geprüft werden. Der Beitrag beschreibt eine technische und betriebliche Gestaltung und ersetzt keine Rechtsberatung.

Human in, on und in Command unterscheiden

Die Begriffe Human in the Loop, Human on the Loop und Human in Command helfen bei der Architektur, sind aber keine vollständige rechtliche Einstufung. Bei Human in the Loop hängt eine konkrete Aktion von einer menschlichen Entscheidung ab. Human on the Loop überwacht einen laufenden automatischen Prozess und kann bei Auffälligkeiten eingreifen. Human in Command beschreibt die übergeordnete organisatorische Kontrolle: Menschen legen Zweck, Grenzen, Verantwortlichkeiten und Abschaltmöglichkeiten des Systems fest.

Ein Unternehmen kann mehrere Modelle verbinden. Routinefälle laufen innerhalb enger Positivkriterien automatisch, Stichproben und Kennzahlen werden überwacht und bestimmte Wirkungen bleiben freigabepflichtig. Die Wahl sollte pro Prozessschritt erfolgen – nicht pauschal für ein gesamtes KI-System.

• Human in the Loop: einzelne Entscheidung vor einer definierten Wirkung
• Human on the Loop: laufende Überwachung mit rechtzeitig nutzbarer Eingriffsmöglichkeit
• Human in Command: Zweck, Grenzen, Rollen und Stop-Entscheidungen auf Prozessebene

Den Kontrollpunkt vor die relevante Wirkung setzen

Viele Prozesse platzieren die Prüfung direkt hinter der Modellausgabe. Das ist nicht immer der richtige Punkt. Zwischen einem KI-Vorschlag und der tatsächlichen Wirkung können weitere Regeln, Datenabgleiche und Zielsysteme liegen. Der Kontrollpunkt sollte dort sitzen, wo noch alle Informationen verfügbar sind und eine Fehlentscheidung noch ohne unverhältnismäßigen Aufwand verhindert werden kann.

Bei einem Antwortentwurf kann die relevante Wirkung der Versand an einen Kunden sein. Bei einer Dokumentenprüfung ist es möglicherweise die fachliche Freigabe, nicht die Texterkennung. Bei einem Agenten kann es die Ausführung eines Werkzeugs mit Schreibrechten sein. Eine Prüfung zu früh erzeugt unnötige Arbeit; eine Prüfung zu spät wird zum Bericht über bereits entstandene Folgen.

• Welche Aktion verändert Daten, Geld, Rechte, Kommunikation oder Sicherheit?
• Bis zu welchem Schritt ist eine Korrektur einfach und vollständig möglich?
• Welche Originalinformationen braucht die prüfende Person für ein unabhängiges Urteil?
• Welches System setzt die freigegebene Entscheidung anschließend tatsächlich um?

Mit einer Kontrollmatrix über Automatik und Freigabe entscheiden

Eine belastbare Freigabelogik beginnt nicht bei einem pauschalen Konfidenzwert. Unternehmen sollten Wirkung, Umkehrbarkeit, Unsicherheit, Datenlage und Neuartigkeit gemeinsam bewerten. Daraus entstehen klar abgegrenzte Zonen: automatische Fortsetzung, stichprobenartige Kontrolle, verpflichtende Einzelprüfung oder sicherer Stopp.

Die Matrix wird für konkrete Fallklassen formuliert. Ein bekannter Dokumenttyp mit vollständigem Bestellbezug kann anders behandelt werden als eine freie Nachricht mit Kontodatenänderung. Regeln, Schwellen und Ausschlussgründe benötigen eine Version, einen fachlichen Eigentümer und ein Abnahmedatum.

• Wirkung: Reichweite für Personen, Verträge, Zahlungen, Stammdaten oder öffentliche Kommunikation
• Umkehrbarkeit: Aufwand, Frist und Vollständigkeit einer möglichen Rücknahme
• Unsicherheit: Qualität von Eingabe, Modellantwort, Quellen und fachlichen Abgleichen
• Neuartigkeit: unbekannte Absender, neue Falltypen, geänderte Regeln oder Modellversionen
• Zeitkritik: zulässige Wartezeit und sicherer Zustand bei ausbleibender Entscheidung
• Ergebnis: automatisch fortsetzen, Stichprobe ziehen, zwingend prüfen oder stoppen

Die Prüfoberfläche muss die Entscheidung erklären, nicht nur anzeigen

Ein Freigabedialog mit einem KI-Ergebnis und zwei Schaltflächen fördert schnelles Bestätigen, aber kein fachliches Prüfen. Wirksame Aufsicht zeigt das Original, den abgeleiteten Vorschlag, die angewendete Regel, relevante Gegenbelege und die konkret bevorstehende Systemaktion in einem nachvollziehbaren Zusammenhang.

Unsicherheit darf nicht als scheinbar exakte Zahl ohne Bedeutung erscheinen. Hilfreicher ist eine fachliche Einordnung: Welche Felder sind uneindeutig, welche Quelle fehlt, welcher Abgleich ist gescheitert und welche Folge hätte eine Freigabe? Die Oberfläche sollte Änderungen und Ablehnung genauso einfach ermöglichen wie Zustimmung.

• Originaleingabe und unveränderte Quelldaten
• KI-Vorschlag mit markierten Abweichungen und offenen Punkten
• Regeln, Quellen und Abgleichergebnisse, auf denen der Vorschlag beruht
• Empfänger, Zielsystem und konkrete Aktion nach der Freigabe
• Optionen zum Korrigieren, Ablehnen, Eskalieren und sicheren Unterbrechen

Kompetenz und Befugnis gemeinsam organisieren

Eine Person kann ein Ergebnis nur wirksam beaufsichtigen, wenn sie den Prozess und die Grenzen des eingesetzten Systems versteht. Dazu gehören typische Fehlerbilder, die Bedeutung von Unsicherheit, bekannte Datenlücken sowie der Umgang mit Abweichungen. Eine allgemeine KI-Schulung allein ersetzt keine fallbezogene Fachkompetenz.

Ebenso wichtig ist die Befugnis. Wer wegen Zeitdrucks, Hierarchie oder fehlender Systemrechte nicht ablehnen oder stoppen kann, trägt nur scheinbar Verantwortung. Rolle, Vertretung, Eskalationsweg und Entscheidungsspielraum sollten deshalb vor der technischen Freigabe festgelegt und in Berechtigungen umgesetzt werden.

• fachliche Kompetenz für den betroffenen Prozess und seine Folgen
• Kenntnis der Systemgrenzen, Datenquellen und typischen Fehlermuster
• ausreichende Zeit und eine erreichbare Vertretungsregel
• Berechtigung zum Ändern, Ablehnen, Eskalieren und Stoppen
• organisatorische Unterstützung bei Konflikten oder wiederkehrenden Fehlern

Automatisierungsbias und bloßes Abnicken gezielt begrenzen

Menschen neigen dazu, plausible Systemvorschläge zu übernehmen, besonders bei hohem Volumen und gleichförmigen Aufgaben. Der AI Act nennt für Hochrisiko-KI ausdrücklich das Risiko, sich automatisch auf Ausgaben zu verlassen. Ein menschlicher Klick ist daher kein Qualitätsnachweis.

Gegenmaßnahmen beginnen in der Gestaltung. Die Zustimmung sollte nicht vorausgewählt sein. Kritische Originalinformationen müssen vor oder neben dem Vorschlag sichtbar sein. Gezielte Testfälle, unabhängige Stichproben und Auswertungen nach Ablehnungsgrund zeigen, ob tatsächlich geprüft wird oder lediglich Durchsatz entsteht.

• keine vorausgewählte Freigabe und keine manipulative Hervorhebung der Zustimmung
• Original und Gegenbelege vor einer Entscheidung leicht vergleichbar machen
• gezielt fehlerhafte Testfälle in Schulung und Abnahme verwenden
• Freigaben, Korrekturen und Ablehnungen nach Grund statt nur nach Menge auswerten
• Prüfdichte, Arbeitslast und monotone Fallfolgen im Betrieb beobachten

Ausnahmen, Vertretung und Timeouts als sicheren Zustand planen

Eine Kontrollschleife versagt, wenn niemand erreichbar ist, die Warteschlange unbemerkt wächst oder ein Zielsystem nach einer Freigabe nicht antwortet. Für jeden prüfpflichtigen Fall braucht es daher einen Besitzer, eine Vertretung, eine zulässige Wartezeit und einen definierten Zustand bei Fristablauf.

Der sichere Zustand hängt von der Wirkung ab. Eine Nachricht kann als Entwurf liegen bleiben, eine Stammdatenänderung gesperrt werden und ein zeitkritischer Servicefall an eine Bereitschaft eskalieren. Ein Timeout darf nicht stillschweigend als Zustimmung gelten. Vier-Augen-Freigaben sind dort sinnvoll, wo Wirkung oder bestehende Fachregeln sie begründen – nicht als pauschale Lösung für jede KI-Ausgabe.

Vorschlag, Freigabe und Ausführung technisch trennen

Das KI-System sollte eine vorgeschlagene Aktion mit Vorgangs-ID und Kontext erzeugen, aber nicht automatisch dieselben Rechte besitzen wie der ausführende Prozess. Die Freigabe wird als eigene, authentifizierte Entscheidung gespeichert. Erst eine begrenzte Prozesskomponente überträgt die genehmigte Aktion an ERP, CRM, DMS oder Kommunikationssystem.

Diese Trennung begrenzt Berechtigungen und macht Wiederanläufe kontrollierbar. Bei einer technischen Wiederholung muss geprüft werden, ob die Aktion bereits ausgeführt wurde. Das Zielsystem bestätigt den fachlichen Erfolg mit eigener ID oder Status. Änderungen nach der Freigabe machen eine neue Prüfung erforderlich; ein alter Klick darf keinen veränderten Inhalt autorisieren.

• Vorschlag mit unveränderbarer Version und Vorgangs-ID speichern
• Freigabe an Person, Zeitpunkt, Kontext und konkrete Aktion binden
• ausführende Komponente nur mit den nötigen Zielsystemrechten ausstatten
• Dubletten durch idempotente Übergabe und Ergebnisabgleich verhindern
• Stopp, Rücknahme und Wiederanlauf pro Systemübergang definieren

Beispielprozess: Lieferantenstammdaten kontrolliert ändern

In diesem Anwendungsszenario erkennt ein KI-Modell aus einer eingehenden Nachricht den Wunsch, Bank- oder Adressdaten eines Lieferanten zu ändern. Der Prozess übernimmt die Nachricht unverändert, ordnet den Absender zu und vergleicht erkannte Werte mit bestehenden Stammdaten. Unbekannte Absender, Bankdatenänderungen und widersprüchliche Angaben führen immer in die menschliche Prüfung.

Die zuständige Person sieht Originalnachricht, bisherigen Datensatz, vorgeschlagene Änderung, Abweichungen und das betroffene ERP-Objekt. Sie kann ablehnen, korrigieren oder einen unabhängigen Rückrufprozess auslösen. Nach der Freigabe schreibt nicht das Modell, sondern ein begrenzter Workflow die exakt genehmigten Felder. Das ERP bestätigt die Änderung; Vorgang, Freigabe und Ziel-ID werden miteinander verknüpft.

Das Beispiel zeigt den Unterschied zwischen Modellausgabe und Prozesswirkung. Die KI strukturiert und schlägt vor. Mensch und Fachregel entscheiden. Eine deterministische Schnittstelle führt nur die freigegebene Version aus.

Bei der Abnahme die Kontrolle selbst testen

Ein guter Modelltest genügt nicht. Unternehmen müssen prüfen, ob Menschen relevante Fehler erkennen, rechtzeitig handeln und die Ausführung tatsächlich verhindern können. Dafür werden realistische Grenzfälle, absichtlich falsche Vorschläge, fehlende Quellen und Zielsystemausfälle in einer kontrollierten Umgebung getestet.

Zur Abnahme gehören außerdem Rollen und Wiederanlauf. Kann eine Vertretung übernehmen? Bleibt ein gestoppter Vorgang wirklich ohne Wirkung? Wird nach einer Korrektur nur die neue Version ausgeführt? Erst wenn diese Fragen belegt sind, ist die menschliche Kontrolle mehr als ein Oberflächenelement.

• erkennbare Fehler und schwer erkennbare plausible Fehler getrennt testen
• falsch positive und falsch negative Entscheidungen auswerten
• Zeit bis zur Entscheidung sowie Bestand und Alter der Warteschlange beobachten
• Ablehnung, Änderung, Stopp, Vertretung und Wiederanlauf praktisch durchspielen
• bei Modell-, Regel- oder Schnittstellenänderungen Regressionstests wiederholen

Im Betrieb Wirksamkeit statt Klickzahlen messen

Eine hohe Freigabequote kann ein stabiles System oder wirkungslose Aufsicht bedeuten. Kennzahlen müssen deshalb Wirkung und Kontrollqualität verbinden. Korrekturen und Ablehnungen werden nach Grund erfasst; Stichproben vergleichen freigegebene Fälle erneut mit Original und späterem Ergebnis.

Das Monitoring sollte außerdem erkennen, wann eine Fallklasse ihre bisherige Automatisierungszone verlässt. Neue Dokumenttypen, veränderte Kundengruppen, Modellwechsel oder steigende Eskalationen sind Gründe, Schwellen zurückzunehmen und zeitweise mehr Fälle zu prüfen.

• Korrektur-, Ablehnungs- und Eskalationsquote nach Fallklasse und Ursache
• in Stichproben übersehene Fehler und unnötig vorgelegte Standardfälle
• Bestand, Alter und Wiederholung von Fällen in der Prüfwarteschlange
• ausgelöste Stopps, Rücknahmen und fehlgeschlagene Systemübergaben
• Qualitätsänderungen nach Modell-, Daten-, Regel- oder Prozessversion

Human in the Loop in sieben Schritten umsetzen

Beginnen Sie mit einem klar abgegrenzten Prozess und einer konkreten Wirkung. Die Kontrollarchitektur entsteht dann aus Fachentscheidung, Rollenmodell, Systemgrenzen und Testfällen. Erst danach wird entschieden, welche Standardzone ohne Einzelprüfung laufen darf.

• 1. Prozess, Zweck, betroffene Personen und konkrete Systemwirkungen erfassen
• 2. Fallklassen nach Wirkung, Umkehrbarkeit, Unsicherheit und Neuartigkeit ordnen
• 3. Kontrollpunkt, Prüfinformationen, Rolle, Vertretung und Befugnis festlegen
• 4. Vorschlag, Freigabe und Ausführung technisch sowie in den Rechten trennen
• 5. Ausnahme, Timeout, Stopp, Rücknahme und sicheren Wiederanlauf gestalten
• 6. mit realistischen Fehlerfällen testen und fachlich abnehmen
• 7. begrenzt starten, Wirksamkeit messen und Automatisierungszonen versioniert erweitern