Din AI-politik — 8 sektioner du ikke kan undvære

AI-politikken er det dokument der definerer spillereglerne for AI-brug i jeres organisation. Uden den ved medarbejdere ikke hvad der er tilladt, ledelsen ved ikke hvad der er i drift, og I har ingen ramme at navigere incident-situationer ud fra.

Men de fleste AI-politikker fejler ikke fordi de er juridisk forkerte — de fejler fordi de er skrevet til at ligne en compliance-artefakt fremfor et styringsredskab. En 40-siders AI-politik der ingen læser er mindre værd end en to-siders politik alle kender.

Denne artikel gennemgår de otte sektioner der er obligatoriske i ethvert solidt AI-politikdokument, typiske fejl per sektion, og hvad en review-kadence ser ud for en midmarket-virksomhed.

Sektion 1: Formål og anvendelsesområde

Hvad den skal indeholde: En kort beskrivelse af hvorfor I har en AI-politik, hvem den gælder for (alle medarbejdere? Kun IT? Leverandører?), og hvilke typer AI-systemer den dækker.

Typisk fejl: For bred rammesætning ("gælder for alle former for automatisering og databehandling") eller for snæver ("gælder kun for interne AI-projekter"). Begge ender med at politikken ikke passer til virkeligheden.

Bedre formulering: "Denne politik gælder for alle medarbejdere og kontraktorer i [virksomhed] der bruger, deployer, eller indkøber AI-systemer som led i arbejdet. Den dækker AI-systemer vi deployer i forretningsprocesser, AI-assisterede produkter vi leverer til kunder, og generative AI-værktøjer brugt i det daglige arbejde."

Sektion 2: Definition af AI og risikoniveauer

Hvad den skal indeholde: En klar definition af hvad I betragter som "AI" i politikkens forstand, og en beskrivelse af jeres risikorammer. Brug EU AI Acts fire niveauer: uacceptabel / high-risk / begrænset risiko / minimal risiko.

Typisk fejl: At bruge en teknisk definition som ingen forretningsbrugere forstår. "Maskinlæring der bruger gradientnedstigning-optimering" er ikke brugbar i en AI-politik til forretningsfolk.

Bedre tilgang: Definer AI bredt ("systemer der genererer tekst, billeder, kode eller beslutninger baseret på data") og tilføj en liste over eksempler fra jeres faktiske AI-inventory. Definer derefter risikoniveauerne med konkrete eksempler fra jeres kontekst.

Sektion 3: Acceptabel og uacceptabel brug

Hvad den skal indeholde: En liste over acceptable anvendelser, en liste over forbudte anvendelser, og en gråzone-kategori der kræver forudgående godkendelse.

Typisk fejl: Uacceptabel-listen er juridisk boilerplate der ikke afspejler jeres faktiske risikoprofil. Acceptable-listen er så bred den ikke hjælper nogen med at forstå grænser.

Forbudte kategorier der altid bør med:

• Systemer der bruger social scoring til at rangere individer
• Ansigtsregistrering i offentlige rum til masseovervågning
• Systemer der udnytter sårbarhed (alder, mental tilstand) til at manipulere individers beslutninger
• AI til profilering af individer uden eksplicit samtykke og lovhjemmel

Eksempler på godkendelsespligtig gråzone:

• Nye generative AI-integrationer i kundevendte produkter
• AI-systemer der bruges i rekrutteringsprocesser
• AI-assisteret risikovurdering i kreditsager

Sektion 4: Ansvar og governance

Hvad den skal indeholde: Hvem ejer AI-compliance i organisationen? Hvem godkender nye AI-systemer? Hvem håndterer incidents?

Typisk fejl: Ansvaret er diffust fordelt ("alle har ansvar for AI-compliance") eller samlet hos én person der ikke har kapacitet til det.

Anbefalet minimumsstruktur:

• AI-ansvarlig (eller AI Officer): Overordnet ansvar for politik og compliance. Kan være IT-chef, CTO, eller compliance-leder.
• Systemejere: Hvert AI-system har en forretningsejer der er ansvarlig for korrekt brug og løbende vurdering.
• Godkendelsesproces: Beskriv hvem der skal godkende nye AI-systemer inden deployment.

