Tankeledare

Människan i loopen är inte styrning

mm
Lägg till Unite.AI bland dina föredragna källor på Google

Det uppenbara svaret på AI-risk är “sätt en människa i loopen”. Men denna fras döljer den svåra delen.

En människa i loopen fungerar bara om loopen är utformad. Annars blir människan en av tre fel:

  • En flaskhals, eftersom granskning av AI-utdata tar lika lång tid som att utföra arbetet manuellt.
  • En gummikläm, eftersom granskaren är överbelastad, inte kan se bevisen, inte förstår affärssammanhanget och klickar på godkänn för att hålla kön rörlig.
  • Eller det tredje felet: kraschzonen. Genom att lägga till en människa i loopen namnger institutionen en ansvarig person, men ger den personen ingen verklig kontroll, ingen tid, ingen behörighet, ingen möjlighet att stoppa systemet och ingen möjlighet att ändra nästa körning. Konsekvensen faller på människan, medan beslutsunderlaget förblir oförändrat.

Här är där mycket av samtalet kring företags-AI går fel. Vi pratar om huruvida en människa bör granska arbetet, men inte om hur den granskningen är utformad. Vi antar att tillägget av en person skapar styrning. Det gör det inte. Styrning beror på om granskaren har meningsfull kontroll, meningsfull synlighet och möjlighet att förbättra systemet efter att beslutet har fattats.

Mänsklig granskning är värdefull, men bara när den är placerad där omdöme är viktigt och stöds av tillräckligt med sammanhang för att göra det omdömet meningsfullt.

En valideringsgrind är mer än ett granskningssteg

En grind är inte en pausknapp. Det är ett verifieringsgränssnitt.

När en agent eller automatisering producerar ett förslag – ett utkast till svar, en rekommenderad åtgärd, en klassificering, en betalningsgodkännande, en ärendemottagning, en återbetalningspaket eller ett avslagsbrev – bör granskaren omedelbart förstå vad som är på väg att hända och varför.

En riktig valideringsgrind måste visa vad som är viktigt: det föreslagna tillvägagångssättet; källorna bakom det; reglerna som kontrollerats; affärstransaktionen som kommer att ske; behörigheten som används; revisionsposten som kommer att skrivas; osäkerheten eller undantaget som utlöste granskning; och de tillgängliga valen: godkänn, redigera, avvisa eller eskalera.

Var och en av dessa element finns till för en anledning. Det föreslagna tillvägagångssättet förklarar vad systemet avser att göra. Bevisen förklarar varför. Reglerna och behörigheten visar om rekommendationen passar inom organisationens policy. Osäkerheten berättar för granskaren varför arbetet nådde en människa i första hand. Tillsammans omvandlar de granskning från gissning till verifiering.

Om granskaren måste återupprätta allt detta manuellt är grinden inte byggd.

Syftet med grinden är inte bara att stoppa misstag innan de händer. Dess andra syfte är viktigare. Den fångar institutionens omdöme.

Här börjar företagsdistributionen samla. Varje verkligt godkännande, redigering, avvisande eller eskalering av beslut fångar institutionens omdöme – men bara om grinden fångar varför.

Godkännanden är inte data, men verifieringar är.

En gummiklämd klick fångar ingenting användbart. Ett inspekterat, redigerat, avvisat eller eskalerat beslut med en orsakskod fångar en signal som nästa version av systemet kan lära sig av. Om granskaren klickar på godkänn utan att titta lär systemet ingenting. Om granskaren redigerar, avvisar, eskalerar och ger en orsakskod fångar institutionen omdöme.

Med tiden blir dessa omdömen en av organisationens mest värdefulla tillgångar. De avslöjar var policys är otydliga, var arbetsflöden konsekvent bryter samman, var undantag förekommer oftast och var automatisering bör bli mer självsäker – eller mer begränsad. Målet är inte bara att automatisera mer arbete. Det är att förbättra kvaliteten på framtida beslut genom att fånga hur erfarna människor utövar omdöme idag.

Ansvar kräver mer än en namngiven ägare

Den distinktionen ändrar hur organisationer bör tänka på ansvar också.

En grind räcker inte. En namngiven ägare räcker inte. En revisionslogg räcker inte.

Ansvar kräver konsekvensmottagning: misstaget måste landa någonstans som kan ändra framtida beteende.

Innan du distribuerar AI i konsekvensfullt arbete bör organisationer ställa fem frågor:

  1. Vem tar emot konsekvensen om denna åtgärd är fel?
  2. Hade den personen eller systemet meningsfull kontroll före åtgärden?
  3. Kan den ansvarige ägaren inspektera, begränsa, åsidosätta eller stoppa agenten eller automatiseringen?
  4. Är ansvar proportionellt mot den kontroll som ägaren faktiskt hade?
  5. Vad ändras före nästa körning: färdighet, regel, behörighet, arbetsflöde, automatisering, valideringsgrind, orsakskod, utbildning eller förtroendeklass?

