Start med at kortlægge: sådan gør du EU AI Act håndterbar

Genkend panikken: “Vi må hellere få styr på det der AI-lovgivning”

Jeg kan lige så godt indrømme det: Da vores CFO for nogle måneder siden sagde i et møde, at “vi må hellere få styr på det der EU AI Act”, nikkede jeg klogt. Indeni tænkte jeg noget i retning af: “Ja, og hvad betyder det så helt præcist for os…?”.

To dage senere stod jeg med et udprint af lovteksten, en overstregningstusch og en voksende fornemmelse af, at det her kunne blive enten meget dyrt, meget bureaukratisk eller meget overset. Sandsynligvis en blanding. Hvis du sidder med den samme blanding af pligtfølelse og uklarhed, er du ikke alene.

Den her artikel er til dig, der skal svare på tre meget konkrete spørgsmål i din organisation: Er vi omfattet? Hvis ja, hvordan? Og hvad gør vi de næste 90 dage, uden at lave en NIS2-version 2 med panikmapper og halvfærdige politikker?

Forstå hvad EU AI Act faktisk regulerer (og hvad den lader være)

EU AI Act regulerer brug og udvikling af AI-systemer, ikke “AI” som abstrakt fænomen. Loven kigger på anvendelser, roller og risiko, ikke på hvor imponerende teknologien er.

Den griber primært ind i tre ting: hvordan AI-systemer udvikles (design, data, test), hvordan de bringes på markedet (leverandør- og distributionsansvar) og hvordan de bruges i praksis (kontrol, overvågning, dokumentation). Samtidig er der områder, den i praksis ikke rører ret meget ved: simple, interne værktøjer uden væsentlig påvirkning af mennesker, eksperimenter i sandkasser og meget basal automatisering, som ikke kvalificerer som “AI-system” i lovens forstand.

Hvis du sidder i en typisk dansk virksomhed, vil kernen være: Har vi AI-systemer, der påvirker kunder, borgere eller medarbejdere på måder, som kan skabe væsentlig risiko? Og har vi enten selv udviklet dem eller taget en rolle som leverandør til andre?

Brug 10 spørgsmål som beslutningsflow: er I omfattet?

Det sværeste første skridt er ofte bare at få et klart ja/nej-billede. Så her er et simpelt beslutningsflow, jeg selv ville bruge i et internt møde. Svar ærligt på de her 10 spørgsmål:

• Bruger I i dag nogen form for AI-assisterede værktøjer i forretningen (fx chatbots, anbefalingsmotorer, scoringer, automatiserede beslutningsstøtter)?
• Har I systemer, der automatisk træffer eller foreslår beslutninger om mennesker (ansættelse, kredit, prissætning, prioritering af sager, overvågning)?
• Udvikler I selv modeller, algoritmer eller løsninger, som I sælger eller stiller til rådighed for kunder?
• Indgår AI-funktionalitet som en væsentlig del af et produkt, I leverer til andre (software, platform, hardware med smart-funktioner)?
• Importer I AI-baserede løsninger fra leverandører uden for EU og sælger eller distribuerer dem videre?
• Bruger I AI i processer, der kan have konsekvenser for borgeres eller kunders rettigheder, økonomi eller sikkerhed?
• Har I AI i systemer relateret til HR, kreditvurdering, sundhed, uddannelse, kritisk infrastruktur eller offentlig service?
• Har I governance-strukturer i forvejen (fx fra NIS2, GDPR eller informationssikkerhed), som AI kan kobles naturligt ind i?
• Har I i dag overblik over, hvor AI faktisk er i brug i virksomheden, eller er det mere en fornemmelse?
• Har nogen i direktionen eller bestyrelsen stillet spørgsmål til EU AI Act, risiko eller compliance på området?

Hvis du svarer nej til de første fire spørgsmål, men ja til 5, er I sandsynligvis i spil som importør/distributør. Hvis du svarer ja til 1, 2 eller 6, men ikke udvikler selv, er I typisk “deployer” (bruger) med pligter til styring, risikovurdering og tilsyn.

