Claude Datenresidenz: Was Geo-Pinning wirklich bringt

Ein neuer Schalter in der Claude-API-Konsole verspricht Kontrolle darüber, wo eine KI-Anfrage verarbeitet wird. Für IT-Verantwortliche, die schon länger mit dem Argument "die Daten gehen in die USA" kämpfen, klingt das nach einer Lösung. Ist es aber nur zur Hälfte.

Anthropic hat im August 2026 Datenresidenz-Kontrollen für die Claude API eingeführt: einen Parameter namens inference_geo, mit dem sich steuern lässt, in welcher Region die Modell-Inferenz läuft. Wer die Ankündigung liest, denkt schnell an eine EU- oder Schweiz-Option. Genau die gibt es aber (noch) nicht. Was die Funktion tatsächlich bietet, wofür sie taugt – und warum sie ein rechtliches Problem nicht löst, das viele Betriebe ohnehin schon lösen müssten: darum geht es in diesem Beitrag.

Was inference_geo technisch macht

Der neue Parameter lässt sich auf zwei Ebenen setzen: pro einzelnem API-Aufruf oder als Standardwert für einen ganzen Workspace. Zur Auswahl stehen laut Anthropics Dokumentation genau zwei Werte:

• global (Standard): Die Inferenz kann in jeder verfügbaren Region laufen – optimiert auf Geschwindigkeit und Verfügbarkeit.
• us: Die Inferenz läuft ausschliesslich auf US-Infrastruktur.

Das war's. Keine dritte Option für Europa, keine für die Schweiz. Wer aus einer Ankündigung über "Datenresidenz-Kontrollen" auf ein EU-Rechenzentrum schliesst, liegt damit daneben.

Zusätzlich unterscheidet Anthropic zwischen der Inferenz-Geo (wo die Modellberechnung läuft) und der Workspace-Geo (wo Daten dauerhaft gespeichert und bestimmte Verarbeitungsschritte wie Bildkonvertierung oder Code-Ausführung stattfinden). Bei der Workspace-Geo ist aktuell ebenfalls nur "us" verfügbar – sie lässt sich zudem nur bei der Erstellung eines Workspace festlegen, nicht nachträglich ändern.

Für Claude Managed Agents kommt eine dritte Ebene dazu: Das Geo-Pinning lässt sich direkt in der Agent-Konfiguration oder pro Sitzung überschreiben. Ein Agent ohne explizite Einstellung folgt dem Standardwert des Workspace.

Wer sich für "us" entscheidet, zahlt dafür: Bei Claude 4.6 und neueren Modellen kostet US-only-Inferenz das 1,1-Fache des Standardtarifs – über sämtliche Token-Kategorien hinweg, also Input, Output sowie Cache-Schreiben und -Lesen. Bei älteren Modellen (Claude Opus 4.5, Sonnet 4.5, Haiku 4.5 und früher) ist der Parameter gar nicht nutzbar; ein API-Aufruf mit inference_geo scheitert dort mit einem Fehler.

Für Organisationen mit eigener IT-Governance gibt es zwei weitere Stellschrauben auf Workspace-Ebene: allowed_inference_geos schränkt ein, welche Geo-Werte innerhalb eines Workspace überhaupt zulässig sind – eine Anfrage ausserhalb dieser Liste wird von der API mit einem Fehler abgelehnt. default_inference_geo legt fest, welcher Wert gilt, wenn eine einzelne Anfrage inference_geo gar nicht mitgibt. Beide Einstellungen lassen sich über die Konsole oder die Admin-API konfigurieren – nützlich, wenn eine einheitliche Regel für alle API-Schlüssel eines Teams gelten soll, statt sich auf die Disziplin einzelner Entwickler zu verlassen.

