Human Intervention Rate: Die eine Kennzahl, die zeigt, ob Ihr KI-Rollout wirklich funktioniert

Die meisten Unternehmen, die KI-Agenten in Produktion betreiben, können nicht sagen, wie oft diese Agenten tatsächlich eine Person brauchen. Die Human Intervention Rate ist die Zahl, die diese Frage beantwortet – und am Ende dieses Beitrags sollten Sie sie für einen Workflow berechnen können, den Sie schon heute fahren.

FabricLoops eigener Rahmen für KI-Organisationen definiert die Human Intervention Rate klar: Sie fragt, wie oft automatisierte Arbeit eine Person braucht. Das ist die Definition, und dieser Beitrag weicht nicht davon ab. Was folgt, ist der Teil, den die Konzeptseite nicht vollständig ausführt: die konkrete Rechnung, angewandt auf einen echten Workflow, mit den Zahlen, die die Idee konkret machen statt nur erstrebenswert.

Was die Zahl tatsächlich misst

Die Human Intervention Rate (HIR) ist der Anteil der Aktionen eines Agenten – innerhalb eines definierten Workflows und eines Zeitraums –, bei denen eine Person eingreifen musste, bevor das Ergebnis als fertig gelten konnte. „Eingreifen“ hat hier eine konkrete Bedeutung: Eine Person hat die Ausgabe korrigiert, eine Entscheidung des Agenten überschrieben oder eine Frage beantwortet, die der Agent ausdrücklich gestellt hat, bevor er fortfahren würde – was FabricLoops Loop Agent einen ask_human-Moment nennt. Teilen Sie die Anzahl dieser Aktionen durch die Gesamtzahl der Aktionen, die der Agent im selben Zeitraum ausgeführt hat, und Sie haben die HIR.

Der Grund, warum diese Kennzahl neben Verfügbarkeit und Genauigkeit steht und nicht darunter, ist, dass sie etwas misst, das diese Zahlen nicht sehen. Ein Agent kann bei einem internen Benchmark 95 % Genauigkeit erreichen und trotzdem ein schlechterer Rollout sein als einer mit 80 %, wenn die 5 %, die er falsch macht, still durchrutschen, während die 20 %, bei denen er unsicher ist, jedes Mal markiert werden. Die HIR fragt nicht, ob der Agent gut ist. Sie fragt, ob das System weiß, wann es eine Person braucht, und ob eine Person tatsächlich erscheint, wenn das der Fall ist. Diese zweite Frage entscheidet, ob ein Rollout sicher erweitert werden kann.

Die HIR für einen echten Workflow berechnen

Nehmen Sie einen Workflow, den ein IT- oder Operations-Team heute tatsächlich fahren könnte: Ein Agent triagiert eingehende Support-Tickets, klassifiziert sie (Abrechnung, Fehlerbericht, Erstattung, Kontozugang und so weiter) und entwirft eine erste Antwort. Jeder Entwurf landet in einer Prüfwarteschlange, bevor er einen Kunden erreicht – nichts geht von allein raus. Dieser Prüfschritt allein ist keine Intervention. Wenn eine prüfende Person bei einem Entwurf, der keine Änderungen brauchte, auf „Senden“ klickt, arbeitet der Workflow wie vorgesehen. Intervention ist das, was passiert, wenn der Entwurf Arbeit brauchte: Die prüfende Person hat ihn umgeschrieben, die Klassifizierung korrigiert, das Ticket in eine andere Warteschlange umgeleitet, oder der Agent selbst hat mitten in der Aufgabe pausiert und eine Frage gestellt, bevor er überhaupt etwas entworfen hat.

Die Zahlen unten sind ein illustratives Beispiel, keine Daten eines echten Unternehmens – aber die Form der Geschichte und die Rechnung dahinter sind genau das, was Sie aus Ihren eigenen Logs bauen würden.

Im Pilotmonat berührt der Agent 640 Tickets. Davon brauchen 415 eine Intervention – eine Umschreibung, eine Neuklassifizierung oder eine Umleitung – und nur 75 dieser 415 sind Momente, die der Agent selbst markiert hat, bevor er etwas entworfen hat. Der Rest sind Fehler, die eine prüfende Person im Nachhinein entdeckt. Das ist eine HIR von 64,8 %, bei einem Eskalationsanteil von nur 18 %: Der Agent liegt die meiste Zeit, in der er falsch liegt, selbstbewusst falsch – die schlechteste Variante dieses Problems.

Das Team zieht das Korrekturprotokoll und versieht jede Intervention mit einem Grund. Zwei Kategorien dominieren: Der Agent liest die Erstattungsrichtlinie falsch, sobald ein Betrag im Spiel ist, und er entwirft ruhige, verfahrenstechnische Antworten an Kundinnen und Kunden, die sichtbar wütend sind. Beides lässt sich beheben, ohne das Modell anzufassen – eine explizite Regel, dass jedes Ticket mit einer Erstattung über 50 $ oder über einer Stimmungsschwelle eine ask_human-Eskalation auslöst statt eines Entwurfs. Alles andere wird weiterhin entworfen und geprüft wie zuvor.

Bis Monat drei ist die HIR um mehr als 80 % gefallen, aber die aussagekräftigere Zahl ist der Eskalationsanteil: Er stieg von 18 % auf 79 %. Das meiste, was übrig bleibt, ist nicht, dass der Agent beim Falschliegen ertappt wird – es ist, dass der Agent einen wirklich mehrdeutigen Fall richtig erkennt (ein VIP-Konto, eine Richtlinienausnahme, eine Erstattung genau an der Schwelle) und fragt, bevor er handelt. Der Rückgang ist echt, und er ist verdient: Jede Korrekturrunde floss in explizite Regeln zurück, sodass die konkreten Fehler, die sie erzeugt hatten, nicht wiederkehrten, während die Kategorien, die weiterhin Urteil brauchen, markiert werden, statt dass man um sie herum entwirft.

