Annex III forklaret — hvornår er din AI 'high-risk'?

Annex III er det bilag til EU AI Act der definerer hvilke AI-applikationer der betragtes som "high-risk" og dermed underlagt de strengeste krav. Forståelse af Annex III er ikke en juridisk opgave — det er en it-ledelses-opgave. Du skal kunne afgøre om jeres systemer falder inden for det.

Denne artikel gennemgår de otte kategorier, giver konkrete eksempler fra industrier der er relevante for nordisk midmarket, og beskriver hvad "high-risk" faktisk betyder for jer i praksis.

Hvad er Annex III?

Annex III er en liste over otte kategorier af AI-systemer der automatisk klassificeres som high-risk. Det er ikke en udtømmende liste over alle risikable AI-systemer — det er reguleringslovgivningens svar på "hvilke anvendelser er vigtige nok til at kræve dokumentation, tilsyn og vurdering?"

Kategoriseringen er baseret på tre kriterier: sektoren systemet opererer i, systemets funktion, og den potentielle skade på individers grundlæggende rettigheder.

Vigtig præcisering: High-risk klassificeringen gælder for AI-systemer der bruges som komponenter i regulerede produkter, eller selvstændige AI-systemer der har direkte effekt på adgang til ressourcer, rettigheder eller serviceydelser.

De otte kategorier

1. Biometrisk identifikation og kategorisering

AI-systemer til fjernidentifikation, realtids- eller post-hoc biometrisk identifikation af personer i offentlige rum, samt systemer til at kategorisere individer baseret på biometriske data (ansigt, gang, stemme).

Relevant for midmarket? Adgangskontrolsystemer med ansigtsregistrering, tidsstempling via biometri. Mange HR-systemer i Europa bevæger sig allerede væk fra disse teknologier som reaktion på AI Act.

Hvad det kræver: Fuld high-risk compliance inklusiv FRIA, teknisk dokumentation og menneskelig tilsyn.

2. Kritisk infrastruktur

AI-systemer til styring og drift af kritisk infrastruktur — energi, vand, transport, finansielle infrastrukturer.

Relevant for midmarket? Energi-selskaber, vandforsyninger, produktionsvirksomheder med OT-infrastruktur. AI til forudsigelse af maskinnedbrud eller optimering af energiforbrug kan falde her, afhængigt af kontekst.

Hvad det kræver: Særlig opmærksomhed på robusthed og cybersikkerhed, da fejl kan have samfundsmæssige konsekvenser.

3. Uddannelse og erhvervsuddannelse

AI-systemer der bruges til at bestemme adgang til uddannelse, vurdere studerendes præstationer, eller tilpasse undervisning på måder der kan påvirke karrierevejen.

Relevant for midmarket? E-learning-platforme med AI-drevet bedømmelse, onboarding-systemer der vurderer færdighedsniveau, og HR-systemer der screener kandidater til interne uddannelsesprogrammer.

Hvad det kræver: Klar dokumentation af vurderingskriterier, mulighed for menneskelig gennemgang af AI-beslutninger, og transparens over for de berørte.

4. Beskæftigelse og HR

AI-systemer til rekruttering, screening af ansøgninger, vurdering af præstationer, forfremmelse eller afskedigelse.

Relevant for midmarket? Dette er formentlig den kategori der berører flest nordiske midmarket-virksomheder. CV-screeningsværktøjer, ATS-systemer med AI-ranking, eller AI-drevne performance reviews falder alle her.

Eksempel: Et AI-system der rangerer jobansøgere baseret på CV-analyse er high-risk. Det påvirker direkte individers adgang til beskæftigelse.

Hvad det kræver: FRIA, teknisk dokumentation fra leverandøren, menneskelig tilsyn ved alle endelige beslutninger, og mulighed for at kandidater kan få en forklaring.

5. Adgang til og brug af offentlige og private kerneydelser

AI-systemer der bruges til at vurdere kreditværdighed, afgøre om individer er berettiget til offentlige ydelser, sundhedsydelser, bolig, eller forsikring.