Sektion 5: AI-inventory og registrering

Hvad den skal indeholde: Et krav om at alle AI-systemer i drift registreres i et centralt register, med minimumsinformation per system: navn, leverandør, formål, brugergruppe, risikovurdering, og systemansvarlig.

Typisk fejl: Inventory-kravet er i politikken, men ingen vedligeholder det i praksis. Et register der er seks måneder forældet er ikke et register — det er en risiko.

Praktisk anbefaling: Knytt inventory-kravet til onboarding-processen for nye leverandøraftaler. Ethvert nyt AI-system der indkøbes kræver registrering som del af godkendelsesprocessen.

Sektion 6: Krav ved high-risk AI

Hvad den skal indeholde: En klar beskrivelse af hvilke yderligere krav der gælder for systemer klassificeret som high-risk under EU AI Act.

Minimumskrav for high-risk deployere:

• FRIA (Fundamental Rights Impact Assessment) inden deployment
• Teknisk dokumentation modtaget og opbevaret fra leverandøren
• Menneskelig tilsynsprotokol implementeret og dokumenteret
• Logning af relevant systemaktivitet
• Periodiusk genrevurdering (mindst én gang om året)

Typisk fejl: Politikken beskriver kravene abstractt uden at forklare hvem der er ansvarlig for at opfylde dem, og hvad der skal dokumenteres.

Sektion 7: Medarbejderrettigheder og transparens

Hvad den skal indeholde: En beskrivelse af de rettigheder medarbejdere og andre berørte har i forbindelse med AI-systemer, inklusiv ret til forklaring, menneskelig gennemgang og indsigelse.

Typisk fejl: Afsnittet er skrevet som et juridisk disclaimer frem for en reel beskrivelse af hvad folk kan gøre hvis de er berørt.

Hvad der bør stå:

• Medarbejdere der vurderes af AI-systemer (performance, rekruttering) har ret til at bede om menneskelig gennemgang.
• Kunder der berøres af AI-baserede beslutninger (kredit, service-adgang) har ret til en forklaring.
• Proceduren for at fremsætte en indsigelse er [beskriv konkret process].

Sektion 8: Incidenter og opdateringer

Hvad den skal indeholde: Hvad er en AI-incident? Hvem rapporterer til hvem? Hvad er tidsrammen?

Definition af AI-incident:

• Uventede eller skadelige outputs der påvirker individer
• Brud på politikkens acceptable-brug-regler
• Leverandørmeddelelser om kendte fejl i high-risk systemer
• Brug af AI-systemer uden forudgående godkendelse (shadow AI)

Review-kadence: AI-politikken bør gennemses mindst én gang om året og opdateres ved væsentlige ændringer i AI-inventory, lovgivningen eller organisationen. Angiv hvem der ejer review-processen.

Typiske fejl der sænker en AI-politik

1. Skrevet af juristen alene: Juridisk korrekt men operationelt ubrugelig. Politikken bør skrives i samarbejde med IT, HR og en repræsentant for forretningen.

2. Ingen versionshistorik: En AI-politik der ikke har et versionsnummer og en opdateringsdato giver ingen signaler om hvornår den sidst var relevant.

3. Intet onboarding-link: Politikken eksisterer som PDF, men er ikke en del af onboarding, leverandøraftaler eller projektgodkendelse. Ingen ser den.

4. For specifik på nuværende teknologi: Politikker skrevet til GPT-4 er forældet inden du når at publicere den. Skriv teknologiagnostisk.

5. Ingen konsekvens ved overtrædelse: Politikken beskriver ikke hvad der sker ved brud på reglerne. Det sender et signal om at den ikke er seriøs.

Skabelon: minimumsstruktur for en AI-politik

En AI-politik behøver ikke være lang. Her er en minimumsstruktur på under to sider:

