Residency & compliance

Data stays inside the tier you choose.

Each project is pinned to Spain, the European Union or global. The gateway checks it on every request, and if no allowed route is left, the request fails. It never falls back to a looser tier.

Three tiers, one inside the other.

Tiers are ordered: ES ⊂ EU ⊂ Global. A project may use routes of its own tier or of any stricter tier, never of a wider one.

  • ES

    Spain

    Only routes that process in Spain: Azure Spain Central, Vertex AI in Madrid, or open weights self-hosted in Spain Central. For the strictest requirements.

  • EU

    European Union

    Routes in the EU and in Spain: regional endpoints on Bedrock, Vertex and Foundry, Azure EU Data Zone, or the Mistral API.

  • Global

    Global

    Every route, including direct APIs with global processing. Breadth and price; outside what the ENS story covers.

  • The tier is a property of the project, and every API key belongs to a project.
  • The data plane enforces it on every request, from a local snapshot of keys and allowed routes.
  • If no allowed route is left, the response is a 503. There is no “plan B” outside the tier.
  • Fallbacks after provider failures only go to routes in the same or a stricter tier.
  • The optional x-situra-residency: es|eu header can only tighten the project tier for one request, never loosen it.
Tighten one request to 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"}]}'

# Response when a Spanish route exists:
#   x-situra-residency: es
#   x-situra-route-region: spaincentral
# If no ES route exists for that model: 503, never EU or Global.

The EU and ES tiers are what we offer to the public sector and regulated organisations, and the only tiers the ENS scope covers.

Routing, step by step.

Pick a project tier and a model family. Simulate provider outages and see which routes are tried, which never are, and what the gateway returns.

Project residency tier
Model family
Simulate a provider failure
Route diagram for a project in the EU tier and the Claude family.GlobalEUESSituraMadridAnthropicBedrock EUVertex EUVertex / Foundry ES
Conceptual diagram, not a geographic map. Each ring contains the inner ones: ES ⊂ EU ⊂ Global. The gateway sits at the centre, in Madrid.

Served by Amazon Bedrock (EU) on the first attempt.

Gateway attempts

  1. Attempt 1EUAmazon Bedrock200 OK
  2. —Anthropic API (Global) is never tried: it is outside the project's EU tier.

Fallbacks only go to routes in the same or a stricter tier. Never to a looser one. Retries happen only before the first byte is streamed to the client.

Response (example)

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

Routes for this family

  • GlobalAnthropic APIapi.anthropic.com · global processingBlocked · looser tier
  • EUAmazon BedrockEU regional endpoint · list price +10%Serves the request
  • EUGoogle Vertex AIEU regional endpoint · list price +10%Allowed · standby
  • ESVertex Madrid / Foundry Spain Centralto verifyAvailability in Spain to be verifiedAllowed · standby

Planned catalogue, for illustration. The live catalogue and per-region availability are shown in the console and by GET /v1/models.

Cryptographic evidence, per request, of where it was processed.

Every gateway response carries an x-situra-attestation header: an Ed25519-signed token stating which route, provider, region and tier served that request. Your DPO can keep it, hand it to an auditor and check it without relying on us.

