AI-forordningen i praksis: teknisk dokumentation, logning, menneskeligt tilsyn og datastyring

Det meste af det, der er skrevet om AI-forordningen, handler om anvendelsesområde: hvilket risikoniveau I lander på, om I er udbyder eller idriftsætter, om jeres system fanges af bilag III. Det svarer jeres juridiske rådgivere på.

Det, næsten ingen tager fat på, er, hvad der sker efter svaret. Er jeres system højrisiko, forlanger forordningen et risikostyringssystem, der løber gennem hele livscyklussen, datastyring I kan dokumentere, automatisk logning med defineret opbevaring, teknisk dokumentation i en foreskrevet struktur, menneskeligt tilsyn der er designet frem for påstået, og overvågning efter omsætning, der rent faktisk indsamler noget. Det er tekniske leverancer. Det er den del, vi bygger.

Sådan står fristerne nu

AI-forordningen (forordning (EU) 2024/1689) trådte i kraft i august 2024 og finder anvendelse i etaper. Etaperne blev ændret i 2026, og det er værd at være præcis om, for ændringen flyttede både penge og opmærksomhed.

• 2. februar 2025: forbudte former for praksis og kravene om AI-færdigheder fandt anvendelse.
• 2. august 2025: forpligtelserne for AI-modeller til almen brug fandt anvendelse.
• 2. august 2026: gennemsigtighedsforpligtelserne i artikel 50 fandt anvendelse: oplysning om at brugeren interagerer med et AI-system, mærkning af syntetisk indhold, oplysning om følelsesgenkendelse og biometrisk kategorisering samt mærkning af deepfakes.
• 2. december 2027: højrisikoforpligtelserne for selvstændige systemer, efter Digital Omnibus. Rådet og Parlamentet blev enige om udsættelsen i maj 2026, og den blev endeligt godkendt i juni 2026.
• 2. august 2028: højrisikoforpligtelserne for AI-systemer, der er indbygget i regulerede produkter.

Er I udbyder af et højrisikosystem, købte udsættelsen jer omkring seksten måneder. Den reducerede ikke arbejdet, og den flyttede ikke de to forpligtelser, der allerede gælder: gennemsigtighed efter artikel 50 og AI-færdigheder for de medarbejdere, der betjener systemerne.

Det, vi bygger

Teknisk dokumentation som et genereret artefakt

Bilag IV angiver, hvad den tekniske dokumentation skal indeholde: systembeskrivelse, designvalg, arkitektur, datakrav, træningsmetode hvor det er relevant, validerings- og testprocedurer, målepunkter, risikostyringsforanstaltninger og de ændringer, der er foretaget gennem livscyklussen.

Skrevet i hånden er det dokument forældet ugen efter, det er underskrevet. Vi bygger det som noget, jeres pipeline producerer: model cards og datablade genereret ud fra trænings- og evalueringskørslerne, arkitektur- og dataflowbeskrivelser vedligeholdt sammen med koden, evalueringsresultater hæftet på den version, de beskriver, og en ændringshistorik der kommer fra jeres versionsstyring frem for fra nogens hukommelse. Dokumentet bliver et build-output.

Automatisk logning, der lever op til artikel 12

Højrisikosystemer skal logge automatisk gennem hele deres levetid, på et niveau der gør det muligt at spore systemets funktion og understøtte overvågning efter omsætning, med en opbevaringsperiode, der passer til formålet, og i visse tilfælde på mindst seks måneder.

I praksis betyder det at beslutte, hvad en "hændelse" er for jeres system, at opsamle input, output, modelversion, beslutningsvej og identiteten på det involverede menneske, at gemme det i en form der stadig kan søges i om flere år, og at gøre det uden at samle personoplysninger op, som I ikke har grundlag for at opbevare. Den modsætning (log nok til AI-forordningen, gem lidt nok til GDPR) er det egentlige designproblem, og vi tager det eksplicit sammen med jeres databeskyttelsesfolk.

Datastyring efter artikel 10

Trænings-, validerings- og testdatasæt skal være relevante, tilstrækkeligt repræsentative og i videst muligt omfang fejlfrie og fuldstændige, med undersøgelse for bias. At leve op til det kræver dataherkomst, I kan fremvise, dokumenteret proveniens, en metode til biasvurdering med resultater, og evnen til at reproducere hvilke data der frembragte hvilken modelversion.

