Human-in-the-loop: att behålla en människa i loopen hos en AI-agent

En autonom AI-agent som körs kontinuerligt, väljer sin egen väg och agerar utan att bli tillfrågad vid varje steg, väcker en logisk fråga: vid vilken tidpunkt tar en människa tillbaka kontrollen? Human-in-the-loop är svaret på den frågan. Det är ingen broms på autonomin, det är en vald passage, placerad där åtgärden har tillräckliga konsekvenser för att motivera en validering.

Detaljerad definition

Human-in-the-loop (HITL), bokstavligen människa i loopen, är en designprincip där en person behåller befogenheten att validera, korrigera eller blockera ett beslut eller en åtgärd som genererats av ett AI-system, vid en exakt punkt i processen, innan den får verklig effekt. NIST:s ramverk för AI-riskhantering (AI Risk Management Framework, AI RMF 1.0) behandlar mänsklig tillsyn och ansvarsfördelning mellan människa och AI som styrningselement som ska dokumenteras explicit, och det har blivit en gemensam referens för tillsynsmyndigheter och granskare som bedömer en organisations AI-styrning.

Man måste skilja human-in-the-loop från kontinuerlig övervakning. HITL innebär inte att en människa hela tiden bevakar varje steg en agent tar, vilket skulle tömma autonomin på hela dess poäng. Vändpunkten kommer främst när en agent går från ett enkelt förslag till en verklig åtgärd: att skicka ett meddelande, ändra en databas, utlösa ett arbetsflöde. Det handlar om en riktad kontrollpunkt, placerad före de åtgärder som bedöms mest känsliga eller minst reversibla: ett meddelande till en okänd person, en offentlig publicering, en finansiell transaktion. Resten av agentens arbete kan fortsätta köras i full autonomi.

Det är en mekanism bland andra möjliga skyddsräcken, inte ett universellt krav. Beroende på en åtgärds risknivå kan en organisation välja att inte sätta upp någon mänsklig valideringspunkt alls, att sätta upp en systematisk sådan, eller att lämna valet till användaren.

Så fungerar det

I praktiken sätts en mänsklig valideringspunkt in vid en exakt tidpunkt i ett automatiserat flöde. AI:n (eller agenten) förbereder en åtgärd, men den läggs i en kö i stället för att utföras omedelbart. En person tar emot en notifikation, granskar det föreslagna innehållet, och väljer att godkänna det, ändra det eller avvisa det. Först efter den här valideringen får åtgärden verklig effekt, till exempel att ett meddelande faktiskt skickas.

Tre element skiljer en bra mänsklig valideringspunkt från en enkel byråkratisk broms: timingen (valideringen kommer vid rätt tidpunkt, varken för tidigt eller för sent för att vara användbar), kontexten som ges till personen som validerar (den måste ha underlag att bedöma, inte bara en knapp att klicka på utan information), och omfattningen (bara de verkligt känsliga åtgärderna går genom det här filtret, inte hela agentens arbete, annars blir den obrukbar).

Konkret exempel med Atako

Hos Atako gäller den mest dokumenterade mekanismen för mänsklig validering utskick av kalla mejl, det som kallas cold send, ett meddelande som skickas till någon agenten ännu inte har en pågående konversation med. Tre lägen finns för den här kanalen: läget approval, aktiverat som standard, lägger varje utskick i en kö för mänsklig validering innan det faktiskt skickas; läget auto skickar omedelbart utan granskning, med en varning i gränssnittet som markerar det valet; läget disabled hindrar agenten från att skicka ett kallt mejl, den kan då bara svara i redan pågående konversationstrådar. Svar i en befintlig konversation går aldrig genom en validering, det är bara den första kontakten som berörs.

Ett andra dokumenterat exempel gäller use caset release-communicator, en agent som skriver och publicerar meddelanden om nya funktioner på flera kanaler. För större releaser beskrivs valideringen av innehållet före publicering som valfri på människans sida, ett val som lämnas till teamet snarare än ett krav som påtvingas av plattformen.

Utöver de här två dokumenterade mekanismerna finns det ingen generisk mänsklig valideringsgrind som automatiskt skulle gälla för alla åtgärder hos en Atako-agent. Principen kvarstår: rikta in valideringspunkterna där åtgärden har konsekvenser, i stället för att blockera systematiskt.

Vanliga misstag

Ett klassiskt misstag är att blanda ihop human-in-the-loop med permanent övervakning. HITL kräver inte att en människa bevakar varje steg en agent tar, vilket skulle upphäva själva poängen med automatiseringen. Det är en exakt passage, inte en kontinuerlig kontroll.

Andra misstaget: att placera en mänsklig valideringspunkt på för många åtgärder samtidigt. Ett system som kräver validering för varje mikrobeslut slutar med att ignoreras eller kringgås, eftersom personen som ska validera klickar utan att egentligen läsa igenom. Det är bättre att förbehålla valideringen åt åtgärder med stor påverkan eller låg reversibilitet.

Tredje misstaget: att tro att avsaknaden av en uttrycklig nämnd valideringsmekanism i en dokumentation betyder att ingen kontroll finns. Man måste skilja på explicit mänsklig validering (en människa måste klicka för att åtgärden ska skickas) och andra skyddsräcken som tillämpas i förväg, som behörigheter eller kvoter, utan att kräva direkt mänsklig inblandning varje gång.

Slutligen är det ett feltänk att tro att human-in-the-loop är oförenligt med en agents autonomi. En väl utformad autonom agent kombinerar båda: bred autonomi över merparten av arbetet, och riktade valideringspunkter för de beslut som förtjänar det.