Hva er en TIA (Transfer Impact Assessment)?
En TIA (Transfer Impact Assessment) er en dokumentert vurdering av om lovgivningen i mottakerlandet uthuler beskyttelsen når personopplysninger overføres på grunnlag av standard personvernbestemmelser (SCC). Den kreves for eksempel ved en direkte vei til en AI-leverandør, og den skal svare på hvilket overføringsgrunnlag dere kan forsvare den dagen en utenlandsk forespørsel kommer.
Så snart en AI-tjeneste innebærer at personopplysninger sendes til USA på grunnlag av standard personvernbestemmelser (standardkontraktsklausuler, SCC), dukker kravet om en TIA opp. Transfer Impact Assessment høres byråkratisk ut, men det er et konkret dokument som svarer på ett eneste skarpt spørsmål: Holder beskyttelsen når myndighetene i mottakerlandet kan få tilgang til dataene?
Hva en TIA er
En Transfer Impact Assessment, også kalt tredjelandsvurdering, er en dokumentert vurdering av om lovgivningen i mottakerlandet uthuler den beskyttelsen som standard personvernbestemmelser (SCC) skal gi. Den ble nødvendig etter EU-domstolens Schrems II-dom, som slo fast at SCC er gyldige, men ikke automatisk tilstrekkelige. Dommen tolker overføringsreglene i personvernforordningen (GDPR), som også gjelder i Norge gjennom EØS-avtalen.
Logikken er enkel: En avtale binder partene, men den binder ikke myndighetene i mottakerlandet. Hvis landets lover gir myndighetene tilgang utover det EU/EØS-retten tillater, må eksportøren vurdere om beskyttelsen likevel holder i praksis. Den vurderingen er TIA-en.
TIA eller DPIA: to ulike dokumenter
Mange blander sammen TIA og DPIA. De henger sammen, men svarer på ulike spørsmål. En vurdering av personvernkonsekvenser (DPIA) ser på risikoen ved en behandling som helhet: formål, behandlingsgrunnlag, datamengde og de registrertes rettigheter. En TIA er smalere og handler om selve overføringen til tredjeland: Holder beskyttelsen når dataene forlater EØS til et land der myndighetene kan kreve dem utlevert?
I praksis blir konklusjonen i TIA-en ofte en byggestein i DPIA-en. Har du vurdert at en AI-tjeneste krever en DPIA, og tjenesten innebærer overføring til USA på grunnlag av SCC, hører vurderingen av landrisiko og restrisiko i TIA-en hjemme også i konsekvensvurderingen. Å vite hvilket dokument som svarer på hva, gjør det lettere å unngå både dobbeltarbeid og at ett av dem blir glemt.
Når den kreves i AI-sammenheng
Behovet for en TIA styres av overføringsgrunnlaget, og der skiller leverandørveiene seg fra hverandre.
- En SCC-basert direkte vei til en leverandør, for eksempel direkte til Anthropic, krever en egen TIA. Grunnlaget er avtaleklausulene, og da må du selv vurdere landrisikoen.
- En DPF-vei hos leverandører som Microsoft og OpenAI flytter i stedet spørsmålet over til grunnlagets gyldighet. Hviler overføringen på en adekvansbeslutning, trenger du normalt ingen egen TIA for akkurat den veien.
Det betyr at to AI-leverandører i samme prosjekt kan ha ulikt analysebehov, avhengig av hvilket grunnlag overføringen hviler på. Bruker du begge parallelt, må du holde dem fra hverandre.
Hva TIA-en skal inneholde
En brukbar TIA hviler på tre deler:
- Rettstilstanden i mottakerlandet. Hvilke lover gir myndighetene tilgang? For USA handler det om CLOUD Act og tilhørende lovgivning.
- Den praktiske eksponeringen. Hvor sannsynlig er det at myndighetene faktisk får tilgang til nettopp dine data? Hva slags opplysninger dreier det seg om, og i hvilket volum?
- Tilleggstiltakene. Hvilke tekniske og organisatoriske tiltak reduserer risikoen: kundekontrollerte nøkler (KMS/CMEK), dataminimering, EU-inferens?
Konklusjonen er en begrunnet vurdering av om beskyttelsen holder til tross for lovene i mottakerlandet, med restrisikoen tydelig dokumentert.
Ansvaret for at TIA-en blir gjort, ligger hos dere som behandlingsansvarlige: Dere er eksportøren. Leverandøren kan og bør bidra med underlag om egen virksomhet, egne beskyttelsestiltak og kjeden av underleverandører, men selve vurderingen kan ikke delegeres bort. Det er grunnlaget dere selv kan forsvare, som skal stå i dokumentet. En god måte å komme i gang på er å be om leverandørens åpenhetsdokumentasjon og kartlegge hvor dataene faktisk går, og deretter veie det kartet mot det dere vet om lovgivningen i mottakerlandet. Den som venter med TIA-en til tilsynsmyndigheten spør, har begynt i feil ende.
Kontrollspørsmålet TIA-en skal svare på
Den enkleste måten å finne ut om TIA-en din holder mål, er å stille kontrollspørsmålet fra beslutningsguiden: Hvilket overføringsgrunnlag kan dere forsvare den dagen en amerikansk forespørsel lander på leverandørens bord? Svaret skal stå i TIA-en, konkret og underbygd.
Et scenario gjør det tydelig: Et selskap bruker en SCC-basert AI-tjeneste og antar at signerte klausuler er nok. Når tilsynsmyndigheten spør hvordan de har vurdert CLOUD Act-risikoen, finnes det ikke noe dokumentert svar. Med en TIA på plass kunne de ha pekt på analysen, de valgte tilleggstiltakene og den dokumenterte restrisikoen i stedet for å stå uten svar.
Vil du se hvordan TIA-en henger sammen med SCC, DPF og myndighetstilgang i et helt AI-prosjekt, finner du mer på AI-siden vår. Trenger du hjelp til å utarbeide eller gå gjennom en TIA før en AI-avtale? Ta kontakt, så ser vi på det sammen.
Ofte stilte spørsmål
Når må jeg gjøre en TIA?
Når en overføring til tredjeland hviler på standard personvernbestemmelser (SCC). Etter Schrems II er ikke SCC nok alene: Du må vurdere om lovene i mottakerlandet undergraver beskyttelsen i praksis. Går overføringen i stedet via en adekvansbeslutning som DPF, flyttes spørsmålet over til grunnlagets gyldighet, og det kreves normalt ingen egen TIA for den veien.
Hva er forskjellen på en TIA og en DPIA?
En DPIA, vurdering av personvernkonsekvenser, ser på risikoen ved en behandling som helhet. En TIA er mer avgrenset: Den handler om selve overføringen til tredjeland og risikoen for myndighetstilgang i mottakerlandet. De henger sammen, og konklusjonen i TIA-en om restrisiko hører ofte hjemme også i DPIA-en, men de svarer på ulike spørsmål.
Hva skal en TIA inneholde?
Kjernen er tre deler: lovgivningen i mottakerlandet om myndighetstilgang (som CLOUD Act), den praktiske sannsynligheten for at dataene dine faktisk blir eksponert, og hvilke tilleggstiltak som reduserer risikoen, for eksempel kundekontrollerte nøkler og EU-inferens. Konklusjonen er en vurdering av om beskyttelsen holder til tross for lovene i mottakerlandet.
Hvem har ansvaret for at TIA-en blir gjort?
Den behandlingsansvarlige, altså dere som eksporterer dataene. Leverandøren kan bidra med underlag om egen virksomhet og egne beskyttelsestiltak, men dere er ansvarlige for vurderingen og dokumentasjonen. Det ansvaret kan ikke fullt ut delegeres til leverandøren. Det er grunnlaget dere selv kan forsvare, som skal stå i dokumentet.
Trenger ulike AI-leverandører hver sin TIA?
Ja, hvis de bruker ulike overføringsgrunnlag. En SCC-basert direkte vei krever en egen TIA, mens en DPF-vei flytter analysen over til grunnlagets gyldighet. Bruker dere flere leverandører eller veier parallelt, må dere kanskje håndtere dem hver for seg fordi grunnlaget, og dermed behovet for analyse, er forskjellig.