Menneskeligt tilsyn — på engelsk "human oversight" — er en af de mest misforståede forpligtelser i EU AI Act. I salgsmateriale fra leverandører reduceres det ofte til "vores system har en human-in-the-loop", som om der var tale om en teknisk feature. Men loven beskriver det som en organisatorisk og kompetencemæssig disciplin, der både skal designes ind af provideren (Art. 14) og operationaliseres af deployeren (Art. 26, stk. 2). Og hele konstruktionen er kun værdifuld, hvis den kan dokumenteres.
Denne guide gennemgår, hvad menneskeligt tilsyn faktisk skal kunne, hvordan ansvaret er delt mellem provider og deployer, og — vigtigst — hvilke konkrete dokumenter en dansk virksomhed eller myndighed bør have klar, når tilsynet, en medarbejderrepræsentant eller en skadelidt person beder om at se beviset.
1. To artikler, to roller: Art. 14 vs. Art. 26(2)
Det første skridt mod brugbar dokumentation er at forstå den dobbelte arkitektur. EU AI Act fordeler ansvaret for menneskeligt tilsyn på to forskellige aktører:
Art. 14 (provider): Høj-risiko AI-systemer skal designes, så fysiske personer effektivt kan føre tilsyn — det inkluderer passende human-machine-interface-værktøjer. Provideren skal bygge systemet, så tilsynspersonen kan: forstå kapacitet og begrænsninger, holde øje med drift, opdage anomalier, modgå automation bias, fortolke output korrekt, vælge ikke at bruge systemet i en konkret situation, og — hvor relevant — intervenere via en "stop"-knap.
Art. 26, stk. 2 (deployer): Deployeren skal tildele tilsynet til fysiske personer med nødvendig kompetence, træning og myndighed samt den nødvendige støtte. Det er denne forpligtelse, der oftest undervurderes — for det er ikke nok, at en HR-konsulent "kigger med". Personen skal have reel myndighed til at sige "nej, vi følger ikke systemets anbefaling i dette tilfælde", og det skal kunne dokumenteres.
Konsekvensen af denne arbejdsdeling er klar: deployeren kan ikke skubbe oversight-ansvaret tilbage til provideren med en henvisning til, at "systemet er bare et værktøj". Provideren leverer designet; deployeren leverer disciplinen.
2. Hvad provideren skal levere (og som I skal kræve at få)
Når en dansk deployer skal dokumentere menneskeligt tilsyn, starter mappen med dokumenter, som provideren har pligt til at udlevere. Hvis I ikke har dem, har I et provider-problem, der bør løses kontraktligt før ibrugtagning. Som minimum:
Hvis providerens dokumentation er mangelfuld på disse punkter, er det et rødt flag — både i en kontraktforhandling og i en evt. senere tilsynssag, hvor I vil kunne vise, at I har forsøgt at indhente materialet, men ikke fået det leveret.
3. Hvad deployeren skal producere selv: kernedokumentationen
Den dokumentation, der oftest mangler, når vi gennemgår nye M1-leverancer, er deployer-siden. Det er typisk her, gappet ligger. Den centrale mappe bør indeholde mindst seks artefakter pr. høj-risiko AI-system:
(a) Oversight-protokollen. Et 2–4 siders dokument, der beskriver:
(b) Rolle- og myndighedsbeskrivelser. For hver person, der har et oversight-ansvar, skal det dokumenteres:
(c) Trænings- og kompetencelog. Det er ikke nok at sige "vores HR-konsulenter er erfarne". Det skal dokumenteres, at hver oversight-person har gennemført:
Hver træningssession bør have dato, deltager, varighed, materiale-version og — hvor muligt — en lille kompetence-evaluering (quiz eller scenario-test).
(d) Oversight-log pr. beslutning eller batch. For hver væsentlig beslutning (eller hver batch, hvis volumen er høj) skal det kunne rekonstrueres:
Logs skal opbevares i mindst 6 måneder (Art. 26, stk. 6) — i praksis ofte længere, fordi GDPR-, ansættelses- eller forvaltningsretlige frister kræver det.
(e) Hændelses- og afvigelses-register. Når oversight identificerer noget, der ligner en systemfejl, falsk positiv-rate over forventet niveau, eller en bias-indikator, skal det dokumenteres som en hændelse: dato, beskrivelse, omfang, korrigerende handling, kommunikation til provider (jf. Art. 72-rapportering), evt. midlertidig stop-beslutning.
(f) Periodisk review-rapport. Mindst kvartalsvis (efter compliance-modenhed) bør oversight-rollen evaluere: virker protokollen i praksis? Er der opstået nye fejlmønstre? Har bemandingen været tilstrækkelig? Er der behov for ekstra træning? Rapporten dokumenterer den løbende justering, som Art. 26 implicit kræver.
4. De fire fælder — og hvordan man undgår dem
Erfaringerne fra både GDPR-tilsynssager og fra de første AI-relaterede sager i andre EU-lande viser fire gentagne fælder, som danske deployers bør undgå.
Fælde 1 — Rubber-stamping. Oversight-personen klikker "godkend" på 300 anbefalinger om dagen uden reel granskning. Hvis loggene viser, at 99,8 % af anbefalingerne godkendes uden bemærkning, er det svært at argumentere for, at der er ført tilsyn. Modforanstaltning: stikprøvekontroller dokumenteret som sådan, eller systematisk gennemgang af alle borderline-cases (fx scores tæt på beslutningsgrænsen).
Fælde 2 — Manglende myndighed. Oversight-personen har formelt ret til at tilsidesætte, men i praksis bliver afvigelser fra anbefaling stillet spørgsmål til af leder eller skaber friktion. Modforanstaltning: eksplicit organisatorisk opbakning, dokumenteret i ledelsesgodkendelse af oversight-protokollen.
Fælde 3 — Træning på det forkerte niveau. Oversight-personen får træning i at bruge systemet, men ikke i dets begrænsninger. Modforanstaltning: træningsmaterialet skal eksplicit dække performance pr. delgruppe, kendte fejlmønstre og automation bias.
Fælde 4 — "Vi har en HR-konsulent i loopet." Tilstedeværelse af et menneske er ikke oversight. Hvis personen ikke kender systemets logik og ikke har tid til at granske, er der reelt tale om legitimerende facade-oversight. Modforanstaltning: dimensionér bemandingen efter volumen og kompleksitet, ikke efter budget.
5. Sammenspil med Art. 86 (forklaringsret) og Art. 26(11) (information til berørte)
Oversight-dokumentationen tjener ikke kun det administrative tilsyn — den er også fundamentet for to andre forpligtelser, der vil generere konkrete henvendelser fra borgere og medarbejdere.
Art. 26, stk. 11 kræver, at personer, der er underlagt en høj-risiko AI-beslutning, informeres om dette. Den standardinformation bør pege på, at der er menneskeligt tilsyn — og hvis det er sandt, bør den kunne understøttes af dokumentation. Art. 86 giver derefter retten til en konkret forklaring: hvad var systemets rolle i min sag, og hvordan blev beslutningen truffet? Hvis oversight-loggen pr. beslutning eksisterer, kan forklaringen genereres uden ekstraordinært arbejde. Hvis den ikke eksisterer, står deployeren med en forpligtelse, der ikke kan opfyldes.
6. Tidslinje og praktiske skridt for 2026
EU AI Acts kerneforpligtelser for høj-risiko AI-systemer — herunder Art. 14 og Art. 26 — bliver fuldt anvendelige fra 2. august 2026. For danske deployers, der allerede har høj-risiko AI i drift, betyder det, at oversight-dokumentationen skal være på plads i sommeren 2026. For systemer, der tages i brug efter den dato, gælder dokumentationskravet fra ibrugtagningsdagen.
En realistisk plan for en mellemstor dansk virksomhed eller offentlig myndighed med 1–3 høj-risiko AI-systemer ser typisk sådan ud: identificér systemerne i et AI-inventar (2 uger), indhent providerens oversight-dokumentation og vurder gaps (2 uger), udform oversight-protokol pr. system (3 uger), træn personer og dokumentér (4 uger), etablér logging og review-rytme (løbende). Det er ikke et halvt års projekt — men det er heller ikke et fredagseftermiddags-arbejde.
Konklusion: oversight er dokumentation, der modstår spørgsmål
Menneskeligt tilsyn er ikke en knap, en feature eller en kulturel hensigt. Det er en organisatorisk disciplin, hvis værdi måles på, om den kan modstå konkrete spørgsmål fra tilsynet, medarbejderrepræsentanter og berørte personer. En oversight-praksis uden dokumentation er — set fra et compliance-perspektiv — en oversight-praksis, der ikke eksisterer.
Den gode nyhed er, at dokumentationen ikke skal være tung — den skal være konkret, opdateret og hentbar. Det er forskellen mellem at kunne svare på en anmodning på en eftermiddag og at skulle bede om udsættelse, mens man samler stumperne.