Was Datenhoheit konkret heisst und wo deine Prompts wirklich landen

Was Datenhoheit konkret heisst

Ein Versicherer wollte einen Support-Bot bauen. Schweizer Firma, Schweizer Kunden, alles brav. Im ersten Workshop fiel der Satz, den wir fast immer hören: „Die Daten bleiben ja in der Schweiz.“ Wir fragten zurück, was genau in den Prompts stehen würde. Kundennamen, Policennummern, gelegentlich eine Diagnose. Und der geplante Dienst? Ein „Schweizer“ Anbieter mit hübscher Zürcher Domain, der intern jeden Request an eine US-API weiterreichte. In dem Moment war die Schweiz-Garantie schon weg, bevor die erste Antwort zurückgelaufen war. Genau hier beginnt das Thema: Datenhoheit ist kein Häkchen auf einer Landingpage und kein Serverstandort allein, sondern eine Kette aus drei Fragen, die unabhängig voneinander beantwortet werden müssen.

Drei Ebenen, die ständig verwechselt werden

Wer „Datenhoheit“ sagt, meint fast immer nur eine Ebene und lässt die anderen offen. Die erste ist der Standort der Verarbeitung: In welchem Rechenzentrum, in welchem Land läuft die GPU, die deinen Request rechnet? Das ist real wichtig, etwa für Latenz und für die simple Frage, wessen Polizei theoretisch vor dem Rack stehen könnte. Aber der Standort allein ist schwach. Eine Maschine in Zürich, die von einem US-Mutterkonzern administriert wird, steht physisch in der Schweiz und ist rechtlich trotzdem angreifbar. Standort beantwortet „wo liegen die Bits“, nicht „wer kommt rechtlich dran“.

Die zweite und entscheidende Ebene ist der rechtliche Zugriff: Welchem Recht untersteht der Vertragspartner, und wer kann ihn zwingen? Das hängt nicht am Serverstandort, sondern an der Eigentümer- und Kontrollkette. Ein Schweizer Server, betrieben von der Tochter eines US-Konzerns, fällt unter den Zugriff, den US-Recht auf den Konzern hat. Diese Ebene ist unsichtbar, wenn du nur auf die Flagge im Footer schaust, und sie ist die, die im Ernstfall zählt.

Die dritte Ebene betrifft den Verbleib der Daten, also die Zeit nach dem Request. Werden Prompt und Antwort geloggt, und wenn ja, wie lange? Fliessen sie in Training? Werden sie an Sub-Prozessoren weitergereicht? Ein Anbieter kann in der Schweiz sitzen, korrekt betrieben sein und deine Eingaben trotzdem 90 Tage vorhalten oder zur „Qualitätsverbesserung“ auswerten. Datenhoheit ohne geklärte Retention ist nur die halbe Antwort.

Was das Schweizer Recht tatsächlich verlangt

Seit dem revidierten Datenschutzgesetz (revDSG, in Kraft seit 1. September 2023) sind die Pflichten konkreter, als die meisten annehmen. Sobald ein Dienstleister Personendaten in deinem Auftrag verarbeitet, ist er Auftragsbearbeiter im Sinne von Art. 9 revDSG. Das ist kein Papierkram am Rande: Du bleibst verantwortlich, musst die Bearbeitung vertraglich regeln und sicherstellen, dass der Bearbeiter dieselbe Datensicherheit garantiert, die du schuldest. Ein LLM-Anbieter, der Kundendaten in deinen Prompts sieht, ist damit dein Auftragsbearbeiter, und du brauchst einen Auftragsbearbeitungsvertrag (AVV/DPA), der das festhält. Fehlt der, verarbeitest du formal rechtswidrig, ganz unabhängig davon, wie gut die Technik ist.

Verlassen Personendaten die Schweiz, greift zusätzlich Art. 16 f. revDSG. Bekanntgabe ist nur zulässig, wenn der Zielstaat einen angemessenen Schutz bietet; der Bundesrat führt dazu eine Länderliste (Anhang 1 DSV). Die USA stehen dort nicht pauschal, sondern nur für Unternehmen, die unter dem Swiss-U.S. Data Privacy Framework zertifiziert sind. Ist der Zielstaat nicht angemessen, brauchst du eine eigene Garantie wie Standardvertragsklauseln und musst zusätzlich prüfen, ob das dortige Recht diese Garantie nicht aushebelt. Genau das ist die Logik aus dem Schrems-II-Urteil: Ein Vertrag nützt nichts, wenn eine ausländische Behörde ihn per Gesetz überschreiben kann. Zwischen der Schweiz und dem EWR ist die Lage zwar entspannt, weil man sich gegenseitig als angemessen anerkennt, aber „in der EU gehostet“ heisst eben nicht „dem US-Zugriff entzogen“. Entscheidend bleibt die Kontrollkette des Betreibers, nicht der Breitengrad des Servers.

Der CLOUD Act, konkret durchgespielt

Der US CLOUD Act von 2018 verpflichtet US-Anbieter, Daten herauszugeben, die in ihrem „possession, custody, or control“ stehen, unabhängig vom Speicherort. Das Wort „control“ ist der Hebel, und an drei Fällen wird greifbar, was es anrichtet.

