Hvad er Data Privacy Framework (DPF)?
EU-US Data Privacy Framework (DPF) er en overførselsmekanisme baseret på en afgørelse om tilstrækkeligheden af beskyttelsesniveauet, som tillader at personoplysninger sendes til certificerede amerikanske modtagere uden en egen TIA (Transfer Impact Assessment). Den adskiller sig fra SCC, som kræver en egen vurdering. Hvilken mekanisme der gælder, afhænger af leverandørvejen, og DPF’s holdbarhed prøves netop nu retligt.
Når personoplysninger skal til en amerikansk AI-leverandør, har overførslen brug for et lovligt grundlag. EU-US Data Privacy Framework (DPF) er et af to almindelige grundlag af den slags. At forstå hvad DPF er, og hvor den adskiller sig fra standardkontraktbestemmelser, afgør hvor meget eget analysearbejde der ligger hos dig.
Hvad DPF er
Data Privacy Framework, i den officielle danske tekst databeskyttelsesrammen mellem EU og USA, er en tilstrækkelighedsafgørelse fra Europa-Kommissionen. Det betyder at EU har vurderet at amerikanske modtagere der er certificeret under rammen, tilbyder et beskyttelsesniveau som i al væsentlighed svarer til EU’s. For overførsler til en sådan certificeret modtager kræves der derfor ingen egen TIA: Tilstrækkelighedsafgørelsen udgør selv grundlaget.
Det er den centrale forskel i forhold til standardkontraktbestemmelser (SCC). Med SCC skal du selv lave en Transfer Impact Assessment (TIA) og tilføje tekniske beskyttelsesforanstaltninger. Med DPF flyttes bevisbyrden til certificeringen: Står modtageren på listen, er overførselsgrundlaget på plads.
En udbredt misforståelse er at DPF dermed løser hele spørgsmålet om amerikansk adgang til data. Det gør den ikke. DPF giver overførslen et lovligt grundlag efter GDPR, men den ændrer ikke at en amerikansk modtager stadig er underlagt amerikansk lovgivning som CLOUD Act. Tilstrækkelighedsafgørelsen siger at beskyttelsesniveauet er vurderet tilstrækkeligt på systemniveau. Den er ikke et løfte om at en enkelt anmodning fra en myndighed aldrig kan nå data. DPF og spørgsmålet om myndighedsadgang er altså to lag som begge skal håndteres, ikke ét.
Mekanismen afhænger af leverandørvejen
Her bliver det vigtigt i praksis. Hvilken mekanisme der gælder, afhænger af hvilken leverandør og hvilken vej du vælger.
Visse leverandører, f.eks. Microsoft og OpenAI, er aktive DPF-deltagere, og deres overførsler kan hvile på tilstrækkelighedsafgørelsen. En direkte vej til en anden leverandør, som Anthropic, kan i stedet bygge på SCC plus en egen TIA. Den samme type tjeneste kan altså have forskellig overførselsmekanisme afhængigt af hvordan du køber den.
Et konkret scenarie: En virksomhed antager at “amerikansk AI = DPF” og dokumenterer overførslen derefter. Ved gennemgangen viser det sig at netop den leverandørvej de har valgt, hviler på SCC, ikke DPF, og at TIA’en mangler. Konklusionen er at du skal vide præcis hvilken mekanisme din vej bruger, ikke antage en generel.
Holdbarheden prøves retligt
DPF er den tredje i rækken af mekanismer for overførsler mellem EU og USA. De to forgængere, Safe Harbor og Privacy Shield, blev begge erklæret ugyldige af EU-Domstolen. DPF’s holdbarhed prøves nu på ny, bl.a. i den såkaldte Latombe-sag ved EU-Domstolen.
Det betyder ikke at DPF er ugyldig i dag. Den gælder. Men historikken maner til forsigtighed. At bygge en arkitektur der fuldt ud forudsætter at DPF består for evigt, er at gentage en fejl der allerede er begået to gange.
Kundens kontrolpunkter
Når du gennemgår en AI-aftale hvor DPF påberåbes, er der nogle ting at krydse af:
- Aktuel certificering. Står leverandøren faktisk på den officielle DPF-liste lige nu, for den rette type data? Tjek det, og stol ikke på en markedsføringstekst.
- Den rette mekanisme pr. vej. Hviler jeres specifikke vej på DPF eller på SCC? Antagelsen “amerikansk AI = DPF” holder ikke; det afhænger af leverandør og købsvej.
- Reservemekanisme i aftalen. Er der SCC som fallback hvis DPF skulle falde? Det er den mest almindelige og klogeste sikring.
- Arkitektur der tåler et skifte. Er løsningen bygget så I kan skifte overførselsgrundlag uden at lave alt om?
Byg til et skifte af mekanisme
Den praktiske lære: Byg så et skifte af overførselsmekanisme ikke vælter hele løsningen. Hav en reservemekanisme i aftalen, ofte SCC, og en arkitektur hvor du kan skifte grundlag uden at lave alt om.
Og da deltagerlisten ændrer sig: Tjek altid leverandørens aktuelle DPF-status på den officielle liste før du indgår en aftale. En certificering der gjaldt i sidste kvartal, kan være ændret.
Vil du se hvordan DPF hænger sammen med SCC, data residency og myndighedsadgang i et helt AI-projekt, finder du mere på vores AI-side. Har du brug for hjælp til at afgøre hvilken overførselsmekanisme jeres opsætning faktisk hviler på? Kontakt os.
Ofte stillede spørgsmål
Hvad er forskellen på DPF og SCC?
DPF er en tilstrækkelighedsafgørelse: EU har vurderet at certificerede amerikanske modtagere giver tilstrækkelig beskyttelse, så overførslen kræver ingen egen analyse. SCC er kontraktbestemmelser som du selv skal kombinere med en TIA (Transfer Impact Assessment) og supplerende foranstaltninger. DPF flytter bevisbyrden fra dig til certificeringen mens SCC lægger den på dig.
Er alle amerikanske AI-leverandører med i DPF?
Nej. Deltagelsen er forskellig fra leverandør til leverandør og fra aftalevej til aftalevej. Visse leverandører er aktive DPF-deltagere mens andre veje i stedet hviler på SCC plus en egen TIA. Overførselsmekanismen kan altså være forskellig afhængigt af om du køber direkte eller via en cloudplatform. Tjek hvilken der faktisk gælder.
Hvordan ved jeg om en leverandør er DPF-certificeret?
Certificerede organisationer står på den officielle DPF-liste, som føres af det amerikanske handelsministerium (Department of Commerce). Tjek den aktuelle deltagerstatus der før du indgår en aftale, for en certificering kan være ændret eller ophørt. At en leverandør var med tidligere, er ingen garanti for at den er med i dag.
Er Data Privacy Framework juridisk sikkert på sigt?
Det prøves retligt. DPF’s holdbarhed er genstand for prøvelse ved EU-Domstolen (Latombe-sagen), på samme måde som tidligere mekanismer er blevet erklæret ugyldige. Det er klogt at bygge arkitekturen så et skifte af overførselsmekanisme ikke vælter hele løsningen, snarere end at gå ud fra at DPF består for altid.
Hvad sker der hvis DPF erklæres ugyldig?
Så skal overførslerne hvile på et andet grundlag, i praksis oftest SCC plus en egen TIA. Det er sket før: Både Safe Harbor og Privacy Shield faldt. Derfor bør aftaler have en reservemekanisme, og arkitekturen bør være bygget så et skifte kan gennemføres uden at alt skal laves om.