Third-country transfer and Transfer Impact Assessment (TIA): Swiss data in US and PRC cloud LLMs

What does the third-country transfer regime in revFADP cover?

The revised Federal Data Protection Act (revFADP) regulates in Articles 16 to 18 the disclosure of personal data abroad. A third country in the sense of the Act is any state outside Switzerland not recognised by Federal Council ordinance as providing adequate protection. The list of recognised states is in Annex 1 of the DPO and as of May 2026 includes EU/EEA countries, the United Kingdom, Canada (commercial sub-area), Israel, Argentina, Uruguay, New Zealand, Japan, South Korea and the United States (subject to the Data Privacy Framework, see below).

Where the third country is NOT on the list, Art. 16 para. 2 revFADP applies: disclosure is permitted only if suitable safeguards ensure adequate protection in the specific case. Recognised safeguards include: international treaty, standard data protection clauses (SCC), specific contractual clauses, binding corporate rules (BCR, approved by EDÖB), or a code of conduct / certificate. In the absence of suitable safeguards, Art. 17 revFADP kicks in with exception grounds: explicit consent of the data subject, contract performance, overriding public interests, protection of life and limb, publicly available data.

Relevant for AI use: every prompt transmission to a US or PRC provider containing personal data is a disclosure under Art. 16 revFADP. The question is never WHETHER it is a transfer – the question is which safeguard supports it and whether the safeguard is sufficient in the specific case. This examination is called Transfer Impact Assessment.

Why the TIA is central with cloud LLMs

Switzerland recognised in July 2024 the Swiss-U.S. extension of the EU-US Data Privacy Framework (DPF), effective 15 September 2024. Since then US companies certified with the US Department of Commerce for the Swiss-U.S. DPF count as recipients with an adequate level of protection under Art. 16 para. 1 revFADP. Microsoft, Google and Anthropic are certified; OpenAI completed its certification in March 2025.

The DPF does not however suffice in all cases. First, it only covers data within the certified scope – the list of data types is self-declared by the recipient and may be narrow. Second, the Federal Supreme Court and doctrine (Vischer, Walder Wyss, Homburger) have not yet conclusively ruled whether the DPF sufficiently constrains continuing US mass surveillance under Section 702 FISA and Executive Order 12333. Third, the DPF is a bilateral mechanism; it does not apply to PRC providers (Alibaba Tongyi, Baidu Ernie, DeepSeek-Cloud).

The EDÖB has therefore recommended since September 2023, with its TIA guidance, to assess every third-country transfer in a documented procedure – even where the destination is on the adequacy list. The TIA module is a structured questionnaire ending in a formal documentation that serves as proof in EDÖB proceedings.

How a TIA for a cloud LLM is built

The EDÖB TIA module is structured in four blocks.

Block 1 – Transfer description: Who is controller, who is recipient? Which data categories? Which purposes? Which retention period? Example OpenAI: controller Swiss SME fiduciary, recipient OpenAI Ireland Ltd (as contractual party) with sub-processing by OpenAI OpCo LLC (USA), data categories pseudonymised mandate data and accounting questions, purpose answer generation, retention Zero Data Retention.

Block 2 – Legal-environment analysis: Which laws in the destination country allow government access? For the US: FISA Section 702 (mass surveillance of foreigners), Executive Order 12333 (foreign-intelligence collection), CLOUD Act (extraterritorial production orders), Stored Communications Act. For the PRC: Cybersecurity Law 2017, Data Security Law 2021, Personal Information Protection Law 2021, National Intelligence Law Article 7 (duty to cooperate with intelligence services). This block documents the legal exposure.

Block 3 – Case-specific risk analysis: How likely is government access to the specific data? Factors: political sensitivity of data, prominent persons, sector-specific intelligence interest (semiconductors, pharma, defence). For a Swiss fiduciary using AI for routine balance-sheet plausibility checks the risk is low; for a law firm with a US-sanctioned client or a pharma company with active-substance data it is real.

