Human-in-the-loop-designmønstre til AI-arbejdsgange
Let øvet9 min læsningAutomatiseringer

Human-in-the-loop-designmønstre til AI-arbejdsgange

Menneskelig gennemgang er ikke et vagt sikkerhedsnet. En praktisk guide til at beslutte, hvad mennesker skal godkende, stikprøvekontrollere, revidere, eskalere eller aldrig uddelegere i AI-arbejdsgange.

Hvad du bør kunne

Human-in-the-loop-design virker, når menneskets rolle er konkret: godkend, stikprøvekontrollér, revidér, eskalér eller tag ejerskab for undtagelsen. Hvis arbejdsgangen kun siger 'et menneske kan gennemgå det', har ingen endnu designet sikkerhedssystemet.

AI Expert TeamUdgivet: 17. maj 2026
Gemt kun i denne browser.
I denne artikel

De fleste teams behandler “human in the loop” som en beroligende formulering. Det lyder sikkert. Det lyder ansvarligt. Det betyder ofte også, at ingen har besluttet, hvad mennesket faktisk skal gøre.

Et menneske kan godkende en handling, gennemgå en stikprøve, håndtere undtagelser, udføre efterfølgende revision, forbedre arbejdsgangen med rettelser eller eje forretningsbeslutningen. Det er forskellige mønstre med forskellige omkostninger, fejltyper og bemandingsbehov.

Denne artikel giver dig en praktisk beslutningsmodel til at vælge det rigtige mønster.

Menneskelig gennemgang er en kontrol, ikke pynt. Hvis kontrollanten ikke har tydelig myndighed, et tidsbudget, en tjekliste og en stopregel, er arbejdsgangen reelt stadig fuldautomatisk.

Start med konsekvens

Begynd ikke med modellen. Begynd med konsekvensen af et forkert output.

Stil fem spørgsmål:

  1. Kan det påvirke en kunde, medarbejder, leverandør eller regulator?
  2. Kan det sende, udgive, slette, opkræve, refundere eller ændre en registrering?
  3. Kan det udsætte personlige, fortrolige, finansielle, juridiske eller sundhedsrelaterede data?
  4. Vil en forkert besvarelse være svær at opdage senere?
  5. Vil en fejl skade tilliden, selv om den teknisk kan tilbageføres?

Jo flere ja-svar I har, desto mere eksplicit skal menneskets rolle være.

Mønster 1: Mennesket godkender hver handling

Brug dette, når handlingen er ekstern, destruktiv, finansiel, juridisk, HR-relateret eller synlig for kunden.

Eksempler:

  • sende en kunde-e-mail,
  • publicere en offentlig artikel,
  • udstede en refusion,
  • slette poster,
  • ændre en kontraktbestemmelse,
  • afgive en ansættelsesanbefaling.

Modellen forbereder et forslag eller anbefaling. Mennesket godkender, redigerer eller afviser det. Den endelige handling sker ikke før godkendelsen er registreret.

God design til godkendelse inkluderer:

  • en klar forskel eller forhåndsvisning,
  • det anvendte kildegrundlag,
  • modellens tillid eller risikoflag, hvis tilgængelig,
  • en afvisningsvej med ét klik,
  • en obligatorisk begrundelse for tilsidesættelse i højrisikoforløb,
  • en revisionslog med kontrollant, tidsstempel og endelig handling.

Dette er det dyreste mønster, men det er den rigtige standard for handlinger med væsentlige konsekvenser.

Mønster 2: Mennesket gennemgår undtagelser

Brug dette, når de fleste tilfælde er rutinemæssige, men nogle er tvivlsomme eller risikable.

Eksempler:

  • supportsager, der nævner opsigelse, juridiske trusler, sikkerhed eller fakturering,
  • fakturaekstraktion med lav tillid eller manglende felter,
  • kvalifikation af leads, hvor virksomhedsstørrelse eller intention er usikker,
  • dokumentklassificering, når flere kategorier passer.

