EU AI Act — 20 ærlige svar

EU AI Act kræver ikke en specifik titulatur, men deployers af high-risk AI-systemer skal have klart dokumenteret ansvar for compliance. I praksis er det oftest IT-chefen, CTO, compliance-leder eller en dedikeret AI Officer. For en midmarket-virksomhed vil en deltidsrolle med klart defineret ansvar og mandat som regel være tilstrækkeligt. Det vigtige er at en navngiven person ejer AI-politikken og er eskalationspunkt for AI-incidents.

En AI governance-struktur er de processer og ansvarsniveauer der sikrer at AI-systemer indkøbes, deployes og bruges ansvarligt. For midmarket inkluderer dette minimum: en godkendelsesproces for nye AI-systemer, klare systemejere for hvert AI-system i drift, en eskalationsvej ved incidents, og en review-kadence for AI-politikken. Det behøver ikke være et formelt udvalg — det kan fungere som en del af eksisterende IT-governance.

For deployere af high-risk AI er en skrevet AI-politik praktisk talt obligatorisk — ikke fordi loven eksplicit kræver et dokument med den titel, men fordi tilsynsforpligtelserne (Article 26) kræver dokumenterede procedurer for brug, tilsyn og incidents. En AI-politik der samler disse krav i ét dokument giver klart overblik og er lettere at vise til tilsynsmyndigheder. For virksomheder der kun deployer minimal-risk AI er en skrevet politik stadig god praksis.

Definér hvad en AI-incident er i jeres kontekst: uventede eller skadelige outputs, brud på acceptable-use-politikken, shadow AI-brug, eller leverandørmeddelelser om kendte fejl i high-risk systemer. Opret en simpel incident-log med felter for dato, system, beskrivelse, berørte og afhjælpende handlinger. For high-risk systemer med potentiel effekt på individers rettigheder bør der være en dokumenteret eskalationsproces til systemejeren og eventuelt DPO. Svære incidents rapporteres muligvis til nationale tilsynsmyndigheder.

En AI inventory er et struktureret register over alle AI-systemer I bruger i jeres organisation. Det inkluderer indkøbte AI-applikationer, AI-funktioner i eksisterende platforme (f.eks. Copilot i M365, AI-ranking i jeres ATS), interne AI-modeller og generative AI-tjenester medarbejdere bruger i dagligdagen (shadow AI). Per system bør inventoryen minimum dokumentere: navn, leverandør, formål, brugergruppe, risikovurdering (Annex III-reference), systemansvarlig og deployment-dato.

Brug EU AI Acts fire niveauer: uacceptabelt (forbudt — f.eks. social scoring), high-risk (Annex III kategorier — f.eks. AI-rekruttering, kreditscoring), begrænset risiko (systemer der interagerer med mennesker men ikke high-risk — f.eks. chatbots, deepfake-generering) og minimal risiko (spam-filtre, anbefalingsalgoritmer). Tjek hvert system mod Annex III: berører det biometri, kritisk infrastruktur, uddannelse, beskæftigelse, finansielle kerneydelser, retshåndhævelse, migration eller retsvæsen? Ja-svar indikerer sandsynligvis high-risk.

En brugsbeskrivelse dokumenterer hvad systemet er designet til, hvem der bruger det og under hvilke betingelser. For high-risk systemer er dette et krav under Article 26. En god brugsbeskrivelse indeholder: systemets formål og tilsigtede brug, de primære brugergrupper (antal og rolle), de konkrete forretningsprocesser det understøtter, og potentielle effekter på berørte individer. Den behøver ikke være lang — to til tre afsnit per system er normalt nok.

Article 4 i EU AI Act pålægger deployers at sikre at medarbejdere der arbejder med AI-systemer har tilstrækkelig viden og forståelse til at bruge dem ansvarligt og inden for de tilsigtede rammer. Det er ikke et krav om specifik certificering eller et bestemt antal timer — det er et krav om at sikre passende kompetence baseret på systemets risikoprofil og den pågældendes rolle. For medarbejdere der bruger high-risk AI er kravene højere end for dem der bruger et simpelt AI-baseret rettekatalog.

Det afhænger af systemets risikoniveau og medarbejderens rolle. Tilsynsmyndigheder forventer proportionalitet: en HR-medarbejder der bruger et AI-rekrutteringssystem (high-risk) har brug for grundig træning i systemets begrænsninger, biasrisici og klageprocedurer. En medarbejder der bruger en AI-drevet søgefunktion (minimal risk) har brug for langt mindre. En praktisk minimumsstandard: alle medarbejdere der beslutter vha. AI-output om individer bør have dokumenteret træning i systemets begrænsninger og i hvordan menneskelig tilsyn fungerer.

Hold en simpel træningslog med: medarbejdernavn (eller anonymiseret ID), dato for gennemførelse, system der er trænet på, og formatet (e-learning, workshop, self-study). For high-risk systemer anbefales en bekræftelse fra medarbejderen at de har gennemgået og forstået materialet. En CSV-fil eller et regneark i jeres interne dokumentsystem er tilstrækkeligt til at starte — vigtigere er at loggen faktisk eksisterer og er opdateret.

