Människan i loopen — så designar ni granskning och ansvar i AI-flöden

Den vanligaste frågan om AI i drift är inte om systemet kan göra uppgiften. Det är vad som händer när det gör fel. Frågan är rimlig, och svaret avgör ofta om ett system används eller blir liggande. Ett system som ingen litar på används inte, oavsett hur bra det är.

Det gäller för övrigt människor också. Ingen organisation förväntar sig att medarbetare aldrig gör fel. Den förväntar sig att fel upptäcks, rättas och inte upprepas. Samma förväntan är rimlig för ett AI-system.

Lösningen är sällan att göra systemet felfritt, eftersom det inte går. Lösningen är att designa flödet så att människor och system gör det de är bäst på, att det är tydligt var gränsen går och att fel upptäcks innan de får konsekvenser. Det kallas ofta "människan i loopen". Det här kapitlet handlar om hur ni designar den.

Tre nivåer av självständighet

Varje steg i ett AI-flöde kan ha en av tre nivåer av självständighet.

Föreslå. Systemet tar fram ett förslag, och en människa fattar beslutet. Ett utkast till svar, en föreslagen kontering, en rekommenderad kategori. Människan godkänner, ändrar eller avvisar.

Utföra med kontroll. Systemet utför uppgiften själv, men en människa granskar ett urval i efterhand eller får en signal när något avviker. Ärenden sorteras automatiskt, och en ansvarig går igenom stickprov varje dag.

Utföra självständigt. Systemet utför uppgiften utan granskning, och kvaliteten följs upp genom mätning över tid. Det passar för steg där fel är billiga och lätta att rätta, och där systemet har visat att det håller.

De flesta flöden innehåller alla tre nivåerna. Att läsa och sortera ett ärende kan vara självständigt. Att föreslå ett svar kan vara på förslagsnivå. Att skicka ett svar som innebär en ersättning till kunden kan kräva godkännande. Poängen är att bestämma nivån för varje steg medvetet, i stället för att låta den bli en bieffekt av hur systemet råkade byggas.

Så väljer ni nivå

Två frågor avgör vilken nivå ett steg ska ha.

Den första är vad ett fel kostar. Ett felsorterat ärende kostar några minuter när det skickas vidare. En felaktig betalning, ett avtalsbrott eller ett olämpligt svar till en viktig kund kostar betydligt mer. Ju högre kostnad, desto mer kontroll.

Den andra är hur väl systemet har bevisat sig. Ett nytt system har ingen historik. Ett system som har hanterat tiotusen fall med uppmätt kvalitet har det. Nivån bör följa det som har bevisats, inte det som har utlovats.

En enkel matris hjälper. Låg kostnad för fel och bevisad kvalitet: självständigt. Låg kostnad men obevisad kvalitet: utföra med kontroll. Hög kostnad för fel: föreslå, oavsett hur bra systemet verkar. Över tid flyttar steg ofta från föreslå till utföra med kontroll, men sällan hela vägen till självständigt om felen är dyra.

Osäkerhet som designprincip

Den viktigaste egenskapen hos ett system i drift är inte att det har rätt. Det är att det vet när det kanske har fel.

Bygg därför in osäkerhet i varje steg. Systemet ska inte bara ge ett svar, utan också en bedömning av hur säkert svaret är, och en anledning när det är osäkert. "Artikelnumret finns inte i registret." "Beloppet avviker från avtalet." "Kunden skriver om något som inte liknar tidigare ärenden."

Bestäm sedan vad som ska hända vid osäkerhet. Oftast lämnas fallet över till en människa med anledningen synlig. Det gör att granskaren vet vad som ska kontrolleras, i stället för att behöva gå igenom hela fallet från början.

Det finns också regler som inte ska bedömas av modellen alls. Belopp över en viss gräns, nya kunder, ärenden som nämner juridiska ord. Sådana regler skrivs som vanlig kod och skickar fallet till granskning oavsett vad modellen tycker. Det är enkelt, förutsägbart och lätt att förklara.

