Mange AI-værktøjer i gratis eller billige versioner forbeholder sig retten til at bruge jeres data til modeltræning. Det står typisk begravet i standardvilkårene. Din medarbejder bruger et AI-værktøj til at opsummere mødereferater. Leverandøren bag værktøjet bruger stilfærdigt alle de referater til at træne sin næste model. Pludselig ligger jeres interne strategidrøftelser og personaleoplysninger i en database, I hverken kontrollerer eller kender omfanget af. Det scenarie er ikke fiktion og illustrerer tydeligt risikoen ved håndtering af skygge-AI, som IT-afdelingen bør have en strategi for. Det sker, når en databehandleraftale enten mangler eller ikke er skruet sammen til AI. Denne artikel giver dig en konkret tjekliste over de krav, jeres databehandleraftale skal opfylde, før I lukker en AI-leverandør ind i organisationen. Har du brug for det store overblik over det juridiske landskab omkring AI, er vores komplette guide til AI og corporate compliance et godt sted at starte.
Indholdsfortegnelse
- Hvad skal en databehandleraftale for AI indeholde?
- Sådan forhindrer I leverandøren i at bruge jeres data til træning
- Hvad er særligt ved AI-DPA'er ift. almindelige DPA'er?
- Opsummering: Jeres minimumstjekliste
Hvad skal en databehandleraftale for AI indeholde?
En databehandleraftale (forkortet DPA) er den kontrakt, der bestemmer, hvad en leverandør må og ikke må gøre med jeres data. Under GDPR er den lovpligtig, hver gang en ekstern part behandler personoplysninger på jeres vegne. Det gælder også AI-værktøjer.
Men en standard DPA, som den I måske kender fra jeres lønsystem eller nyhedsbrevsudbyder, dækker sjældent de særlige risici, AI introducerer. Derfor skal I sikre, at aftalen som minimum indeholder disse syv punkter:
1. Klart formål og begrænsning
Aftalen skal præcist beskrive, hvad leverandøren må bruge jeres data til. "Levering af tjenesten" er for vagt. En brugbar formulering ser konkret ud:
"Leverandøren må udelukkende behandle kundens data med det formål at opsummere uploadede dokumenter og returnere output til den bruger, der uploadede dokumentet. Ingen anden behandling er tilladt."
Sammenlign med en typisk svag formulering fra standardvilkår:
"We may use your data to provide, improve, and personalize our services."
Den anden formulering giver leverandøren næsten ubegrænset spillerum. Den første lukker det.
2. Forbud mod brug af data til modeltræning
Det her er det vigtigste punkt. Aftalen skal eksplicit fastslå, at leverandøren ikke må bruge jeres input, output eller metadata til at træne, finjustere eller forbedre egne modeller. En robust formulering:
"Leverandøren må ikke anvende kundens data, herunder input, output, afledte data eller metadata, til træning, validering, finjustering eller på anden måde til forbedring af egne eller tredjeparts maskinlæringsmodeller."
Læg mærke til, at formuleringen eksplicit nævner afledte data og metadata. Mange leverandører omgår et træningsforbud ved at hævde, at de "kun" bruger aggregerede eller anonymiserede data, som teknisk set ikke er jeres data. Den formulering lukker den bagdør.
3. Ring-fencing af jeres data
Jeres data skal være logisk adskilt fra andre kunders data. Tænk på det som at leje et aflåst opbevaringsrum frem for at smide jeres ting i et fælles lagerhal. I praksis betyder det, at leverandøren skal kunne dokumentere:
- At jeres data opbevares i en dedikeret database eller container, ikke i et delt datalager
- At inferens (selve AI-behandlingen) sker i et isoleret miljø
- At logs og fejlrapporter ikke samler data på tværs af kunder
Spørg konkret: "Kan I sende os en arkitekturbeskrivelse, der viser, hvordan vores data er isoleret?" Leverandører, der ikke kan svare på det spørgsmål, har sandsynligvis ikke løst problemet.
4. Lokation for databehandling
Aftalen skal angive præcise geografiske lokationer for både opbevaring og processering. "EU" er ikke præcist nok, fordi EU inkluderer lande med vidt forskellig praksis for myndighedsadgang til data. For de fleste danske organisationer er minimumskravet:
- Opbevaring: Danmark eller et andet EU/EØS-land
- Processering: Samme geografi som opbevaring
- Backup og disaster recovery: Eksplicit nævnt med geografisk placering
Vær særligt opmærksom på inferens-stedet. Mange leverandører opbevarer data i EU, men sender dem midlertidigt til servere i USA, når AI-modellen rent faktisk kører. Det er et GDPR-problem, selvom dataen vender tilbage.
5. Underdatabehandlere
AI-leverandører bruger næsten altid underleverandører til hosting, inferens eller logning. En håndfuld typiske eksempler: AWS eller Azure til hosting, Datadog til logning, Anthropic eller OpenAI til selve modelkørslen. Aftalen skal:
- Liste alle aktuelle underdatabehandlere med navn og land
- Give jer ret til at modtage besked (minimum 30 dages varsel) ved nye underdatabehandlere
- Give jer ret til at gøre indsigelse mod nye underdatabehandlere
Det sidste punkt er afgørende. En notifikationsret uden indsigelsesret er nærmest meningsløs i praksis.
6. Sletning og dataportabilitet
Hvad sker der med jeres data, når I opsiger aftalen? Aftalen skal specificere:
- En konkret tidsfrist for sletning efter aftalens ophør (typisk 30-90 dage)
- Et format, hvori I kan få data udleveret (CSV, JSON eller andet maskinlæsbart format)
- Bekræftelse på sletning i form af et skriftligt certifikat
- Hvad der sker med data, der er kopieret til backup-systemer
Mange organisationer opdager for sent, at de ikke kan få deres data ud i et brugbart format. Det er et reelt problem, hvis I skal skifte leverandør eller skal fremvise data i forbindelse med en GDPR-forespørgsel.
7. Auditrettigheder
I skal have ret til at auditere, om leverandøren faktisk overholder aftalen. Uden den ret er resten af kontrakten en tillidserklæring. I praksis tager auditrettigheder to former:
- Direkte audit: I (eller en tredjepart I bemyndiger) har ret til at gennemgå leverandørens systemer og dokumentation
- Certifikatbaseret audit: Leverandøren skal fremvise aktuelle certifikater, f.eks. SOC 2 Type II, ISO 27001 eller tilsvarende
For store leverandører er direkte audit sjældent realistisk. Kræv i stedet SOC 2 Type II-rapporter udstedt inden for de seneste 12 måneder, og ret til at stille opfølgende spørgsmål til rapporten. Denne ret er essentiel for at sikre gennemsigtighed og undgå black-box-problematikken.
En IT-chef i en dansk kommune, der skal implementere et AI-baseret borgerserviceværktøj, kan bruge denne liste som tjekliste i dialogen med leverandøren. Mangler ét af de syv punkter, er det et rødt flag, der skal afklares, før kontrakten underskrives. Læs mere om AI og GDPR i sundhedssektoren for dybere indsigt i den case.
Sådan forhindrer I leverandøren i at bruge jeres data til træning
Forbuddet mod modeltræning på jeres data fortjener sit eget afsnit, fordi det er her, de fleste organisationer bliver overrasket.
Enterprise-versioner af f.eks. Microsoft Copilot og ChatGPT har DPA'er, der eksplicit udelukker modeltræning på kundedata. Men det kræver, at I faktisk har den rigtige licenstype, og at DPA'en er aktiveret. En organisation der betaler for ChatGPT Team tror måske de er dækket ind. men det er kun ChatGPT Enterprise-licensen der aktiverer den fulde DPA med træningsforbud.
Tre konkrete ting I kan gøre:
Læs standardvilkårene, før I køber. Mange leverandører har offentligt tilgængelige DPA'er på deres hjemmeside. Søg specifikt efter disse formuleringer:
- "we may use input data to improve our services". rødt flag
- "we may use aggregated or anonymized data". rødt flag, fordi anonymisering er reversibel
- "customer data is not used for model training". acceptabelt, men verificér at det gælder jeres licenstype
- "enterprise customers' data is excluded from training". acceptabelt, forudsat I har enterprise-licens
Kræv en eksplicit "no-training"-klausul. Formuleringen skal være utvetydig og dække mere end blot "jeres data". Et godt eksempel:
"Leverandøren må ikke bruge kundens data, herunder input, output, afledte data og metadata, til træning, validering eller forbedring af egne eller tredjeparts modeller, hverken direkte eller via anonymisering, aggregering eller anden form for transformation."
Tillægget om anonymisering og aggregering er vigtigt. Det lukker den bagdør, som mange leverandører bruger: de "anonymiserer" data og hævder derefter, at det ikke er jeres data mere.
Verificér, at det teknisk hænger sammen. En kontraktuel garanti er kun noget værd, hvis den kan verificeres. Spørg leverandøren:
- "Kan I beskrive, teknisk, hvordan vores data er isoleret fra jeres træningsinfrastruktur?"
- "Fremgår det af jeres SOC 2-rapport, at kundedata er udelukket fra modeltræning?"
- "Hvem i jeres organisation har adgang til vores data, og hvad er adgangskontrollen?"
En leverandør, der ikke kan svare konkret på disse spørgsmål, har sandsynligvis ikke implementeret de nødvendige tekniske foranstaltninger.
En dansk sundhedsregion har brugt denne tilgang i praksis. De krævede, at leverandørens AI-løsning kørte i et dansk datacenter med fuldstændig adskillelse fra leverandørens øvrige infrastruktur. Det betød højere pris, men også fuldstændig kontrol.
Hvad er særligt ved AI-DPA'er ift. almindelige DPA'er?
Når du sammenligner en databehandleraftale for et klassisk SaaS-system (f.eks. et CRM) med en for et AI-system, er der tre afgørende forskelle:
Data bruges aktivt, ikke bare passivt
I et traditionelt system opbevares og vises jeres data. I et AI-system processeres data aktivt: det analyseres, transformeres og kombineres. Det øger risikoen for, at personoplysninger dukker op i uventede sammenhænge.
Et konkret eksempel: Hvis to medarbejdere uploader dokumenter om henholdsvis en medarbejders sygefravær og en afskedigelsesproces til samme AI-system, kan systemet i teorien sætte de to ting i forbindelse, selvom de aldrig var tænkt som relaterede. I et traditionelt system ville de to dokumenter ligge i separate mapper.
Outputtet kan indeholde nye personoplysninger
Hvis en medarbejder beder et AI-værktøj om at opsummere en personalemappe, kan outputtet indeholde fortolkninger eller kombinationer af data, der udgør ny personoplysningsbehandling. Det er ikke en hypotetisk risiko: et AI-system, der opsummerer "høj sygefravær, igangværende afskedigelsessag, vurdering: lav performance", har skabt en ny personoplysning, der ikke eksisterede i inputdataen.
Jeres DPA skal adressere hvem der er ansvarlig for output, ikke kun input. En konkret formulering:
"Behandlingsansvarlig er dataansvarlig for ethvert output genereret på baggrund af kundens data, uanset om outputtet udgør en ny eller afledt personoplysning."
Modellerne opdateres løbende
Mange AI-leverandører opdaterer deres modeller regelmæssigt. En ny modelversion kan ændre, hvilke data der sendes hvor, og hvordan data behandles under inferens. Jeres aftale skal sikre:
- At I modtager besked ved modelopdateringer, der ændrer databehandlingens karakter
- At opdateringer ikke automatisk ændrer geografien for databehandling
- At I har ret til at fastfryse en specifik modelversion i en periode, hvis en opdatering er problematisk
Microsoft Copilots enterprise-DPA er et godt eksempel på best practice. Den inkluderer eksplicit at kundedata ikke bruges til modeltræning, at data forbliver inden for EU-datagrænsen for EU-kunder, og at underdatabehandlere er offentligt listet og opdateret løbende. Det er den standard, I bør holde andre leverandører op imod.
Har I brug for at forstå, hvordan data kan lække gennem daglige AI-prompts, kan I læse mere om beskyttelse af forretningshemmeligheder ved AI-brug.
Opsummering: Jeres minimumstjekliste
Før I underskriver en kontrakt med en AI-leverandør, stil disse spørgsmål:
- Er formålet med databehandlingen præcist og begrænset i kontraktens ordlyd?
- Er der et eksplicit forbud mod modeltræning, der også dækker afledte data og metadata?
- Er vores data ring-fenced fra andre kunders data, og kan leverandøren dokumentere det teknisk?
- Ved vi præcist, i hvilke lande vores data behandles, både under opbevaring og under inferens?
- Har vi godkendelsesret over alle underdatabehandlere, ikke blot notifikationsret?
- Er sletningsfrister, dataformat og sletningscertifikat beskrevet?
- Har vi auditrettigheder eller adgang til aktuelle SOC 2 Type II-rapporter?
Kan leverandøren sige ja til alle syv punkter, er I godt på vej. Kan de ikke, er det tid til at forhandle, inden kontrakten underskrives. En ufuldstændig DPA er ikke en formalitet, der kan ordnes senere. Det er et juridisk og operationelt problem, der er langt sværere at løse, efter data allerede er delt.
Ofte stillede spørgsmål
Bruno Poulsen er partner i Poulsen & Vinding, et konsulenthus der hjælper danske virksomheder og styrelser med at tage generativ AI i brug i den daglige drift. Han er senior underviser hos Bigum&Co gennem 10+ år og har siden 2023 stået bag AI-implementeringer, foredrag og workshops for blandt andre Lægemiddelstyrelsen, GS1 Danmark, Bornholms Højskole og 30+ bornholmske SMV’er via Business Center Bornholm. Skriver om praktisk anvendelse af AI-værktøjer, prompt engineering og hvordan ledelser kommer i gang mandag morgen kl. 08.00.
