Teknologi og compliance

AI og GDPR: Sådan beskytter du virksomhedens data, når I bruger kunstig intelligens

Når AI sendes ind i interne systemer, kundedata og supportflows, ændrer I typisk hele datakæden: prompts, logs, hosting og underleverandører. GDPR kræver lovlighed, gennemsigtighed, dataminimering, sikkerhed og dokumentation - bare med flere usynlige led end i klassiske databaser.

Se governance-tjeklisten nedenfor →

Kort om opgaven

Hvorfor AI ændrer persondata-risikoen i enterprise

Når I bruger kunstig intelligens på interne systemer, kundedata eller supportflows, ændrer I typisk behandlingen af personoplysninger: data sendes til modeller, lagres i logs, deles med underleverandører og kan ende i workflows, hvor formålet ikke længere er tydeligt for brugeren.

Kort sagt handler AI og GDPR i enterprise om at styre hele datakæden fra input (prompts, dokumenter, tickets) til output (svar, klassifikationer, kode) og om at sikre, at roller, kontrakter og risikovurderinger matcher den måde, I faktisk bruger værktøjet på - ikke den måde, leverandørens marketingside beskriver det.

Features

Hvad betyder AI og GDPR i praksis for enterprise?

Personoplysninger forbliver personoplysninger, men scope bliver ofte større, fordi API-kæden skjuler flere behandlingsled end i klassiske systemer.

Samme kernekrav, større scope

Der skal være behandlingsgrundlag, klart formål, passende sikkerhed og respekt for registreredes rettigheder - også når et sprogmodel-API tilføjer sessionslagring, fejlretning og kvalitetsmåling.

Der hvor risikoen bliver konkret

Interne copilots, kundeserviceassistenter, HR-flows, udvikler-værktøjer og feedback-analyse kan sprede små mængder persondata bredt, hvis prompts kopieres, deles i chatrum eller gemmes uden retention-styring.

Tre praktiske lag at tegne

Skel mellem hvad I selv kontrollerer, hvad en leverandør behandler som databehandler, og hvad der flyder gennem subprocessorer. Uden det skel bliver compliant AI let et slogan.

hvad I selv hoster

Oversigt

Sådan fungerer dataflows og risici i AI-systemer

Et enterprise-AI-setup er en kæde af komponenter, hvor hvert led kan rumme persondata - også når det føles harmløst.

Det brugeren skriver, plus metadata som tid, bruger-id og tenant, sendes ofte til en sky-API eller en intern tjeneste. Det er typisk det mest direkte persondata-led, fordi prompts kan indeholde navne, sager, e-mails eller kundenumre.

Risiko: formålsforblanding og for brede kopier, der ender i chat, tickets eller supportlogs uden styring.

Behandlingsgrundlag og dokumentation

Basis vælges ud fra aktiviteten og skal kunne forklares konkret for hver proces.

Uanset om I står på berettiget interesse, aftale, retlig forpligtelse eller samtykke, skal I kunne forklare, hvorfor behandlingen er nødvendig, og hvordan I begrænser omfanget. Undgå formål formuleret som vi bruger AI uden kobling til en konkret opgave.

Vælg og dokumentér basis pr. proces, ikke som én generel AI-politik.
Tjek særligt medarbejder- og kundedata, fordi legitimitet og information skal kunne eftervises.
Sørg for at kunne redegøre for nødvendighed og mindre indgribende alternativer i praksis.

Læs om implementering og drift

Illustration af dokumentation og procesejerskab

Roller, databehandlerinstruks og subprocessorer

Roller er praktiske: de bestemmer, hvem der må hvad i kæden.

Den ansvarlige bestemmer formål og midler. En databehandler må kun følge instruks. Underdatabehandlere kræver kontrol og ofte forudgående godkendelse. Når I lægger flere SaaS-lag oven på hinanden, skal kæden kunne tegnes uden huller.

Tegn kæden fra datakilde til leverandør og aftal skriftligt, hvem der instruerer hvem.
Sørg for skriftlige mekanismer for nye subprocessorer og faktisk gennemgang, ikke kun papir.
Afklar adgang, deling og logning på tværs af teams, så data ikke flyder på kryds uden ejerskab.

Illustration af leverandørkæde og ansvar

DPIA, høj risiko og kobling til EU AI Act

DPIA binder tekniske valg til risikobegrænsning og kontrol - ikke til en skabelon for skabelonens skyld.

DPIA og sprogmodeller hører sammen, når behandlingen med stor sandsynlighed medfører høj risiko, fx systematisk overvågning, profilering i større skala, følsomme kategorier eller kombinationer med væsentlig effekt for personer. EU AI Act og GDPR overlapper, men de rammer forskellige problemstillinger.

GDPR regulerer persondata, mens EU AI Act sætter krav til AI-systemer som produkter afhængigt af risiko og anvendelse.
I drift er skillelinjen ofte persondata-compliance versus system- og produktcompliance.
Hold dyb forordningsgennemgang på en dedikeret EU AI Act-side, og brug denne side til data- og leverandørstyring.

Illustration af risikovurdering og dokumentation

Tabel til praksis

Faktorer, fejl og næste skridt i samme spor

Den største risiko er ikke kun datalækage. Den er også formålsforblanding, hvor data indsamlet til ét formål ender i et andet, fordi et værktøj genbruges på tværs af teams. Samtidig er dataminimering svær, fordi det er nemt at sende for meget ind i en prompt for en sikkerheds skyld, selv når opgaven kun kræver et udsnit.

