Residencia de datos

Los controles de residencia de datos te permiten administrar dónde se procesan y almacenan tus datos. Dos configuraciones independientes rigen esto:

• Geo de inferencia: Controla dónde se ejecuta la inferencia del modelo, por cada solicitud. Se establece a través del parámetro de API inference_geo o como valor predeterminado del workspace.
• Geo del workspace: Controla dónde se almacenan los datos en reposo y dónde ocurre el procesamiento del endpoint (como la transcodificación de imágenes y la ejecución de código). Se configura a nivel de workspace en la Claude Console.



Geo de inferencia

El parámetro inference_geo controla dónde se ejecuta la inferencia del modelo para una solicitud de API específica. Agrégalo a cualquier llamada POST /v1/messages.



Uso de la API

client = anthropic.Anthropic()

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

for block in response.content:
    if block.type == "text":
        print(block.text)
# Verifica dónde se ejecutó realmente la inferencia
print(f"Inference geo: {response.usage.inference_geo}")



Respuesta

El objeto usage de la respuesta incluye un campo inference_geo que indica dónde se ejecutó la inferencia:

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



Disponibilidad de modelos

El parámetro inference_geo es compatible con Claude 4.6 y modelos posteriores. Las solicitudes con inference_geo en Claude Opus 4.5, Claude Sonnet 4.5, Claude Haiku 4.5 o modelos anteriores devuelven un error 400.



Restricciones a nivel de workspace

La configuración del workspace también admite restringir qué geos de inferencia están disponibles:

• allowed_inference_geos: Restringe qué geos puede usar un workspace. Si una solicitud especifica un inference_geo que no está en esta lista, la API devuelve un error.
• default_inference_geo: Establece el geo de respaldo cuando se omite inference_geo en una solicitud. Las solicitudes individuales pueden anular esto estableciendo inference_geo explícitamente.

Estas configuraciones se pueden establecer a través de la Console o de la Admin API bajo el campo data_residency.



Geo del workspace

El geo del workspace se establece cuando creas un workspace y no se puede cambiar después. Actualmente, "us" es el único geo de workspace disponible.

Para establecer el geo del workspace, crea un nuevo workspace en la Console:

1. Ve a Settings > Workspaces.
2. Crea un nuevo workspace.
3. Selecciona el geo del workspace.



Precios

Los precios de residencia de datos varían según la generación del modelo:

• Claude 4.6 y modelos posteriores: La inferencia solo en EE. UU. (inference_geo: "us") tiene un precio de 1.1x la tarifa estándar en todas las categorías de precios de tokens (input tokens, output tokens, escrituras de caché y lecturas de caché).
• Enrutamiento global (inference_geo: "global"): Se aplican los precios estándar.
• Modelos anteriores: No admiten inference_geo (consulta Disponibilidad de modelos); se aplican los precios estándar. Las solicitudes que incluyen el parámetro devuelven un error 400.

Estos precios se aplican a la Claude API (de primera parte) y a Claude Platform en AWS. En Claude en Microsoft Foundry, el mismo multiplicador de 1.1x se aplica a las implementaciones alojadas en Azure que usan el tipo de implementación US Data Zone Standard. Las plataformas operadas por socios (Bedrock y Google Cloud) tienen sus propios precios regionales. Consulta Precios de residencia de datos para obtener más detalles.



Compatibilidad con la Batch API

El parámetro inference_geo es compatible con la Batch API. Cada solicitud en un lote puede especificar su propio valor de inference_geo.



Migración desde las exclusiones heredadas

Si tu organización optó previamente por excluirse del enrutamiento global para mantener la inferencia en EE. UU., tu workspace se ha configurado automáticamente con allowed_inference_geos: ["us"] y default_inference_geo: "us". No se requieren cambios en el código. Tus requisitos de residencia de datos existentes continúan aplicándose a través de los nuevos controles de geo.



Qué cambió

La exclusión heredada era una configuración a nivel de organización que restringía todas las solicitudes a infraestructura ubicada en EE. UU. Los nuevos controles de residencia de datos la reemplazan con dos mecanismos:

• Control por solicitud: El parámetro inference_geo te permite especificar "us" o "global" en cada llamada a la API, dándote flexibilidad a nivel de solicitud.
• Controles de workspace: Las configuraciones default_inference_geo y allowed_inference_geos en la Console te permiten aplicar políticas de geo en todas las claves de un workspace.



Qué sucedió con tu workspace

Tu workspace se migró automáticamente:

Todas las solicitudes de API que usan claves de tu workspace continúan ejecutándose en infraestructura ubicada en EE. UU. No se necesita ninguna acción para mantener tu comportamiento actual.



Si quieres usar el enrutamiento global

Si tus requisitos de residencia de datos han cambiado y quieres aprovechar el enrutamiento global para obtener mejor rendimiento y disponibilidad, actualiza la configuración de geo de inferencia de tu workspace para incluir "global" en los geos permitidos y establece default_inference_geo en "global". Consulta Restricciones a nivel de workspace para obtener más detalles.



Impacto en los precios

Los modelos heredados no se ven afectados por esta migración. Para conocer los precios actuales de los modelos más recientes, consulta Precios.



Limitaciones actuales

• Límites de velocidad compartidos: Los "rate limits" (límites de velocidad) se comparten entre todos los geos.
• Geo de inferencia: Solo "us" y "global" están disponibles.
• Geo del workspace: Solo "us" está disponible actualmente. El geo del workspace no se puede cambiar después de la creación del workspace.



Próximos pasos