1. Formål og hvem det gælder for (3-5 sætninger)
2. Definition af AI og risikoniveauer (med eksempler fra jeres inventory)
3. Acceptable og uacceptable anvendelser (konkret liste)
4. Ansvar: AI-ansvarlig, systemejere, godkendelsesproces
5. Inventory-krav: hvad der registreres, hvem der ejer det
6. High-risk AI: minimumskrav
7. Medarbejderrettigheder og transparens
8. Incident-definitioner og -procedure

AI-politikken og jeres leverandørdialog

En undervurderet funktion af AI-politikken er at den definerer de krav I stiller til nye AI-leverandører. Mange virksomheder opdager nu at de ikke kan besvare spørgsmål fra leverandørernes compliance-teams fordi de ikke har en klar intern politik at referere til.

En konkret anvendelse: Inkludér jeres AI-politik som bilag til standardkontrakten for IT-indkøb. Det sætter klare forventninger om at leverandøren skal dokumentere systemets AI Act-status, levere teknisk dokumentation for high-risk systemer, og notificere jer ved væsentlige ændringer.

En anden anvendelse: Brug politikkens acceptable-brug-sektion til at definere hvad medarbejdere kan bruge generative AI-tjenester til, og hvad der er forbudt (f.eks. behandling af fortrolige kundeoplysninger i ikke-godkendte AI-tjenester).

AI-politikken i onboarding og træning

En AI-politik der kun lever som PDF i et compliance-drev har begrænset værdi. For at den fungerer som styringsredskab skal den integreres i organisationens hverdag:

Onboarding: Alle nye medarbejdere bør læse og bekræfte forståelse af AI-politikken som del af onboarding. Det tager fem minutter og etablerer en klar forventning.

AI-relateret træning: Brug AI-politikken som udgangspunkt for AI literacy-træning. Hvad er acceptable brug? Hvad er forbudt? Hvad gør man hvis man er i tvivl?

Leverandøraftaler: Inkludér et krav om at leverandører kender til jeres AI-politik og er enige i den relevante sektion om krav til leverandørdokumentation.

Incident-proceduren: Sørg for at den ansvarlige for incident-rapportering kender proceduren og har et klart eskalationspunkt.

Hvad tilsynsmyndigheder ser efter

Når en tilsynsmyndighed gennemgår jeres AI-politik vil de typisk kigge på:

• Dækning: Dækker politikken alle AI-systemer I er ansvarlige for, inklusive embedded AI og leverandørsystemer?
• Operationalisering: Er ansvarsrollen konkret tilknyttet en person eller stilling, eller er den abstrakt?
• Opdatering: Er der dokumentation for at politikken er opdateret siden den første version?
• Awareness: Kan I dokumentere at medarbejdere kender politikken?

Det er ikke tilstrækkeligt at have et dokument. I skal kunne vise at dokumentet er aktivt i drift — at det er en del af onboarding, at det er linket til AI-godkendelsesprocessen, og at incident-proceduren faktisk er blevet fulgt hvis der har været incidents.

Hvornår skal politikken opdateres?

Politikken bør gennemgås ved:

• Ny lovgivning: Når AI Act-delegerede retsakter opdaterer Annex III eller indfører nye krav
• Ny AI-deployment: Ethvert nyt high-risk AI-system bør trigge en revision af politikkens high-risk sektion
• Incidents: Efter enhver AI-incident af en vis alvorlighed bør incident-definitionen og -proceduren gennemgås
• Organisatoriske ændringer: Ny AI-ansvarlig, ny leverandørstrategi, nye forretningsområder

Næste skridt

Download vores tjekliste og brug den som struktureret udgangspunkt for jeres AI-politik. Husk: en simpel politik I faktisk bruger er bedre end en avanceret politik ingen kender.

Når I har skrevet et første udkast, test det mod tre spørgsmål: Kan en ny medarbejder læse den og forstå hvad der er tilladt? Kan IT-chefen bruge den til at afvise et nyt AI-indkøb der ikke lever op til kravene? Kan HR bruge den til at håndtere en medarbejders klage over AI-baseret vurdering?

Tre "ja" — I har en brugbar AI-politik.

En AI-politik er ikke et compliance-dokument. Det er et styringsredskab. Skriv det til de mennesker der skal bruge det, ikke til dem der skal revidere det.