De fleste er enige om, at mennesker skal kunne kontrollere AI i virksomheden. Uenigheden opstår, når det skal omsættes til praksis: hvad må systemet gøre selv? Denne artikel giver en konkret niveaumodel, der gør samtalen og designet præcist.
I denne artikel
Det korte svar
"Human-in-the-loop" betyder, at et menneske indgår i beslutningen, før eller mens AI udfører arbejde. Men som krav er sætningen for upræcis: den siger ikke hvornår, hvor og med hvilket ansvar mennesket indgår.
En brugbar model deler agentens handlekraft i fire niveauer: læse, foreslå, handle med godkendelse og handle inden for faste grænser. Niveauet vælges pr. workflow ud fra konsekvens og reversibilitet, ikke som ét princip for hele virksomheden.
Hvorfor "et menneske i loopet" ikke er nok
To løsninger kan begge kaldes human-in-the-loop og alligevel være vidt forskellige. I den ene godkender en medarbejder hver enkelt handling, før den udføres. I den anden overvåger en medarbejder et dashboard, mens systemet handler selv, og kan gribe ind bagefter. Forskellen i risiko er enorm, men sproget skjuler den.
Derfor bør kravet formuleres som et niveau af handlekraft med tilhørende kontrolpunkter, ikke som et princip i en politik. Det gør samtalen mellem ledelse, IT og procesejer konkret: hvad må systemet gøre selv, hvad kræver godkendelse, og hvad må det aldrig?
De fire niveauer af handlekraft
Niveau 1: Læse. Systemet henter og sammenholder information fra godkendte kilder, men ændrer intet. Typisk anvendelse: søgning, statusopsamling, kontrol af dokumentation. Risikoen ligger alene i adgang og fortrolighed, og styres med rettigheder, dataminimering og logning.
Niveau 2: Foreslå. Systemet udarbejder kladder, klassifikationer eller ændringsforslag, som et menneske beslutter over. Fejl bliver til rettelser, ikke til hændelser. Det er her, de fleste piloter bør begynde: værdien kan måles på rigtige opgaver, mens konsekvensen ved fejl er en dårlig kladde.
Niveau 3: Handle med godkendelse. Systemet forbereder en konkret handling, og en autoriseret person godkender den enkelte handling og dens konsekvens, før den udføres. Egnet til handlinger med reel konsekvens: sende, oprette, ændre. Godkendelsen skal være informeret: den, der godkender, skal kunne se grundlag, kilder og forventet effekt.
Niveau 4: Handle inden for faste grænser. Systemet udfører på forhånd godkendte, afgrænsede og reversible handlinger selv, for eksempel inden for beløbsgrænser, whitelistede modtagere eller bestemte objekttyper. Alt uden for grænsen stoppes eller eskaleres. Grænserne er definerede i kode og kan revideres.
Et tænkt eksempel: fakturabehandling
Følg de fire niveauer gennem ét velkendt workflow. På niveau 1 læser løsningen fakturaen og slår ordre, leverandør og kontrakt op. På niveau 2 foreslår den kontering, dimension og godkender, og lægger forslaget i en kø. På niveau 3 godkender en medarbejder bogføringen af den enkelte faktura på et informeret grundlag: match mod ordre, afvigelser og historik er synlige. På niveau 4 kan tilbagevendende fakturaer fra kendte leverandører inden for en fastsat beløbsgrænse bogføres automatisk, mens alt andet fortsat går til godkendelse.
Eksemplet er et mønster, ikke et produkt. Pointen er, at niveauerne ikke er et enten-eller: et modent workflow bruger typisk alle fire samtidig, fordelt efter konsekvens og reversibilitet pr. handlingstype.
Sådan vælges niveauet pr. workflow
To spørgsmål afgør det meste. Hvad er konsekvensen, hvis handlingen er forkert: intern og lille, eller ekstern og pinlig, eller irreversibel og dyr? Og kan handlingen fortrydes: kan en kladde slettes, en post rulles tilbage, en mail ikke?
Lav konsekvens og høj reversibilitet peger mod niveau 2 eller 4. Høj konsekvens eller lav reversibilitet peger mod niveau 2 eller 3, uanset hvor god modellen er. Kritiske, eksterne eller irreversible handlinger bør som udgangspunkt kræve menneskelig godkendelse.
Bemærk, at ét workflow kan rumme flere niveauer: agenten læser frit (niveau 1), foreslår svar (niveau 2), sender rutinesvar inden for en snæver grænse (niveau 4) og lægger alt andet til godkendelse (niveau 3).
Kontrol skal håndhæves af kode, ikke af prompten
Et niveau er kun reelt, hvis det håndhæves uden for modellens frie vurdering. Instruksen "spørg altid før du sender" er ikke en kontrol; den er et håb. Håndhævelsen skal ligge i deterministisk kontrolkode: rettigheder, der ikke giver skriveadgang på niveau 1 og 2; en godkendelseskø, som handlinger fysisk skal igennem på niveau 3; og tekniske grænser med validering på niveau 4.
Dertil kommer sporbarhed: hvem eller hvad foreslog, hvem godkendte, hvad blev udført, og på hvilket grundlag. En audit trail er ikke bureaukrati; det er forudsætningen for at kunne udvide handlekraften senere med god samvittighed.
Tre typiske indvendinger
"Godkendelser bliver en flaskehals." Kun hvis køen er designet dårligt. Saml godkendelser i fornuftige bundter, vis grundlaget klart, og flyt kun de handlingstyper til niveau 4, hvor data viser, at forslagene alligevel godkendes uændret.
"Folk klikker bare ja." Det er et reelt fænomen, og det håndteres med design, ikke formaninger: vis afvigelser frem for rå data, gør konsekvensen synlig, og brug stikprøvekontrol af godkendte handlinger som en del af driften.
"Niveau 4 er for farligt." Niveau 4 uden grænser er ikke niveau 4, men niveau 5: fuld autonomi, og den arbejder vi ikke med i kritiske workflows. Selve pointen med niveau 4 er, at grænserne er snævre, definerede i kode, reversible og reviderbare.
Kort om regulering
EU’s AI-forordning stiller krav om menneskeligt tilsyn for AI-systemer i højrisikokategorier. De fleste administrative workflows falder uden for de kategorier, men retningen er tydelig: jo større konsekvens, desto mere eksplicit skal det menneskelige ansvar være. En niveaumodel som ovenstående gør det ansvar konkret og dokumenterbart, uanset om et system er omfattet eller ej.
Uafhængigt af regulering gælder det organisatoriske: der skal være en navngiven ejer af løsningen, og den, der godkender, skal have både kompetencen og tiden til reelt at vurdere, ikke bare klikke ja.
Roller: hvem godkender, og hvem ejer?
En niveaumodel virker kun, hvis rollerne er navngivne. Godkenderen skal have faglig kompetence til at vurdere handlingen, mandat til at afvise den og tid til opgaven i sin hverdag. Ejeren af løsningen, ofte procesejeren, har ansvar for kvalitet i drift, for stikprøver og for at foreslå ændringer af niveauer og grænser.
Undgå den diffuse model, hvor "teamet" godkender. Når alle godkender, godkender ingen, og audit trailen mister sin værdi, fordi ansvaret ikke kan placeres. Én handlingstype, én godkenderrolle, én ejer.
Praktisk opstart
Start på niveau 1 og 2: læseadgang til godkendte kilder og forslag i en kø. Mål kvaliteten mod en baseline, og lad godkendelsesdata vise, hvor systemet rammer rigtigt. Udvid derefter selektivt: de handlinger, hvor forslagene konsekvent godkendes uændret, er kandidater til niveau 3 eller 4, én handlingstype ad gangen.
Nedskriv niveauvalget pr. workflow sammen med grænser, godkendere og log. Det dokument er lille, men det er forskellen på kontrolleret drift og gradvis afdrift.
Læs også
Skal jeres næste AI-løsning designes med tydelig kontrol?
Beskriv workflowet, så foreslår vi handlekraftniveau, godkendelsespunkter og logning som en del af løsningsdesignet.
Vurdér et workflow →