Designa granskningen, inte bara systemet

Det är vanligt att lägga mycket arbete på själva AI-steget och lite på granskningen. Det är ett misstag. Om granskningen är krånglig blir den antingen långsam, så att effekten försvinner, eller slarvig, så att kontrollen försvinner.

En bra granskning har fyra egenskaper.

1. Allt som behövs finns på ett ställe. Granskaren ser det som kom in, det systemet föreslår, varför, och vilka källor förslaget bygger på. Ingen ska behöva öppna tre system för att kontrollera ett förslag.
2. Det osäkra är markerat. Om systemet var osäkert på ett belopp, markera beloppet. Granskaren ska kunna fokusera på det som behöver kontrolleras.
3. Det är lätt att rätta. Att ändra ett förslag ska gå lika snabbt som att godkänna det. Annars godkänns förslag som borde ha ändrats.
4. Rättelser sparas. Varje ändring är information om var systemet brister. Spara den, så att den kan användas för att förbättra instruktioner och regler.

Ett bra mått på granskningen är hur lång tid den tar per fall. Om det tar nästan lika lång tid som att göra arbetet själv, är det något i designen som inte fungerar.

Fällan med automatisk tillit

Det finns en risk som växer när systemet blir bättre. När nittiofem förslag av hundra är rätt, slutar granskaren att granska. Förslagen godkänns med ett klick, och de fem felen passerar.

Det är ett välkänt fenomen från andra automatiserade system, och det går att motverka.

• Visa inte alltid förslaget först. För vissa fall kan granskaren få bedöma själv innan förslaget visas. Det håller omdömet vid liv.
• Lägg in kontrollfall. Kända fall med ett känt rätt svar, blandade bland de vanliga, visar om granskningen fungerar.
• Variera granskarna. Den som har granskat samma typ av fall i månader ser mindre än den som kommer in med nya ögon.
• Mät andelen ändrade förslag. Om den plötsligt sjunker mot noll kan det betyda att systemet har blivit bättre, men det kan också betyda att granskningen har blivit sämre. Följ upp med stickprov.

Ansvar som inte går att delegera

Ett AI-system kan utföra arbete, men det kan inte ta ansvar. Ansvaret ligger kvar hos verksamheten, och det behöver vara tydligt hos vem.

Bestäm därför tre roller för varje flöde.

• Ägaren ansvarar för att flödet ger rätt resultat, bestämmer nivåerna av självständighet och fattar beslut om förändringar.
• Granskarna ansvarar för de fall de godkänner. Det är deras beslut, inte systemets.
• Förvaltaren ansvarar för att systemet fungerar tekniskt, följer upp kvaliteten och justerar instruktioner och regler.

I mindre organisationer kan samma person ha flera roller. Det viktiga är att någon har varje roll och vet om det.

Dokumentera också vad systemet får och inte får göra. Det behöver inte vara långt. En sida som beskriver flödet, nivåerna, gränserna och rollerna räcker, och den gör det mycket lättare att svara när någon frågar hur systemet fungerar, oavsett om det är en kund, en revisor eller en ny medarbetare.

Ett exempel

Tänk er ett företag som hanterar reklamationer från kunder. Varje vecka kommer ett par hundra ärenden, och en reklamationshandläggare bedömer om varan ska ersättas, repareras eller avvisas.

Flödet byggs i fyra steg med olika nivåer.

1. Läsa och strukturera ärendet sker självständigt. Systemet plockar ut ordernummer, artikel, beskrivning av felet och bilder.
2. Slå upp ordern och garantivillkoren sker självständigt, med en flagga om ordern inte hittas.
3. Föreslå beslut sker på förslagsnivå. Systemet föreslår ersättning, reparation eller avslag och motiverar förslaget med villkoren och felbeskrivningen. Osäkra fall och fall över ett visst belopp markeras.
4. Skicka svar till kunden sker först när handläggaren har godkänt beslutet. Systemet tar fram svaret utifrån beslutet.

