• Nachrichten
  • Managed Agents
  • Admin
Search...
⌘K
Organisation
Admin APIWorkspaces
Authentifizierung
ÜbersichtWorkload Identity FederationWIF-Referenz
Monitoring
Usage and Cost APIRate Limits APIClaude Code Analytics API
Daten & Compliance
DatenresidenzAPI und Datenaufbewahrung
Compliance API
ÜbersichtZugriff erhaltenAktivitäts-FeedChats, Dateien und ProjekteOrganisationen, Benutzer, Rollen und GruppenIntegration entwerfenFehlerFAQ
Log in
Datenresidenz
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...

Solutions

  • AI agents
  • Code modernization
  • Coding
  • Customer support
  • Education
  • Financial services
  • Government
  • Life sciences

Partners

  • Amazon Bedrock
  • Google Cloud's Vertex AI

Learn

  • Blog
  • Courses
  • Use cases
  • Connectors
  • Customer stories
  • Engineering at Anthropic
  • Events
  • Powered by Claude
  • Service partners
  • Startups program

Company

  • Anthropic
  • Careers
  • Economic Futures
  • Research
  • News
  • Responsible Scaling Policy
  • Security and compliance
  • Transparency

Learn

  • Blog
  • Courses
  • Use cases
  • Connectors
  • Customer stories
  • Engineering at Anthropic
  • Events
  • Powered by Claude
  • Service partners
  • Startups program

Help and security

  • Availability
  • Status
  • Support
  • Discord

Terms and policies

  • Privacy policy
  • Responsible disclosure policy
  • Terms of service: Commercial
  • Terms of service: Consumer
  • Usage policy
Admin/Daten & Compliance

Datenresidenz

Verwalte mit geografischen Kontrollen, wo die Modellinferenz ausgeführt wird und wo Daten gespeichert werden.

Was this page helpful?

  • Inference geo
  • API-Nutzung
  • Antwort
  • Modellverfügbarkeit
  • Einschränkungen auf Workspace-Ebene
  • Workspace geo
  • Preise
  • Batch-API-Unterstützung
  • Migration von Legacy-Opt-outs
  • Was sich geändert hat
  • Was mit deinem Workspace passiert ist
  • Wenn du globales Routing verwenden möchtest
  • Auswirkungen auf die Preise
  • Aktuelle Einschränkungen
  • Nächste Schritte

Diese Funktion ist für Zero Data Retention (ZDR) qualifiziert. Wenn deine Organisation eine ZDR-Vereinbarung hat, werden Daten, die über diese Funktion gesendet werden, nicht gespeichert, nachdem die API-Antwort zurückgegeben wurde.

Mit „data residency" (Datenresidenz)-Kontrollen kannst du verwalten, wo deine Daten verarbeitet und gespeichert werden. Zwei unabhängige Einstellungen steuern dies:

  • Inference geo: Steuert, wo die Modellinferenz ausgeführt wird, auf Basis einzelner Anfragen. Wird über den API-Parameter inference_geo oder als Workspace-Standard festgelegt.
  • Workspace geo: Steuert, wo Daten im Ruhezustand gespeichert werden und wo die Endpunktverarbeitung (wie Bildtranskodierung und Codeausführung) stattfindet. Wird auf Workspace-Ebene in der Claude Console konfiguriert.

Claude Managed Agents unterstützt den Parameter inference_geo nicht, berücksichtigt aber die in der Console konfigurierte Workspace geo. Mit selbst gehosteten Sandboxes bleiben die Tool-Ausführung und das Sandbox-Dateisystem auf von dir kontrollierter Infrastruktur.

Inference geo

Der Parameter inference_geo steuert, wo die Modellinferenz für eine bestimmte API-Anfrage ausgeführt wird. Füge ihn zu jedem POST /v1/messages-Aufruf hinzu.

