Skip to main content
dijitul
Data residency

Where your prompts are actually processed.

This page is written to be quoted in a data protection impact assessment. Every claim below is stated at the strength we can actually support — no rounding up, no marketing shorthand. Where a guarantee is narrower than you might expect, we say so.

Data processing addendum Ask a specific question →

The two tiers

UK tier and EEA tier are not the same thing.

Your key is assigned a residency tier. That tier is a ceiling, never a preference: if no route satisfies it, the request fails rather than being quietly downgraded.

Where your data is processed

Switch tier to see the difference.

London eu-west-2 Dublin eu-west-1 Paris eu-west-3 Frankfurt eu-central-1 Stockholm eu-north-1 Milan eu-south-1 Madrid eu-south-2

Inference runs in London and nowhere else. Available for Claude Sonnet 4.6 and Claude Opus 4.6, the models AWS can invoke in-region in the UK. Requests for any other model are refused rather than routed elsewhere.

Processed within the EEA — which may not be the UK. AWS may execute a request in any of these seven regions. Every response tells you which set applied, in the x-gateway-regions header. Never outside the EEA.

UK tier

In-Region invocation

“Your prompts are processed in the UK and do not leave it.”

Requests on this tier are invoked In-Region on AWS Europe (London), region code eu-west-2. In-Region invocation means the model is called against the London endpoint using a bare model identifier. There is no cross-region routing involved. Inference happens in London and nowhere else.

Only a subset of Claude models support In-Region invocation in London. On this tier you may use Claude Sonnet 4.6 and Claude Opus 4.6. No other model is available, and a request for one will be refused rather than served from elsewhere.

Processing regions
eu-west-2
Leaves the UK?
No

EEA tier

EU cross-region inference profile

“Processed within EU/EEA regions; may leave the UK but never the EEA.”

Every model other than Sonnet 4.6 and Opus 4.6 — that is Claude Opus 5, Claude Sonnet 5 and Claude Haiku 4.5 — is served through AWS's EU cross-region inference profile. AWS documents that a request entering this profile may be processed in any of the seven regions listed below, at AWS's discretion, in order to manage capacity.

It is false to describe this tier as UK-only. A request you send from London can be processed in Frankfurt or Stockholm. What we can promise is that it will not leave the EEA.

Processing regions
Seven — see below
Leaves the UK?
Possibly

Named in full

The seven EEA regions

These are every AWS region that a request on the EEA tier may be processed in. There are no others, and this list is not abbreviated anywhere else on the site.

  • eu-west-1

    Dublin, Ireland

  • eu-west-2

    London, United Kingdom

    Also the UK tier's only region

  • eu-west-3

    Paris, France

  • eu-central-1

    Frankfurt, Germany

  • eu-north-1

    Stockholm, Sweden

  • eu-south-1

    Milan, Italy

  • eu-south-2

    Madrid, Spain

You can verify the tier on every response

Rather than asking you to trust a PDF, the gateway discloses the routing on the response itself. Every reply carries the residency tier the key is on and the regions the request was eligible to be processed in. 

HTTP/1.1 200 OK
content-type: application/json
x-gateway-residency: uk
x-gateway-regions: eu-west-2
x-gateway-model: anthropic.claude-sonnet-4-6

Model catalogue

Which model runs on which tier

The mapping below is enforced in code, not in documentation. A scheduled job re-verifies each route against the live AWS account and disables anything that is no longer invocable, so the catalogue cannot drift into claiming a UK route AWS has withdrawn.

Claude models and the residency tiers they are available on
Model UK tier EEA tier Context
Claude Sonnet 4.6 claude-sonnet-4-6 Available In-Region, eu-west-2 Available Any of the seven regions 200K
Claude Opus 4.6 claude-opus-4-6 Available In-Region, eu-west-2 Available Any of the seven regions 200K
Claude Opus 5 claude-opus-5 Not available No London In-Region route Available Any of the seven regions 200K
Claude Sonnet 5 claude-sonnet-5 Not available No London In-Region route Available Any of the seven regions 200K
Claude Haiku 4.5 claude-haiku-4-5 Not available No London In-Region route Available Any of the seven regions 200K

We fail closed

If your key is on the UK tier and you request a model that has no UK route, the request is refused with residency_unavailable. It is never silently served from the EEA tier, and never from Anthropic's US API. A residency setting that can be quietly downgraded is not a residency setting. 

{
  "type": "error",
  "error": {
    "type": "residency_unavailable",
    "message": "claude-opus-5 has no UK-only route. Your key is restricted to residency tier 'uk'. Use claude-sonnet-4-6 or claude-opus-4-6, or move this workload to a key on the EEA tier."
  }
}

The underlying platform

What AWS Bedrock does with the request

Our residency claim rests on AWS Bedrock's behaviour, so it is worth being explicit about what that behaviour is.

Zero data retention

Amazon Bedrock is zero-data-retention by default. AWS does not store your prompts or the model's completions. They are held in memory for the duration of the call and then discarded.

Zero operator access

Bedrock operates a zero-operator-access model. Anthropic has no access to prompts or completions sent through Bedrock — the model weights run inside AWS's environment, and the model provider does not receive the traffic.

No training on your data

Because neither AWS nor Anthropic retains the content of a Bedrock inference call, there is no corpus of your prompts for anyone to train on.

The contractual position