Wer schon vor der Einführung dieser Funktion aus Datenschutzgründen ein sogenanntes "Global-Routing-Opt-out" bei Anthropic beantragt hatte, wurde automatisch migriert: Der Workspace erhielt allowed_inference_geos: ["us"] und default_inference_geo: "us" als neue Entsprechung des alten Opt-outs. Bestehende Anfragen liefen dadurch ohne Codeänderung weiter ausschliesslich über US-Infrastruktur. Wer stattdessen künftig von globalem Routing profitieren möchte – etwa wegen besserer Verfügbarkeit –, muss die Workspace-Einstellungen aktiv anpassen.

Warum "Geo-Pinning" kein Datenschutz-Häkchen ist

Der Denkfehler, dem viele unterliegen, ist naheliegend: "Wenn ich die Inferenz auf eine Region festlege, ist das Datenschutzproblem gelöst." Rechtlich betrachtet stimmt das nicht – aus zwei Gründen.

Erstens: inference_geo steuert nur den technischen Ort der Berechnung. Ob dort überhaupt Personendaten anfallen, wie lange sie zwischengespeichert werden und wer im Ereignisfall Zugriff hat, regelt der Parameter nicht.

Zweitens, und wichtiger: Rechtlich massgeblich ist nach Art. 16 des revidierten Datenschutzgesetzes (revDSG) nicht, wo ein Server physisch steht, sondern an welchen Anbieter Personendaten bekanntgegeben werden – und ob dessen Sitzstaat ein angemessenes Datenschutzniveau bietet. Der Bundesrat führt dazu eine Staatenliste. Die USA stehen weiterhin nicht darauf.

Das heisst konkret: Ein US-amerikanischer Anbieter wie Anthropic zählt datenschutzrechtlich als Übermittlung in ein Land ohne anerkannt angemessenes Schutzniveau – unabhängig davon, ob die Inferenz technisch in den USA oder "global" läuft. Wer inference_geo: "us" setzt, verlagert lediglich die Serverstandort-Wahrscheinlichkeit, ändert aber nichts an der rechtlichen Einordnung des Anbieters.

Um eine solche Übermittlung dennoch zulässig zu machen, verlangt Art. 16 zusätzliche Garantien. In der Praxis sind das fast immer Standardvertragsklauseln (SCC) – vertragliche Zusicherungen, die ein angemessenes Schutzniveau vertraglich herstellen. Der EDÖB hat dazu seinen Leitfaden zur Datenübermittlung ins Ausland aktualisiert und die revidierten EU-Standardvertragsklauseln sowie die Musterklauseln des Europarats für die Verwendung unter dem revDSG anerkannt. Ohne solche Garantien – oder eine andere der in Art. 16 Abs. 2 genannten Grundlagen, etwa ein Staatsvertrag oder vom EDÖB vorab genehmigte Datenschutzklauseln – ist eine Übermittlung von Personendaten an einen US-Anbieter grundsätzlich nicht zulässig.

Für die betroffene Meldepflicht ist ein Detail praktisch relevant: Solange die verwendeten SCC vom EDÖB anerkannt sind, entfällt die sonst nötige vorgängige Meldung an die Aufsichtsbehörde. Wer prüfen will, ob eine bestehende Klausel-Version noch aktuell ist, findet die anerkannten Fassungen in der EDÖB-Publikation zur Auslandsbekanntgabe.

Zwei Betriebe, zwei unterschiedliche Antworten

Ein Vergleich macht den Unterschied greifbar. Ein Treuhandbüro nutzt Claude für interne Textarbeit – Protokollentwürfe, allgemeine Recherchefragen, keine Mandantendaten im Prompt. Hier ist das Risiko überschaubar: Es fliessen keine oder kaum Personendaten an den Anbieter, inference_geo kann auf "global" bleiben, und die Standard-SCC im Anthropic-Vertragswerk decken die verbleibende Übermittlung ab.

Ein Callcenter-Dienstleister dagegen lässt einen KI-Agenten Kundenanfragen inklusive Namen, Vertragsnummern und teils Gesundheitsangaben zusammenfassen. Hier reicht ein Blick ins Vertragswerk nicht mehr: Es braucht eine dokumentierte Risikoeinschätzung, klare Regeln, welche Datenfelder überhaupt in den Prompt gelangen dürfen, und im Zweifel eine formelle Datenschutz-Folgenabschätzung. inference_geo: "us" kann hier sinnvoll sein, um gegenüber Kunden eine präzisere Aussage zum Verarbeitungsort zu machen – ersetzt aber auch in diesem Fall keine der genannten Massnahmen.

