Die Schweizer Frage

Eine Frage, die öfter kommt, als man denkt — und eine Antwort, die überrascht

Sie kommt fast reflexartig, sobald das Wort „Datenresidenz" in einem Gespräch fällt, das nicht mit einem Schweizer Unternehmen geführt wird: „Warum sollte uns das betreffen, wir sitzen doch in Deutschland?" Die Antwort ist überraschender, als die Frage vermuten lässt — und genau deshalb lohnt es sich, sie ausführlich zu geben.

Für Kunden mit Sitz in der Schweiz ist Datenresidenz bei JiCo keine Option unter mehreren, die man in den Einstellungen anwählen oder abwählen kann, sondern eine feste, nicht verhandelbare Anforderung. Alle dauerhaften Datenbestände — der Audit-Trail, die interne Warteschlange für Aufträge, das verschlüsselte Mapping, jeder Cache, jedes Protokoll — bleiben in der Infrastruktur des Kunden. Kommt überhaupt ein Cloud-Modell zum Einsatz, ist das nur über eine fest auf die Schweiz gepinnte Region zulässig, mit ausdrücklich abgeschalteter regionsübergreifender Verteilung der Anfragen. Lässt sich für einen bestimmten Weg die Residenz nicht zweifelsfrei belegen, bleibt es automatisch beim lokalen Modell — nicht als Verlegenheitslösung, sondern als bewusst gewählte Vorgabe für genau diesen Zweifelsfall.

Der einfache Teil — und der eigentlich schwierige

Der naheliegende Teil dieser Anforderung ist tatsächlich einfach zu erfüllen: Ein lokales Modell und eine lokale Datenablage erfüllen die Anforderung praktisch von selbst, ohne dass man dafür etwas Besonderes bauen müsste — die Daten verlassen die Maschine schlicht nie, weil es dafür keinen technischen Grund gibt.

Die eigentliche Arbeit steckt in dem, was man auf den ersten Blick nicht sieht — im Beiwerk, das niemand als „die Datenverarbeitung" bezeichnen würde und das trotzdem genau dort ansetzt: ein automatischer Update-Check, der beim Programmstart kurz nach Hause telefoniert. Ein Absturzbericht, der irgendwo landet, ohne dass jemand bewusst „senden" geklickt hätte. Ein Telemetrie-Endpunkt für Betriebsdaten, der zufällig nicht in der Schweiz liegt, weil ihn niemand explizit dorthin konfiguriert hat. Keine dieser Stellen verändert auch nur ein einziges Bit einer tatsächlichen Personendatei — und trotzdem wäre die Residenz gebrochen, sollte auch nur eine davon unbemerkt aktiv bleiben. Genau deshalb bleiben Telemetrie und vergleichbare Nebenkanäle bei JiCo im Ruhezustand, solange niemand explizit einen Endpunkt dafür konfiguriert — ein Vorteil an dieser Stelle, kein technisches Versäumnis.

Die Kiste, die die Frage architektonisch statt vertraglich beantwortet

Für Kunden, die diese Frage nicht über eine Konfigurationseinstellung, sondern über die Architektur selbst beantworten wollen — weil eine Einstellung sich ändern lässt, eine physische Anordnung aber nicht so leicht —, gibt es eine bevorzugte Ausprägung: eine eigene Appliance auf Apple-Silicon-Hardware direkt beim Kunden, mit Ollama nativ auf dem Host-Betriebssystem und den übrigen Bausteinen containerisiert daneben.

Dieser konkrete Zuschnitt ist eine technische Notwendigkeit, kein symbolischer Wunsch nach eigener Hardware: Ein containerisiertes Sprachmodell verliert unter macOS den direkten Zugriff auf die Grafikeinheit und fällt dadurch auf die deutlich langsamere CPU-Berechnung zurück — real gemessen drei- bis sechsmal langsamer als mit direktem Hardwarezugriff. Für einen einzelnen interaktiven Chat mag das noch tolerierbar sein. Für einen nächtlichen Auftragslauf über hunderte Tickets würde es das gesamte Zeitfenster sprengen, in dem eine Freigabe-Mappe bis zum nächsten Morgen fertig sein muss.

Der angenehme Nebeneffekt dieser Lösung: Eine physische Kiste im eigenen Rechenzentrum braucht weder einen Cloud-Vertrag noch eine fortlaufende Prüfung, ob die regionsübergreifende Verteilung wirklich abgeschaltet bleibt. Die Anforderung ist erfüllt, weil es schlicht keinen Weg nach draußen gibt, der überhaupt geprüft werden müsste — nicht weil eine Konfiguration es verspricht, sondern weil die Hardware es baulich unmöglich macht.

Zwei Wege, dieselbe Region, unterschiedliche Fallstricke

Selbst wenn ein Cloud-Modell im Einzelfall bewusst gewählt wird, endet die Prüfung nicht mit der Wahl der richtigen Region. Zwei große Anbieter stellen Zugriff auf ein bekanntes Cloud-Modell über eine Schweizer Region an — einmal über die eine, einmal über die andere große Cloud-Infrastruktur, beide mit einem Rechenzentrum in Zürich. Beide Wege gelten nur dann als residenzkonform, wenn die Anfrage tatsächlich auf dieser einen Region gepinnt bleibt.

Der Fallstrick dabei ist eine Funktion, die eigentlich Ausfallsicherheit verbessern soll: eine regionsübergreifende Verteilung von Anfragen, die bei hoher Auslastung automatisch auf eine andere, unter Umständen weit entfernte Region ausweicht. Genau diese Funktion muss für Schweizer Kunden ausdrücklich abgeschaltet sein oder ihr Wirkungsbereich nachweislich auf die Schweiz beschränkt bleiben — sonst würde eine Funktion, die für mehr Zuverlässigkeit sorgen soll, im Hintergrund still genau die Zusage brechen, die man gerade erst gegeben hat.

Warum diese Antwort auch außerhalb der Schweiz relevant ist

Der Mechanismus, der ursprünglich für die Schweiz entwickelt wurde, ist im Kern derselbe, den ein deutsches Unternehmen für seine Auftragsverarbeitung nach der DSGVO braucht, oder ein österreichisches für Fragen des Amtsgeheimnisses in bestimmten Branchen: ein nachweisbarer, konkret benennbarer Ort der tatsächlichen Verarbeitung — und im Zweifelsfall eine Entscheidung, die konsequent zugunsten der Zurückhaltung ausfällt, statt zugunsten der bequemeren Option.

Wer diese Frage überhaupt stellt — egal aus welchem der drei DACH-Länder —, fragt in aller Regel nicht nur nach einem einzelnen, konkret benannten Gesetz. Er fragt nach einer grundsätzlichen Haltung zur Kontrolle über die eigenen Daten, und die lässt sich an dieser einen Antwort meistens schon recht zuverlässig ablesen.