dijitul Ltd is the data processor in respect of the personal data you send through the gateway. You remain the data controller. AWS is our sub-processor. There is no other party in the chain.

The AWS Data Processing Addendum, the EU Standard Contractual Clauses and the UK Information Commissioner's Office International Data Transfer Addendum are incorporated automatically into the AWS Customer Agreement. They do not need to be separately negotiated, requested or signed for them to apply to our use of AWS.

Our own data processing addendum passes the equivalent commitments through to you. Read it here.

Certifications that cover Amazon Bedrock

Amazon Bedrock is in scope for the following AWS certifications. These are AWS's certifications covering the service we build on, not certifications held by dijitul Ltd.

  • ISO/IEC 27001:2022
  • ISO/IEC 27017
  • ISO/IEC 27018
  • ISO/IEC 27701
  • ISO/IEC 42001 (AI management)
  • SOC 1
  • SOC 2
  • SOC 3

Plain English

What we can and cannot promise

The second list is the more useful one. If a supplier only ever shows you the first, ask them for the second.

What we can promise

  • On the UK tier, your prompts are processed in the UK and do not leave it. Inference is invoked In-Region on AWS Europe (London), eu-west-2.
  • On the EEA tier, your prompts are processed within EU/EEA regions. They may leave the UK, but they never leave the EEA.
  • The seven regions the EEA tier may use are named in full on this page and returned on every response in the X-Gateway-Regions header.
  • AWS Bedrock is zero-data-retention by default: AWS does not store your prompts or completions.
  • Bedrock uses zero-operator-access: Anthropic has no access to prompts or completions sent through it.
  • dijitul Ltd is your data processor and AWS is our sub-processor. There is no other party in the request path.
  • The AWS DPA, the EU Standard Contractual Clauses and the ICO International Data Transfer Addendum are incorporated automatically into the AWS Customer Agreement.
  • Amazon Bedrock is in scope for AWS's ISO 27001:2022, ISO 27017, ISO 27018, ISO 27701, ISO/IEC 42001 and SOC 1/2/3 certifications.
  • A residency-constrained key fails closed. It is never downgraded to a wider tier to keep a request alive.

What we cannot promise

  • That the EEA tier is UK-only. It is not. AWS may process an EEA-tier request in Dublin, London, Paris, Frankfurt, Stockholm, Milan or Madrid. If you need UK-only, use the UK tier and accept its shorter model list.
  • That Anthropic's own API offers EU or UK residency. It does not. Anthropic's public API processes and stores data in the United States. That is precisely why this gateway exists, and it is why a residency-constrained key can never fall back to it.
  • That we hold Cyber Essentials Plus for this service. We do not. AWS holds a Cyber Essentials Plus certificate, but its scope is AWS's own corporate network — it does not certify AWS services, and it certainly does not certify ours. Anyone citing it as cover for a cloud service has misread the certificate.
  • Any NCSC certification. None exists to hold. The NCSC does not certify cloud services against its Cloud Security Principles. AWS publishes a mapping of its controls to those principles; a mapping is a self-assessment aid, not a certification.
  • That every Claude model is available in the UK. Only Sonnet 4.6 and Opus 4.6 support In-Region invocation in London today. If AWS adds more, they will appear in the catalogue above once the verification job confirms them.
  • That redaction is a substitute for a lawful basis. PII redaction reduces what the model sees. It does not by itself make a processing activity lawful, and it does not remove your obligations as controller.

If you are completing a supplier assessment

Email support@dijitul.uk with the questionnaire and we will complete it against this page. We will not answer a question more favourably in a spreadsheet than we have answered it here.

Questions

Residency questions we are asked most

Which tier should I choose?

If a contract, regulator or internal policy requires UK-only processing, choose the UK tier and use Claude Sonnet 4.6 or Claude Opus 4.6. If your requirement is EEA-wide — which covers most UK GDPR adequacy positions — the EEA tier opens up the full model range.

Tiers are set per key, so you can run a UK-tier key for client matter and an EEA-tier key for internal tooling side by side.

Does the gateway itself store my prompts?

No. Prompt and completion bodies are not written to disk. We record metadata — timestamp, model, token counts, latency, status — for metering and diagnostics. Bodies are only ever stored if you explicitly enable time-limited debug capture, which expires automatically.

See the security page for the detail.

Where is the gateway application itself hosted?

The gateway, its database and its metering counters run in the United Kingdom. The residency tier governs where inference happens; the application tier is UK-hosted regardless of which inference tier your key is on.

Can I get a signed data processing addendum?

Yes. Our DPA is published and offered on a counter-signature basis. It names AWS as sub-processor and reflects the tier your keys are configured for.

Note: the published version is currently a draft pending legal review — the banner on that page says so, and we will not pretend otherwise while it is.

What happens if AWS withdraws the London In-Region route for a model?

A scheduled verification job checks every declared route against the live AWS account. If a UK route stops being invocable, that model is disabled on the UK tier and UK-tier requests for it fail with residency_unavailable. It is not moved to the EEA tier on your behalf.

Is my data used to train models?

No. Bedrock does not retain prompts or completions, and Anthropic does not receive them, so there is nothing to train on. We do not use your prompts for training either.

Read it, then test it.

Get a key, send one request, and check the X-Gateway-Regions header against what this page told you.

Get an API key Security & key handling

Questions about a specific compliance requirement? support@dijitul.uk