KI-agenter15 Aug 2026 · 10 min

Human-in-the-loop AI: Slik beholder du reell menneskelig kontroll

Human-in-the-loop AI betyr at et menneske får en definert rolle i en KI-prosess. Personen kan kontrollere et forslag, godkjenne en handling, rette en feil eller ta over når systemet er usikkert.

Det høres enkelt ut. Legg inn en godkjenningsknapp, så er mennesket i loopen. I praksis er det ikke nok. Kontroll er først reell når personen forstår situasjonen, har tid til å vurdere den og faktisk kan stoppe eller endre det systemet vil gjøre.

Denne guiden viser hvor menneskelig kontroll bør ligge, hvordan en godkjenningsflyt kan bygges, og hva dere bør måle etter lansering.

Hva er human-in-the-loop AI?

I denne guiden bruker vi human-in-the-loop, forkortet HITL, om KI-systemer der menneskelig vurdering er en planlagt del av arbeidsflyten.

En enkel flyt kan se slik ut:

1. Systemet mottar en oppgave og samler relevant kontekst.
2. KI-en lager et forslag eller anbefaler en handling.
3. En regel vurderer risiko, usikkerhet og konsekvens.
4. Saken sendes videre automatisk eller legges i en kø for kontroll.
5. Et menneske godkjenner, retter, avviser eller eskalerer.
6. Systemet logger beslutningen og bruker utfallet i senere evaluering.

Mennesket trenger ikke kontrollere alt. Målet er å plassere vurderingen der en feil er vanskelig å oppdage, dyr å rette eller alvorlig for den som blir berørt.

Human-in-the-loop, human-on-the-loop og full automasjon

Tre begreper gjør det enklere å diskutere graden av kontroll.

Human-in-the-loop

Systemet må vente på et menneske før en bestemt handling kan fortsette. Dette passer når konsekvensen er høy eller beslutningen krever kontekst som ikke bør overlates til modellen alene.

Eksempel: En KI-agent skriver et svar på en krevende kundesak, men en medarbeider må godkjenne svaret før det sendes.

Human-on-the-loop

Systemet arbeider selvstendig, mens et menneske overvåker og kan gripe inn. Personen kontrollerer avvik, stikkprøver eller varsler fremfor hver enkelt sak.

Eksempel: Et dokumentløp behandler vanlige saker automatisk, men sender uvanlige kombinasjoner til en kontrollkø.

Human-out-of-the-loop

Systemet gjennomfører oppgaven uten menneskelig kontroll i den enkelte saken. Det kan være riktig for avgrensede, reversible og godt testede oppgaver.

Eksempel: En intern agent sorterer ikke-sensitive henvendelser i forhåndsdefinerte kategorier. Feil sortering kan oppdages og rettes uten at agenten har utført en ekstern handling.

Skillet handler ikke om hvor avansert modellen er. Det handler om konsekvensen av handlingen og hvor lett den kan reverseres.

Når bør et menneske være i loopen?

Start med fire spørsmål.

1. Kan handlingen reverseres?

Et forslag kan ofte endres. En sendt e-post, slettet post eller utført betaling er vanskeligere å hente tilbake. Jo mindre reversibel handlingen er, desto sterkere bør kontrollpunktet være.

2. Hvem blir berørt hvis systemet tar feil?

En intern kladd og en beslutning som påvirker en kunde har ulik risiko. Vurder også om feilen kan påvirke rettigheter, økonomi, sikkerhet, personvern eller tillit.

3. Hvor tydelig er riktig svar?

Noen oppgaver har klare regler. Andre krever skjønn, motstridende hensyn eller informasjon som ikke finnes i systemet. Høy usikkerhet bør føre til kontroll eller eskalering.

4. Kan teamet oppdage feilen i tide?

Overvåking hjelper lite hvis konsekvensen oppstår før noen rekker å reagere. Da bør systemet stoppe før handlingen, ikke varsle etterpå.

En praktisk startmodell er:

| Risiko | Usikkerhet | Reverserbarhet | Anbefalt kontroll | |---|---|---|---| | Lav | Lav | Enkel | Automatisk behandling med stikkprøver | | Lav | Høy | Enkel | Send usikre saker til kontroll | | Høy | Lav | Vanskelig | Obligatorisk godkjenning før handling | | Høy | Høy | Vanskelig | Godkjenning, tydelig eskalering og eventuelt to personer |

Matrisen er et arbeidsverktøy, ikke en fasit. Teamet må definere hva "lav" og "høy" betyr for den konkrete prosessen.

Fem mønstre for menneskelig kontroll

Godkjenning før handling

KI-en forbereder arbeidet, men får ikke fullføre uten et eksplisitt ja. Kontrollpunktet bør ligge rett før den irreversible delen av flyten.

Vis hva agenten vil gjøre, hvilke data den brukte og hvilke felt som blir endret. En knapp merket "Godkjenn" uten denne konteksten skaper bare en formalitet.

Eskalering ved usikkerhet