Svarer du ja til 3 eller 4, har I potentielt rollen som “provider” (leverandør) af AI-systemer, og så stiger kompleksiteten. På det her tidspunkt giver det mening at tænke EU AI Act sammen med jeres eksisterende rammer for digitalisering og teknologi, i stedet for at opfinde en parallel verden kun til AI.

Oversæt klasserne: fra forbudt til minimal risiko i praksis

Loven opererer med fire kategorier: forbudte systemer, højrisiko, begrænset risiko og minimal risiko. Juridisk set er der en del detaljer, men som arbejdsredskab kan du stille tre spørgsmål:

• Påvirker systemet mennesker på måder, der kan være svære at opdage eller modsætte sig (fx manipulation, skjult scoring)?
• Er systemet knyttet til områder med stor betydning for liv, rettigheder eller økonomi (sundhed, job, kredit, uddannelse, kritisk infrastruktur)?
• Er der en realistisk risiko for diskrimination, fejlklassificering eller alvorlige konsekvenser ved fejl?

Forbudte systemer vil i praksis sjældent være noget, en almindelig dansk virksomhed har planer om at implementere. Det handler fx om social scoring på statsniveau eller manipulation af svage grupper.

Højrisiko er til gengæld relevant: algoritmer til rekruttering og medarbejdervurdering, kreditvurderingssystemer, AI i medicinsk udstyr, systemer der styrer adgang til uddannelse eller velfærdsydelser. Begrænset risiko er typisk ting som generative AI-chatbots, personaliseret markedsføring og interne assistenter. Minimal risiko dækker alt det, hvor AI mest er smart funktionalitet uden nævneværdig indvirkning på mennesker.

Forstå jeres rolle: provider, deployer, importør og distributør

EU AI Act skelner skarpt mellem roller. Det er ikke bare semantik, det er en direkte vej til jeres kravniveau. Helt forenklet:

• Provider: Den, der udvikler et AI-system og sætter det på markedet eller i drift under eget navn eller varemærke.
• Deployer: Den, der bruger systemet i praksis i sin virksomhed eller organisation.
• Importør: Den, der bringer et AI-system fra et land uden for EU ind på EU-markedet.
• Distributør: Den, der gør et AI-system tilgængeligt, uden at være udvikler eller importør.

Mange danske virksomheder vil primært være deployers: de tager et system fra en stor leverandør og bruger det i HR, salg eller drift. Her er nøglen at sikre klare kontrakter, forståelse for systemets risici og passende kontrol i driften.

Er I provider, skal I forholde jer til designkrav, teknisk dokumentation, datastyring, test og konformitetsvurdering. Her er der en direkte kobling til klassisk it-kontraktpraksis og produktansvar, bare i AI-tøj. Importører og distributører skal sikre, at de systemer, de bringer ind eller sælger videre, faktisk overholder kravene.

Start med et AI-inventar: sådan får du overblik på 1 uge

Det mest effektive ikke-dramatiske skridt, jeg har set, er et simpelt AI-inventar. Ikke en 70-siders rapport. Et kontrolark med tre faner kan gøre mere gavn end endnu en politik.

Fane 1: Systemliste

Lav en tabel med: systemnavn, leverandør, ejer internt, formål, forretningsproces, berørte brugere (kunder, borgere, medarbejdere), og om der træffes eller støttes beslutninger om mennesker. Brug brede kilder: IT, HR, marketing, drift og “skjulte” løsninger som Excel-modeller og low-code apps.

Fane 2: Anvendelse og data

Tilføj felter for: inputdata (hvad fodres systemet med?), output (hvad spytter det ud?), hvor data kommer fra, og om der bruges persondata. Notér også om modellen lærer løbende (selvforstærkende) eller er statisk.

Fane 3: Foreløbig risikoetiket