Vi bygger den pipeline, der gør de udsagn kontrollerbare frem for ønsketænkning: versionerede datasæt, reproducerbare splits, automatiserede datakvalitetstjek og biasevaluering på de beskyttede karakteristika, der er relevante for jeres anvendelse.

Menneskeligt tilsyn, bygget frem for erklæret

Artikel 14 kræver, at højrisikosystemer designes, så et menneske kan forstå outputtet, forblive opmærksom på automatiseringsbias, fortolke resultatet korrekt, beslutte ikke at bruge det og gribe ind eller standse systemet.

Det er en kravspecifikation til en brugerflade. Vi bygger tilsynet ind i produktet: konfidens og usikkerhed vist ærligt, de faktorer der ligger bag et output gjort synlige, en tilsidesættelse der er lige så let at bruge som en accept, en stopfunktion der virker, og logning af hver tilsidesættelse, så overvågningen efter omsætning har noget at lære af.

Overvågning efter omsætning og indberetning af hændelser

Der skal foreligge en overvågningsplan, og alvorlige hændelser skal indberettes til den relevante myndighed. Vi bygger den telemetri, der føder den: ydelse målt mod de målepunkter, der står i jeres dokumentation, detektion af drift i input og output, en kanal for brugerrapporterede problemer der faktisk når frem til udviklingen, og et hændelsesforløb med tidsfristerne indbygget frem for opdaget under en hændelse.

Gennemsigtighedsforpligtelser efter artikel 50

Gælder allerede. Oplysning om at brugeren har med et AI-system at gøre, maskinlæsbar mærkning af syntetisk lyd, billede, video og tekst, mærkning af deepfakes og oplysning ved følelsesgenkendelse. Vi implementerer oplysningsfladerne og mærkningen af indholdets oprindelse (C2PA content credentials hvor det er den rigtige mekanisme), og sørger for, at de overlever de eksport- og genkodningsveje, der normalt fjerner dem.

Registrering og støtte til overensstemmelsesvurdering

Højrisikosystemer på bilag III-områderne skal registreres i EU-databasen, før de bringes i omsætning, og udbydere skal gennemføre en overensstemmelsesvurdering. Vi forbereder det tekniske input (dokumentationen, dokumentationspakken, de artefakter fra kvalitetsstyringssystemet der ligger på udviklingssiden), og arbejder sammen med jeres bemyndigede organ eller jeres interne vurderingsproces.

Hvad det ikke er

Vi yder ikke juridisk rådgivning, og vi fortæller jer ikke, hvilket risikoniveau jeres system ligger på. Den vurdering er juridisk og har reelle konsekvenser, og den hører hjemme hos en advokat eller en kvalificeret compliancerådgiver.

Vi sælger heller ikke en AI-governanceplatform. Der findes mange af dem, og er jeres behov et register over AI-systemer og et policyworkflow, vil en af dem tjene jer bedre, end vi ville. Det, vi laver, er ingeniørarbejdet inde i selve systemerne.

Hvem det er til

Udbydere af højrisiko-AI-systemer efter bilag III (rekruttering og medarbejderstyring, kreditvurdering, forsikringsprissætning, bedømmelse i uddannelse, adgang til væsentlige tjenester, biometriske systemer), som nu har frist til december 2027 og meget at bygge.

Producenter, der bygger AI ind i regulerede produkter (medicinsk udstyr, maskiner, køretøjer), hvor AI-forordningen lægger sig oven på en eksisterende overensstemmelsesordning, og de to dokumentationssæt skal stemme overens.

Virksomheder, der idriftsætter højrisikosystemer købt af andre, og som har deres egne forpligtelser: menneskeligt tilsyn, relevans af inputdata, overvågning og opbevaring af logfiler.

Alle, der leverer generative funktioner til brugere i EU, hvor gennemsigtighedskravet i artikel 50 allerede gælder i dag uanset risikoniveau.

Sådan forløber et samarbejde

Teknisk gap-analyse, to til fire uger. Vi tager den klassificering, jeres juridiske team er nået frem til, og vurderer jeres systemer op mod de tekniske forpligtelser, der følger af den. Leverancen er et gap-register (forpligtelse, nuværende tilstand, hvad der skal bygges, estimat), som både jeres compliance- og udviklingsansvarlige kan arbejde ud fra.

