Den hyppigste misforståelse jeg møder om EU AI Act er denne: compliance er leverandørens problem.
Virksomheden har købt et system fra en stor softwareleverandør. Leverandøren har bekræftet, at produktet er bygget i overensstemmelse med EU AI Act. Ergo er virksomheden compliant.
Det er ikke korrekt.
EU AI Act opdeler ansvar i to kategorier. Providere er dem, der bygger og markedsfører AI-systemer. Deployere er dem, der anvender AI-systemer i en professionel kontekst. De fleste virksomheder er deployere. Og deployer-ansvaret er selvstændigt. Det deles ikke med leverandøren og kan ikke outsources til en leverandørerklæring.
Udskydelsen af højrisikofristen til 2. december 2027 ændrer ikke på det. Den flytter tidspunktet, hvor kravene til højrisikosystemer gælder, ikke hvem de gælder for. Og flere krav gælder allerede. Offentliggør I deepfakes eller bruger følelsesgenkendelse, er det jer som deployer, der skal oplyse om det.
Hvad deployer-ansvaret konkret indebærer
Som deployer skal I bruge et højrisikosystem efter leverandørens brugsanvisning. Og tager I et system i brug til et højrisikoformål, det ikke er bygget til, bliver I selv provider med hele leverandøransvaret. En sprogmodel købt til at opsummere dokumenter bliver ikke godkendt til at sortere jobansøgere, blot fordi nogen internt finder den velegnet til det.
For højrisikosystemer har I fra december 2027 ansvar for at sikre menneskelig overvågning. Det er ikke tilstrækkeligt, at et menneske teknisk set kan gribe ind. Der skal faktisk være en proces, der sikrer at et menneske gennemgår og godkender output i de sammenhænge, loven kræver det.
I skal tage skridt til at understøtte, at medarbejdere, der arbejder med AI-systemet, har den nødvendige forståelse. Kravet blev blødt op med Omnibus, men det gælder stadig. Og menneskelig overvågning virker kun, hvis de mennesker, der overvåger, forstår systemets begrænsninger og ved, hvornår de skal tilsidesætte dets output.
Og I skal gemme de logs, et højrisikosystem danner, i mindst seks måneder, så brugen kan dokumenteres. Ikke leverandøren. Jer.
Hvorfor det er et arkitekturspørgsmål, ikke et juridisk spørgsmål
Når deployer-ansvaret lander hos jura, opstår der systematisk et problem: jura ved, hvad der kræves, men ved ikke, hvad systemet reelt gør. De ved, at der skal være menneskelig overvågning, men ved ikke, hvilke processer systemet indgår i. Og dermed heller ikke, om overvågningen faktisk er på plads.
De ved, at brugen skal logges, men ved ikke, om der overhovedet er et logningssystem koblet til det pågældende AI-system i produktionsmiljøet.
De spørgsmål besvares af Enterprise Architecture. Eller de burde.
AI-governance, der er placeret udelukkende hos compliance-funktionen, er governance, der mangler halvdelen af det faktuelle grundlag for sine egne konklusioner.
Tre spørgsmål du kan stille i denne uge
For hvert AI-system I anvender: bruges det kun til det formål, det er vurderet og godkendt til? Hvem kontrollerer det og hvor ofte?
For højrisikosystemer: er den menneskelige overvågning en reel del af arbejdsprocessen? Eller er det en formel mulighed, ingen bruger i praksis?
For hele porteføljen: er der nogen, der ved præcis hvilke AI-systemer I bruger i dag, herunder dem leverandøren aktiverede uden at spørge?
De spørgsmål er billige at stille. Dyre at stå med, når nogen udefra stiller dem i stedet.
Læs mere om emnet
EU AI Act 2026: guide og tidslinje efter Omnibus →
Brian P.N. Tofft
Managing Partner, We Lead Projects
Klarsynet er Brians månedlige nyhedsbrev om AI-governance, enterprise architecture og projektledelse. Skrevet ud fra det, han ser hos kunderne.