Til sidst giver I hver løsning en foreløbig etikette: sandsynligvis minimal, begrænset eller potentiel højrisiko. Brug gerne simple farver, men hold jer fra at gøre det mere avanceret end nødvendigt. Det vigtige er, at I får et fælles billede, som kan danne grundlag for næste trin.

Byg et enkelt kontrolkatalog: hvad giver mest effekt først?

Når inventaret er på plads, bliver næste refleks ofte: “Vi burde lave et helt nyt AI-governance-rammeværk”. Inden du bestiller slide-sættet, kan du spørge: Hvad har vi allerede, vi kan genbruge? Hvis I i forvejen arbejder med informationssikkerhed eller NIS2, har I allerede kontroller omkring risikovurderinger, adgangsstyring, ændringshåndtering og leverandørstyring.

Et minimums-kontrolkatalog for AI kunne fx indeholde:

• En simpel risikovurdering for hvert højrisiko- eller gråzone-system (hvad kan gå galt, hvem rammes, hvor sandsynligt er det?).
• En beslutning om human oversight: hvem må overrule systemet, og hvordan gøres det i praksis?
• Krav til leverandører om dokumentation, modelbeskrivelse og fejl- eller incident-håndtering.
• Procedurer for test og ændringer, før nye versioner sættes i drift.
• En plan for information til brugere eller berørte om, at AI indgår i processen.

Du kan med fordel tænke det sammen med jeres arbejde med cyber og informationssikkerhed, så AI ikke får sit eget vilde vesten, men falder ind i kendte mønstre for styring.

Få styr på dokumentation: hvad skal kunne vises frem?

EU AI Act har tydelige krav til dokumentation, især for højrisiko-systemer. Men selv for begrænset risiko giver det mening at tænke: Hvad skal jeg kunne vise, hvis en intern eller ekstern audit spørger om vores AI-brug?

Som deployer vil det typisk være:

• AI-inventar med klar ejer og formål for hvert system.
• Beskrivelse af væsentlige use cases: hvad systemet bruges til i praksis.
• En kort risikovurdering med identificerede kontroller.
• Referencer til kontrakter og aftaler med leverandører om ansvar og support.
• Beviser for træning og instruktion af medarbejdere, der bruger systemet.

Som provider er det mere omfattende: teknisk dokumentation, beskrivelser af modelarkitektur, testresultater, datasætbeskrivelser, performance-målinger og et mere detaljeret kvalitetsstyringssystem. Her nærmer vi os klassisk produktudvikling med compliance indbygget.

Tag data, model og drift alvorligt: logging, oversight og incidents

AI-systemer er ikke statiske. De ændrer sig over tid, de påvirkes af nye data og de møder virkeligheden på uforudsigelige måder. Loven lægger vægt på fire ting, du med fordel kan tage med i jeres praksis, også før kravene rammer fuldt ud:

• Logging: Gem relevante logdata, der gør det muligt at forstå, hvad der er sket ved beslutninger eller fejl.
• Human oversight: Definér klart, hvor mennesker skal være i loopet, og hvordan de kan gribe ind.
• Incident-håndtering: Beslut, hvornår noget er en AI-relateret hændelse, hvordan det indrapporteres, og hvem der gør hvad.
• Kontinuerlig evaluering: Sæt faste tidspunkter for at revurdere systemers performance og risiko, fx årligt eller ved større ændringer.

Her er det oplagt at koble AI ind i jeres eksisterende beredskab for driftsfejl, sikkerhed og klager. Der er sjældent nogen grund til at opbygge endnu et parallelspor, hvis I allerede har et nogenlunde velfungerende setup.

Fordel rollerne: hvem ejer hvad internt?

Selv den bedste plan falder til jorden, hvis ingen føler sig ansvarlige. Jeg har efterhånden set en håndfuld forskellige modeller, men et mønster går igen: Fordel ejerskab på tværs af it, forretning, risk/compliance og ledelse.

Et simpelt RACI-udkast kunne se sådan her ud:

