Mänsklig interventionsgrad: det enda måttet som visar om er AI-utrullning faktiskt fungerar
De flesta företag som kör AI-agenter i produktion kan inte säga hur ofta de agenterna faktiskt behöver att en person kliver in. Mänsklig interventionsgrad är talet som svarar på den frågan — och i slutet av den här texten ska du kunna räkna ut den för ett arbetsflöde du redan kör.
FabricLoops eget ramverk för AI-organisationer definierar mänsklig interventionsgrad rakt av: den frågar hur ofta automatiserat arbete behöver en person. Det är definitionen, och den här texten avviker inte från den. Det som följer är den del som konceptsidan inte skriver ut i sin helhet: den faktiska räkningen, tillämpad på ett verkligt arbetsflöde, med siffrorna som gör idén konkret i stället för bara eftersträvansvärd.
Vad talet faktiskt mäter
Mänsklig interventionsgrad (HIR) är andelen av en agents åtgärder, inom ett avgränsat arbetsflöde och en tidsperiod, som krävde att en person klev in innan utfallet kunde räknas som färdigt. «Kliva in» har en bestämd betydelse här: en person rättade utdata, upphävde ett beslut agenten fattade, eller svarade på en fråga som agenten uttryckligen ställde innan den skulle gå vidare — det som FabricLoops Loop Agent kallar ett ask_human-ögonblick. Dividera antalet sådana åtgärder med det totala antalet åtgärder agenten tog under samma period, och du har HIR.
Måttet förtjänar en plats bredvid drifttid och träffsäkerhet, inte under dem, eftersom det mäter något de talen inte ser. En agent kan visa 95 % träffsäkerhet på ett internt riktmärke och ändå vara en sämre utrullning än en som ligger på 80 %, om de 5 % den har fel slinker igenom tyst medan de 20 % den är osäker på flaggas varje gång. HIR frågar inte om agenten är bra. Den frågar om systemet vet när det behöver en person, och om en person faktiskt dyker upp när det gör det. Den andra frågan avgör om en utrullning är säker att utöka.
Räkna HIR för ett verkligt arbetsflöde
Ta ett arbetsflöde som ett IT- eller driftteam kan köra redan i dag: en agent som triagerar inkommande supportärenden, klassar dem (fakturering, felrapport, återbetalning, kontoåtkomst och så vidare) och skriver ett första svar. Varje utkast hamnar i en granskningskö innan det når en kund — inget skickas av sig själv. Det granskningssteget är i sig inte intervention. En granskare som klickar «skicka» på ett utkast som inte behövde ändras är arbetsflödet som fungerar som det är tänkt. Intervention är det som händer när utkastet behövde arbete: en granskare skrev om det, rättade klassningen, skickade ärendet till en annan kö, eller agenten själv stannade mitt i uppgiften och ställde en fråga innan den skrev något alls.
Siffrorna nedan är ett illustrativt exempel, inte ett verkligt företags data — men historiens form, och räknesättet bakom den, är precis det du bygger av dina egna loggar.
Under pilotmånaden rör agenten 640 ärenden. Av dem behöver 415 en intervention — en omskrivning, en omklassning eller en omstyrning — och bara 75 av de 415 är ögonblick som agenten själv flaggade innan den skrev något. Resten är fel som en granskare fångar i efterhand. Det är en HIR på 64,8 %, med en eskaleringsandel på bara 18 %: när agenten har fel har den oftast fel med självförtroende, vilket är den sämsta varianten av det här problemet.
Teamet tar fram korrektionsloggen och märker varje intervention med en orsak. Två kategorier dominerar: agenten läser återbetalningspolicyn fel så fort ett belopp i dollar är inblandat, och den skriver lugna, procedurmässiga svar till kunder som synligt är arga. Båda går att laga utan att röra modellen — lägg till en uttrycklig regel: varje ärende som nämner en återbetalning över $50, eller som ligger över ett tröskelvärde för känsla, utlöser en ask_human-eskalering i stället för ett utkast. Allt annat skrivs och granskas som förut.
| Månad | Ärenden hanterade | Interventioner | HIR | Eskaleringsandel |
|---|---|---|---|---|
| 1 — Pilot | 640 | 415 | 64,8 % | 18 % |
| 2 — Efter tillagda regler | 810 | 224 | 27,7 % | 58 % |
| 3 — Regler justerade igen | 940 | 101 | 10,7 % | 79 % |
I månad tre har HIR sjunkit med mer än 80 %, men det mer informativa talet är eskaleringsandelen: den steg från 18 % till 79 %. Det mesta som är kvar är inte att agenten ertappas med att ha fel — det är att agenten korrekt känner igen ett genuint tvetydigt fall (ett VIP-konto, ett policyundantag, en återbetalning som ligger precis på tröskeln) och frågar innan den agerar. Nedgången är verklig, och förtjänad: varje omgång korrigeringar matades tillbaka in i uttryckliga regler, så de konkreta felen som gav upphov till dem slutade återkomma, medan de kategorier som fortfarande kräver omdöme fortsätter att flaggas i stället för att skrivas runt.
Den nedgång som betyder något är den där agenten blir bättre på att veta vad den inte vet — inte den där en person tyst slutar kontrollera.
Misstaget: att behandla noll som målet
När ett team ser HIR falla månad för månad är nästa fråga uppenbar: hur lågt kan den gå. Instinkten är att behandla noll som mållinjen — beviset på att agenten till slut blev bra nog att köra utan uppsikt. Den instinkten är bakvänd, och det är den vanligaste feltolkningen av det här måttet.
Ett arbetsflöde som visar 0 % intervention i veckor i sträck betyder nästan aldrig att agenten slutade göra fel. Det betyder att ett av två saker hände: granskare slutade faktiskt läsa utkasten innan de godkände dem, eller eskaleringsvägen gick sönder tyst — trösklar luckrades upp, en dirigeringsregel fallerade utan ljud, eller ask_human-utlösaren slutade avfyras. Hur som helst säger nollan inte att systemet slutade behöva en person. Den säger att en person slutade bli tillfrågad, eller slutade titta.
Det faktiska målet var aldrig färre interventioner i det abstrakta. Det är ett system där de specifika ögonblicken som behöver en persons omdöme lyfts fram — och bara de ögonblicken — så att en persons uppmärksamhet går dit den faktiskt behövs, i stället för att delas jämnt över allt eller utebli helt. Ett arbetsflöde på 12 % HIR, där nästan hela de 12 procenten är agenten som korrekt flaggar genuint tvetydiga eller högriskfall, är friskare än ett på 2 %, där det mesta av de 2 procenten är en granskare som snubblar över ett fel agenten aldrig flaggade. Det lägre talet kan dölja det sämre systemet.
Det är precis vad eskaleringsandelen är till för. Sedd bredvid HIR säger den vilken historia du är i:
Om HIR sjunker medan eskaleringsandelen ligger stilla eller också sjunker, bokför det inte som en vinst än. Dra ett slumpmässigt urval av åtgärder loggade som «ingen intervention behövdes» och låt någon granska dem kallt, utan att säga att urvalet flaggats som rent. Kontrollera om signaler nedströms — återöppnade ärenden, klagomål, återkrav av återbetalningar, CSAT — driver uppåt samtidigt. En fallande HIR med stigande problem nedströms är inte ett system som lärde sig snabbare. Det är ett system som ingen fångade i tid.
Vad du ska instrumentera om du vill mäta det här i dag
Inget av det här kräver nya verktyg så mycket som det kräver att du loggar rätt sak. De flesta team som kör en agent följer redan volym — hur många ärenden den rörde, hur många uppgifter den skrev. Nästan inget av dem följer utfallet, och det är det enda HIR faktiskt behöver.
- Logga ett utfall för varje åtgärd, inte bara en aktivitetsräkning. Skickat som det var, redigerat före sändning, avvisat och omskrivet, eller eskalerat av agenten själv. Utan loggning på utfallsnivå går HIR inte att räkna alls — du vet att agenten gjorde något, inte om det behövde rättas.
- Lås nämnaren innan du rättar täljaren. Bestäm vad som räknas som en åtgärd i det här arbetsflödet — ett ärende som rörts, en uppgift som skrivits — och håll den definitionen stadig över perioder, så att en förändring i HIR speglar agentens omdöme och inte en förändring i hur du räknar.
- Märk varje intervention med en orsak. «Redigerad» säger nästan ingenting. «Redigerad: återbetalningspolicy över $50 felaktigt tillämpad» säger exakt vad som ska lagas härnäst. En kort, konsekvent taxonomi gör en korrektionslogg till en åtgärdslista i stället för en resultattavla.
- Följ eskaleringsandelen tillsammans med HIR, inte i stället för den. De två talen tillsammans säger om en nedgång är förtjänad eller lånad — se trendtabellen ovan.
- Sätt ett golv, inte ett mål på noll. Bestäm, per arbetsflöde, hur en rimlig HIR skild från noll ser ut givet hur mycket verklig tvetydighet flödet innehåller, och behandla en andel som faller långt under det golvet som något att undersöka, inte att fira.
- Rapportera HIR per arbetsflöde, aldrig som ett enda blandat tal för hela företaget. Ett genomsnitt döljer vilket flöde som faktiskt har förtjänat mindre uppsikt och vilket som tyst samlar risk under en rubrik som ser bra ut.
- Kontrollera det «rena» urvalet enligt schema. Plocka med jämna mellanrum åtgärder loggade som utan behov av intervention och låt någon granska dem utan att veta att de flaggats som rena. Det är den enda direkta kontrollen av att granskarna fortfarande läser.
Därför är Loop Agent byggd kring ask_human, resume och eskalering via kanalappar, snarare än kring tyst autonomi — en agent som pausar för att fråga är en agent som med avsikt syns i täljaren för din HIR, inte en som ertappades av en slump. Eskaleringar och utkast dyker upp i samma Grupper där teamet redan arbetar, bredvid uppgifter och anteckningar, så att ögonblicket som behövde en person syns där arbetet redan lever — inte begravt i en separat agentkonsol som ingen tittar i. I Enterprise låter granskningsloggar IT och drift se vad agenter gjorde och exakt när en människa klev in, vilket är råmaterialet som HIR byggs av från början.
Para ihop det med Läsbarhet — det medföljande konceptet för att också göra behörigheter och åtkomst synliga — och du får de två frågor varje AI-utrullning ska kunna svara på innan den utökas: vem kan se vad en agent gör, och hur ofta behöver en person faktiskt kliva in.