Relevant for midmarket? Finansielle institutioner med AI-drevne kreditscoring-systemer, forsikringsselskaber med AI-risikovurdering, og sundhedsvirksomheder med AI-triage-systemer.

Hvad det kræver: Fuld dokumentation og transparens. Individer har ret til at forstå grundlaget for beslutninger der påvirker dem.

6. Retshåndhævelse

AI-systemer brugt af politimyndigheder til risikovurdering af individer, analyse af kriminalitet og profiling.

Relevant for midmarket? Meget lavt — primært relevant for offentlige myndigheder. Undtagelse: sikkerhedsvirksomheder der leverer analysetjenester til politiet.

7. Migration og asylstyring

AI-systemer der bruges til grænseovervågning, risikovurdering i asylprocesser, eller identitetsverifikation af migranter.

Relevant for midmarket? Lavt. Primært relevant for offentlige myndigheder og dedikerede leverandører til migrationsforvaltning.

8. Administration af retfærdighed og demokrati

AI-systemer der hjælper domstole med faktanalyse, tolkning af lovgivning, eller vurdering af sagers udfald.

Relevant for midmarket? Lavt. Relevant for juridiske tech-virksomheder og systemer der understøtter retsvæsenet.

Hvad der IKKE er high-risk

Det er ligeså vigtigt at forstå hvad der ikke er high-risk. AI Act definerer en "minimal risk" kategori der ikke har nogen formelle forpligtelser, blot frivillige transparensanbefalinger:

• Spam-filtre
• Anbefalingsalgoritmer (Netflix-lignende) der ikke påvirker adgang til ressourcer
• Indholdsmoderationssystemer der ikke diskriminerer
• Prisfastsættelsesalgoritmer for massemarkedsprodukter
• Produktivitetsassistenter (generativ AI til tekstforslag, kodning osv.)

Et vigtigt punkt: Generel-purpose AI-modeller som GPT eller Claude er ikke i sig selv high-risk systemer. Det er den specifikke deployment og applikation der afgør klassificeringen.

Selvcheck: Er jeres system high-risk?

Brug disse tre spørgsmål som første filter:

1. Sektortjek: Opererer systemet inden for en af de otte kategorier (biometri, infrastruktur, uddannelse, HR, finansielle services, retshåndhævelse, migration, retsvæsen)?

2. Effektstjek: Kan systemets output direkte påvirke et individs adgang til ydelser, ressourcer, beskæftigelse, eller offentlige tjenester?

3. Beslutningsstjek: Bruger I systemets output til at træffe eller informere beslutninger om specifikke individer?

Tre "ja"-svar: Jeres system er sandsynligvis high-risk og kræver fuld compliance-indsats.

Én eller to "ja"-svar: Gennemgå kategorien grundigt med jeres juridiske rådgiver.

Alle "nej": Systemet er sandsynligvis ikke high-risk, men dokumentér begrundelsen.

Hvad high-risk klassificering kræver i praksis

For deployere (de fleste midmarket-virksomheder) kræver high-risk klassificering:

• Teknisk dokumentation fra leverandøren: I har krav på at modtage og opbevare dokumentation om systemets arkitektur, træningsdata og kendte begrænsninger.
• FRIA (Fundamental Rights Impact Assessment): En fem-trins vurdering af systemets potentielle effekt på grundlæggende rettigheder.
• Menneskelig tilsynsprotokol: En skriftlig procedure for hvornår og hvordan en medarbejder kan gribe ind eller overstyre systemet.
• Logning: Relevant systemaktivitet skal logges i tilstrækkeligt omfang til at muliggøre revision.
• Transparens over for brugere: Individer der er berørt af systemets beslutninger skal informeres om dette.

Grænsetilfælde: Embedded AI i eksisterende systemer

Et hyppigt spørgsmål: "Hvad med AI der er bygget ind i SAP, Dynamics 365, eller vores ERP?" Svaret er nuanceret.

Generelt gælder: Hvis den AI-funktion der er bygget ind i systemet falder inden for en Annex III-kategori, og I bruger den funktion til at træffe beslutninger om individer, er I deployer af et high-risk AI-system — uanset om AI'en er synlig for jer eller ej.