WertBeschreibung
"global"Standard. Die Inferenz kann in jeder verfügbaren Region ausgeführt werden, um optimale Leistung und Verfügbarkeit zu erzielen.
"us"Die Inferenz wird nur auf US-basierter Infrastruktur ausgeführt.

API-Nutzung

Antwort

Das usage-Objekt in der Antwort enthält ein inference_geo-Feld, das angibt, wo die Inferenz ausgeführt wurde:

Output
{
  "usage": {
    "input_tokens": 25,
    "output_tokens": 150,
    "inference_geo": "us"
  }
}

Modellverfügbarkeit

Der Parameter inference_geo wird von Claude Opus 4.6, Claude Sonnet 4.6 und neueren Modellen unterstützt. Anfragen mit inference_geo an Claude Opus 4.5, Claude Sonnet 4.5, Claude Haiku 4.5 oder ältere Modelle geben einen 400-Fehler zurück.

Der Parameter inference_geo ist über die Claude API (First-Party) und Claude Platform on AWS verfügbar. Bei Amazon Bedrock, Vertex AI und Microsoft Foundry wird die Inferenzregion durch die Endpunkt-URL oder das Inferenzprofil bestimmt, daher ist inference_geo dort nicht anwendbar. Der Parameter inference_geo ist auch nicht über den OpenAI-SDK-Kompatibilitätsendpunkt verfügbar.

Einschränkungen auf Workspace-Ebene

Workspace-Einstellungen unterstützen auch die Einschränkung, welche Inference geos verfügbar sind:

  • allowed_inference_geos: Schränkt ein, welche Geos ein Workspace verwenden kann. Wenn eine Anfrage eine inference_geo angibt, die nicht in dieser Liste enthalten ist, gibt die API einen Fehler zurück.
  • default_inference_geo: Legt die Fallback-Geo fest, wenn inference_geo in einer Anfrage weggelassen wird. Einzelne Anfragen können dies überschreiben, indem sie inference_geo explizit setzen.

Diese Einstellungen können über die Console oder die Admin API unter dem Feld data_residency konfiguriert werden.

Workspace geo

Die Workspace geo wird beim Erstellen eines Workspace festgelegt und kann danach nicht mehr geändert werden. Derzeit ist "us" die einzige verfügbare Workspace geo.

Um die Workspace geo festzulegen, erstelle einen neuen Workspace in der Console:

  1. Gehe zu Settings > Workspaces.
  2. Erstelle einen neuen Workspace.
  3. Wähle die Workspace geo aus.

Claude Platform on AWS: Die Workspace geo ist nicht konfigurierbar. Workspaces werden über die AWS Console bereitgestellt, und die Workspaces-Seite in der Claude Console ist schreibgeschützt. Claude Managed Agents-Sitzungen auf dieser Plattform laufen mit einer effektiven Workspace geo von "us", was derzeit die einzige verfügbare Workspace geo ist. Siehe Claude Platform on AWS für plattformspezifische Überlegungen zur Datenresidenz.

Preise

Die Preise für Datenresidenz variieren je nach Modellgeneration:

  • Claude Opus 4.6, Claude Sonnet 4.6 und neuer: Inferenz nur in den USA (inference_geo: "us") wird mit dem 1,1-fachen des Standardtarifs über alle Token-Preiskategorien hinweg berechnet (Input-Token, Output-Token, Cache-Schreibvorgänge und Cache-Lesevorgänge).
  • Globales Routing (inference_geo: "global"): Es gelten die Standardpreise.
  • Ältere Modelle: Unterstützen inference_geo nicht (siehe Modellverfügbarkeit); es gelten die Standardpreise. Anfragen, die den Parameter enthalten, geben einen 400-Fehler zurück.

Diese Preise gelten für die Claude API (First-Party) und Claude Platform on AWS. Von Partnern betriebene Plattformen (Bedrock und Vertex AI) haben ihre eigenen regionalen Preise. Siehe Preise für Datenresidenz für Details.

