Human Intervention Rate: de ene maatstaf die laat zien of je AI-uitrol echt werkt
De meeste bedrijven die AI-agenten in productie draaien, kunnen niet zeggen hoe vaak die agenten daadwerkelijk een persoon nodig hebben. De Human Intervention Rate is het getal dat die vraag beantwoordt — en aan het eind van dit stuk moet je hem kunnen uitrekenen voor een workflow die je al draait.
FabricLoops eigen kader voor AI-organisaties definieert de Human Intervention Rate helder: het vraagt hoe vaak geautomatiseerd werk een persoon nodig heeft. Dat is de definitie, en dit stuk wijkt er niet van af. Wat volgt is het deel dat de conceptpagina niet helemaal uitschrijft: de echte som, toegepast op één echte workflow, met de getallen die het idee concreet maken in plaats van alleen nastrevenswaardig.
Wat het getal werkelijk meet
De Human Intervention Rate (HIR) is het aandeel van de acties van een agent, binnen één afgebakende workflow en één periode, waarbij een persoon moest ingrijpen voordat de uitkomst als afgerond kon gelden. «Ingrijpen» heeft hier een precieze betekenis: een persoon corrigeerde de output, herriep een beslissing die de agent nam, of beantwoordde een vraag die de agent uitdrukkelijk stelde voordat hij verder zou gaan — wat FabricLoops Loop Agent een ask_human-moment noemt. Deel het aantal van die acties door het totale aantal acties dat de agent in dezelfde periode nam, en je hebt de HIR.
Deze maatstaf hoort naast uptime en nauwkeurigheid, niet eronder, omdat hij iets meet wat die getallen niet zien. Een agent kan op een interne benchmark 95% nauwkeurigheid scoren en toch een slechtere uitrol zijn dan een agent met 80%, als de 5% die hij fout heeft stil doorglipt terwijl de 20% waarover hij onzeker is elke keer wordt gemarkeerd. De HIR vraagt niet of de agent goed is. Hij vraagt of het systeem weet wanneer het een persoon nodig heeft, en of er dan ook echt iemand komt. Die tweede vraag bepaalt of een uitrol veilig kan worden uitgebreid.
HIR berekenen voor één echte workflow
Neem een workflow die een IT- of operationsteam vandaag al kan draaien: een agent die binnenkomende supporttickets triaget, ze classificeert (facturatie, bugrapport, terugbetaling, accounttoegang, enzovoort) en een eerste antwoord opstelt. Elk concept belandt in een reviewwachtrij voordat het een klant bereikt — er gaat niets vanzelf weg. Die reviewstap op zich is geen interventie. Een reviewer die op «versturen» klikt bij een concept dat geen wijzigingen nodig had, is de workflow die werkt zoals hij is ontworpen. Interventie is wat gebeurt wanneer het concept werk nodig had: een reviewer herschreef het, corrigeerde de classificatie, stuurde het ticket naar een andere wachtrij, of de agent zelf pauzeerde halverwege en stelde een vraag voordat hij iets opstelde.
De cijfers hieronder zijn een illustratief voorbeeld, geen data van een echt bedrijf — maar de vorm van het verhaal, en de som erachter, is precies wat je uit je eigen logs bouwt.
In de pilotmaand raakt de agent 640 tickets. Daarvan hebben er 415 een interventie nodig — een herschrijving, een herclassificatie of een omleiding — en slechts 75 van die 415 zijn momenten die de agent zelf markeerde voordat hij iets opstelde. De rest zijn fouten die een reviewer achteraf vangt. Dat is een HIR van 64,8%, met een escalatie-aandeel van slechts 18%: de agent heeft het meestal zelfverzekerd fout op het moment dat hij fout zit, en dat is de slechtste vorm van dit probleem.
Het team trekt het correctielog en labelt elke interventie met een reden. Twee categorieën domineren: de agent leest het restitutiebeleid verkeerd zodra er een bedrag in dollars in zit, en hij stelt kalme, procedurele antwoorden op voor klanten die zichtbaar boos zijn. Beide zijn te repareren zonder het model aan te raken — voeg een expliciete regel toe: elk ticket dat een restitutie boven $50 noemt, of dat boven een sentimentdrempel scoort, triggert een ask_human-escalatie in plaats van een concept. Al het andere wordt nog steeds opgesteld en beoordeeld zoals eerder.
| Maand | Tickets afgehandeld | Interventies | HIR | Escalatie-aandeel |
|---|---|---|---|---|
| 1 — Pilot | 640 | 415 | 64,8% | 18% |
| 2 — Na toegevoegde regels | 810 | 224 | 27,7% | 58% |
| 3 — Regels opnieuw afgesteld | 940 | 101 | 10,7% | 79% |
In maand drie is de HIR met meer dan 80% gedaald, maar het informatievere getal is het escalatie-aandeel: het steeg van 18% naar 79%. Het meeste van wat overblijft is niet de agent die op een fout wordt betrapt — het is de agent die een echt ambigu geval correct herkent (een VIP-account, een beleidsuitzondering, een restitutie die precies op de drempel valt) en vraagt voordat hij handelt. De daling is echt, en verdiend: elke ronde correcties werd teruggevoerd in expliciete regels, zodat de concrete fouten die ze veroorzaakten niet meer terugkwamen, terwijl de categorieën die nog oordeel nodig hebben gemarkeerd blijven in plaats van met een concept te worden omzeild.
De daling die ertoe doet, is die waarbij de agent beter wordt in weten wat hij niet weet — niet die waarbij een persoon stilletjes stopt met controleren.
De fout: nul als doel behandelen
Zodra een team de HIR maand na maand ziet dalen, is de voor de hand liggende volgende vraag hoe laag hij kan. Het instinct is om nul als finish te behandelen — het bewijs dat de agent eindelijk goed genoeg is om zonder toezicht te draaien. Dat instinct staat achterstevoren, en het is de meest voorkomende mislezing van deze maatstaf.
Een workflow die wekenlang 0% interventie laat zien, betekent bijna nooit dat de agent geen fouten meer maakt. Het betekent dat een van twee dingen gebeurde: reviewers lazen de concepten niet meer echt voordat ze ze goedkeurden, of het escalatiepad brak stilletjes — drempels werden versoepeld, een routeringsregel faalde zonder geluid, of de ask_human-trigger stopte met afgaan. Hoe dan ook zegt de nul niet dat het systeem geen persoon meer nodig heeft. Hij zegt dat er niet meer om een persoon wordt gevraagd, of dat die persoon niet meer kijkt.
Het echte doel was nooit minder interventies in het abstracte. Het is een systeem waarin de specifieke momenten die het oordeel van een persoon nodig hebben zichtbaar worden — en alleen die momenten — zodat de aandacht van een persoon gaat naar wat die aandacht echt nodig heeft, in plaats van gelijk over alles te worden verdeeld of helemaal te ontbreken. Een workflow op 12% HIR, waarbij bijna al die 12% de agent is die echt ambigue of risicovolle gevallen correct markeert, is gezonder dan een op 2%, waarbij het grootste deel van die 2% een reviewer is die op een fout stuit die de agent nooit markeerde. Het lagere getal kan het slechtere systeem verbergen.
Daar is het escalatie-aandeel precies voor. Naast de HIR bekeken, vertelt het in welk verhaal je zit:
Als de HIR daalt terwijl het escalatie-aandeel vlak blijft of ook daalt, boek het nog niet als een overwinning. Trek een willekeurige steekproef uit de acties die als «geen interventie nodig» zijn gelogd en laat iemand ze koud beoordelen, zonder te zeggen dat de steekproef als schoon was gemarkeerd. Kijk of downstreamsignalen — heropende tickets, klachten, terugvorderingen van restituties, CSAT — tegelijk omhoog drijven. Een dalende HIR met stijgende downstreamproblemen is geen systeem dat sneller leerde. Het is een systeem dat niemand op tijd ving.
Wat je moet instrumenteren om dit vandaag te meten
Dit vraagt minder om nieuwe tooling dan om het juiste te loggen. De meeste teams die een agent draaien, volgen al volume — hoeveel tickets hij aanraakte, hoeveel taken hij opstelde. Bijna geen van hen volgt de uitkomst, en dat is het enige wat de HIR echt nodig heeft.
- Log een uitkomst voor elke actie, niet alleen een activiteitentelling. Verstuurd zoals het was, bewerkt voor het versturen, afgewezen en herschreven, of geëscaleerd door de agent zelf. Zonder logging op uitkomstniveau is de HIR helemaal niet te berekenen — je weet dat de agent iets deed, niet of het gecorrigeerd moest worden.
- Zet de noemer vast voordat je de teller repareert. Bepaal wat voor deze workflow als één actie telt — één aangeraakt ticket, één opgestelde taak — en houd die definitie stabiel over periodes, zodat een verandering in de HIR het oordeel van de agent weerspiegelt en niet een verandering in hoe je telt.
- Label elke interventie met een reden. «Bewerkt» zegt bijna niets. «Bewerkt: restitutiebeleid boven $50 verkeerd toegepast» zegt precies wat je daarna moet repareren. Een korte, consistente taxonomie maakt van een correctielog een takenlijst in plaats van een scorebord.
- Volg het escalatie-aandeel naast de HIR, niet in plaats ervan. De twee getallen samen zeggen of een daling verdiend of geleend is — zie de trendtabel hierboven.
- Stel een vloer in, geen doel van nul. Bepaal per workflow hoe een plausibele HIR boven nul eruitziet, gegeven hoeveel echte ambiguïteit die workflow bevat, en behandel een percentage dat ver onder die vloer zakt als iets om te onderzoeken, niet om te vieren.
- Rapporteer de HIR per workflow, nooit als één gemengd bedrijfsbreed getal. Een gemiddelde verbergt welke workflow echt minder toezicht heeft verdiend en welke stilletjes risico opstapelt onder een kop die er goed uitziet.
- Controleer de «schone» steekproef op een schema. Haal periodiek acties op die als zonder interventie zijn gelogd en laat iemand ze beoordelen zonder te weten dat ze als schoon waren gemarkeerd. Het is de enige directe check of je reviewers nog lezen.
Daarom is Loop Agent gebouwd rond ask_human, resume en escalatie via kanaal-apps, en niet rond stille autonomie — een agent die pauzeert om te vragen, is een agent die met opzet in de teller van je HIR verschijnt, niet een die per ongeluk werd betrapt. Escalaties en concepten komen in dezelfde Groepen waar het team al werkt, naast taken en notities, zodat het moment dat een persoon nodig had zichtbaar is waar het werk al leeft — niet begraven in een aparte agentconsole die niemand nakijkt. Op Enterprise laten auditlogs IT en operations zien wat agenten deden en precies wanneer een mens ingreep, en dat is de grondstof waaruit de HIR in de eerste plaats wordt gebouwd.
Zet dit naast Leesbaarheid — het begeleidende concept om ook rechten en toegang zichtbaar te maken — en je hebt de twee vragen die elke AI-uitrol moet kunnen beantwoorden voordat hij wordt uitgebreid: wie kan zien wat een agent doet, en hoe vaak moet een persoon daadwerkelijk ingrijpen.