Du behøver ikke AI-forordningen. Artikel 5 sagde allerede nej.

Compliance-teams venter på vejledning om AI-forordningen, før de rører ved deres AI-implementeringer. De forpligtelser, der rent faktisk bider, er otte år gamle og allerede i kraft.

Den mest udbredte sætning i europæisk AI-governance lige nu

"Vi venter, til der kommer klarere vejledning om AI-forordningen."

Jeg hører det i næsten hver eneste samtale, som regel fra en kompetent person, der oprigtigt forsøger at gøre det ordentligt. Det lyder fornuftigt. Det er den mest bekostelige fejl, der begås i europæisk databeskyttelse lige nu, og den bygger på en fejllæsning af, hvilken forordning der reelt gør arbejdet.

To ting er sande, og de peger i hver sin retning. AI-forordningen kræver mindre af en almindelig virksomhed, end de fleste frygter. GDPR kræver mere, gælder allerede i dag, og de fleste AI-pipelines fejler den allerede.

Hvad AI-forordningen faktisk kræver af dig

Start med at finde ud af, hvad du er. Forordningens forpligtelser er inddelt efter rolle, og forskellen mellem dem er enorm.

Hvis du udvikler og markedsfører et AI-system i eget navn, er du en provider, og du bærer den tunge ende: overensstemmelsesvurdering, teknisk dokumentation, risikostyringssystemer, overvågning efter markedsføring.

Hvis du køber Copilot, eller Gemini, eller et API, og bruger det i din virksomhed, er du en deployer. Dine forpligtelser er betydeligt lettere — primært menneskeligt tilsyn, brug af systemet i overensstemmelse med providerens anvisninger, transparens over for de berørte personer, og relevans af inputdata, hvor du har kontrollen.

Langt de fleste europæiske virksomheder er deployers. De budgetterer med provider-forpligtelser, de aldrig kommer til at bære.

Tidslinjen underbygger pointen. Forordningen trådte i kraft i august 2024. Forbudte praksisser og pligter om AI-kompetence gjaldt fra februar 2025. Forpligtelser for AI-modeller til almen brug fra august 2025. Højrisikokategorierne — dem, der genererer det overensstemmelsespapirarbejde, alle frygter — ligger i august 2026 og august 2027, og kun for systemer, der falder ind under bilag III's anvendelsestilfælde eller sikkerhedskomponenter. Rekruttering, kreditvurdering og medarbejderstyring er omfattet. Din interne vidensassistent er det næsten helt sikkert ikke.

Så for en typisk deployer er AI-forordningen en governance- og dokumentationsøvelse, faseinddelt, og for det meste endnu ikke forfalden.

Hvad GDPR kræver, og har krævet siden 2018

Se nu på, hvad der sker, i det øjeblik du peger en retrieval-pipeline mod et filshare.

Artikel 5(1)(b), formålsbegrænsning. Personoplysninger indsamlet til ét formål må ikke viderebehandles på en måde, der er uforenelig med det formål. De CV'er, der blev indsamlet for at besætte en stilling i 2019, blev indsamlet for at besætte en stilling. At indeksere dem i en virksomhedsassistent er et nyt formål, og du skal have vurderet dets forenelighed. Næsten ingen har dokumenteret dette.

Artikel 5(1)(c), dataminimering. Behandling skal være tilstrækkelig, relevant og begrænset til, hvad der er nødvendigt. At indeksere en hel tenant, fordi det var svært at afgrænse den, er selve definitionen på at fejle denne test. "Vi indlæste alt og stoler på rettigheder til at filtrere det" er ikke minimering; det er fravær af minimering med en kompenserende kontrol skruet på.

Artikel 5(1)(e), opbevaringsbegrænsning. Man opbevarer ikke personoplysninger længere, end formålet kræver. Hver eneste organisation, jeg har gennemgået, opbevarer personoplysninger i årevis ud over ethvert forsvarligt formål. Det var allerede en overtrædelse, mens det lå stille på et filshare. At fodre det ind i et system designet til at bringe det frem på forlangende gør en sovende overtrædelse til en aktiv.

Artikel 5(2), ansvarlighed. Du skal kunne påvise overholdelse af alt det ovenstående. Ikke opnå det. Påvise det. Hvis du ikke kan fremvise en oversigt over, hvad du opbevarer, hvorfor, og under hvilken opbevaringsregel, fejler du dette, uanset hvor velopdragen din model er.