Wenn du Priority Tier verwendest, wirkt sich der 1,1-fache Multiplikator für Inferenz nur in den USA auch darauf aus, wie Token gegen deine Priority-Tier-Kapazität gezählt werden. Jedes mit inference_geo: "us" verbrauchte Token zieht 1,1 Token von deinen zugesagten TPM ab, konsistent damit, wie andere Preismultiplikatoren (wie Prompt-Caching) die Verbrauchsraten beeinflussen.

Batch-API-Unterstützung

Der Parameter inference_geo wird von der Batch API unterstützt. Jede Anfrage in einem Batch kann ihren eigenen inference_geo-Wert angeben.

Migration von Legacy-Opt-outs

Wenn deine Organisation zuvor das globale Routing deaktiviert hat, um die Inferenz in den USA zu halten, wurde dein Workspace automatisch mit allowed_inference_geos: ["us"] und default_inference_geo: "us" konfiguriert. Es sind keine Codeänderungen erforderlich. Deine bestehenden Anforderungen an die Datenresidenz werden weiterhin durch die neuen Geo-Kontrollen durchgesetzt.

Was sich geändert hat

Das Legacy-Opt-out war eine Einstellung auf Organisationsebene, die alle Anfragen auf US-basierte Infrastruktur beschränkte. Die neuen Datenresidenz-Kontrollen ersetzen dies durch zwei Mechanismen:

  • Kontrolle pro Anfrage: Mit dem Parameter inference_geo kannst du bei jedem API-Aufruf "us" oder "global" angeben, was dir Flexibilität auf Anfrageebene gibt.
  • Workspace-Kontrollen: Mit den Einstellungen default_inference_geo und allowed_inference_geos in der Console kannst du Geo-Richtlinien für alle Keys in einem Workspace durchsetzen.

Was mit deinem Workspace passiert ist

Dein Workspace wurde automatisch migriert:

Legacy-EinstellungNeues Äquivalent
Opt-out vom globalen Routing (nur USA)allowed_inference_geos: ["us"], default_inference_geo: "us"

Alle API-Anfragen, die Keys aus deinem Workspace verwenden, werden weiterhin auf US-basierter Infrastruktur ausgeführt. Es ist keine Aktion erforderlich, um dein aktuelles Verhalten beizubehalten.

Wenn du globales Routing verwenden möchtest

Wenn sich deine Anforderungen an die Datenresidenz geändert haben und du globales Routing für bessere Leistung und Verfügbarkeit nutzen möchtest, aktualisiere die Inference-geo-Einstellungen deines Workspace, um "global" in die erlaubten Geos aufzunehmen, und setze default_inference_geo auf "global". Siehe Einschränkungen auf Workspace-Ebene für Details.

Auswirkungen auf die Preise

Legacy-Modelle sind von dieser Migration nicht betroffen. Aktuelle Preise für neuere Modelle findest du unter Preise.

Aktuelle Einschränkungen

  • Gemeinsame Ratenlimits: Ratenlimits werden über alle Geos hinweg geteilt.
  • Inference geo: Nur "us" und "global" sind verfügbar.
  • Workspace geo: Derzeit ist nur "us" verfügbar. Die Workspace geo kann nach der Workspace-Erstellung nicht mehr geändert werden.

Nächste Schritte

Preise

Sieh dir die Preisdetails zur Datenresidenz an.

Workspaces

Erfahre mehr über die Workspace-Konfiguration.

Usage and Cost API

Verfolge Nutzung und Kosten nach Datenresidenz.

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-opus-4-8",
    max_tokens=1024,
    inference_geo="us",
    messages=[
        {"role": "user", "content": "Summarize the key points of this document."}
    ],
)

print(response.content[0].text)
# Prüfe, wo die Inferenz tatsächlich ausgeführt wurde
print(f"Inference geo: {response.usage.inference_geo}")