Når AI rører kundedata, prompts, logs og underleverandører, ændrer I hele datakæden. Vi bygger lovlighed, dataminimering og sporbarhed ind som fundament og koder regler ind som grænser systemet ikke kan bryde, i stedet for at tilføje compliance bagefter.
Kort svar
Når I bruger en AI-model på persondata, bliver I dataansvarlig for den behandling, og leverandøren bliver databehandler med krav om en DPA-aftale. De største compliance-risici opstår når persondata forlader jeres system: i prompts til sky-API'er, i logfiler der opbevares for længe, og når subprocessorer videresender data uden jeres kendskab. Lokal eller selvhostet AI reducerer disse risici.
Det vigtigste
Det kan være lovligt, men kræver et gyldigt behandlingsgrundlag, en DPA-aftale med leverandøren og afklaring af, om data behandles uden for EU. OpenAI tilbyder DPA-vilkår, men det er jeres ansvar at vurdere om overførslen er lovlig og nødvendig for formålet.
GDPR handler om persondata: retten til sletning, dataportabilitet og lovlige behandlingsgrundlag. EU AI Act handler om risikoen ved AI-systemet: krav til dokumentation, menneskelig kontrol og åbenhed, særligt for højrisiko-applikationer som rekruttering og kreditvurdering.
En DPA bør specificere: hvilke data behandles, til hvilket formål, i hvilke datacentre, hvem er subprocessorer, hvordan slettes data, og hvordan håndteres brud. Undgå leverandører der afviser at underskrive en DPA eller ikke kan redegøre for subprocessorer.
Selvhostet AI fjerner de fleste tredjepartsrisici, men skaber egne forpligtelser: I bliver selv ansvarlige for modelsikkerhed, adgangskontrol, logning og opdatering. GDPR gælder stadig. Forskellen er at I kontrollerer behandlingen selv.
Kort om opgaven
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.
Personoplysninger forbliver personoplysninger, men scope bliver større, fordi API-kæden skjuler flere behandlingsled. Vi bygger lovlighed ind som fundament, ikke som et lag der klistres på til sidst.
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 i baggrunden.
Compliance holder, når reglerne er kodet ind som grænser systemet ikke kan bryde. Vores dbeb.dk-konfigurator koder BR18 og Eurocode ind, så den blokerer output der ikke overholder reglerne. Samme mønster bruger vi til GDPR og EU AI Act: kontrollen sidder i systemet, ikke i en vejledning.
Følsom tekst kan køre på infrastruktur I styrer og forlader ikke jeres miljø. Når data ikke sendes til et SaaS-lag, falder en hel klasse af subprocessor- og dataresidency-spørgsmål bort, før de bliver et problem.
hvad I selv hosterEt 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.
Modeller og hosting afgør, om inferens sker i eget miljø, hos en hyperscaler eller hos en specialiseret udbyder. Placering, kryptering og adgangskontrol er afgørende for, om data forbliver inden for aftalte grænser.
Risiko: at data passagerer regioner eller subprocessorer, I ikke har kontrakter og instrukser på.
Fejlsporing, sikkerhedsmonitorering og performance kan gemme indhold, som ikke var ment til langtidsgemning. Det er et klassisk sted, hvor minimering og retention-politikker enten bliver konkrete - eller usynligt fraværende.
Risiko: at prompts og svar ender i logfiler uden sletning, adgangstyring eller formålsafgrænsning.
Oversættelse, stemme-til-tekst, dokumentindeksering og betalingsgateways kan tilføje nye behandlere uden at det står tydeligt i den første indkøbsaftale. Kæden skal kunne tegnes uden huller.
Risiko: at I mister overblikket over subprocessorer, instrukser og godkendelser i en SaaS-stak.
Basis vælges ud fra aktiviteten og kodes ind, så hver proces kan forklares konkret.
Roller er praktiske: de bestemmer, hvem der må hvad i kæden, og hvor data overhovedet rejser hen.
DPIA binder tekniske valg til risikobegrænsning og kontrol, ikke til en skabelon for skabelonens skyld.
Tabel til praksis
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
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.
Start med hvad der faktisk sendes til modeller, hvad der logges, og hvilke teams der genbruger prompts og udklip på tværs.
Følsom tekst kan køre på infrastruktur I styrer, så den ikke forlader jeres miljø. Det fjerner en hel klasse af dataresidency- og subprocessor-spørgsmål fra ligningen.
Indfør anonymisering, uddrag og kontroller som regler værktøjet håndhæver, så minimering ikke kun er et princip på slideet, men adfærd i systemet.
Hver ændring i integrationer, modeller eller hosting verificeres og versioneres, så DPIA, DPA og adgang følger med og kan rulles tilbage, ikke fryses som et øjebliksbillede fra sidste kvartal.
Små, konkrete greb der reducerer både compliance-risiko og driftstab, kodet ind som grænser frem for hensigter.
DPA'er, subprocessor-lister og tydelige instrukser der kan omsættes til faktisk adgang og logging i IT, ikke kun til et dokument der ligger i et drev.
Skabeloner til prompts, forbud mod fulde dumps i chat, og klare undtagelser for hvornår mere data er berettiget, håndhævet i værktøjet.
Følsom tekst kan køre på infrastruktur I styrer og forlader ikke jeres miljø, så data ikke sendes til et SaaS-lag I bagefter skal dokumentere.
Knyt risiko til konkrete kontroller og ejerskab, ikke til generelle AI-principper.
Hvem godkender output, hvornår er der review, og hvordan fanges fejl før de når produktion.
Ikke en juridisk tidslinje, men et praktisk spor for teamet der skal udføre det.
Kortlæg faktiske use cases, datakilder og hvilke persondata der kan ende i prompts, logs og integrationer.
Juster DPA'er, subprocessor-godkendelser og sikkerhedskrav så de matcher den reelle model- og hosting-kæde.
Beslut hvor DPIA er påkrævet, og bind dokumentation til konkrete kontroller og ansvarlige ejere.
Når modeller, værktøjer og workflows skifter, skal dokumentation og adgang følge med - ellers slipper kontrollen.
Korte svar på det, teamet ofte spørger om første gang I standardiserer AI-brug.
Tre dybdesider der supplerer denne guide, uden at gentage den samme EU AI Act-gennemgang.
Datagrænser, hosting og hvornår egen kontrol giver mening.
Modelinferens, miljøer og praktisk dataafgrænsning.
Dybere om risikoklasser, krav og produktsporet ved siden af GDPR.
Udrulning, governance og løbende ændringskontrol i praksis.
Korte, konkrete artikler om dataflows, leverandørkrav og praktisk CTO-styring - uden fyld.
Vi sender en bekræftelses-e-mail. Du kan altid afmelde dig igen.
Vi bruger kun mailen til nyhedsbrev og relevante opdateringer. Du kan framelde når som helst.
Vi koder lovlighed, dataminimering og sporbarhed ind som grænser systemet ikke kan bryde, præcis som dbeb.dk håndhæver BR18 og Eurocode. Resultatet er dataflow, leverandørstyring og logging der kan forklares til både ledelse og drift.
