Residencia y cumplimiento

Los datos se quedan dentro del nivel elegido.

Cada proyecto se fija a España, a la Unión Europea o a global. La pasarela lo comprueba en cada petición y, si no hay una ruta permitida, la petición falla. Nunca se desvía a un nivel más laxo.

Tres niveles, uno dentro de otro.

Los niveles están ordenados: ES ⊂ EU ⊂ Global. Un proyecto puede usar rutas de su nivel o de cualquier nivel más estricto, nunca de uno más amplio.

  • ES

    España

    Solo rutas que procesan en España: Azure Spain Central, Vertex AI en Madrid o pesos abiertos autoalojados en Spain Central. Para los requisitos más estrictos.

  • EU

    Unión Europea

    Rutas en la UE y en España: endpoints regionales de Bedrock, Vertex y Foundry, Azure EU Data Zone o la API de Mistral.

  • Global

    Global

    Todas las rutas, incluidas las APIs directas con procesamiento global. Amplitud y precio; queda fuera de lo que cubre la historia ENS.

  • El nivel es una propiedad del proyecto, y cada clave de API pertenece a un proyecto.
  • El plano de datos lo aplica en cada petición, a partir de una instantánea local de claves y rutas permitidas.
  • Si no queda ninguna ruta permitida, la respuesta es un error 503. No hay «plan B» fuera del nivel.
  • Las alternativas ante fallos del proveedor solo van a rutas del mismo nivel o de uno más estricto.
  • La cabecera opcional x-situra-residency: es|eu solo puede endurecer el nivel del proyecto para una petición, nunca relajarlo.
Endurecer una petición a ES
curl https://api.situra.ai/v1/chat/completions \
  -H "Authorization: Bearer $SITURA_API_KEY" \
  -H "Content-Type: application/json" \
  -H "x-situra-residency: es" \
  -d '{"model": "claude-sonnet-4-6", "messages": [{"role": "user", "content": "Hola"}]}'

# Respuesta si hay ruta en España:
#   x-situra-residency: es
#   x-situra-route-region: spaincentral
# Si no hay ninguna ruta ES para ese modelo: 503, sin recurrir a EU ni Global.

Los niveles EU y ES son los que ofrecemos al sector público y a organizaciones reguladas, y los únicos que cubre el alcance ENS.

El enrutamiento, paso a paso.

Se elige el nivel de un proyecto y una familia de modelos, se simulan caídas del proveedor y se ve qué rutas se intentan, cuáles no y qué devuelve la pasarela.

Nivel de residencia del proyecto
Familia de modelos
Simular fallo del proveedor
Diagrama de rutas para un proyecto de nivel EU y la familia Claude.GlobalEUESSituraMadridAnthropicBedrock EUVertex EUVertex / Foundry ES
Diagrama conceptual, no geográfico. Cada anillo contiene a los interiores: ES ⊂ EU ⊂ Global. La pasarela está en el centro, en Madrid.

Servida por Amazon Bedrock (EU) en el primer intento.

Intentos de la pasarela

  1. Intento 1EUAmazon Bedrock200 OK
  2. —No se intenta Anthropic API (Global): queda fuera del nivel EU del proyecto.

Las alternativas solo van a rutas del mismo nivel o de uno más estricto. Nunca a uno más laxo. Solo se reintenta antes de enviar el primer byte al cliente.

Respuesta (ejemplo)

HTTP/1.1 200 OK
x-situra-residency: eu
x-situra-route-region: eu
x-situra-attempts: 1

Rutas de esta familia

  • GlobalAnthropic APIapi.anthropic.com · procesamiento globalBloqueada · nivel más laxo
  • EUAmazon BedrockEndpoint regional UE · precio de lista +10 %Sirve la petición
  • EUGoogle Vertex AIEndpoint regional UE · precio de lista +10 %Permitida · en reserva
  • ESVertex Madrid / Foundry Spain Centralpor verificarDisponibilidad en España por verificarPermitida · en reserva

Catálogo previsto, con fines ilustrativos. El catálogo real y su disponibilidad por región se muestran en la consola y en GET /v1/models.

Prueba criptográfica, en cada petición, de dónde se procesó.

Cada respuesta de la pasarela incluye la cabecera x-situra-attestation: un token firmado con Ed25519 que dice qué ruta, proveedor, región y nivel sirvieron esa petición. El DPD de la organización puede guardarlo, entregarlo a un auditor y comprobarlo sin depender de nosotros.