Eksempel: Dynamics 365 HR har en "Kandidatanbefalings"-funktion baseret på AI. Bruger I den aktivt til at sortere ansøgere, er I sandsynligvis deployer af et high-risk system inden for kategori 4. Det er leverandørens ansvar at levere dokumentationen — men det er jeres ansvar at bede om den og opbevare den.

Eksempel 2: SAP's predictive maintenance-modul til produktionsudstyr. Afhænger af om det bruges til "kritisk infrastruktur" (kategori 2) eller blot til produktionsoptimering i ikke-kritisk kontekst.

Leverandøransvar vs. deployer-ansvar

Det er vigtigt at skelne mellem hvad leverandøren er ansvarlig for og hvad I som deployer er ansvarlig for.

Leverandørens ansvar (udbyder under AI Act):

• Teknisk dokumentation af systemet (Article 11)
• CE-mærkning og overensstemmelsesvurdering for high-risk systemer
• Registrering i EU-databasen over high-risk AI-systemer
• Opdatering og vedligehold af compliance-dokumentation

Jeres ansvar som deployer:

• At modtage og opbevare leverandørens tekniske dokumentation
• At gennemføre FRIA inden deployment
• At implementere menneskelig tilsynsprotokol
• At informere berørte individer
• At sikre at systemet kun bruges inden for dets tilsigtede anvendelse

Det betyder at jeres due diligence-proces for AI-indkøb bør inkludere et krav om at leverandøren kan dokumentere systemets Annex III-status, og at I modtager den tekniske dokumentation I er berettiget til.

Hvad sker der, når Annex III opdateres?

AI Act giver Kommissionen beføjelse til at opdatere Annex III via delegerede retsakter. Det betyder at listen over high-risk systemer kan udvides over tid. EU's AI-kontor overvåger løbende teknologiudviklingen og markedets praksis.

For jer som virksomheder betyder det: AI inventory og risikoklassificering er ikke en engangsopgave. Det er en løbende proces. Sæt en halvårlig gennemgang i kalenderen fra 2026.

Hvad gælder for systemer I bygger internt?

Mange midmarket-virksomheder bygger eller fine-tuner AI-modeller selv — typisk ved brug af platforme som Azure OpenAI, AWS Bedrock, eller Google Vertex AI. Hvad gælder for disse systemer?

Hvis I bygger et AI-system der falder under en Annex III-kategori, er I udbyder under AI Act — ikke blot deployer. Det indebærer langt mere omfattende krav: overensstemmelsesvurdering, CE-mærkning, registrering i EU-databasen, og fuld teknisk dokumentation inklusiv beskrivelse af træningsdata.

For de fleste midmarket-virksomheder der bruger pre-trained modeller og tilpasser dem via prompt engineering eller fine-tuning, er klassificeringen knap så klar. Generelt gælder: Tilpasning via prompting ændrer ikke on sig selv klassificeringen. Fine-tuning på egne data til en high-risk applikation kan gøre jer til udbyder.

Praktisk konklusion for midmarket

De fleste nordiske midmarket-virksomheder vil have ét til tre high-risk systemer i brug — typisk inden for HR (rekruttering), muligvis inden for finansiel risikovurdering, og potentielt inden for OT-styring i produktionsvirksomheder.

Start med HR og rekrutteringsværktøjer. Det er den kategori der rammer bredest i midmarket og er lettest at identificere.

Kontakt jeres leverandører og bed om: (1) en erklæring om systemets Annex III-status, (2) teknisk dokumentation som I er berettiget til som deployer, og (3) en beskrivelse af det menneskelige tilsynsregime.

Dokumentér begrundelsen for systemer I klassificerer som "ikke high-risk". Tilsynsmyndighederne kan spørge — og "vi vidste det ikke" er ikke et svar der mindsker ansvaret.

Annex III er ikke designet til at forbyde disse systemer. Det er designet til at gøre dem ansvarlige. Det kræver papirarbejde — men papirarbejdet er muligvis det vigtigste I gør for at beskytte jer selv og jeres medarbejdere.