Hvad er en TIA (Transfer Impact Assessment)?
En TIA (Transfer Impact Assessment) er en dokumenteret vurdering af om modtagerlandets lovgivning udhuler beskyttelsen ved en overførsel af personoplysninger baseret på SCC. Den kræves når overførslen hviler på standardkontraktbestemmelser, f.eks. en direkte vej til en AI-leverandør, og skal besvare hvad jeres holdbare mekanisme er den dag en udenlandsk anmodning lander.
Så snart en AI-tjeneste indebærer at personoplysninger sendes til USA på grundlag af standardkontraktbestemmelser, dukker kravet om en TIA op. Transfer Impact Assessment lyder bureaukratisk, men det er et konkret dokument der besvarer ét skarpt spørgsmål: Holder beskyttelsen når modtagerlandets myndigheder kan få adgang til dataene?
Hvad en TIA er
En Transfer Impact Assessment (en overførselsanalyse) er en dokumenteret vurdering af om lovgivningen i modtagerlandet udhuler den beskyttelse som standardkontraktbestemmelserne (SCC) skal give. Den blev nødvendig efter EU-Domstolens Schrems II-dom, som slog fast at SCC er gyldige, men ikke automatisk tilstrækkelige.
Logikken er enkel: En aftale binder parterne, men den binder ikke modtagerlandets myndigheder. Hvis landets love giver myndigheder adgang ud over hvad EU-retten tillader, må eksportøren vurdere om beskyttelsen alligevel holder i praksis. Den vurdering er TIA’en.
TIA eller DPIA: to forskellige dokumenter
En almindelig sammenblanding er TIA og DPIA. De hænger sammen, men besvarer forskellige spørgsmål. En DPIA, en konsekvensanalyse vedrørende databeskyttelse, vurderer risiciene ved en behandling i det hele taget: formål, retsgrundlag, mængden af data, de registreredes rettigheder. En TIA er smallere og fokuserer på netop tredjelandsoverførslen: Holder beskyttelsen når dataene forlader EU til et land hvis myndigheder kan kræve dem udleveret?
I praksis bliver TIA’ens konklusion ofte en byggesten i DPIA’en. Har du vurderet at en AI-tjeneste kræver en DPIA, og tjenesten indebærer overførsel til USA på grundlag af SCC, hører TIA’ens vurdering af landerisikoen og restrisikoen også hjemme i konsekvensanalysen. At vide hvilket dokument der besvarer hvad, gør det lettere at undgå dobbeltarbejde uden at overse nogen af dem.
Hvornår den kræves i AI-sammenhæng
Behovet for en TIA styres af overførselsmekanismen, og her er leverandørvejene forskellige.
- En direkte vej baseret på SCC til en leverandør, f.eks. en direkte vej til Anthropic, kræver en særskilt TIA. Grundlaget er kontraktbestemmelserne, og så må du selv vurdere landerisikoen.
- En DPF-vej hos leverandører som Microsoft og OpenAI flytter i stedet spørgsmålet til mekanismens gyldighed. Hviler overførslen på en afgørelse om tilstrækkeligheden af beskyttelsesniveauet, har du normalt ikke brug for en særskilt TIA for netop den vej.
Det betyder at to AI-leverandører i samme projekt kan have forskellige behov for analyse afhængigt af hvad overførslen er baseret på. Kører du begge parallelt, må du holde dem adskilt.
Hvad TIA’en skal indeholde
En brugbar TIA hviler på tre dele:
- Retstilstanden i modtagerlandet. Hvilke love giver myndigheder adgang? For USA drejer det sig om CLOUD Act og relateret lovgivning.
- Den praktiske eksponering. Hvor sandsynligt er det at netop dine data faktisk tilgås? Hvilken type oplysninger drejer det sig om, og i hvilken mængde?
- De supplerende foranstaltninger. Hvilke tekniske og organisatoriske beskyttelser mindsker risikoen: kundekontrollerede nøgler (KMS/CMEK), dataminimering, EU-inferens?
Konklusionen er en begrundet vurdering af om beskyttelsen holder trods modtagerlandets love, med en tydelig redegørelse for restrisikoen.
Ansvaret for at TIA’en bliver lavet, ligger hos jer som dataansvarlig. I er eksportøren. Leverandøren kan og bør bidrage med materiale om sin virksomhed, sine beskyttelsesforanstaltninger og sin kæde af underdatabehandlere, men selve vurderingen kan ikke uddelegeres. Det er jeres holdbare grundlag der skal stå i dokumentet. En god måde at komme i gang på er at bede om leverandørens gennemsigtighedsmateriale og kortlægge hvor dataene faktisk går hen, og derefter holde kortlægningen op mod hvad I ved om modtagerlandets lovgivning. Den der venter med TIA’en til en tilsynsmyndighed spørger, er begyndt i den forkerte ende.
Kontrolspørgsmålet TIA’en skal besvare
Den enkleste måde at vide om din TIA holder, er at stille beslutningsguidens kontrolspørgsmål: Hvad er jeres holdbare overførselsmekanisme den dag en amerikansk anmodning lander på leverandørens bord? Svaret skal stå i TIA’en, konkret og underbygget.
Et scenarie gør det tydeligt: En virksomhed bruger en AI-tjeneste baseret på SCC og går ud fra at underskrevne kontraktbestemmelser er nok. Når tilsynsmyndigheden spørger hvordan de har vurderet risikoen ved CLOUD Act, er der intet svar dokumenteret. Med en TIA på plads havde de kunnet pege på analysen, de valgte supplerende foranstaltninger og redegørelsen for restrisikoen i stedet for at stå uden svar.
Vil du se hvordan TIA’en hænger sammen med SCC, DPF og myndighedsadgang i et helt AI-projekt, finder du mere på vores AI-side. Har du brug for hjælp til at udarbejde eller gennemgå en TIA før en AI-aftale? Kontakt os, så kigger vi på det sammen.
Ofte stillede spørgsmål
Hvornår skal jeg lave en TIA?
Når en overførsel til et tredjeland hviler på standardkontraktbestemmelser (SCC). Efter Schrems II er SCC ikke nok i sig selv: Du skal vurdere om modtagerlandets love undergraver beskyttelsen i praksis. Går overførslen i stedet via en afgørelse om tilstrækkeligheden af beskyttelsesniveauet som DPF, flyttes spørgsmålet til mekanismens gyldighed, og en særskilt TIA kræves normalt ikke for den vej.
Hvad er forskellen på en TIA og en DPIA?
En DPIA (konsekvensanalyse vedrørende databeskyttelse) vurderer risiciene ved en behandling i det hele taget. En TIA er mere afgrænset: Den fokuserer på netop tredjelandsoverførslen og risikoen for myndighedsadgang i modtagerlandet. De hænger sammen, og TIA’ens konklusion om restrisiko hører ofte også hjemme i DPIA’en, men de besvarer forskellige spørgsmål.
Hvad skal en TIA indeholde?
Kernen er tre dele: modtagerlandets lovgivning om myndighedsadgang (som CLOUD Act), den praktiske sandsynlighed for at dine data faktisk eksponeres og hvilke supplerende foranstaltninger der mindsker risikoen, f.eks. kundekontrollerede nøgler og EU-inferens. Konklusionen er en vurdering af om beskyttelsen holder trods modtagerlandets love.
Hvem har ansvaret for at TIA’en bliver lavet?
Den dataansvarlige, altså jer der eksporterer dataene. Leverandøren kan bidrage med materiale om sin virksomhed og sine beskyttelsesforanstaltninger, men vurderingen og dokumentationen er jeres ansvar. Den kan ikke fuldt ud uddelegeres til leverandøren; det er jeres holdbare grundlag der skal stå i dokumentet.
Kræver forskellige AI-leverandører forskellige TIA’er?
Ja, hvis de bruger forskellige overførselsmekanismer. En direkte vej baseret på SCC kræver en særskilt TIA mens en DPF-vej flytter analysen til mekanismens gyldighed. Kører I flere leverandører eller veje parallelt, kan I have brug for at håndtere dem hver for sig fordi grundlaget, og dermed behovet for analyse, er forskelligt.