Læg dertil artikel 6 — du skal have et behandlingsgrundlag for den nye behandling, og det, du havde til indsamlingen, følger ikke automatisk med — og artikel 35, fordi behandling af personoplysninger i stort omfang med ny teknologi nærmest er et lærebogseksempel på en DPIA-udløser.

Intet af dette afventer noget. Intet af det kræver vejledning. Det har kunnet håndhæves i otte år, med bødeloftet fra artikel 83(5) tilknyttet, som er det højere niveau: op til 4% af den globale årlige omsætning.

Hvad det betyder for den databeskyttelsessoftware, du køber

Der findes en reel effektivisering her, og næsten ingen griber den.

NIS2 artikel 21 kræver risikostyringsforanstaltninger, der står i forhold til risikoen, og den dækker udtrykkeligt sikkerhedspolitik for informationssystemer og håndtering af aktiver. GDPR artikel 32 kræver sikkerhed i behandlingen. AI-forordningens deployer-forpligtelser kræver, at du ved, hvilke data der går ind i systemet.

Alle tre ønsker det samme underliggende artefakt: en forsvarlig oversigt over, hvilke data du opbevarer, hvor de er, hvem der er ansvarlig for dem, og hvad der sker med dem over tid. Byg det én gang. Tre tilsynsmyndigheder, tre regelsæt, ét bevis. De fleste organisationer kører tre separate projekter, der hver især producerer en delvis version af det.

Dette er også den test, man skal anvende, når man vurderer databeskyttelsessoftware. Spørg, om den producerer dette ene artefakt eller endnu en isoleret rapport. Et værktøj, der udfører PII-detektion, men ikke kan fortælle dig, hvem der ejer dataene, hvad opbevaringsreglen er, og om sletning blev udført, har løst den nemme tredjedel af problemet og efterladt dig de to andre.

Fire spørgsmål

Hvis du vil vide, hvor du står, uden at bestille noget som helst, så besvar disse. Ingen værktøjer nødvendige, og hvert eneste af dem kan besvares i denne uge.

1. Hvilke personoplysninger har dit AI-system fået adgang til? Ikke "hvilke SharePoint-sites" — hvilke kategorier af personoplysninger findes i dem. Hvis svaret er "det ved vi ikke, vi afgrænsede efter site", har du fejlet artikel 5(1)(c), og du kan stoppe her.

2. Hvad blev disse data oprindeligt indsamlet til? For hver væsentlig kategori. Hvis du ikke kan svare, kan du ikke vurdere forenelighed under 5(1)(b).

3. Hvad er din opbevaringsregel for dem, og bliver den håndhævet? Et politikdokument, der beskriver sletning, som ingen udfører, er værre end ingen politik. Det beviser, at man vidste det.

4. Kan du påvise alt det ovenstående over for en tilsynsmyndighed? Med registreringer, ikke påstande. Det er artikel 5(2), og det er den, der gør en forsvarlig position til en uforsvarlig.

Fejler du disse, er AI-forordningen ikke dit problem. Det er det andet lag på et fundament, der allerede er non-compliant, og ingen vejledning fra Bruxelles vil ændre svaret.

Den gode nyhed, sådan som den nu er

Udbedringen af alle fire er det samme stykke arbejde, og det er ikke et AI-projekt.

Klassificér, hvad du opbevarer. Få dem, der ejer dataene, til at bekræfte, hvad der stadig har et formål. Slet det, der ikke har, og gem beviset for, at du gjorde det. Forbind derefter dit AI-system til det, der er tilbage.

Gør du det, bliver AI-forordningen det, den burde have været hele tiden — en dokumentationsøvelse oven på en databestand, du faktisk kan beskrive. Springer du det over, beder du en tilsynsmyndighed om at acceptere, at du implementerede et retrieval-system på tværs af personoplysninger, du ikke kunne opgøre, til formål du ikke havde vurderet, opbevaret ud over en grænse, du ikke havde håndhævet.

Den samtale går ikke godt. Den har intet at gøre med AI.

Hvis du vil vide, hvad der faktisk ligger i dine ustrukturerede data, tilbyder vi en gratis gennemgang.