Nimm zuerst den Anbieter, der mit „Rechenzentrum in der Schweiz, Schweizer GmbH“ wirbt, dessen Muttergesellschaft aber in den USA sitzt. Kann die US-Mutter auf die Systeme der Tochter zugreifen oder sie anweisen, dann gelten die Daten als unter ihrer Kontrolle, und eine US-Anordnung kann sie erfassen, obwohl die Bits Zürich nie verlassen haben. Der Serverstandort ist in diesem Fall rechtlich fast irrelevant, weshalb die vollständige Eigentümerkette zur ersten Frage gehört, nicht zur letzten. Dann der „Schweizer“ Proxy aus der Eingangsszene: ein Dienst mit Schweizer Domain und Schweizer Rechnung, der intern jeden Request an OpenAI, Anthropic oder einen anderen US-Anbieter weiterreicht. Hier verlässt dein Prompt die Schweiz beim ersten Token, und die hübsche Frontend-Herkunft ändert daran nichts. Das ist der Unterschied zwischen souveräner Inferenz auf eigenen, offenen Modellen wie bei Managed Inference und einer Fassade vor einer fremden API.

Der dritte Fall ist der, den man am leichtesten übersieht, und er kam in jenem Workshop auf den Tisch: der Support-Chat, in dessen Prompts Kundennamen, Vertragsnummern oder Gesundheitsangaben stehen. Sobald das passiert, ist jeder einzelne LLM-Aufruf eine Bearbeitung von Personendaten, oft sogar von besonders schützenswerten. Es fühlt sich an wie „nur ein API-Call“, ist rechtlich aber dasselbe wie das Versenden einer Kundendatei. Wer das nicht einordnet, baut sich unbemerkt eine unzulässige Auslandbekanntgabe ein.

Branchen, in denen es kein „bequem“ gibt

Für regulierte Branchen ist Datenhoheit selten Komfort, sondern Vorbedingung. Das Bankkundengeheimnis nach Art. 47 BankG ist strafbewehrt, und das FINMA-Rundschreiben 2018/3 zum Outsourcing verlangt, dass eine Auslagerung kontrollierbar bleibt und die Aufsicht jederzeit Zugriff hat. Ein LLM, das Kundendaten an eine intransparente US-API gibt, ist in diesem Rahmen kaum haltbar; nachweisbare Verarbeitung innerhalb der Schweiz ist hier oft nicht Kür, sondern die einzige gangbare Option.

Ähnlich, aber mit noch schärferer persönlicher Konsequenz, liegt es bei den klassischen Geheimnisträgern. Das Berufsgeheimnis nach Art. 321 StGB bindet Anwälte, Ärzte und ihre Hilfspersonen, das Amtsgeheimnis nach Art. 320 StGB bindet die Verwaltung. Beides sind Straftatbestände, keine blossen Compliance-Empfehlungen. Gibt eine Kanzlei Mandatsdaten in ein Modell, dessen Betreiber sie nicht kontrolliert, riskiert sie eine Geheimnisverletzung. Für diese Berufe ist die Architektur des Anbieters damit eine Frage der eigenen Strafbarkeit, nicht der Datenhygiene.

Die Fragen, die du jedem Anbieter stellen solltest

Recht und Technik müssen sich am Ende decken, sonst ist der Vertrag Theater. Im Hintergrund klärst du dafür ein paar technische Punkte ab: die Eigentümerkette bis nach oben, die Liste der Sub-Prozessoren wie Monitoring, Logging, Auth oder CDN, die Logging- und Retention-Regeln, ein verbindliches Nein zu Training auf deinen Daten, die Stelle, an der TLS endet und der Klartext vorliegt, und einen unterschriebenen AVV, der all das festhält. Im Gespräch mit dem Anbieter machst du daraus konkrete Fragen, denn ein sauberer Anbieter antwortet schnell und konkret, während Ausweichen selbst schon ein Befund ist:

• „In welchem Land steht die GPU, und wem gehört das Rechenzentrum?“ Standort und Betreiber können auseinanderfallen; eine Antwort, die nur das Land nennt und den Betreiber verschweigt, ist unvollständig.
• „Wem gehört euer Unternehmen, bis ganz nach oben?“ Das zielt auf den CLOUD Act. Wer hier vage wird oder „das ist vertraulich“ sagt, hat oft eine ausländische Mutter, die er nicht betonen will.
• „Reicht ihr meine Prompts an eine externe API weiter?“ Das hebelt die Schweiz-Garantie sofort aus. Ein Zögern oder ein „teilweise“ bedeutet faktisch ja.
• „Welche Sub-Prozessoren sind beteiligt?“ Dort sitzt die Lücke meist. Wer keine Liste hat, hat den Datenfluss nie sauber dokumentiert.
• „Werden meine Eingaben geloggt, wie lange, und zu welchem Zweck?“ „Nur zur Fehlersuche“ ohne Frist ist eine offene Tür.
• „Werden meine Daten je zum Training verwendet?“ Ein Ja macht den Datenabfluss dauerhaft; die Antwort muss schriftlich und ausnahmslos sein.
• „Bekomme ich einen AVV, der das alles festhält?“ Ohne Vertrag ist keine der mündlichen Zusagen etwas wert. Wer keinen AVV anbietet, ist für regulierte Daten disqualifiziert.

Datenhoheit ist Architektur, kein Label

Die unbequeme Summe aus all dem: Echte Datenhoheit entsteht nicht durch eine Flagge im Footer, sondern durch die Bauweise. Offene Modelle auf gemieteter Hardware in der Schweiz, ohne fremde API dahinter, mit klarer Eigentümerkette, dokumentierten Sub-Prozessoren und vertraglich fixierter Retention. Genau so ist Managed Inference gebaut: die Souveränität als Eigenschaft der Architektur, nicht als Versprechen auf einer Folie. Was eigener Betrieb dieser Art real kostet, rechnen wir in Kosten von selbst betriebenen LLMs durch. Und im Zweifel schauen wir uns deinen konkreten Datenfluss an und sagen dir ehrlich, wo deine Prompts am Ende landen, so wie damals beim Versicherer, dessen Bot am Ende auf souveräner Infrastruktur lief statt auf einer Zürcher Fassade.