Cabecera del token
{ "alg": "EdDSA", "typ": "situra-residency+jwt", "kid": "7c1e…a90b" }
Claims firmados
{
  "iss": "gw-spaincentral-…",
  "rid": "req_8354f6fb…",
  "iat": 1790391273,
  "org": "…", "prj": "…", "kid_pub": "…",
  "model": "gpt-5-mini",
  "route": "…",
  "provider": "azure-openai",
  "region": "spaincentral",
  "residency": "es",
  "project_residency": "es",
  "attempts": 1
}
Ed25519

sign(base64url(header) + "." + base64url(claims))

Claims firmados
ridIdentificador de la petición (igual que x-request-id)
iatMomento de emisión (segundos Unix)
issInstancia de la pasarela que enrutó la petición
org · prjOrganización y proyecto
kid_pubParte pública de la clave de API usada (nunca el secreto)
modelModelo solicitado por el cliente
route · provider · regionRuta del catálogo, proveedor y región que sirvieron la petición
residencyNivel de la ruta que la sirvió: es, eu o global
project_residencyNivel exigido por el proyecto
attemptsRutas intentadas (las alternativas nunca salen del nivel permitido)

Qué demuestra

  • Qué ruta, proveedor y región sirvieron esa petición concreta, y con qué nivel de residencia.
  • Que lo afirma la pasarela de Situra, con una firma Ed25519 que cualquiera puede comprobar sin confiar en nosotros ni en la consola.
  • Que el token no se ha alterado: cambiar un solo carácter invalida la firma.

Qué no demuestra

  • Lo que ocurre dentro del proveedor del modelo: eso depende de sus compromisos regionales y de su contrato como subencargado.
  • Es una declaración firmada por Situra, no una certificación de terceros.

Verificación independiente

Las claves públicas se publican como JWKS (OKP, Ed25519) en https://api.situra.ai/.well-known/situra-attestation-keys. El mismo token se guarda con los metadatos de la petición, para que aparezca en la consola y en las exportaciones de auditoría.

Terminal
# 1. Haz una petición y guarda la cabecera
curl -sD - -o /dev/null https://api.situra.ai/v1/chat/completions \
  -H "Authorization: Bearer $SITURA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"gpt-5-mini","messages":[{"role":"user","content":"Hola"}]}' \
  | grep -i '^x-situra-attestation:'

# 2. Descarga las claves públicas de la pasarela
curl -s https://api.situra.ai/.well-known/situra-attestation-keys

Dónde se ejecuta la plataforma no es dónde se ejecuta el modelo.

Las revisiones ENS y RGPD de los compradores comprueban las dos cosas. Nosotros también.

Azure · Spain Central

¿Dónde se ejecuta la plataforma?

En Microsoft Azure, región Spain Central (Madrid): pasarela, plano de control, base de datos, claves y registros de uso. Esto es el alcance del ENS.

  • Pasarela y plano de control en AKS
  • PostgreSQL con aislamiento por fila entre clientes
  • Secretos en Azure Key Vault (Managed HSM)

route → upstream endpoint

¿Dónde se ejecuta el modelo?

Lo decide el endpoint del proveedor al que llama la ruta. Una pasarela en España que reenvía un prompt a un endpoint en EE. UU. sigue sacando ese prompt de la UE. Por eso el nivel de residencia elige la ruta, no solo el alojamiento.

  • El proveedor del modelo es un subencargado del tratamiento
  • Cada ruta declara su región y su nivel
  • La respuesta indica la región usada: x-situra-route-region

Qué ofrece cada API directa (septiembre de 2026).

Por eso Situra mantiene su propio conector para cada proveedor, tanto APIs directas como endpoints de hiperescaladores: cada modelo tiene una ruta por nivel de residencia.

La disponibilidad regional cambia a menudo. Cada par modelo–ruta se comprueba antes de entrar en el catálogo.
ProveedorProcesamiento de la API directaRuta hacia procesamiento en la UE
Anthropic Global por defecto; la API directa ofrece solo las geografías de inferencia «us» y «global». Endpoints regionales en Amazon Bedrock, Google Vertex AI y Microsoft Foundry, con un precio de lista un 10 % superior.
OpenAI Procesamiento en EE. UU. por defecto. Proyectos de región Europa para clientes elegibles, o Azure EU Data Zone y despliegues regionales.
Google (Gemini) Global. Endpoints de Vertex AI en la UE o en Madrid (europe-southwest1).
DeepSeek Datos almacenados en China; Italia bloqueó el servicio. Ninguna por parte de DeepSeek; se autoalojan los pesos abiertos en la UE.
Mistral Alojamiento en la UE por defecto. La misma API.