Token header
{ "alg": "EdDSA", "typ": "situra-residency+jwt", "kid": "7c1e…a90b" }
Signed claims
{
  "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))

Signed claims
ridRequest id (same as x-request-id)
iatIssued at (Unix seconds)
issGateway instance that routed the request
org · prjOrganisation and project
kid_pubPublic part of the API key used (never the secret)
modelModel the client requested
route · provider · regionCatalogue route, provider and region that served the request
residencyTier of the route that served it: es, eu or global
project_residencyTier the project required
attemptsRoutes tried (fallbacks never leave the allowed tier)

What it proves

  • Which route, provider and region served that specific request, and at which residency tier.
  • That Situra’s gateway says so, with an Ed25519 signature anyone can check without trusting us or the console.
  • That the token has not been altered: changing a single character breaks the signature.

What it doesn’t prove

  • What happens inside the model provider: that rests on the provider’s regional commitments and its sub-processor contract.
  • It is a statement signed by Situra, not a third-party certification.

Verify it yourself

Public keys are published as a JWKS (OKP, Ed25519) at https://api.situra.ai/.well-known/situra-attestation-keys. The same token is stored with the request’s metadata, so it shows up in the console and in audit exports.

Terminal
# 1. Make a request and keep the header
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. Fetch the gateway’s public keys
curl -s https://api.situra.ai/.well-known/situra-attestation-keys

Where the platform runs is not where the model runs.

Buyers’ ENS and GDPR reviews check both. So do we.

Azure · Spain Central

Where does the platform run?

On Microsoft Azure, Spain Central region (Madrid): gateway, control plane, database, keys and usage records. This is the ENS scope.

  • Gateway and control plane on AKS
  • PostgreSQL with row-level tenant isolation
  • Secrets in Azure Key Vault (Managed HSM)

route → upstream endpoint

Where does the model run?

That is decided by the provider endpoint the route calls. A gateway in Spain that forwards a prompt to a US endpoint still sends that prompt out of the EU. That is why the residency tier selects the route, not just the hosting.

  • The model provider is a sub-processor
  • Every route declares its region and tier
  • Responses state the region used: x-situra-route-region

What each direct API offers (September 2026).

That is why Situra keeps its own connector to every upstream, direct APIs and hyperscaler endpoints alike: each model gets one route per residency tier.

Regional availability changes often. Every model–route pair is checked before it enters the catalogue.
ProviderDirect API processingRoute to EU processing
Anthropic Global by default; the direct API offers only “us” and “global” inference geographies. Regional endpoints on Amazon Bedrock, Google Vertex AI and Microsoft Foundry, at a 10% higher list price.
OpenAI US processing by default. Europe-region projects for eligible customers, or Azure EU Data Zone and regional deployments.
Google (Gemini) Global. Vertex AI endpoints in the EU or in Madrid (europe-southwest1).
DeepSeek Data stored in China; Italy blocked the service. None from DeepSeek; the open weights are self-hosted in the EU.
Mistral EU hosting by default. The same API.

Metadata only, by default.

What is never stored cannot leak. Request content is logged only when the customer turns it on for a project.

More on the security design
Default
Metadata only: who, which model, tokens, cost, latency and status. No prompts, no responses.
Content logging
Opt-in per project, with 0 to 365 days of retention, encrypted under each customer’s own data key. Destroying that key makes the content unreadable (crypto-shredding).
Zero retention
Available only on models whose provider supports it. The console shows which routes offer it, and a project can require it.
Situra staff
No access to prompt content. No back-office API returns it, and every read of a customer’s data is audited.

Designed for ENS Alta. Certification, on the calendar.

ENS is a prerequisite for public cloud contracts in Spain. We design to category Alta and certify Media first, which covers most public buyers and reaches market sooner.

Microsoft’s announcement of ENS Alto for the Madrid region
  1. Oct 2026 Next

    ENS roles appointed, security policy approved by management, ENS consultant and ENAC-accredited certification body chosen

    Signed policy, role appointments

  2. Oct–Nov 2026 Planned

    System categorisation on the five ENS dimensions; MAGERIT/PILAR risk analysis; one integrated ENS + ISO 27001 Annex A statement of applicability

    Categorisation, risk register, integrated SoA

  3. Nov 2026 – Mar 2027 Planned

    Controls and procedures implemented: access, change, incidents, backups, continuity, suppliers, training

    Procedures, supplier certificates on file

  4. From beta go-live Planned

    Operate and collect evidence; internal audit; management review

    Evidence log, internal audit report

  5. Q2–Q3 2027 Target

    Joint ENS category Media + ISO/IEC 27001 certification audit (stage 1 and stage 2)

    Target: certificates

  6. After certification Later

    ISO/IEC 42001; ENS category Alta upgrade; recurring ENS audits and ISO surveillance

    Expanded scope

Compliance roadmap. These are targets, not achievements; they depend on the beta going live on time, because auditors need evidence of the system in operation.

The paperwork your DPO will ask for.

We act as a processor for our customers. This is the documentation we are preparing for the beta.

Data processing agreement (Art. 28)
A DPA template with the sub-processor list annexed and the technical and organisational measures. In preparation
Public sub-processor list
Cloud, payments and model providers, with the processing location per tier. In preparation See sub-processors
Record of processing (Art. 30)
What we process, for what purpose, for how long and where. In preparation
Impact assessment (Art. 35)
A DPIA covering opt-in prompt and response logging. In preparation

What about the CLOUD Act?

Azure has a US parent, and some buyers raise it. Today we answer with verifiable facts: the platform and data run in Spain Central, default logging is metadata only, opt-in content is encrypted under per-customer keys, and zero-retention routes exist.

Roadmap Later we will offer a sovereign tier on EU-owned infrastructure, with Mistral and self-hosted open weights, for buyers who want no US-parent provider in the chain. It is on the roadmap, with no committed date.

Private beta · Q4 2026

We are looking for three to five organisations for the beta.

Spanish public administrations and regulated organisations that want to use AI models with data residency under control. We work with each organisation on ENS categorisation, the DPA and the integration.