Residencia de datos

La residencia de datos es el compromiso de un proveedor de que los datos que un cliente envía a su servicio (prompts, documentos, resultados) se procesan y, en su caso, se almacenan dentro de una región geográfica definida, como la Unión Europea o Estados Unidos. Para un servicio de IA como Claude, importa tanto dónde se ejecutan las inferencias como dónde quedan registros, logs o datos en reposo. No es lo mismo que el cifrado ni que las políticas de retención: responde a la pregunta en qué país físico viven mis datos.

Cómo funciona

Un servicio con control de residencia enruta las peticiones a infraestructura ubicada en la región elegida. En la práctica hay tres capas que considerar:

• Procesamiento (datos en tránsito y en uso): dónde corren las GPU que ejecutan el modelo cuando mandas un prompt.
• Almacenamiento (datos en reposo): dónde se guardan, si se guardan, los logs, cachés o archivos subidos.
• Metadatos y operación: telemetría, facturación y soporte, que a veces cruzan fronteras aunque el contenido no lo haga.

Anthropic ofrece el acceso a Claude por tres vías principales, y la residencia depende de cuál uses. La API directa de Anthropic, Claude en Amazon Bedrock y Claude en Google Cloud Vertex AI permiten seleccionar regiones concretas. A través de los hyperscalers puedes anclar las inferencias a regiones europeas (por ejemplo zonas en Fráncfort o Irlanda), heredando además el aparato de cumplimiento del proveedor cloud. La configuración exacta de regiones disponibles cambia con el tiempo, así que conviene verificarla en la documentación vigente antes de diseñar una arquitectura.

Por qué importa

Si construyes con Claude para una empresa europea, un hospital o una administración pública, la residencia de datos suele ser un requisito no negociable. El RGPD restringe las transferencias internacionales de datos personales, y sectores como banca, salud o sector público añaden exigencias propias. Elegir una región europea reduce la superficie legal: evitas depender de mecanismos de transferencia internacional y simplificas la evaluación de impacto.

Para el builder, esto se traduce en decisiones técnicas concretas: qué endpoint llamar, qué región configurar en Bedrock o Vertex, y qué garantías contractuales exigir. Un dato clave de la política comercial de Anthropic es que, por defecto, no entrena sus modelos con los datos enviados por clientes de la API y productos de empresa. Eso es distinto de la residencia, pero ambos conceptos se evalúan juntos en una due diligence de privacidad. Si quieres dominar este tipo de decisiones de arquitectura, es justo el terreno de un curso para construir sobre la API de Claude con criterio de cumplimiento.

Residencia frente a conceptos que se confunden

• No es soberanía de datos: la soberanía implica que los datos están sujetos a las leyes de un país; la residencia solo describe su ubicación física. Un dato alojado en la UE puede seguir expuesto a leyes extraterritoriales según el proveedor.
• No es retención: la retención dice cuánto tiempo se guarda algo; la residencia dice dónde.
• No es cifrado: puedes cifrar datos que viajan al otro lado del mundo; eso no los hace residentes de tu región.

Errores comunes

El más frecuente es asumir que usar un proveedor europeo garantiza residencia completa: el enrutamiento de inferencias, los logs de depuración o el soporte técnico pueden salir de la región si no lo configuras expresamente. Otro error es ignorar la caché y los datos subidos a herramientas: si tu aplicación persiste conversaciones o archivos, esos datos también necesitan una ubicación controlada. Y un tercero: confundir la zona de tu cuenta de facturación con la zona donde se procesa el contenido. Revisa siempre el acuerdo de tratamiento de datos (DPA) del proveedor y la matriz de regiones soportadas antes de firmar.