Drittlandtransfer und Transfer Impact Assessment (TIA): CH-Daten in US- und PRC-Cloud-LLMs

Was regelt der Drittlandtransfer im revDSG?

Das revidierte Datenschutzgesetz (revDSG) regelt in den Artikeln 16 bis 18 die Bekanntgabe personenbezogener Daten ins Ausland. Drittland im Sinne des Gesetzes ist jedes Land ausserhalb der Schweiz, das nicht durch eine Verordnung des Bundesrats als angemessenes Schutzniveau anerkannt ist. Die Liste der anerkannten Staaten ist in Anhang 1 der DSV geführt und umfasst per Mai 2026 die EU/EWR-Staaten, Grossbritannien, Kanada (kommerzieller Teilbereich), Israel, Argentinien, Uruguay, Neuseeland, Japan, Suedkorea und die USA (unter Vorbehalt des Data Privacy Frameworks, siehe unten).

Ist das Drittland NICHT auf der Liste, greift Art. 16 Abs. 2 revDSG: Die Bekanntgabe ist nur zulässig, wenn geeignete Garantien einen angemessenen Schutz im Einzelfall sicherstellen. Als geeignete Garantien gelten: völkerrechtlicher Vertrag, Standarddatenschutzklauseln (SCC), spezifische Vertragsklauseln, verbindliche unternehmensinterne Datenschutzvorschriften (BCR, vom EDÖB genehmigt), oder ein Verhaltenskodex / Zertifikat. Fehlen geeignete Garantien, kommt Art. 17 revDSG mit Ausnahmegründen ins Spiel: ausdrückliche Einwilligung der betroffenen Person, Vertragsdurchführung, überwiegende öffentliche Interessen, Schutz von Leib und Leben, öffentlich zugängliche Daten.

Für KI-Nutzung relevant: Jede Prompt-Übermittlung an einen US- oder PRC-Anbieter, die personenbezogene Daten enthält, ist eine Bekanntgabe iSv Art. 16 revDSG. Die Frage ist nie, OB es ein Transfer ist – die Frage ist, mit welcher Garantie er gestützt wird und ob die Garantie im Einzelfall ausreicht. Diese Prüfung heisst Transfer Impact Assessment.

Warum das TIA bei Cloud-LLMs zentral ist

Die Schweiz hat im Juli 2024 die Schweiz-USA-Erweiterung des EU-US Data Privacy Framework (DPF) anerkannt, mit Wirkung ab dem 15. September 2024. Seitdem gelten US-Unternehmen, die sich beim US-Handelsministerium für das Swiss-U.S. DPF zertifizieren, als Empfänger mit angemessenem Schutzniveau im Sinne von Art. 16 Abs. 1 revDSG. Microsoft, Google und Anthropic sind zertifiziert; OpenAI hat seine Zertifizierung im März 2025 abgeschlossen.

Das DPF reicht aber nicht in allen Fällen. Erstens deckt es nur Daten, die unter den zertifizierten Geltungsbereich fallen – die Liste der Datentypen wird vom Empfänger selbst deklariert und kann eng ausfallen. Zweitens hat das Bundesgericht in der Lehre (Vischer, Walder Wyss, Homburger) noch nicht abschliessend entschieden, ob das DPF die anhaltende Massenüberwachung durch US-Geheimdienste nach Section 702 FISA und Executive Order 12333 ausreichend einschränkt. Drittens ist das DPF ein bilateraler Mechanismus; bei PRC-Anbietern (Alibaba Tongyi, Baidu Ernie, DeepSeek-Cloud) greift es nicht.

Deshalb empfiehlt der EDÖB seit September 2023 mit seinem TIA-Leitfaden, jeden Drittlandtransfer in einem nachvollziehbaren Verfahren zu bewerten – auch wenn das Zielland auf der Adäquanz-Liste steht. Das TIA-Modul ist ein strukturierter Fragenkatalog, der in einer formalen Dokumentation muendet und im EDÖB-Verfahren als Prüfnachweis dient.

Wie ein TIA für einen Cloud-LLM aufgebaut wird

Das EDÖB-TIA-Modul ist in vier Blöcke gegliedert.

Block 1 – Transferbeschreibung: Wer ist Verantwortlicher, wer Empfänger? Welche Datenkategorien? Welche Zwecke? Welche Speicherdauer? Beispiel OpenAI: Verantwortlicher Schweizer KMU-Treuhänder, Empfänger OpenAI Ireland Ltd (als Vertragspartner) mit Sub-Processing durch OpenAI OpCo LLC (USA), Datenkategorien pseudonymisierte Mandantendaten und Buchhaltungsfragen, Zweck Antwortgenerierung, Speicherung Zero Data Retention.

Block 2 – Rechtsraum-Analyse: Welche Gesetze im Zielland erlauben Zugriffe durch Behörden? Für die USA: FISA Section 702 (Massenüberwachung Ausländer), Executive Order 12333 (Auslandsaufklärung), CLOUD Act (extraterritoriale Datenherausgabe), Stored Communications Act. Für die PRC: Cybersecurity Law 2017, Data Security Law 2021, Personal Information Protection Law 2021, National Intelligence Law Article 7 (Verpflichtung zur Mitarbeit mit Geheimdiensten). Der Block dokumentiert die juristische Tragweite.

Block 3 – Risikoanalyse im Einzelfall: Wie wahrscheinlich ist ein behördlicher Zugriff auf die konkreten Daten? Faktoren: politische Sensibilität der Daten, prominente Personen, branchen-spezifische Aufklärungsinteressen (z.B. Halbleiter, Pharma, Verteidigung). Bei einem Schweizer Treuhand-Büro, das KI für routinemässige Bilanz-Plausibilisierung einsetzt, ist das Risiko gering; bei einer Anwaltskanzlei mit US-sanktioniertem Mandanten oder bei einer Pharma-Firma mit Wirkstoff-Daten ist es real.

