In welchem Rechenzentrum rechnet Claude? Verbindung nachverfolgen und Verarbeitung auf Schweiz oder EU beschränken

Wer Claude über claude.ai, Claude Code oder die API nutzt, erfährt nicht, in welchem Rechenzentrum das Modell die Anfrage verarbeitet. Sichtbar ist nur der erste Abschnitt der Verbindung bis zum nächsten Edge-Knoten. Für Unternehmen, die Personendaten oder vertrauliche Inhalte an ein Sprachmodell übergeben, ist das zu wenig: Sie müssen gegenüber Kunden, Datenschutzberatern oder der Revision belegen können, wo die Verarbeitung stattfindet.

Dieser Beitrag zeigt, wie weit sich die Verbindung selbst nachverfolgen lässt, was über Anthropics Rechenzentren öffentlich bekannt ist und über welche Wege sich die Verarbeitung verbindlich auf die EU oder den Raum EU plus Schweiz beschränken lässt. Die Preise und Regionen entsprechen dem Stand vom 2. Oktober 2026.

Schweiz-Fokus: Massgebend ist das revidierte Datenschutzgesetz (revDSG). Eine Bekanntgabe von Personendaten ins Ausland ist nach Art. 16 revDSG zulässig, wenn der Bundesrat dem Zielstaat einen angemessenen Schutz attestiert (Anhang 1 der Datenschutzverordnung, DSV) oder geeignete Garantien wie Standardvertragsklauseln bestehen. Die EU- und EWR-Staaten stehen auf dieser Liste, die USA nur für Unternehmen, die nach dem Swiss-U.S. Data Privacy Framework zertifiziert sind. Ein Verarbeitungsort in der EU vereinfacht die Begründung deshalb erheblich, ersetzt aber nicht die übrigen Pflichten (Auftragsbearbeitungsvertrag, Information der betroffenen Personen, Datensicherheit).

EU-Hinweis: Für Unternehmen mit Sitz in der EU gelten stattdessen die Art. 44 ff. DSGVO. Die EU-Kommission hat der Schweiz ein angemessenes Datenschutzniveau bescheinigt (Angemessenheitsbeschluss 2000/518/EG, im Januar 2024 bestätigt); eine Verarbeitung in Zürich ist für EU-Unternehmen also kein Drittlandtransfer im problematischen Sinn.

Welche Stationen eine Anfrage an Claude durchläuft

Eine Anfrage an claude.ai oder api.anthropic.com läuft über drei Stationen:

Die Hostnamen claude.ai und api.anthropic.com zeigen beide auf die Adresse 160.79.104.10. Sie gehört zum Präfix 160.79.104.0/23, das auf Anthropic registriert ist (AS399358) und laut RPKI gültig von Anthropic stammt. Im globalen Routing wird das Präfix jedoch ausschliesslich über Cloudflare (AS13335) angekündigt: Anthropic bringt seine eigenen IP-Adressen in das Anycast-Netz von Cloudflare ein. Dieselbe Adresse wird dadurch weltweit von jedem Cloudflare-Standort beantwortet, und die Verbindung landet beim nächstgelegenen Edge-Knoten.

Den Edge-Knoten selbst bestimmen

Cloudflare gibt den bedienenden Standort in einer Diagnoseseite und im Header cf-ray preis. Das Kürzel hinter der Ray-ID ist ein IATA-Flughafencode: ZRH steht für Zürich, GVA für Genf, FRA für Frankfurt, MRS für Marseille.

curl -s https://api.anthropic.com/cdn-cgi/trace

Relevant sind in der Ausgabe die Zeilen colo= (Edge-Standort) und loc= (Land, dem Cloudflare Ihre Absenderadresse zuordnet). Unter Windows liefert PowerShell dasselbe:

$trace = Invoke-WebRequest -Uri "https://api.anthropic.com/cdn-cgi/trace" -UseBasicParsing
$trace.Content

Den Header lesen Sie mit einer HEAD-Anfrage aus:

curl -sI https://api.anthropic.com/ \
  | grep -i -E '^(server|cf-ray):'

Optionen erklärt

Option	Wirkung
-s	Unterdrückt Fortschrittsanzeige und Fehlermeldungen von curl
-I	Sendet eine HEAD-Anfrage und gibt nur die Antwort-Header aus
grep -i	Sucht ohne Beachtung der Gross-/Kleinschreibung
-E '^(server|cf-ray):'	Erweiterter regulärer Ausdruck: nur Zeilen, die mit server: oder cf-ray: beginnen