En mänsklig grind utan meningsfull kontroll är inte styrning. Det är en kraschzon.

Loopen är inte stängd tills den fångade omdömet ändrar något: färdighet, regel, behörighet, eskaleringströskel, automatisering, test, granskningsgränssnitt, utbildningsplan, revisionsprov, eller förtroendeklass. En konsekvens som inte ändrar nästa körning är bara en incident, inte inlärning. Organisationer förbättras när varje meningsfull granskning ändrar nästa version av systemet, antingen genom att finslipa policy, strama upp behörigheter, förbättra automatisering eller stärka valideringsupplevelsen själv.

Stödstrukturer förhindrar fel. Utvärderingar bygger förtroende.

Organisationer behöver också skilja mellan stödstrukturer och utvärderingar. De löser olika problem som behöver lösningar.

  1. Stödstrukturer tvingar fram beteende vid körning. Schema kontroller, osäkra parametrar blockerare, behörighetskontroller, PII radering, prompt injektionsförsvar och verktygsanvändningsbegränsningar finns till för att förhindra osäkert beteende innan det händer.
  2. Utvärderingar mäter prestanda över tid. De undersöker kvalitet, drift, verktygsval, eskaleringens kvalitet, kostnad, latens och policyefterlevnad. De berättar för organisationen om systemet fortsätter att förtjäna förtroende.

En skyddar det nuvarande beslutet. Den andra förbättrar framtida beslut.

Stödstrukturer och utvärderingar tjänar olika syften, och så gör också de människor som är ansvariga för dem. Plattformen tvingar fram policy. Operatörer utvärderar resultat. Tillsammans skapar de återkopplingsloop som tillåter systemet att förbättras utan att offra styrning.

Systemet hämtar policyn, anspråksposten, stöddokumenten, tidigare fall, och organisationens playbook. Det förbereder triage-paketet, föreslår allvarlighetsgrad, identifierar saknad bevisning och öppnar en underärende för bedrägeri om reglerna kräver det. Adjusteraren ser det föreslagna tillvägagångssättet, bevisen, orsakskoden, revisionsposten och konsekvensen av godkännande. Istället för att återupprätta fallet från flera system kan granskaren fokusera på att validera rekommendationen själv. Först efter validering uppdaterar automatiseringen fallet, utfärdar betalning, begär ytterligare dokumentation eller stänger arbetet.

Ett anspråksarbetsflöde demonstrerar hur detta fungerar i praktiken. Agenten memoriserade inte en process. Den agerade inom en publicerad karta.

Arkitektur bör följa arbetet

Samma princip gäller oavsett hur arbetet själv är organiserat. Inte alla företagsproblem har samma form, och styrning bör återspegla det. Vissa arbeten börjar med ett mål. Vissa börjar med ett ärende; vissa börjar med ett stabilt arbetsflöde. Arkitekturen bör följa arbetet, inte tvärtom.

En mållett distribution börjar med en resultat istället för en förskriven väg. Lösa denna kund eskalering. Minska avhopp risken på detta konto. Utreda denna bedrägerisignal. Förbered denna förnyelseplan. Destinationen är tydlig, men vägen kan ändras när ny information blir tillgänglig. En huvudagent bryter ned arbetet, använder godkända agenter och verktyg, anropar godkänd automatisering och tilldelar mänskligt arbete inom styrda gränser. Dess styrka är anpassningsförmåga. Dess risk är att anpassningsförmåga utan tydliga begränsningar blir oförutsägbarhet.

Därför kräver flexibla system starkare styrning, inte mindre. Tydliga arbetsflödesgränser, automatiseringsbehörigheter, beslutsrättigheter, revisionsposter och eskaleringregler blir viktigare ju mer kapabel AI blir. Ju mer frihet en agent har att bestämma sin egen väg, desto mer noggrant måste institutionen definiera gränserna inom vilka den kan verka.

Företags-AI kommer inte att lyckas för att varje beslut har en människa någonstans i loopen.

Det kommer att lyckas för att institutioner lär sig att bygga loopen själv.

Daniel Dines är grundare och verkställande ordförande för UiPath (NYSE: PATH), en global ledare inom affärsorkestrering och automation. Dines har också tjänstgjort som chefsinnovationschef för företaget. Dines startade UiPath 2005 med målet att bygga ett företag som skulle hjälpa människor att minska den tid och stress som uppstår från meningslösa, upprepade uppgifter. UiPath bygger på sin grund som världens ledande automationsplattform för att bli ledande inom agentic automation genom att utveckla AI-teknik som speglar mänsklig intelligens med alltmer sofistikerad komplexitet, vilket förändrar hur företag opererar, innovrerar och konkurrerar. Med fokus på säkerhet, noggrannhet och motståndskraft är UiPath engagerat i att forma en värld där AI förbättrar mänsklig potential och revolutionerar branscher.