Was das für den KI-Einsatz im eigenen Betrieb bedeutet

Die gute Nachricht zuerst: Für die meisten Betriebe, die Claude über offizielle, vertraglich abgesicherte Kanäle nutzen, ändert sich durch diese Erkenntnis wenig an der Grundlage – vorausgesetzt, die nötigen Garantien bestehen bereits. Drei Punkte lohnen sich trotzdem zu prüfen:

Auftragsverarbeitungsvertrag (AVV) und SCC kontrollieren. Wer Claude direkt über die API, über ein Drittanbieter-Tool oder über eine Cloud-Plattform nutzt, sollte im Vertragswerk nachsehen, ob Standardvertragsklauseln oder eine gleichwertige Garantie hinterlegt sind. Bei seriösen Anbietern ist das Teil der Vertragsunterlagen – ein kurzer Blick oder eine Nachfrage beim Anbieter schafft Klarheit.

Sensible Daten identifizieren. Nicht jede KI-Anwendung verarbeitet gleich riskante Daten. Eine interne Textzusammenfassung ohne Personenbezug ist datenschutzrechtlich unkritischer als ein KI-Agent, der Kundendossiers, Gesundheitsdaten oder Bonitätsinformationen verarbeitet. Für Letzteres lohnt sich eine kurze Datenschutz-Folgenabschätzung (DSFA), bevor der Rollout beginnt.

Geo-Pinning gezielt einsetzen, wo es hilft. Auch wenn inference_geo: "us" keine EU-Option ersetzt, kann die Einstellung sinnvoll sein – etwa um Latenzschwankungen durch globales Routing zu vermeiden oder um vertragliche Zusagen gegenüber eigenen Kunden präziser zu formulieren ("Inferenz läuft ausschliesslich auf US-Infrastruktur" ist eine klarere Aussage als "irgendwo global"). Als alleinige Compliance-Massnahme reicht es nicht.

Wenn echte EU- oder Schweiz-Residenz nötig ist

Für Betriebe mit strengeren Anforderungen – etwa Branchen mit besonders schützenswerten Personendaten oder vertraglichen Zusagen an eigene Kunden – reicht die direkte Claude-API-Lösung aktuell nicht aus. Zwei Wege führen dann weiter: Claude über Amazon Bedrock in einer europäischen Region wie der AWS-Region Zürich, oder eine self-hosted Betriebsumgebung mit entsprechender Infrastrukturkontrolle. Beide Ansätze sind aufwendiger als ein API-Parameter, bieten dafür aber eine belastbarere Antwort auf die Frage "Wo genau liegen die eigenen Daten?". Mehr dazu im Beitrag zu Claude Code Self-Hosted.

Fazit: Ein nützliches Werkzeug, kein Freipass

Anthropics Geo-Pinning ist ein sinnvoller Baustein für mehr Transparenz und Kontrolle – aber kein Ersatz für die eigentliche rechtliche Arbeit. Wer Personendaten an Claude oder einen anderen US-Anbieter übermittelt, braucht weiterhin Standardvertragsklauseln oder eine gleichwertige Garantie nach Art. 16 revDSG, unabhängig davon, welchen Wert inference_geo trägt. Die eigentliche Frage lautet nicht "Wo läuft die Inferenz?", sondern "Welche Garantien bestehen für die Datenübermittlung – und sind sie dokumentiert?"

Wer die eigene KI-Nutzung datenschutzrechtlich sauber aufstellen möchte – von der Vertragsprüfung bis zur technischen Umsetzung –, findet bei KI-Integration von Hedinger-Digital eine praxisnahe Einordnung. Für ein unverbindliches Gespräch: Jetzt Kontakt aufnehmen.