Under de första veckorna granskas allt. Efter en tid, när andelen ändrade förslag har varit låg och stabil, flyttas enkla ersättningar under en viss summa till "utföra med kontroll": de godkänns automatiskt och handläggaren går igenom stickprov dagligen. Avslag förblir på förslagsnivå, eftersom ett felaktigt avslag kostar mer i kundrelation än en felaktig ersättning kostar i pengar.

Handläggaren lägger nu sin tid på de svåra fallen och på mönster i reklamationerna som kan skickas vidare till inköp och produkt. Det är arbete som tidigare aldrig hanns med.

Lägg märke till att flödet inte blev helt automatiskt, och att det var ett medvetet val. Den del som automatiserades var den där fel är billiga och kvaliteten bevisad. Den del som blev kvar hos människan var den där omdöme och kundrelation väger tyngst. Det är ofta så ett bra AI-flöde ser ut.

Vad granskarna behöver veta

De som granskar är ofta samma personer som gjorde arbetet för hand. Det är en fördel, eftersom de vet hur ett bra resultat ser ut. Men rollen förändras, och det behöver förklaras.

Granskarna behöver förstå vad systemet gör och inte gör, varför vissa fall lämnas över och andra inte, och hur de rapporterar när något verkar fel. De behöver också veta att deras rättelser används. Ingenting tar död på engagemanget snabbare än att rätta samma fel varje dag utan att något händer.

Ge därför granskarna ett enkelt sätt att markera återkommande problem, och visa regelbundet vad som har ändrats tack vare deras rättelser. Det gör granskningen till ett förbättringsarbete i stället för ett kontrollarbete, och det gör systemet bättre snabbare.

Vanliga misstag

• Att bestämma nivån en gång för alla. Nivån ska följa den bevisade kvaliteten och kunna ändras åt båda hållen. Om kvaliteten sjunker, till exempel efter en förändring i ett av era system, ska steget kunna flyttas tillbaka till tätare granskning.
• Att låta systemet avgöra allt som rör osäkerhet. Modellens egen bedömning är användbar, men den räcker inte. Komplettera alltid med enkla regler för de fall där ni redan vet att en människa ska titta.
• Att mäta systemet men inte granskningen. Om granskarna godkänner fel förslag är kontrollen verkningslös, oavsett hur bra systemet är.
• Att göra granskningen till ett sidouppdrag. Om granskning är något som ska hinnas med mellan annat arbete, blir den slarvig. Planera in tiden.

Hur loopen förändras över tid

Människan i loopen är inte ett permanent tillstånd, utan en process. I början är loopen tät, eftersom systemet inte har bevisat sig. Med tiden blir den glesare där kvaliteten är bevisad och fel är billiga, och förblir tät där fel är dyra.

Det som driver förändringen är mätning. Hur ofta ändras förslag? Vilka typer av fall är osäkra? Hur ofta upptäcks fel i efterhand? Hur ni följer upp kvaliteten över tid beskrivs i kapitlet om kvalitet i drift.

Och förändringen ska vara ett beslut, inte en glidning. När ett steg flyttas till en högre nivå av självständighet ska ägaren ha fattat beslutet utifrån mätningar, och det ska vara dokumenterat. Det skyddar både verksamheten och de människor som arbetar med systemet.

Sammanfattning

• Bestäm medvetet nivån för varje steg: föreslå, utföra med kontroll eller utföra självständigt.
• Låt kostnaden för fel och den bevisade kvaliteten avgöra nivån.
• Bygg in osäkerhet som en del av systemet, och komplettera med enkla regler som alltid skickar vissa fall till granskning.
• Designa granskningen lika noga som systemet: allt på ett ställe, det osäkra markerat, lätt att rätta.
• Motverka automatisk tillit med kontrollfall, variation och uppföljning.
• Ansvaret ligger kvar i verksamheten. Bestäm ägare, granskare och förvaltare för varje flöde.
• Hur ni bygger resten av systemet för drift beskrivs i kapitlet från pilot till drift, och vilka uppgifter som passar för AI i kapitlet om vad AI kan göra i dag.