Hur jag designar human-in-the-loop för kritiska AI-system
Human-in-the-loop låter tryggt, men kan bli dålig produktdesign väldigt snabbt. Om en användare måste godkänna varje liten modelloperation har man ofta inte byggt ett säkert system. Man har byggt ett klicklager ovanpå automationen. Användaren lär sig dessutom snart att godkänna utan att läsa.
Human-in-the-loop låter tryggt, men kan bli dålig produktdesign väldigt snabbt. Om en användare måste godkänna varje liten modelloperation har man ofta inte byggt ett säkert system. Man har byggt ett klicklager ovanpå automationen. Användaren lär sig dessutom snart att godkänna utan att läsa.
Jag placerar därför mänskliga checkpoints efter risk, inte efter antal agentsteg. Samma princip återkommer i flera saker jag byggt: en CV-coach får föreslå förbättringar men ska inte hitta på erfarenheter; en contentpipeline får skriva men måste kunna blockera vid saknad evidens; en finansiell analys får hellre säga "kan inte bedöma" än att fylla luckor.
Human-in-the-loop är en riskmodell
Frågan är inte "ska en människa vara med?". Frågan är vilken typ av fel som motiverar mänsklig kontroll. Jag tittar främst på tre dimensioner: reversibilitet, påverkan och verifierbarhet.
En felaktig sammanfattning som kan regenereras är annorlunda än ett skickat mejl. Ett dåligt textförslag är annorlunda än en databasändring. En klassificering med tydligt facit är annorlunda än en bedömning där modellen saknar tillräckligt underlag.
Tre frågor före varje checkpoint
Jag använder tre frågor:
- Kan handlingen enkelt backas? Om nej ökar behovet av approval.
- Hur dyrt är felet? Ekonomi, juridik, kundpåverkan och publicering väger tungt.
- Kan systemet själv verifiera resultatet? Om nej behöver osäkerheten eskaleras.
Det ger en bättre matris än "alla writes kräver godkännande". En intern draft-write kan vara låg risk. Ett skickat kundmejl kan vara hög risk trots att båda tekniskt är writes.
Approval före handling, inte efter
En vanlig anti-pattern är att logga ett riskfyllt resultat efter att handlingen redan skett. Human-in-the-loop fungerar bäst när den sitter precis före irreversibel execution. Agenten kan göra research, skapa förslag och validera så långt det går. Människan får sedan ett kompakt beslutspaket: vad systemet tänker göra, varför, vilka källor som användes och vilken osäkerhet som återstår.
OpenAI:s aktuella guidance för workspace agents beskriver just required approvals och human-in-the-loop checkpoints som guardrails för känsliga handlingar. Jag ser dem som en del av workflowdesignen, inte som en generell pausknapp.
Abstention är också human-in-the-loop
Den mest underskattade mekanismen är att systemet får avstå. BLOCKED och NOT READY är bättre states än ett hallucinerat svar. En människa ska inte bara godkänna AI:s bästa gissning; ibland ska modellen uttryckligen lämna över därför att den inte kan avgöra frågan.
I finansiell analys är detta särskilt tydligt. Om aktuell kurs, rapportdata eller balansräkning saknas ska analysen inte fyllas med plausibla antaganden. I contentflödet gäller samma sak för ett materiellt claim utan källa.
Olika system behöver olika stopp
För en CV-coach placerar jag mänsklig kontroll vid materiella förändringar av användarens profil. Språkliga förbättringar kan ofta automatiseras, men en ny kompetens eller arbetslivserfarenhet får inte smygas in.
För content behövs kontrollen när evidens inte kan verifieras automatiskt och vid publicering. För ett agentiskt workflow som får verktygsaccess behövs approval när agenten går från analys till en extern handling med betydande konsekvens.
Det betyder att samma produkt kan ha både helautomatiska och manuella delar. Riskklassning ska styra friktionen.
Designa för beslutskvalitet
En approval-dialog som bara säger "Tillåt?" är svag. Jag vill visa det en människa behöver för att fatta beslutet:
Människan ska inte behöva återskapa agentens hela arbetsgång. Kontrollpunkten ska komprimera den.
Logga varför människan behövdes
Varje eskalering är också produktdata. Om samma typ av fråga alltid kräver människa kan det betyda att en validator saknas, att source-of-truth är svag eller att agentens behörighet är felkalibrerad. Jag loggar därför triggern, beslutet och vad som hände efteråt.
På sikt vill jag flytta lågriskbeslut från människa till deterministisk kontroll och behålla människor där omdömet verkligen behövs. Human-in-the-loop är då inte ett permanent manuellt lager. Det är en adaptiv gräns mellan automation och ansvar.