Aus einem Schweizer Netz ist in der Regel ZRH oder GVA zu erwarten. Liegt der Internetausgang an einem anderen Ort, etwa bei einem Firmennetz mit zentralem Ausgang im Ausland, antwortet der Edge-Knoten dort, zum Beispiel mit colo=FRA oder colo=MRS. Der Edge-Standort folgt also Ihrem Netzausgang, nicht dem Ort der Verarbeitung.

Warum der Traceroute am Edge endet

Ein Traceroute zeigt den Weg bis zum Edge-Knoten und nicht weiter:

Test-NetConnection -ComputerName api.anthropic.com -TraceRoute -Hops 20

Optionen erklärt

Option	Wirkung
-ComputerName api.anthropic.com	Zielhost der Messung
-TraceRoute	Ermittelt die Router-Hops auf dem Weg zum Ziel
-Hops 20	Maximale Anzahl Hops, die geprüft werden

Unter Linux und macOS entspricht das traceroute -n api.anthropic.com (-n unterdrückt die DNS-Auflösung der Hops). In der Messung lagen die letzten Hops vor 160.79.104.10 im Adressbereich 162.158.0.0/15, der Cloudflare gehört. Danach endet die Spur: Die Verbindung wird am Edge-Knoten terminiert, die Weiterleitung ins Backend läuft in einer neuen, internen Verbindung, die von aussen nicht sichtbar ist.

Wem das Präfix gehört und über welches Netz es angekündigt wird, zeigt RIPEstat:

curl -s "https://stat.ripe.net/data/prefix-overview/data.json?resource=160.79.104.10"
curl -s "https://stat.ripe.net/data/bgp-state/data.json?resource=160.79.104.0/23"

Im zweiten Ergebnis enden alle AS-Pfade auf 13335 399358: Cloudflare ist der einzige Upstream des Anthropic-Präfixes.

Eine öffentliche Messung, die den Weg bis in ein Inferenz-Rechenzentrum zurückverfolgt, gibt es nach meiner Recherche nicht, und wegen der Terminierung am Edge ist sie mit Netzwerkwerkzeugen auch nicht möglich. Messdienste wie llmlatency.dev erfassen nur die Antwortzeit bis zum ersten Byte am Edge (Stand September 2026: 96 ms Median aus US-Central, 199 ms aus Deutschland). Die Zeit bis zum ersten Token (Time to First Token) liesse sich zwar aus mehreren Standorten vergleichen, sie hängt aber stärker von Modell, Promptlänge und Auslastung ab als von der Distanz. Ein Rückschluss auf einen Standort ist damit nicht belastbar.

Was über Anthropics Rechenzentren bekannt ist

Anthropic betreibt bisher kein eigenes, öffentlich zugeordnetes Inferenz-Rechenzentrum mit Adresse. Die Rechenleistung stammt aus Partnerschaften, die Tim Cadenbach im TCDEV-Blog zusammengetragen hat:

Training und Inferenz finden nicht zwingend am selben Ort statt. Die Inferenz kann in beliebigen AWS- oder Google-Cloud-Regionen laufen, und welcher Standort die Antwort für einen Nutzer in der Schweiz rechnet, legt Anthropic nicht offen. Gesichert ist nur, was die Datenschutzerklärung festhält: Vertragspartner und Verantwortlicher für Kunden aus dem EWR, dem Vereinigten Königreich und der Schweiz ist Anthropic Ireland, Limited in Dublin; die Daten werden auf Server in den USA oder in andere Länder ausserhalb des EWR übermittelt, gestützt auf Standardvertragsklauseln.

Die Steuerung bei Anthropic direkt: nur USA oder global

Die Claude API kennt seit den Modellen der Generation 4.6 den Parameter inference_geo. Er hat genau zwei Werte:

Einen Wert für die EU oder die Schweiz gibt es nicht. Auch der Speicherort des Workspace (workspace geo) lässt sich derzeit nur auf us setzen. Die Antwort meldet im Feld usage.inference_geo, welche Einstellung angewendet wurde, aber keine konkrete Region. Für Haiku 4.5 und ältere Modelle quittiert die API den Parameter mit einem Fehler 400.

Für claude.ai und Claude Code mit einem Abonnement (Pro, Max, Team, Enterprise) gibt es keine Einstellung des Verarbeitungsorts. Über die direkten Anthropic-Angebote lässt sich die Verarbeitung also weder auf die EU noch auf die Schweiz beschränken. Das geht nur über die Cloud-Anbieter, die Claude in ihren eigenen Regionen betreiben.

AWS Bedrock: Raum EU plus Schweiz ab Zürich

AWS Bedrock betreibt Claude auf AWS-Infrastruktur. Anthropic hat laut AWS keinen Zugriff auf Prompts, Antworten oder Logs der Kunden. Die Region wählen Sie über die Quellregion Ihres API-Aufrufs und über das Inference Profile:

Für die Schweiz ist die Region eu-central-2 (Zürich) massgebend. Dort sind Opus 5.5, Sonnet 5.5 und Haiku 4.5 verfügbar, allerdings nur als Global- oder EU-Profil und nicht In-Region. Ein Profil, das ausschliesslich in Zürich rechnet, existiert nicht. Wird das EU-Profil aus Zürich aufgerufen, verteilt AWS die Anfragen laut Modellkarte (belegt für Haiku 4.5 und Sonnet 4.6) auf diese Regionen:

Zürich ist nur dann ein mögliches Ziel, wenn die Anfrage aus Zürich stammt. Die Verarbeitung bleibt damit im Raum EU plus Schweiz. Für Opus 5.5 und Sonnet 5.5 nennt die Modellkarte die Zielregionen nicht; die tatsächliche Liste gibt die API zurück:

aws bedrock get-inference-profile \
  --region eu-central-2 \
  --inference-profile-identifier eu.anthropic.claude-sonnet-5-5 \
  --query "models[].modelArn"

Optionen erklärt

Option	Wirkung
bedrock get-inference-profile	Liest die Definition eines Inference Profile
--region eu-central-2	Quellregion Zürich; die Zielliste hängt von der Quellregion ab
--inference-profile-identifier	ID des EU-Profils für Sonnet 5.5
--query "models[].modelArn"	Gibt nur die Modell-ARNs aus; die Region steht jeweils im ARN

Gespeichert werden Daten standardmässig nur in der Quellregion. Eine Ausnahme sind Inhalte, die für die Missbrauchserkennung zurückbehalten werden: Sie liegen in der Zielregion. Der Transport zwischen den Regionen läuft verschlüsselt über das AWS-Netz.

Verarbeitungsregion pro Anfrage belegen

Bedrock ist der einzige der beschriebenen Wege, der die tatsächliche Verarbeitungsregion pro Anfrage protokolliert. CloudTrail schreibt sie in der Quellregion in das Feld additionalEventData.inferenceRegion:

aws cloudtrail lookup-events \
  --region eu-central-2 \
  --lookup-attributes AttributeKey=EventSource,AttributeValue=bedrock.amazonaws.com \
  --max-results 20 \
  --query "Events[].CloudTrailEvent" \
  --output text \
  | jq -r '[.eventTime, .eventName, .additionalEventData.inferenceRegion] | @tsv'

Optionen erklärt

Option	Wirkung
cloudtrail lookup-events	Durchsucht die CloudTrail-Ereignisse der letzten 90 Tage
--region eu-central-2	Quellregion, in der die Aufrufe protokolliert werden
--lookup-attributes AttributeKey=EventSource,AttributeValue=bedrock.amazonaws.com	Filtert auf Ereignisse von Bedrock
--max-results 20	Begrenzt die Ausgabe auf 20 Ereignisse
--query "Events[].CloudTrailEvent"	Gibt nur das vollständige Ereignis als JSON-Text aus
--output text	Ausgabe ohne JSON-Hülle, ein Ereignis pro Zeile
jq -r '… | @tsv'	Extrahiert Zeitpunkt, Aktion und Verarbeitungsregion als tabulatorgetrennte Zeile

Zusätzlich lassen sich mit einer Service Control Policy (SCP) in AWS Organizations alle Regionen ausserhalb von EU und Schweiz sperren. Ist eine Zielregion eines Profils gesperrt, schlägt die Anfrage fehl, statt auf eine andere Region auszuweichen. Mit dieser Kombination ist der Verarbeitungsort technisch erzwungen und pro Anfrage nachweisbar.

Claude Code über Bedrock in der EU

Auch Claude Code lässt sich über Bedrock betreiben. In einer eu-*-Region wählt Claude Code das Präfix eu. automatisch:

export CLAUDE_CODE_USE_BEDROCK=1
export AWS_REGION=eu-central-2
claude

Mit ANTHROPIC_BEDROCK_REGION_PREFIX lässt sich das Präfix übersteuern. Die AWS-Anmeldung erfolgt über die üblichen Mechanismen (Profil, SSO, Umgebungsvariablen). Abgerechnet wird über das AWS-Konto, nicht über ein Claude-Abonnement.

Google Vertex AI: nur EU, ausdrücklich ohne Schweiz

Auf Google Cloud (Vertex AI, inzwischen unter dem Namen Gemini Enterprise Agent Platform) ist die Lage für die Schweiz ungünstiger:

Google schliesst die Schweiz im EU-Multi-Region-Endpunkt ausdrücklich aus: Er deckt nur EU-Mitgliedstaaten ab, das Vereinigte Königreich und die Schweiz gehören nicht dazu. Mehrere Schweizer Ratgeberseiten nennen europe-west6 als Weg zu Claude in Zürich; laut der offiziellen Standorttabelle von Google ist dort kein Claude-Modell verfügbar. Ein Protokollfeld mit der tatsächlichen Verarbeitungsregion pro Anfrage dokumentiert Google nicht. Für den globalen Endpunkt hält Google fest, dass sich die Region der Verarbeitung weder steuern noch ermitteln lässt.

Vertex AI eignet sich damit für eine Verarbeitung ausschliesslich in der EU, nicht für eine Verarbeitung in der Schweiz.

Microsoft Foundry: derzeit keine EU-Option

Microsoft bietet Claude in Foundry in zwei Varianten an. „Hosted on Azure” rechnet auf Azure-Infrastruktur, als Global Standard oder als Data Zone Standard; die Data Zone gibt es für Claude nur für die USA. „Hosted on Anthropic” rechnet auf Anthropic-Infrastruktur, und Microsoft weist darauf hin, dass Daten ausserhalb von Azure und ausserhalb der gewählten Region verarbeitet werden können. Anthropic führt Foundry für Europa als „Coming soon”. In Microsoft 365 Copilot und Copilot Studio sind die Anthropic-Modelle von der EU Data Boundary ausgenommen und in EU, EFTA (also auch in der Schweiz) und im Vereinigten Königreich standardmässig deaktiviert.

Übersicht: welcher Weg welchen Verarbeitungsort zusichert

Ein Weg, der die Verarbeitung von Claude garantiert auf die Schweiz beschränkt, existiert derzeit bei keinem Anbieter. Am nächsten kommt AWS Bedrock mit Quellregion Zürich und EU-Profil. Muss zusätzlich ausgeschlossen sein, dass Daten die EU verlassen (etwa wegen vertraglicher Zusagen an EU-Kunden), lässt sich das EU-Profil aus einer EU-Region wie Frankfurt aufrufen; Zürich ist dann kein Ziel mehr.

Was die regionale Bindung kostet

Alle drei Cloud-Anbieter und Anthropic selbst verrechnen für eine Bindung an eine Region oder Geografie einen Aufschlag von 10 % gegenüber dem globalen Endpunkt. Die Preise richten sich bei Bedrock nach der Quellregion; Zürich, Frankfurt und North Virginia kosten dasselbe. Das Routing zwischen Regionen ist nicht zusätzlich kostenpflichtig.

Listenpreise in USD pro 1 Mio. Token (Input / Output):

Bei Vertex AI gilt der Preis der EU-Spalte für Haiku 4.5 und Sonnet 4.6 in der Region europe-west1. Ein Rechenbeispiel für eine interne Anwendung mit 50 Mio. Input- und 10 Mio. Output-Token pro Monat:

Die regionale Bindung kostet also 10 % mehr als der globale Endpunkt. Gegenüber dem Listenpreis bei Anthropic direkt mit inference_geo: "us" ist ein EU-Profil auf Bedrock gleich teuer. Bei der Wahl ins Gewicht fallen eher die Nebenkosten: Ein AWS- oder Google-Cloud-Konto mit Organisationsrichtlinien, Logging und Budgetwarnungen muss aufgebaut und betrieben werden, und die festen Monatspreise der Claude-Abonnemente entfallen zugunsten einer reinen Abrechnung nach Verbrauch. Ob sich der Wechsel rechnet, hängt vom Volumen ab; ein Abonnement hat einen festen Preis pro Person, bietet aber keine Kontrolle über den Verarbeitungsort.

Aufbewahrung und Training

Neben dem Ort zählt, wie lange Daten gespeichert werden:

• Anthropic API: Prompts und Antworten werden nicht zum Training verwendet, solange keine ausdrückliche Zustimmung vorliegt. Zero Data Retention (ZDR) ist auf Anfrage pro Organisation erhältlich und mit inference_geo kombinierbar. Inhalte, die die Missbrauchserkennung markiert, bleiben auch mit ZDR bis zu zwei Jahre gespeichert. Für die Modelle Fable und Mythos ist eine Aufbewahrung von 30 Tagen Pflicht.
• AWS Bedrock: Inhalte gehen nicht an Anthropic. Die Aufbewahrung ist pro Modell zwischen none, default und aws_review wählbar; Fable verlangt aws_review mit bis zu 30 Tagen Speicherung zur Prüfung durch AWS.
• Google Vertex AI: Google verwendet die Daten nur mit vorheriger Zustimmung für Training oder Fine-Tuning.