Systemet sender saker til mennesker når modellen eller reglene ikke har godt nok grunnlag. Terskelen kan bygge på flere signaler:

• manglende eller motstridende data
• en forespørsel utenfor kjent omfang
• uvanlig høy verdi eller konsekvens
• et avvik fra normal prosess
• et verktøy som svarer med feil eller uventet format

Ikke bruk modellens egen sikkerhetsscore som eneste signal. Kombiner den med forretningsregler og faktisk målt feilrate for den aktuelle oppgaven.

Kø for unntak

Vanlige saker går automatisk. Unntak samles i en kø med prioritet, frist, eier og begrunnelse. Dette kan gi høy grad av automasjon uten å late som om alle saker er like.

Køen bør vise nok informasjon til at en person kan ta en beslutning uten å lete i flere systemer. Den bør også skille mellom "trenger godkjenning" og "trenger mer informasjon".

Stikkprøver

Et team kan kontrollere et utvalg av saker som systemet ellers ville behandlet automatisk. Stikkprøver avdekker endringer i datakvalitet, nye feilvarianter og gradvis svekkelse som terskelregler ikke fanger opp.

Utvalget bør inneholde både tilfeldige saker og målrettede risikogrupper. Bare å kontrollere de mest åpenbare avvikene gir et skjevt bilde.

Todelt godkjenning

Særlig krevende handlinger kan kreve to roller. Én person vurderer det faglige innholdet. En annen kontrollerer mandat, konsekvens eller utførelse.

Dette bør brukes selektivt. Hvis to personer må godkjenne alt, blir køen raskt en flaskehals og kontrollen kan ende som rutinemessig klikking.

Slik bygger du en god HITL-flyt

1. Tegn opp handlingene, ikke bare modellen

Start med hele arbeidsprosessen. Marker hvor data hentes, hvor KI-en tolker eller foreslår, hvilke verktøy den kan bruke, og når noe får effekt utenfor systemet.

Den største risikoen ligger ofte i handlingen etter modellsvaret. Et upresist utkast kan rettes. Et upresist utkast som sendes automatisk kan allerede ha skapt et problem.

2. Definer beslutningsgrenser

Skriv ned hva systemet kan gjøre selv, hva som krever godkjenning og hva som alltid skal avvises eller eskaleres.

Gode grenser er konkrete. "Mennesket kontrollerer viktige saker" er for uklart. "Alle eksterne utsendelser med manglende kundekontekst må godkjennes" kan testes.

3. Gi kontrolløren riktig kontekst

En vurderingsflate bør svare på fem ting:

• Hva vil systemet gjøre?
• Hvorfor ble saken sendt til kontroll?
• Hvilke data og regler ligger bak forslaget?
• Hva kan skje hvis kontrolløren godkjenner?
• Hvordan kan forslaget rettes eller eskaleres?

Vis relevant informasjon, ikke hele rågrunnlaget. For mye støy gjør det vanskeligere å se det som faktisk avgjør saken.

4. Gjør avvisning og retting like enkelt som godkjenning

Hvis "Godkjenn" er lett synlig mens "Avvis" ligger skjult, vil grensesnittet påvirke beslutningen. Gi kontrolløren tydelige alternativer og en kort måte å registrere hvorfor forslaget ble endret.

Begrunnelsen er nyttig når teamet skal finne gjentatte feil og forbedre regler, instruksjoner eller datagrunnlag.

5. Planlegg for fravær og kø

Hvem tar saken når den vanlige kontrolløren ikke er tilgjengelig? Hva skjer når fristen går ut? Skal agenten vente, avbryte eller sende saken videre?

Velg en trygg standard. Stillhet bør ikke tolkes som godkjenning for handlinger som krever aktiv vurdering.

6. Logg hele beslutningskjeden

Lagre versjonen som ble foreslått, signalene som utløste kontroll, hvem som vurderte saken, hva personen valgte og hva systemet til slutt gjorde.

Loggen skal gjøre en hendelse mulig å undersøke. Den skal ikke samle mer persondata enn prosessen trenger. Avklar tilgang, lagringstid og sletting før lansering.

7. Test med realistiske feil

En vanlig demo viser normalflyten. En nyttig test viser hva som skjer når data mangler, verktøy feiler, to kilder er uenige, køen blir full eller kontrolløren ikke svarer.

Test også om personen rekker å gripe inn. En nødknapp er lite verdt hvis grensesnittet ikke forklarer situasjonen før fristen er ute.

Vanlige feil

Mennesket blir et gummistempel

Hvis nesten alle forslag godkjennes uten endring, kan det bety at systemet fungerer godt. Det kan også bety at kontrolløren mangler tid, kontekst eller reell myndighet. Se på behandlingstid, begrunnelser og mønsteret i stikkprøver før dere konkluderer.

Alt sendes til kontroll

En HITL-flyt skal bruke menneskelig vurdering der den gir verdi. Når alle saker havner i samme kø, har teamet ofte ikke definert risiko og unntak tydelig nok.

Kontrollpunktet kommer for sent