• Forretningsejere: ansvarlige for use case, effekt, og at AI faktisk løser et reelt forretningsproblem.
• IT/data: ansvarlige for teknisk drift, integration, sikkerhed og baseline af tekniske kontroller.
• Risk/compliance/legal: rådgivende på risikovurdering, lovfortolkning og dokumentationskrav.
• Ledelse/dir: ansvarlige for prioritering, risikovillighed og at sikre ressourcer.

Her kan I med fordel genbruge strukturer fra organisering og governance og ikke opfinde helt nye fora. Måske skal jeres eksisterende sikkerhedsudvalg bare have AI som fast punkt på dagsordenen hver anden måned.

Lav en 30/60/90-dages plan: forskel på SMV og større virksomhed

For at få det her ud af powerpoint og ind i hverdagen, hjælper det med en konkret tidsramme. Her er et skitseforslag til en 30/60/90-dages plan, du kan justere til jeres virkelighed.

De første 30 dage: overblik og sprog

Fælles for både SMV og større virksomhed:

• Udpeg en lille kernegruppe (it/data, forretning, risk/compliance).
• Lav AI-inventaret i simpel form og få det godkendt i ledelseskredsen.
• Klassificér systemerne foreløbigt i minimal, begrænset og potentiel højrisiko.
• Identificér 2-3 use cases, der kræver særlig opmærksomhed.

Forskellen er mest i ambitionsniveauet. En SMV kan klare inventaret på et par workshops, mens en større virksomhed måske skal gå mere systematisk til værks.

Dag 31-60: styring og kontroller

Her begynder forskellen for alvor at vise sig.

For SMV’er kan fokus være:

• At få simple kontroller på plads for de vigtigste use cases.
• At sikre at leverandørkontrakter tjekkes for ansvar og support.
• At beskrive human oversight og incident-håndtering i kort form.

For større virksomheder kan fokus være:

• At koble AI ind i eksisterende risk management og it-governance.
• At definere et grundlæggende kontrolkatalog og en standard for risikovurderinger.
• At beslutte en model for central vs. decentral styring af AI-projekter.

Dag 61-90: forankring og forbedring

I den sidste fase handler det om at gøre det til en del af driften, ikke et engangsprojekt.

For SMV’er kan det betyde:

• At opdatere et par nøglepolitikker (it, data, sikkerhed) med AI-afsnit.
• At lave en kort vejledning til medarbejdere om brug af AI, især generative værktøjer.
• At beslutte et årligt review af AI-inventaret.

For større virksomheder kan fokus være:

• At etablere faste rapporteringslinjer til ledelse og evt. bestyrelse.
• At integrere AI i projektmodeller, porteføljestyring og arkitekturprincipper.
• At planlægge en intern audit eller selv-evaluering, når lovens tidsplan kræver det.

Brug AI Act som løftestang, ikke bare som pligt

EU AI Act kan hurtigt blive endnu et compliance-projekt, der lever sit eget liv i en mappe på intranettet. Eller det kan blive en anledning til at få bedre styr på data, systemer og beslutninger, som alligevel havde brug for opmærksomhed.

Hvis jeg skulle opsummere ét praktisk råd, du kan tage med til næste møde, er det her: Start småt, men start struktureret. Et godt AI-inventar, et enkelt kontrolkatalog og en realistisk 90-dages plan giver dig langt mere ro end endnu en lang rapport, ingen læser. Og hvis du allerede er i gang med fx NIS2, kan erfaringerne derfra være en genvej.

De spørgsmål, jeg ville stille mig selv og mine kolleger nu, er: Hvor bruger vi faktisk AI i dag, og hvem tør skrive sit navn på den liste? Hvilke 2-3 systemer vil vi ikke have på forsiden af avisen, hvis de fejler? Og hvordan gør vi det her til noget, vi arbejder med løbende, i stedet for et engangsprojekt, der dør, når præsentationen er færdig?