Block 4 – Supplementary measures: Where the risk analysis shows residual risks, technical and organisational safeguards are added: pseudonymisation, encryption at rest and in transit (TLS 1.3 as minimum), zero data retention, EU hosting of the inference endpoint (Azure OpenAI EU, Anthropic via AWS Frankfurt, Google EU Data Boundary), strict sub-processor lists, contractual clauses on information about authority requests.

TIA workflow in 6 steps

1. 01Build a transfer inventory: which data go to which recipient, in which country, under which legal basis?
2. 02Adequacy check: is the destination listed (DPO Annex 1)? If yes, is the recipient DPF-certified? If not, which safeguard under Art. 16 para. 2 revFADP?
3. 03Legal-environment analysis: which authority access powers in the destination country? FISA 702, CLOUD Act, EO 12333 for the US; PIPL + NIL Art. 7 for the PRC.
4. 04Case-by-case risk assessment: data categories, affected persons, sectoral intelligence interest, likelihood, severity.
5. 05Supplementary measures: encryption, pseudonymisation, EU-hosted inference endpoint, ZDR, contractual notification clauses.
6. 06Documentation and review: complete the EDÖB module, file in the compliance dossier, review annually and on every material change.

When a TIA is required

Mandatory: before any first-time disclosure of personal data to a recipient outside the CH/EU/EEA adequacy zone, or with DPF certification outside the declared scope. Even where the destination country is listed, the EDÖB recommends a simplified TIA as routine documentation.

In practice, for AI use in Swiss SMEs: TIA for OpenAI, Anthropic, Google, Microsoft Azure OpenAI on first implementation. TIA for Cohere (Canada – adequate but TIA recommended). TIA with elevated requirements for DeepSeek-API (PRC, no DPF), Baidu, Alibaba. NO TIA needed for Mistral SaaS in the EU, Aleph Alpha on CH hosting, or local Llama/Qwen deployments.

Repetition: the TIA must be redone on any material change – provider switch, new data categories, change of hosting location, new key law in the destination country. An annual routine review is customary. The document remains in the compliance file and is to be produced on EDÖB request.

Special caution for particularly sensitive personal data under Art. 5 lit. c revFADP (health, religious beliefs, criminal prosecution, biometric data) and for data under professional secrecy (Art. 321 SCC). Here requirements on the safeguard and supplementary measures are markedly stricter; when in doubt, no third-country disclosure.

When a classical TIA does not apply

A TIA is not a cure-all. Three constellations where TIA documentation does not suffice and other paths are needed:

Professional-secrecy cases: For Art. 321 SCC data (lawyer, notary, physician), a TIA with positive risk assessment alone does NOT satisfy the criminal confidentiality duty. Additional client consent, true anonymisation, or local hosting are required. See Professional Secrecy Art. 321 SCC.

Politically high-sensitivity mandates: Where data categories belong to sectors actively collected against in the destination country (US-FISA listings: semiconductors, quantum, biotech, defence; PRC intelligence interest: pharma, semiconductors, machinery), residual risk is not manageable with standard measures. EU hosting or local operation is the only clean solution.

Mass transfer with personal reference: Where a process transfers millions of personal-data records per year (e.g. AI-supported CRM analysis on all customer data), TIA evaluation itself becomes a task. EDÖB attention is high. BCR instead of SCC, plus EU hosting, are advisable.

No TIA required: with full anonymisation under Art. 5 lit. a revFADP (irreversible loss of personal reference). Anyone mathematically anonymising a dataset (k-anonymity >= 5, differential privacy) can send it without a TIA. Caution: pseudonymisation alone is NOT anonymisation in the legal sense.

Trade-offs

FAQ

Related topics

Sources

1. EDÖB – Leitfaden zur Prüfung des Datenexports (TIA-Modul) · 2024-08
2. revDSG Art. 16-18 – Bekanntgabe ins Ausland (fedlex.admin.ch) · 2026-01
3. Swiss-U.S. Data Privacy Framework – Federal Council recognition (15 September 2024) · 2024-08
4. DSV Anhang 1 – Staaten mit angemessenem Schutzniveau · 2026-01
5. Microsoft EU Data Boundary – Documentation for EU/EFTA customers · 2026-03
6. OpenAI – Swiss-U.S. DPF certification (dataprivacyframework.gov) · 2025-03