En Fundamental Rights Impact Assessment (FRIA) er obligatorisk for deployere af high-risk AI-systemer (Article 27) inden deployment. 'High-risk' er defineret i Annex III — de otte kategorier inkluderer rekruttering og HR, kreditvurdering og finansielle kerneydelser, biometrisk identifikation, kritisk infrastruktur og uddannelse. FRIA skal revideres mindst hvert tredje år eller ved væsentlige ændringer i systemet. For systemer der behandler personoplysninger bør FRIA koordineres med en DPIA.

DPIA (Data Protection Impact Assessment) er et krav under GDPR og fokuserer på risici for personoplysninger og datasubjekters rettigheder. FRIA (Fundamental Rights Impact Assessment) er et nyt krav under AI Act og har et bredere fokus: alle grundlæggende rettigheder — herunder ret til ligebehandling, adgang til beskæftigelse og uddannelse, og menneskelig værdighed. FRIA er ikke begrænset til personoplysninger. Når et high-risk AI-system behandler personoplysninger, kræves begge vurderinger.

Article 11 kræver at udbydere af high-risk AI-systemer opbevarer og stiller teknisk dokumentation til rådighed. Som deployer er I berettiget til at modtage denne dokumentation fra jeres leverandør. Den tekniske dokumentation skal beskrive: systemets generelle beskrivelse og formål, systemarkitekturen, udviklingsprocessen (inkl. træningsdata-beskrivelse), ydeevnemetrikker og testresultater, kendte begrænsninger og risici, og cybersikkerhedsforanstaltninger. Bed jeres leverandører eksplicit om Article 11-dokumentation.

Article 12 og 26 kræver at high-risk AI-systemer logger aktivitet tilstrækkeligt til at muliggøre retrospektiv analyse af systemets opførsel. Det konkrete logningskrav afhænger af systemets art. For systemer der træffer eller påvirker beslutninger om individer bør loggen som minimum dokumentere: hvornår systemet blev brugt, hvilke inputs der blev givet, hvad outputtet var, og hvem der tog den endelige beslutning. Spørg jeres leverandør om systemets built-in logging og om I kan eksportere disse logs.

Gennemgå eksisterende kontrakter for AI-systemer med henblik på tre punkter: (1) Er leverandørens Annex III-klassificering af systemet dokumenteret? (2) Stiller leverandøren teknisk dokumentation til rådighed som krævet under Article 11? (3) Forpligter leverandøren sig til at informere jer om væsentlige ændringer i systemet der kan påvirke jeres compliance? Ved næste kontraktfornyelse kan I tilføje specifikke AI Act-clausuler. Start med at sende en simpel forespørgsel til jeres vigtigste AI-leverandører.

AI due diligence er processen med at vurdere et AI-system og dets leverandør inden deployment. En minimumsbaseret due diligence-tjekliste bør dække: Annex III-klassificering, tilgængelighed af teknisk dokumentation, leverandørens compliance-status, databehandlingsaftale (DPA), geografisk dataplacement, og kontaktperson for compliance-spørgsmål. For high-risk systemer bør due diligence dokumenteres og gemmes som del af compliance-arkivet.

Løbende leverandørovervågning handler om at holde sig opdateret om ændringer i AI-systemer der kan påvirke jeres compliance-status. Praktiske tiltag: tilmeld jer leverandørernes AI-compliance-nyhedsbreve eller release notes, sæt en halvårlig reminder om at tjekke om der er nye versioner af high-risk systemer, og sørg for at I modtager notifikation om incidents (mange leverandørkontrakter inkluderer dette ikke som standard — det skal eksplicit aftales).

For visse typer AI-genereret indhold er transparens et krav under AI Act Article 50. Specifikt gælder: deepfakes og AI-genererede lyd/billede/video-indhold til formål der kan vildlede skal mærkes. Chatbots og systemer der interagerer med mennesker på en måde der kan forveksles med menneskeinteraktion skal informere brugerne om at de interagerer med AI. For organisationer der bruger AI til at generere indhold til kunder og stakeholders er en klar mærkningspolitik en god idé.

Artikel 26 kræver at deployere af high-risk AI-systemer implementerer passende menneskelige overvågningstiltag. Det betyder i praksis: definér for hvert high-risk system hvilke beslutninger AI-output kan informere kontra hvilke der kræver human final approval, dokumentér proceduren for hvornår og hvordan en medarbejder kan override eller stoppe systemet, og sørg for at medarbejdere faktisk har kapacitet og kompetence til at udøve dette tilsyn. Menneskelig tilsyn er ikke reelt hvis medarbejderen altid godkender AI-outputtet uden review.

AI Act og GDPR overlapper på vigtige punkter, særligt for AI-systemer der behandler personoplysninger. Koordinationspunkter: (1) Opdatér jeres Register of Processing Activities (RoPA) med AI-systemer der behandler personoplysninger. (2) Koordinér FRIA og DPIA for high-risk AI-systemer med persondata. (3) Gennemgå privatlivspolitikker og -meddelelser for at afspejle AI-behandling. (4) Inkludér AI-leverandører i jeres leverandøroversigt under GDPR. DPO'en bør inddrages tidligt i AI Act compliance-arbejdet.