AI Act-software kan understøtte kortlægning, dokumentation og opfølgning på konkrete AI-systemer. Valget afhænger af virksomhedens rolle, anvendelse og nødvendige dokumentation. Denne guide vurderer arbejdsopgaver og indkøbskriterier; den angiver ikke dokumenterede markedspriser eller en rangering af bestemte leverandører.
Opdateret EU-tidslinje og virksomhedens rolle
Europa-Kommissionens aktuelle oversigt, kontrolleret 8. september 2026, skelner mellem følgende datoer. AI-omnibus trådte i kraft 27. juli 2026. Den tidligere generelle angivelse af august 2026 for højrisikokrav er derfor ikke et korrekt grundlag for planlægningen.
| Dato i EU | Relevant område |
|---|---|
| 2. februar 2025 | Forbudte praksisser og AI-kompetencer |
| 2. august 2025 | GPAI-forpligtelser og dele af styringsreglerne |
| 2. august 2026 | Generel anvendelse, herunder relevante gennemsigtighedskrav, med undtagelser |
| 2. december 2027 | Højrisikoanvendelser i bestemte følsomme områder efter bilag III |
| 2. august 2028 | Højrisikosystemer indlejret i regulerede produkter |
Knyt hver opgave til den konkrete bestemmelse, rolle og anvendelse. En deployer, en systemudbyder og en GPAI-modeludbyder har ikke identiske pligter. Kontroller også særlige overgangsregler. Et internt AI-register er en praktisk oversigt; det er ikke det samme som enhver lovbestemt registreringspligt. GDPR gælder selvstændigt, når personoplysninger behandles, og en DPIA kræves efter betingelserne i artikel 35, ikke automatisk ved enhver AI-anvendelse.
Tidslinjen: hvornår gælder hvad?
AI-forordningen trådte i kraft den 1. august 2024 og indfases trinvist:
Risikoklassifikationen: fundamentet
AI-forordningen inddeler systemer i fire risikoniveauer, og softwaren skal understøtte klassifikationen:
- Uacceptabel risiko – forbudt (f.eks. social scoring, visse former for biometrisk overvågning).
- Høj risiko – tilladt med strenge krav til risikostyring, datastyring, dokumentation, menneskeligt tilsyn og robusthed (f.eks. AI i rekruttering, kreditvurdering, kritisk infrastruktur).
- Begrænset risiko – gennemsigtighedskrav (f.eks. chatbots skal oplyse, at brugeren taler med en maskine).
- Minimal risiko – ingen særlige krav (f.eks. spamfiltre).
Størstedelen af arbejdet ligger i at afgøre, om et system er højrisiko, og – hvis det er – at opfylde de tilhørende krav. Et værktøj, der guider denne vurdering og dokumenterer resultatet, er kernen i AI Act-software.
Hvad skal softwaren dække?
| Krav | Hvad det indebærer | Hvad værktøjet skal kunne |
|---|---|---|
| AI-register | Overblik over alle AI-systemer | Struktureret register over udviklede og anvendte systemer |
| Risikoklassifikation | Placering i de fire niveauer | Guidet vurdering med dokumentation |
| Højrisikodokumentation | Teknisk dokumentation, risikostyring | Skabeloner og sporbarhed |
| Gennemsigtighed | Oplysning til brugere | Registrering af gennemsigtighedsforanstaltninger |
| Overlap med GDPR | AI der behandler personoplysninger | Kobling til fortegnelsen og DPIA |
Udvalgskriterier for danske virksomheder
- AI-register først. Uden et overblik over, hvilke AI-systemer virksomheden anvender, kan intet andet gøres. Registeret er startpunktet.
- Guidet risikoklassifikation. De fleste virksomheder er i tvivl om, hvornår et system er højrisiko. Et værktøj, der guider vurderingen, sparer juristtimer.
- Kobling til GDPR. Undgå at føre AI- og GDPR-dokumentation i to systemer, der ikke taler sammen.
- Tilgængelig dokumentation og databeskyttelse. Afklar passende sprog, adgang, hosting og eventuelle overførsler; EU-hosting er ikke i sig selv et generelt krav eller et bevis på lovlig behandling.
AI-kompetencer: et krav der allerede gælder
En pligt, der ofte overses, er kravet om AI-kompetencer (AI literacy), der har været gældende siden den 2. februar 2025. Enhver virksomhed, der udvikler eller anvender AI-systemer, skal sikre, at de medarbejdere, der arbejder med systemerne, har et tilstrækkeligt niveau af viden om AI – tilpasset deres rolle og systemets risiko. Det er ikke et krav om formel certificering, men om, at virksomheden aktivt sørger for, at medarbejderne forstår, hvad systemerne gør, hvilke risici de indebærer, og hvordan de bruges ansvarligt. For danske virksomheder betyder det, at AI-efterlevelse ikke kun handler om dokumentation, men også om træning. En registrering af oplæring kan indgå som dokumentation; den viser ikke alene, at det nødvendige kompetenceniveau er opnået – på samme måde som dokumentation af medarbejderuddannelse under NIS2 og GDPR.
Højrisikosystemernes konkrete krav
Når et system klassificeres som højrisiko, udløser AI-forordningen en række konkrete pligter, som softwaren skal hjælpe med at dokumentere. Udbyderen skal etablere et risikostyringssystem, sikre datastyring af høj kvalitet i træningsdata, udarbejde teknisk dokumentation, føre logfiler, sikre gennemsigtighed over for brugerne, muliggøre menneskeligt tilsyn og opnå et passende niveau af nøjagtighed og robusthed. Deployere – altså virksomheder, der anvender et højrisikosystem udviklet af andre – har deres egne pligter, blandt andet at bruge systemet i overensstemmelse med brugsanvisningen, sikre menneskeligt tilsyn og overvåge driften. For danske virksomheder er det væsentligt at afklare, om man er udbyder eller deployer, fordi pligterne er forskellige. Værktøjet kan organisere oplysningerne, men den konkrete juridiske vurdering skal stadig gennemføres.
AI-register: sådan kommer du i gang
Startpunktet for enhver AI Act-efterlevelse er et register over virksomhedens AI-systemer. Uden overblik over, hvad der reelt anvendes, kan intet klassificeres eller dokumenteres. En pragmatisk fremgangsmåde: kortlæg alle systemer med en AI-komponent – både indkøbte værktøjer og egenudviklede løsninger – notér for hvert system, hvad det bruges til, hvilke data det behandler, og om det træffer eller understøtter beslutninger om mennesker. Klassificér derefter hvert system i de fire risikoniveauer, og prioritér de systemer, der kan være højrisiko. Registeret bør holdes ajour, efterhånden som nye AI-værktøjer tages i brug – præcis som fortegnelsen over behandlingsaktiviteter under GDPR. Mange danske virksomheder opdager i denne øvelse, at de anvender langt flere AI-systemer end forventet, ofte indlejret i eksisterende software.
Skal min virksomhed overholde AI-forordningen?
Hvis I udvikler eller anvender AI-systemer, gælder forordningen for jer – med krav der afhænger af systemets risikoniveau. De fleste virksomheder anvender AI af begrænset eller minimal risiko med lette krav, men systemer i rekruttering, kreditvurdering eller kritisk infrastruktur kan være højrisiko med omfattende pligter. Start med at kortlægge og klassificere jeres AI-systemer.
En konkret indkøbsprøve med et hypotetisk system
Bed to mulige leverandører gennemføre den samme opgave med syntetiske oplysninger. Et tænkt firma vil anvende et AI-værktøj til at sortere ansøgninger, men har endnu ikke afgjort klassifikation eller roller. Eksemplet er en demonstration af arbejdsgangen, ikke en juridisk konklusion om alle rekrutteringssystemer. Først registreres formål, brugergruppe, leverandør, version og de oplysninger, systemet behandler.
Vis derefter, hvordan en ansvarlig person undersøger de relevante kriterier og gemmer begrundelsen. Et automatisk resultat som høj risiko skal kunne forbindes med de oplysninger og regler, der førte til resultatet. Hvis en nødvendig oplysning mangler, skal den stå som en åben afklaring. Systemet må ikke få en godkendt status alene, fordi et spørgeskema teknisk kan afsluttes.
I næste trin ændres den planlagte anvendelse. Værktøjet skal gøre det muligt at se, hvilke vurderinger ændringen berører, hvem der skal reagere, og hvilken tidligere version der gjaldt. Kontroller, om historikken viser selve begrundelsen eller kun datoen for en redigering. En dato uden beslutningens indhold er et svagt grundlag for senere kontrol.
Kravliste med beviser frem for afkrydsninger
| Arbejdsopgave | Hvad virksomheden bør bede om at se |
|---|---|
| Oprette system | Et register med formål, ejer, rolle og konkret anvendelse |
| Dokumentere klassifikation | Vurdering, kilde, manglende oplysninger og ansvarlig beslutning |
| Knytte persondata | Henvisning til relevant behandling og særskilt DPIA-vurdering |
| Følge en ændring | Tidligere version, nye oplysninger og opfølgende opgaver |
| Kontrollere adgang | Adskilte roller for redigering, læsning og godkendelse |
| Udlevere materiale | Læselig eksport med nødvendige bilag og sammenhæng |
| Afslutte tjenesten | Tilbagelevering, sletning og dokumentation af resterende kopier |
For hvert punkt noteres, om funktionen er demonstreret i den tilbudte pakke, kræver et tillægsmodul eller blot er lovet til senere. Fremtidig udvikling kan indgå i en kommerciel dialog, men den er ikke en eksisterende kontrol. Virksomheden skal kende konsekvensen, hvis en nødvendig funktion ikke er klar ved den planlagte anvendelse.
Hvad skal et pristilbud indeholde?
Bed om et skriftligt tilbud på det samme afgrænsede omfang. Angiv antal systemer, brugere, vurderinger og de integrationer, der faktisk skal bruges. Spørg særskilt til indførsel, migrering, oplæring, support, eksport og afslutning. En lav licenspris kan ikke sammenlignes meningsfuldt med et tilbud, der omfatter væsentligt flere ydelser.
Opdel interne omkostninger fra leverandørens faktura. Fagpersoner skal stadig fremskaffe oplysninger, vurdere roller og træffe beslutninger, selv om et værktøj organiserer arbejdet. Brug et hypotetisk budget til intern planlægning, hvis nødvendigt, og mærk det tydeligt som et skøn. Et internt skøn må ikke præsenteres som en verificeret dansk markedspris.
Personoplysninger i selve styringsværktøjet
Et AI-register kan indeholde navne på medarbejdere, hændelser, vurderinger og fortrolige bilag. Kortlæg derfor også styringsplatformens egen behandling. Afklar leverandørens rolle, adgang ved support, underdatabehandlere, opbevaring og eventuelle overførsler. Et værktøj til efterlevelse er ikke fritaget for den vurdering, som virksomheden foretager af andre tjenester.
Ved en prøve bør syntetiske oplysninger bruges, hvor de kan vise funktionen. Upload ikke komplette personalesager blot for at se en rapportskabelon. Hvis produktionsdata er nødvendige, skal den konkrete anvendelse være afklaret på forhånd. Bed leverandøren vise, hvordan adgang begrænses, og hvordan prøveoplysninger fjernes efter vurderingen.
Godkendelse og efterfølgende kontrol
Beslutningen skal angive det valgte omfang, uafklarede spørgsmål og betingelser før brug. En vellykket demonstration beviser den observerede funktion i den viste version; den beviser ikke, at alle virksomhedens AI-systemer opfylder loven. Placer ansvaret for faglige vurderinger hos de relevante roller og bevar dokumentation for deres beslutninger.
Efter indførsel gennemgås et konkret system fra registrering til opfølgning. Kontroller også, om eksporten stadig er læselig, og om en ændring faktisk når frem til den ansvarlige. Når lovgrundlag eller produkt ændres, skal berørte vurderinger åbnes igen efter behov. Det er denne løbende sammenhæng, virksomheden køber støtte til.
Se DPIA-processen for den særskilte databeskyttelsesvurdering, fortegnelsen for databehandlingens formål, databeskyttelse i Danmark for den nationale ramme, programvare til fortegnelse for registerarbejdet og udvalgskriterier for GDPR-software for dokumenterede indkøbsspørgsmål.