EU AI Act og GDPR overlapper, men de løser forskellige problemer: klassificering og dokumentation versus persondataret. For en CTO er skillelinjen i dagligdagen persondata-compliance over for system- og produktcompliance.

Faktorer i korte træk

Roller og ansvar: Tegn kæden fra datakilde til leverandør og aftal skriftligt, hvem der instruerer hvem.
Behandlingsgrundlag: Vælg og dokumentér basis pr. proces, og undgå vi bruger AI som generisk formål.

Almindelige fejl og misforståelser om datasikkerhed, sky-API'er og compliant AI

Det ser ofte fornuftigt ud at købe en sikker chatbot og tro, at problemet er løst. I praksis mangler der typisk DPA'er, subprocessorer, logning med retention, dataflow-kort og en realistisk risikovurdering. Tillid kommer af konkrete kontroller - ikke af en badge på en salgsside.

Når AI ændrer sig hurtigt, skal politikker, adgang og leverandørkrav følge med. Et løbende review af ændringer i hosting, nye integrationer og faktisk brug er ofte det, der adskiller kontrolleret udrulning fra stille formåls glide.

Kortlæg dataflow og sand brug

Start med hvad der faktisk sendes til modeller, hvad der logges, og hvilke teams der genbruger prompts og udklip på tværs.

Juridisk og teknisk kæde i samme diagram

Samme diagram skal kunne læses af juridisk ejerskab og drift: roller, instrukser, regioner og subprocessorer.

Minimum af data i prompten

Indfør rutiner for anonymisering, uddrag og manuelle kontroller, så minimering ikke kun er et princip på slideet, men en adfærd i værktøjerne.

Revision der matcher ændringshastigheden

Når I tilføjer nye integrationer eller skifter hosting, skal DPIA, DPA og adgang følge med - ellers bliver dokumentationen et øjebliksbillede fra sidste kvartal.

Features

Kontroller der typisk giver effekt først

Små, konkrete greb der reducerer både compliance-risiko og driftstab.

Skriftlige rammer der kan følges

DPA'er, subprocessor-lister og tydelige instrukser der kan omsættes til adgang og logging i IT.

Dataminimering med regler

Skabeloner til prompts, forbud mod fulde dumps i chat, og klare undtagelser for hvornår mere data er berettiget.

Logning med retention

Hvad logges, hvor længe, hvem må se det, og hvordan slettes eller pseudonymiseres indhold.

DPIA der binder til valg

Knyt risiko til konkrete kontroller og ejerskab, ikke til generelle AI-principper.

Menneskelig kontrol

Hvem godkender output, hvornår er der review, og hvordan fanges fejl i produktion.

Historik

Et forløb I kan genkende: fra beslutning til løbende kontrol

Ikke en juridisk tidslinje, men et praktisk spor for teamet der skal udføre det.

Uge 1-2

Afklaring og kortlægning

Kortlæg faktiske use cases, datakilder og hvilke persondata der kan ende i prompts, logs og integrationer.

Uge 3-5

Kontrakter og tekniske krav

Juster DPA'er, subprocessor-godkendelser og sikkerhedskrav så de matcher den reelle model- og hosting-kæde.

Måned 2

Risikovurdering og DPIA-spor

Beslut hvor DPIA er påkrævet, og bind dokumentation til konkrete kontroller og ansvarlige ejere.

Løbende

Drift, måling og ændringskontrol

Når modeller, værktøjer og workflows skifter, skal dokumentation og adgang følge med - ellers slipper kontrollen.

Hele kæden

Fra prompt-input til logs og fakturering

Subprocessorer

Skal være synlige i kontrakter og instrukser

DPIA

Når risikoen for personer bliver høj

Minimering

Mindre data i prompten, mindre eksponering

FAQ

FAQ: AI, GDPR og enterprise-drift

Korte svar på det, teamet ofte spørger om første gang I standardiserer AI-brug.

Er en chatbot automatisk GDPR-problemet?

Ikke i sig selv. Problemet er persondata i prompts og logs, formål, sikkerhed og dokumentation i hele kæden. Et værktøj kan se sikkert ud i marketing, mens dataflowet stadig er uklart.

Hvad er forskellen på controller og databehandler i praksis?

Den ansvarlige bestemmer formål og midler og skal kunne redegøre over for registrerede. Databehandleren må kun behandle efter instruks og med passende sikkerhed. Hvis I styrer formålet, er I typisk controller over for jeres egne processer.

Hvornår er en DPIA relevant med sprogmodeller?

Når behandlingen sandsynligvis medfører høj risiko for personers rettigheder, fx større profilering, følsomme data eller systematisk overvågning. DPIA skal binde tekniske valg til risikobegrænsning og kunne eftervises.

Er EU AI Act det samme som GDPR?

De overlapper, men de løser forskellige problemer. GDPR handler om persondata. EU AI Act stiller krav til AI-systemer som produkter afhængigt af risiko og anvendelse. I drift skal I typisk håndtere begge spor, men med forskellige kontroller og dokumentation.

Hvad er den mest almindelige fejl ved sky-API'er?

At man antager at data opfører sig som i et internt system. API-kald kan inkludere lagring til fejlretning, måling og underleverandører, som ikke er synlige i brugergrænsefladen, medmindre I har aftalt og testet det.

Hvordan undgår I formålsforblanding?

Vær konkret om formål pr. proces, begræns genbrug på tværs af teams, og styr prompts og logs med retention og adgang. Teknisk arkitektur og pædagogik skal trække i samme retning.