Udvikling, i faser, som regel med start i logning og dokumentationsgenerering, fordi alt det øvrige producerer dokumentation, der skal lande et sted.

Readiness-gennemgang forud for overensstemmelsesvurderingen, med dokumentationspakken samlet og de tilbageværende huller nævnt ærligt.

Standarder og rammeværk

Forordning (EU) 2024/1689 og dens bilag III og IV; de harmoniserede standarder, der er på vej fra CEN/CENELEC JTC 21; ISO/IEC 42001 for ledelsessystemer for AI og ISO/IEC 23894 for AI-risikostyring; NIST AI Risk Management Framework hvor et amerikansk moderselskab skal have overensstemmelse med det; og GDPR, som ikke forsvinder, og som lægger rammerne for de fleste beslutninger om logning.

Ofte stillede spørgsmål

Er AI-forordningen blevet udsat?

Delvist. Digital Omnibus udsatte højrisikoforpligtelserne til 2. december 2027 for selvstændige systemer og 2. august 2028 for AI indbygget i regulerede produkter. Forbudte former for praksis, AI-færdigheder, forpligtelserne for AI-modeller til almen brug og gennemsigtighedsreglerne i artikel 50 blev ikke udsat og gælder nu.

Vi bruger kun AI-systemer, andre har bygget. Har vi forpligtelser?

Ja, som idriftsætter. De omfatter at bruge systemet i overensstemmelse med brugsanvisningen, at tildele det menneskelige tilsyn til personer med kompetence og beføjelse til at udøve det, at sikre at inputdata er relevante for det tilsigtede formål, at overvåge driften og at opbevare logfiler. Lettere end en udbyders forpligtelser, men reelle, og bemærk, at væsentlige ændringer af et system eller at sætte sit eget navn på det kan gøre jer til udbyder.

Vores system er ikke højrisiko. Er der noget at gøre?

Sandsynligvis to ting. Gennemsigtighedskravet i artikel 50 gælder for visse systemer uanset risikoniveau, herunder chatbots og generering af syntetisk indhold. Og kravet om AI-færdigheder i artikel 4 gælder generelt for udbydere og idriftsættere. Derudover er det værd at kunne dokumentere klassificeringsbeslutningen, hvis en myndighed en dag spørger.

Kan den tekniske dokumentation virkelig genereres?

Det meste, ja. Arkitektur, beskrivelser af datasæt, evalueringsresultater, målepunkter, modelversioner og ændringshistorik findes allerede i jeres systemer; arbejdet er at opsamle det i en stabil struktur på byggetidspunktet. De egentligt fortællende afsnit (tilsigtet formål, risikoanalyse, designrationale) skrives af mennesker og lægges så i det samme repository, så de versioneres sammen med alt andet.

Hvordan spiller AI-forordningen sammen med GDPR?

De overlapper og trækker af og til i hver sin retning, især på logning. AI-forordningen vil have sporbarhed; GDPR vil have dataminimering og sletning. Løsningen er som regel pseudonymisering, omhyggelig afgrænsning af hvad der logges, og en defineret opbevaringsperiode knyttet til et dokumenteret formål. Det er en designbeslutning, taget én gang og bevidst.

Gør det os til udbyder af en model, at vi bruger en tredjeparts model?

Nej, men at bygge et AI-system oven på den kan gøre jer til udbyder af det system, med de forpligtelser der følger med. Hvor grænsen går afhænger af, hvad I bygger, og hvordan I præsenterer det, og det er et juridisk spørgsmål, men den tekniske konsekvens er, at I bør regne med at skulle have dokumentation for jeres eget system uanset hvad.

Kom i gang

Fortæl os, hvad jeres systemer gør, og hvor jeres juridiske rådgivere er landet på klassificeringen. Så vurderer vi, hvad forpligtelserne betyder i kode, og giver jer et gap-register med et estimat på hver linje.

Kontakt os for at booke en teknisk gap-analyse for AI-forordningen.

Relaterede ydelser

• AI-agenter og MCP-integration: at bygge de systemer, dette regelsæt regulerer
• EU market entry development: den bredere EU-stak for digital compliance
• Udbedring af webtilgængelighed: den anden EU-forpligtelse, der viser sig at være et udviklingsprojekt