Vad är en TIA (Transfer Impact Assessment)?

Av Weapp · Uppdaterad

En TIA (Transfer Impact Assessment) är en dokumenterad bedömning av om mottagarlandets lagstiftning urholkar skyddet vid en SCC-baserad överföring av personuppgifter. Den krävs när överföringen vilar på standardavtalsklausuler, till exempel en direktväg till en AI-leverantör, och ska besvara vad er försvarbara mekanism är den dag en utländsk begäran landar.

Så snart en AI-tjänst innebär att personuppgifter skickas till USA på grund av standardavtalsklausuler dyker kravet på en TIA upp. Transfer Impact Assessment låter byråkratiskt, men det är ett konkret dokument som besvarar en enda skarp fråga: håller skyddet när mottagarlandets myndigheter kan komma åt datan?

Vad en TIA är

En Transfer Impact Assessment är en dokumenterad bedömning av om lagstiftningen i mottagarlandet urholkar det skydd som standardavtalsklausulerna (SCC) ska ge. Den kom att bli nödvändig efter EU-domstolens Schrems II-dom, som slog fast att SCC är giltiga men inte automatiskt tillräckliga.

Logiken är enkel: ett avtal binder parterna, men det binder inte mottagarlandets myndigheter. Om landets lagar ger myndigheter åtkomst utöver vad EU-rätten tillåter, måste exportören bedöma om skyddet ändå håller i praktiken. Den bedömningen är TIA:n.

TIA eller DPIA – två olika dokument

En vanlig sammanblandning är TIA och DPIA. De hänger ihop men svarar på olika frågor. En DPIA – konsekvensbedömning – bedömer riskerna med en behandling i stort: ändamål, laglig grund, mängd data, rättigheter för de registrerade. En TIA är smalare och fokuserar på just tredjelandsöverföringen: håller skyddet när datan lämnar EU till ett land vars myndigheter kan begära ut den?

I praktiken blir TIA:ns slutsats ofta en byggsten i DPIA:n. Har du bedömt att en AI-tjänst kräver en DPIA, och tjänsten innebär överföring till USA på SCC-grund, hör TIA:ns bedömning av landrisken och restrisken hemma också i konsekvensbedömningen. Att veta vilket dokument som svarar på vad gör det lättare att inte dubbelarbeta – och att inte missa någondera.

När den krävs i AI-sammanhang

Behovet av TIA styrs av överföringsmekanismen, och där skiljer sig leverantörsvägarna åt.

  • En SCC-baserad direktväg till en leverantör – exempelvis en direktväg till Anthropic – kräver en egen TIA. Grunden är avtalsklausulerna, och då måste du själv bedöma landrisken.
  • En DPF-väg hos leverantörer som Microsoft och OpenAI flyttar i stället frågan till mekanismens giltighet. Vilar överföringen på ett adekvansbeslut behöver du normalt ingen egen TIA för just den vägen.

Det betyder att två AI-leverantörer i samma projekt kan ha olika analysbehov beroende på hur överföringen är grundad. Kör du båda parallellt måste du hålla isär dem.

Vad TIA:n ska innehålla

En användbar TIA vilar på tre delar:

  1. Rättsläget i mottagarlandet. Vilka lagar ger myndigheter åtkomst? För USA handlar det om CLOUD Act och relaterad lagstiftning.
  2. Den praktiska exponeringen. Hur sannolikt är det att just din data faktiskt nås? Vilken typ av uppgifter rör det sig om, och i vilken volym?
  3. Tilläggsåtgärderna. Vilka tekniska och organisatoriska skydd minskar risken – kundkontrollerade nycklar (KMS/CMEK), dataminimering, EU-inferens?

Slutsatsen är en motiverad bedömning av om skyddet håller trots mottagarlandets lagar, med restrisken tydligt redovisad.

Ansvaret för att TIA:n görs ligger på er som personuppgiftsansvarig – ni är exportören. Leverantören kan och bör bistå med underlag om sin verksamhet, sina skyddsåtgärder och sin underbiträdeskedja, men själva bedömningen kan inte delegeras bort. Det är er försvarbara grund som ska stå i dokumentet. Ett bra sätt att komma igång är att begära leverantörens transparensunderlag och kartlägga vart datan faktiskt går, och sedan väga den kartan mot vad ni vet om mottagarlandets lagstiftning. Den som väntar med TIA:n tills en tillsyn frågar har börjat i fel ände.

Kontrollfrågan TIA:n ska besvara

Det enklaste sättet att veta om din TIA duger är att ställa beslutsguidens kontrollfråga: vad är er försvarbara överföringsmekanism den dag en amerikansk begäran landar på leverantörens bord? Svaret ska stå i TIA:n, konkret och underbyggt.

Ett scenario gör det tydligt: ett bolag använder en SCC-baserad AI-tjänst och antar att signerade klausuler räcker. När tillsynen frågar hur de bedömt CLOUD Act-risken finns inget svar dokumenterat. Med en TIA på plats hade de kunnat peka på analysen, de valda tilläggsåtgärderna och den redovisade restrisken – i stället för att stå svarslösa.

Vill du se hur TIA:n hänger ihop med SCC, DPF och myndighetsåtkomst i ett helt AI-projekt finns mer på vår AI-sida. Behöver du hjälp att ta fram eller granska en TIA inför ett AI-avtal? Hör av dig så tittar vi på det tillsammans.

Vanliga frågor

När behöver jag göra en TIA?

När en överföring till tredjeland vilar på standardavtalsklausuler (SCC). Efter Schrems II räcker inte SCC ensamt – du måste bedöma om mottagarlandets lagar undergräver skyddet i praktiken. Går överföringen i stället via ett adekvansbeslut som DPF flyttas frågan till mekanismens giltighet, och någon egen TIA krävs normalt inte för den vägen.

Vad är skillnaden mellan en TIA och en DPIA?

En DPIA (konsekvensbedömning) bedömer riskerna med en behandling i stort. En TIA är mer avgränsad: den fokuserar på just tredjelandsöverföringen och risken för myndighetsåtkomst i mottagarlandet. De hänger ihop – TIA:ns slutsats om restrisk hör ofta hemma också i DPIA:n – men de svarar på olika frågor.

Vad ska en TIA innehålla?

Kärnan är tre delar: mottagarlandets lagstiftning om myndighetsåtkomst (som CLOUD Act), den praktiska sannolikheten att din data faktiskt exponeras, och vilka tilläggsåtgärder som minskar risken – exempelvis kundkontrollerade nycklar och EU-inferens. Slutsatsen är en bedömning av om skyddet håller trots mottagarlandets lagar.

Vem ansvarar för att TIA:n görs?

Den personuppgiftsansvarige – alltså ni som exporterar datan. Leverantören kan bistå med underlag om sin verksamhet och sina skyddsåtgärder, men bedömningen och dokumentationen är ert ansvar. Det går inte att fullt ut delegera till leverantören; det är er försvarbara grund som ska stå i dokumentet.

Behöver olika AI-leverantörer olika TIA?

Ja, om de använder olika överföringsmekanismer. En SCC-baserad direktväg kräver en egen TIA, medan en DPF-väg flyttar analysen till mekanismens giltighet. Kör ni flera leverantörer eller vägar parallellt kan ni behöva hantera dem var för sig, eftersom grunden – och därmed analysbehovet – skiljer sig.