Et varsel etter at handlingen er utført er overvåking, ikke forhåndsgodkjenning. Plasser stoppunktet før systemet sender, endrer, sletter eller forplikter noe.

Ingen eier eskaleringen

En kø uten navngitt ansvarlig blir en parkeringsplass. Hver type avvik trenger en eier, forventet svartid og en trygg standard når ingen svarer.

Tilbakemeldinger samles, men brukes ikke

Korreksjoner har liten verdi hvis de bare lagres. Planlegg en fast gjennomgang av hva som blir avvist, hvilke regler som utløser unødvendige saker, og hvilke feil som slipper gjennom.

Hva bør dere måle?

Mål før dere justerer tersklene. Ellers vet dere ikke om mer automasjon gir en bedre prosess eller bare færre synlige kontroller.

Følg minst disse størrelsene:

• andel saker som går automatisk
• andel saker som sendes til kontroll
• hvor ofte forslag rettes, avvises eller eskaleres
• behandlingstid i kontrollkøen
• feil som oppdages etter godkjenning
• feil som oppdages i automatiske saker
• hvor ofte to kontrollører vurderer samme sak ulikt
• hvilke regler som utløser flest unødvendige kontroller

Del tallene etter oppgavetype og risikonivå. Et samlet gjennomsnitt kan skjule at én liten gruppe står for de alvorlige feilene.

Bestem også på forhånd hva som skal føre til at systemet går tilbake til strengere kontroll. Det kan være en bestemt feiltype, svikt i et verktøy eller en endring i datagrunnlaget.

Et eksempel: KI-agent for kundehenvendelser

Tenk deg en agent som leser en henvendelse, finner relevant informasjon og lager et svarutkast. Dette er et tenkt eksempel, ikke en beskrivelse av en bestemt løsning.

En forsiktig første versjon kan bruke denne flyten:

1. Agenten klassifiserer henvendelsen og lager et utkast.
2. Vanlige spørsmål med komplett grunnlag sendes til en medarbeider for rask kontroll.
3. Saker med manglende data, klage, økonomisk konsekvens eller uvanlig språk sendes til en erfaren saksbehandler.
4. Medarbeideren ser utkastet, grunnlaget og årsaken til eskalering i samme flate.
5. Personen kan redigere, godkjenne, avvise eller be om mer informasjon.
6. Teamet gjennomgår korreksjoner og feil før det eventuelt lar noen avgrensede kategorier gå automatisk.

Poenget er ikke å starte med maksimal automasjon. Start med synlig kontroll, mål hva som faktisk skjer, og utvid mandatet for de delene som er stabile og reversible.

Sjekkliste før lansering

• Er alle eksterne eller irreversible handlinger identifisert?
• Finnes det en tydelig regel for automatisk behandling, kontroll og avvisning?
• Forstår kontrolløren hvorfor saken ble stoppet?
• Har personen informasjon, tid og myndighet til å gripe inn?
• Kan forslaget rettes uten å starte hele prosessen på nytt?
• Har hver kontrollkø en eier og en trygg standard ved tidsavbrudd?
• Blir forslag, beslutninger og utførte handlinger logget?
• Er tilgang og lagring av data avklart?
• Er normalflyt, feilflyt og full kø testet?
• Finnes det måltall og grenser som kan stramme inn automasjonen igjen?

Ofte stilte spørsmål

Må et menneske godkjenne hvert KI-svar?

Nei. Kontrollnivået bør følge risiko, usikkerhet og reverserbarhet. Mange team starter med bred kontroll og går gradvis over til stikkprøver og unntaksbehandling for avgrensede oppgaver.

Gjør human-in-the-loop systemet tregere?

En godkjenning tar tid og kan skape kø. Derfor bør teamet reservere manuell kontroll for saker der vurderingen er nødvendig, og måle både ventetid og feil før tersklene endres.

Hvordan velger vi terskel for eskalering?

Begynn konservativt. Bruk faktiske korreksjoner og feil fra piloten til å justere terskelen. Se på oppgavetyper hver for seg fremfor å bruke én score for hele systemet.

Hvem har ansvaret når KI-en foreslår og et menneske godkjenner?

Ansvar må beskrives i prosessen og forankres hos virksomheten. Et godkjenningssteg gjør ikke ansvarsfordelingen tydelig av seg selv. Definer hvem som eier modellen, arbeidsflyten, den faglige beslutningen og den utførte handlingen.

Kan vi fjerne menneskelig kontroll senere?

Ja, for avgrensede oppgaver som viser stabil kvalitet og lav, reversibel risiko. Behold stikkprøver, overvåking og en måte å skru strengere kontroll på igjen.

Bygg kontrollen inn fra starten

Human-in-the-loop fungerer best når teamet designer arbeidsflyten rundt reelle beslutninger. Finn handlingene med høy konsekvens. Gi kontrolløren mandat og kontekst. Mål korrigeringer, ventetid og feil før dere automatiserer mer.

Planlegger dere en KI-agent eller copilot der mennesker må kunne kontrollere viktige handlinger? Start en samtale.