Der Fehler: null als Ziel zu behandeln

Sobald ein Team zusieht, wie die HIR Monat für Monat fällt, ist die naheliegende nächste Frage, wie tief sie sinken kann. Der Instinkt ist, null als Ziellinie zu behandeln – der Beweis, dass der Agent endlich gut genug ist, um unbeaufsichtigt zu laufen. Dieser Instinkt ist verkehrt, und er ist die häufigste Fehldeutung dieser Kennzahl.

Das eigentliche Ziel war nie weniger Interventionen im Abstrakten. Es ist ein System, in dem die konkreten Momente, die das Urteil einer Person brauchen, sichtbar werden – und nur diese Momente –, sodass die Aufmerksamkeit einer Person dorthin geht, wo sie tatsächlich gebraucht wird, statt gleichmäßig über alles verteilt zu werden oder ganz zu fehlen. Ein Workflow bei 12 % HIR, bei dem fast alle dieser 12 % der Agent sind, der wirklich mehrdeutige oder folgenreiche Fälle richtig markiert, ist gesünder als einer bei 2 %, bei dem der größte Teil dieser 2 % eine prüfende Person ist, die über einen Fehler stolpert, den der Agent nie markiert hat. Die niedrigere Zahl kann das schlechtere System verbergen.

Genau dafür ist der Eskalationsanteil da. Neben der HIR betrachtet, sagt er Ihnen, in welcher Geschichte Sie stecken:

Wenn die HIR sinkt, während der Eskalationsanteil flach bleibt oder fällt, verbuchen Sie das noch nicht als Erfolg. Ziehen Sie eine Zufallsstichprobe der Aktionen, die als „keine Intervention nötig“ protokolliert wurden, und lassen Sie jemanden sie unvoreingenommen prüfen, ohne zu sagen, dass die Stichprobe als sauber markiert war. Prüfen Sie, ob nachgelagerte Signale – Tickets, die wieder geöffnet werden, Beschwerden, Erstattungsrückforderungen, CSAT – gleichzeitig nach oben driften. Eine fallende HIR bei steigenden nachgelagerten Problemen ist kein System, das schneller gelernt hat. Es ist ein System, das niemand rechtzeitig erwischt hat.

Was Sie instrumentieren sollten, wenn Sie das heute messen wollen

Nichts davon verlangt so sehr neue Werkzeuge wie das Protokollieren der richtigen Sache. Die meisten Teams, die einen Agenten betreiben, erfassen bereits Volumen – wie viele Tickets er berührt, wie viele Aufgaben er entworfen hat. Fast keines erfasst das Ergebnis, und genau das braucht die HIR.

1. Protokollieren Sie ein Ergebnis für jede Aktion, nicht nur eine Aktivitätszahl. Unverändert gesendet, vor dem Senden bearbeitet, abgelehnt und neu geschrieben, oder vom Agenten selbst eskaliert. Ohne Protokollierung auf Ergebnisebene lässt sich die HIR gar nicht berechnen – Sie wissen, dass der Agent etwas getan hat, nicht, ob es korrigiert werden musste.
2. Fixieren Sie den Nenner, bevor Sie den Zähler fixieren. Entscheiden Sie, was für diesen Workflow als eine Aktion zählt – ein berührtes Ticket, eine entworfene Aufgabe – und halten Sie diese Definition über Zeiträume hinweg stabil, damit eine Änderung der HIR das Urteil des Agenten widerspiegelt und nicht eine Änderung Ihrer Zählweise.
3. Versehen Sie jede Intervention mit einem Grund. „Bearbeitet“ sagt fast nichts. „Bearbeitet: Erstattungsrichtlinie über 50 $ falsch angewandt“ sagt genau, was als Nächstes zu beheben ist. Eine kurze, konsistente Taxonomie macht aus einem Korrekturprotokoll eine Aufgabenliste statt einer Anzeigetafel.
4. Verfolgen Sie den Eskalationsanteil neben der HIR, nicht an ihrer Stelle. Die beiden Zahlen zusammen sagen Ihnen, ob ein Rückgang verdient oder geliehen ist – siehe die Tendenz oben.
5. Setzen Sie eine Untergrenze, kein Ziel von null. Entscheiden Sie pro Workflow, wie eine plausible HIR ungleich null aussieht, gegeben wie viel echte Mehrdeutigkeit dieser Workflow enthält, und behandeln Sie eine Rate, die deutlich unter diese Untergrenze fällt, als etwas, das untersucht werden muss, nicht als etwas, das gefeiert wird.
6. Berichten Sie die HIR pro Workflow, niemals als eine vermischte unternehmensweite Zahl. Ein einzelner Durchschnitt verbirgt, welcher konkrete Workflow tatsächlich weniger Aufsicht verdient hat und welcher still Risiko unter einer gut aussehenden Schlagzeile anhäuft.
7. Prüfen Sie die „saubere“ Stichprobe nach einem Zeitplan nach. Ziehen Sie regelmäßig Aktionen, die als ohne Interventionsbedarf protokolliert wurden, und lassen Sie jemanden sie prüfen, ohne zu wissen, dass sie als sauber markiert waren. Das ist die einzige direkte Prüfung, ob Ihre Prüfenden noch lesen.