Por defecto, solo metadatos.

Lo que no se guarda no se puede filtrar. El contenido de las peticiones solo se registra si el cliente lo activa en un proyecto.

Más sobre el diseño de seguridad
Por defecto
Solo metadatos: quién, qué modelo, tokens, coste, latencia y estado. Ni prompts ni respuestas.
Registro de contenido
Opcional por proyecto, con retención de 0 a 365 días, cifrado con la clave de datos propia de cada cliente. Borrar esa clave hace ilegible el contenido (borrado criptográfico).
Retención cero
Disponible solo en modelos cuyo proveedor lo admite. La consola indica qué rutas lo ofrecen, y un proyecto puede exigirlo.
Personal de Situra
Sin acceso al contenido de los prompts. Ninguna API del back office lo devuelve, y cada lectura de datos de un cliente queda auditada.

Diseñado para ENS Alta. Certificación, en el calendario.

El ENS es un requisito previo para los contratos públicos en la nube. Diseñamos para la categoría Alta y certificamos primero la Media, que cubre a la mayoría de compradores públicos y llega antes al mercado.

Anuncio de Microsoft sobre ENS Alto en la región de Madrid
  1. Oct 2026 Siguiente

    Roles ENS, política de seguridad aprobada por dirección, consultor ENS y entidad de certificación acreditada por ENAC

    Política firmada, nombramientos

  2. Oct–Nov 2026 Planificado

    Categorización del sistema en las cinco dimensiones ENS; análisis de riesgos con MAGERIT/PILAR; declaración de aplicabilidad integrada ENS + ISO 27001 Anexo A

    Categorización, registro de riesgos, SoA integrada

  3. Nov 2026 – Mar 2027 Planificado

    Implantación de controles y procedimientos: accesos, cambios, incidentes, copias, continuidad, proveedores, formación

    Procedimientos, certificados de proveedores

  4. Desde la beta Planificado

    Operación y recogida de evidencias; auditoría interna; revisión por la dirección

    Registro de evidencias, informe de auditoría interna

  5. Q2–Q3 2027 Objetivo

    Auditoría conjunta de certificación ENS categoría Media + ISO/IEC 27001 (fase 1 y fase 2)

    Objetivo: certificados

  6. Tras la certificación Después

    ISO/IEC 42001; ampliación a ENS categoría Alta; auditorías ENS y seguimiento ISO recurrentes

    Alcance ampliado

Hoja de ruta de cumplimiento. Son objetivos, no hitos alcanzados; dependen de que la beta entre en operación a tiempo, porque la auditoría exige evidencias del sistema funcionando.

La documentación que va a pedir el DPD.

Actuamos como encargado del tratamiento de nuestros clientes. Esta es la documentación que preparamos para la beta.

Contrato de encargo del tratamiento (art. 28)
Plantilla de DPA con la lista de subencargados como anexo y las medidas técnicas y organizativas. En preparación
Lista pública de subencargados
Proveedores de nube, pagos y modelos, con la ubicación del tratamiento por nivel. En preparación Ver subencargados
Registro de actividades de tratamiento (art. 30)
Qué tratamos, con qué finalidad, durante cuánto tiempo y dónde. En preparación
Evaluación de impacto (art. 35)
Una EIPD que cubre el registro opcional de prompts y respuestas. En preparación

¿Y la CLOUD Act?

Azure tiene una matriz estadounidense, y algunos compradores lo plantean. Hoy respondemos con hechos verificables: la plataforma y los datos se ejecutan en Spain Central, el registro por defecto es solo de metadatos, el contenido opcional se cifra con claves por cliente y hay rutas de retención cero.

Hoja de ruta Más adelante ofreceremos un nivel soberano sobre infraestructura de propiedad europea, con Mistral y pesos abiertos autoalojados, para quien no quiera ningún proveedor con matriz estadounidense en la cadena. Está en la hoja de ruta, sin fecha comprometida.

Beta privada · Q4 2026

Buscamos entre tres y cinco organizaciones para la beta.

Administraciones públicas españolas y organizaciones reguladas que quieran usar modelos de IA con la residencia de datos bajo control. El acompañamiento incluye la categorización ENS, el DPA y la integración.