Block 4 – Ergänzende Massnahmen: Wenn die Risikoanalyse Restrisiken zeigt, werden technische und organisatorische Schutzmassnahmen eingefügt: Pseudonymisierung, Verschlüsselung at-rest und in-transit (TLS 1.3 als Minimum), Zero Data Retention, EU-Hosting des Inferenz-Endpoints (Azure OpenAI EU, Anthropic via AWS Frankfurt, Google EU Data Boundary), strenge Sub-Processor-Listen, Vertrags-Klauseln zur Information bei Behördenanfragen.

TIA-Workflow in 6 Schritten

1. 01Transfer-Inventar erstellen: Welche Daten gehen an welchen Empfänger, in welches Land, mit welcher Rechtsgrundlage?
2. 02Adäquanz-Check: Ist das Zielland gelistet (DSV Anhang 1)? Wenn ja, ist der Empfänger DPF-zertifiziert? Wenn nein, welche Garantie nach Art. 16 Abs. 2 revDSG?
3. 03Rechtsraum-Analyse: Welche Zugriffsbefugnisse der Behörden im Zielland? FISA 702, CLOUD Act, EO 12333 für USA; PIPL + NIL Art. 7 für PRC.
4. 04Einzelfall-Risikobewertung: Datenkategorien, betroffene Personen, sektorales Aufklärungsinteresse, Risiko-Wahrscheinlichkeit, Schadensausmass.
5. 05Ergänzende Massnahmen: Verschlüsselung, Pseudonymisierung, EU-Hosting des Inferenz-Endpoints, ZDR, Vertrags-Notification-Klauseln.
6. 06Dokumentation und Review: EDÖB-Modul ausfüllen, in Compliance-Akte ablegen, jährliche Prüfung und bei jeder wesentlichen Änderung.

Wann ein TIA nötig ist

Pflicht: Vor jeder erstmaligen Bekanntgabe personenbezogener Daten an einen Empfänger ausserhalb der CH/EU/EWR-Adäquanz-Zone, oder bei DPF-Zertifizierung ausserhalb des deklarierten Geltungsbereichs. Auch wenn das Zielland gelistet ist, empfiehlt der EDÖB ein vereinfachtes TIA als Routinedokumentation.

Konkret für KI-Einsatz in Schweizer KMU: TIA für OpenAI, Anthropic, Google, Microsoft Azure OpenAI bei der Erstimplementierung. TIA für Cohere (Kanada – adäquat, aber TIA empfohlen). TIA mit erhöhten Anforderungen bei DeepSeek-API (PRC, kein DPF), Baidu, Alibaba. KEIN TIA nötig bei Mistral SaaS in der EU, bei Aleph Alpha auf CH-Hosting, oder bei lokalen Llama/Qwen-Deployments.

Wiederholung: Das TIA muss bei wesentlicher Änderung neu durchgeführt werden – Anbieterwechsel, neue Datenkategorien, Änderung des Hosting-Standorts, neues Schlüsselgesetz im Zielland. Eine jährliche Routine-Prüfung ist üblich. Das Dokument bleibt in der Compliance-Akte und ist auf Verlangen des EDÖB vorzulegen.

Besondere Vorsicht bei besonders schützenswerten Personendaten nach Art. 5 lit. c revDSG (Gesundheit, religiöse Überzeugungen, Strafverfolgung, biometrische Daten) und bei Daten unter Berufsgeheimnis (Art. 321 StGB). Hier sind die Anforderungen an die Garantie und an die ergänzenden Massnahmen deutlich strenger; im Zweifel keine Drittland-Bekanntgabe.

Wann ein klassisches TIA nicht greift

Ein TIA ist kein Allheilmittel. Drei Konstellationen, in denen TIA-Dokumentation nicht ausreicht und andere Pfade nötig sind:

Berufsgeheimnis-Fälle: Bei StGB-Art-321-Daten (Anwalt, Notar, Arzt) reicht ein TIA mit positiver Risikobewertung allein NICHT, um die strafrechtliche Geheimhaltungspflicht zu erfüllen. Hier sind zusätzlich Mandanten-Einwilligung oder echte Anonymisierung oder lokales Hosting nötig. Siehe Berufsgeheimnis StGB 321.

Politisch hochsensible Mandate: Wenn die Datenkategorien zu Branchen gehören, die im Zielland aktiv aufgeklärt werden (US-FISA-Listings: Halbleiter, Quantum, Biotech, Verteidigung; PRC-Aufklärungs-Interesse: Pharmazie, Halbleiter, Maschinenbau), ist das Restrisiko mit Standardmassnahmen nicht beherrschbar. EU-Hosting oder lokaler Betrieb sind die einzige saubere Lösung.

Massentransfer mit Personenbezug: Wenn ein Prozess Millionen personenbezogener Datensätze pro Jahr überführt (z.B. KI-gestützte CRM-Analyse mit allen Kundendaten), wird die TIA-Prüfung selbst zur Aufgabe. EDÖB-Aufmerksamkeit ist hoch. BCR statt SCC, plus EU-Hosting, sind angeraten.

Kein TIA nötig: Bei vollständiger Anonymisierung im Sinne von Art. 5 lit. a revDSG (irreversibler Personenbezugsverlust). Wer einen Datensatz mathematisch anonymisiert (k-Anonymität >= 5, differential privacy), kann ihn ohne TIA versenden. Vorsicht: Pseudonymisierung allein ist KEINE Anonymisierung im Rechtssinn.

Vor- und Nachteile

Häufige Fragen

Verwandte Themen

Quellen

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