Arbejdsgangen håndterer normale tilfælde og dirigerer undtagelser til en kø.

Dirigering af undtagelser kræver konkrete regler. “Lav konfidens” alene er ofte for vagt. Bedre udløsere er:

  • manglende obligatoriske felter,
  • konfliktende ekstraherede værdier,
  • et sprog, der ikke understøttes,
  • en ukendt dokumenttype,
  • kundens stemning over en risikotærskel,
  • kontoniveau er enterprise,
  • handlingen ville krydse en penge- eller datatærskel,
  • kildeinformationen er forældet.

Undtagelseskøer kræver ejerskab og serviceniveauer. Hvis ingen kontrollerer køen dagligt, har systemet ikke reduceret arbejdet; det har skjult det.

Mønster 3: Mennesket gennemgår stikprøver

Brug dette, når arbejdsgangen er lav konsekvens, men kvalitetsdrift er vigtig.

Eksempler:

  • interne opsummeringer,
  • indholdsmærkning,
  • udtræk af handlingspunkter fra møder,
  • berigelse af ikke-følsomme CRM-felter,
  • foreslåede links til en vidensbase.

Arbejdsgangen kører automatisk. Et menneske gennemgår en stikprøve: måske 5 procent af outputtene, 20 tilfældige tilfælde om ugen eller alle output fra en nyligt ændret promptversion.

Stikprøver virker kun, når rettelserne føres tilbage til systemet:

  • registrer hvad der var forkert,
  • klassificér fejltypen,
  • opdater prompt, hentning, skema eller værktøjsregler,
  • tilføj eksempler til evalueringer,
  • følg fejlprocenten over tid.

Stikprøver er et kvalitetssystem. De er ikke en godkendelsesport før lancering.

Mønster 4: Mennesket gennemgår efterfølgende

Brug dette, når arbejdsgangen har lav risiko, kan tilbageføres og håndterer store mængder.

Eksempler:

  • intern mærkning,
  • opdagelse af duplikater,
  • forslag til udkast i vidensbasen,
  • omkostningsroutering mellem modeller,
  • oprydning i formatering, der ikke er synlig for kunder.

Arbejdsgangen kører. Logfiler, dashboards og periodiske revisioner opdager problemer.

Dette mønster er kun acceptabelt, når:

  • handlingerne kan tilbageføres,
  • arbejdsgangen har en slukkningsfunktion,
  • loggene er detaljeret nok til at rekonstruere beslutninger,
  • omkostningen ved en manglende fejl er lav,
  • brugere ved, hvordan de skal rapportere dårlige output.

Brug ikke efterfølgende revision til kundesynlige forpligtelser, følsomme data, betalinger eller regulerede beslutninger.

Mønster 5: Mennesket ejer beslutningen

Brug dette, når AI hjælper med analyse, men ikke skal træffe beslutningen.

Eksempler:

  • ansættelse,
  • kredit eller kvalifikationsundersøgelse,
  • juridisk strategi,
  • medicinsk rådgivning,
  • alvorlighed af sikkerhedsincidenter,
  • leverandørvalg,
  • vigtige købssager.

Modellen kan sammenfatte dokumentation, beskrive afvejninger, generere spørgsmål eller sammenligne alternativer. Den person, der ejer beslutningen, godkender den endelige vurdering.

Arbejdsgangen bør gøre det tydeligt:

  • “AI-genereret analyse, ikke en beslutning.”
  • “Beslutningsansvarlig: navn eller rolle.”
  • “Gennemgået dokumentation: kilder.”
  • “Kendte begrænsninger.”
  • “Endelig begrundelse.”

Det forhindrer en almindelig fejl: modellens flade anbefaling bliver beslutningen som standard.

En enkel godkendelsesmatrix

Brug dette som et udgangspunkt:

Arbejdsgangs konsekvensStandardmenneskerolle
Intern, reversibel, lav synlighedRevidér efterfølgende
Intern, gentaget, kvalitetsfølsomStikprøvekontrol
Tvivlsomme tilfælde i ellers rutinemæssig flowUndtagelsesgennemgang
Kundesynlige eller eksterne handlingerGodkend hver handling
Ødelæggende, finansiel, juridisk, HR, reguleretMenneske ejer endelig beslutning

Matrixen er ikke en lov. Den tvinger jer til at træffe et bevidst valg. Hvis I vælger et lettere mønster, skal I skrive hvorfor.

Design gennemgangsskærmen

En god gennemgangsskærm reducerer kontrollantens træthed.

Vis:

  • hvad systemet foreslår,
  • hvilket kildegrundlag systemet brugte,
  • hvad der ændrede sig fra den nuværende tilstand,
  • hvorfor emnet blev dirigeret til gennemgang,
  • de tilladte handlinger,
  • risikoflag,
  • frist, hvis der er en.

Undgå:

  • at vise hele prompten uden bearbejdning,
  • at bede kontrollanter gennemgå rå logfiler,
  • at skjule kildedokumenter,
  • at give kun “godkend” og “afvis”, når “rediger” er nødvendig,
  • at tvinge kontrollanter til at åbne fem systemer igen for at kontrollere ét tilfælde.

Hvis gennemgangen er langsom, vil folk omgå den. Hvis den er uklar, vil folk godkende mekanisk.

Definer stopregler

Alle human-in-the-loop-arbejdsgange har brug for stopregler.

Eksempler:

  • Mere end 3 procent af stikprøverne fejler tjeklisten.
  • Enhver tværkundedatapåvirkning opdages.
  • Mere end fem højrisikoundtagelser står uden gennemgang i 24 timer.
  • En prompt eller modelopdatering øger afvisningsfrekvensen med 50 procent.
  • Arbejdsgangen genererer en ekstern handling, der skulle have krævet godkendelse.

En stopregel skal sige, hvem der sætter arbejdsgangen på pause og hvad der sker derefter.

Almindelige fejl

Mennesker inddrages for sent. Hvis kontrollanten kun ser det færdigpolerede output, kan dårlige kildedata blive overset. Vis kildegrundlag og mellemresultater, når det er nødvendigt.

Tankeløs batchgodkendelse. Batchgodkendelse er nyttig, men kun efter filtre og stikprøver har vist, at batchen er ensartet.

Ingen oplæring af kontrollanter. Kontrollanter har brug for eksempler på gode, dårlige og tvetydige tilfælde.

Ingen feedbackloop. Hvis rettelser ikke forbedrer prompter, hentning, skemaer eller kildeinformation, bliver gennemgangen permanent manuel arbejde.

Ingen kapacitetsplanlægning. En undtagelsesfrekvens på 10 procent ved 1,000 tilfælde om dagen giver 100 menneskelige opgaver. Det kræver et team, ikke en fodnote.

Konklusion

Human-in-the-loop-design er ikke ét mønster. Det er et sæt kontroller, der tilpasses konsekvenserne.

Brug:

  • godkendelse til handlinger med store konsekvenser,
  • undtagelsesgennemgang for tvivlsomme tilfælde,
  • stikprøver til kvalitetsdrift,
  • efterfølgende revision til reversibelt arbejde med lav risiko,
  • menneskeligt ejerskab til reelle forretningsbeslutninger.

Den praktiske test er simpel: hvis modellen er forkert, hvem opdager det, hvem kan stoppe det og hvad gør de præcist? Hvis du ikke kan svare på det, er arbejdsgangen ikke klar.

Læs næste

Fortsæt ad den samme læsevej med de næste praktiske artikler.

Gå i dybden

Håndplukkede eksterne kurser, der går i dybden med dette emne.

Se alle kurser om Automatiseringer