Inference in AWS Europe (London) · eu-west-2

Your AI calls are leaving the UK.

Every prompt sent to a US AI provider is a restricted transfer under UK GDPR. It is lawful — but only with the right clauses and a transfer risk assessment, which the ICO made mandatory in February 2026. Most teams have never done one.

dijitul.ai runs Claude on AWS in London. On a UK‑tier key the inference never leaves the country, so there is no transfer to assess.

Get an API key See exactly where it runs

- base_url="https://api.anthropic.com"
+ base_url="https://api.dijitul.ai"

That is the whole migration. The official Anthropic SDKs work unchanged.

Calling a US provider directly

A restricted transfer under Chapter V
Transfer risk assessment required before you rely on the clauses
Your privacy notice has to name a US processor
Your record of processing has to log the transfer

On a UK‑tier key

Inference runs in London, eu-west-2, and nowhere else
No international transfer of your prompt content
A processing agreement with a UK company, AWS named as sub-processor
Per-request proof in the x-gateway-regions header

We are careful with this claim: AWS is a US-owned company, so this is data residency, not sovereignty. What that does and does not mean.

The problem

Your clients' data cannot go to the United States.

Solicitors, accountants, healthcare providers and the public sector all sit under contractual or regulatory constraints on where personal data is processed. That is usually the end of the AI conversation — not because the technology is unsuitable, but because the hosting is.

Anthropic’s own API is US-processed

Anthropic does not offer an EU or UK data-residency option on its public API. Requests are processed and stored in the United States. For a lot of UK organisations that alone closes the door.

DPIAs stall on the transfer question

An international transfer means transfer risk assessments, standard contractual clauses and an ICO addendum — plus a supplier questionnaire nobody has time to complete. Projects die in the paperwork.

Shadow AI fills the gap anyway

While procurement deliberates, staff paste client matter into consumer chatbots. The practical risk is not the sanctioned tool you blocked; it is the unsanctioned one you cannot see.

How it works

Three steps. No rewrite.

There is no proprietary SDK to adopt and no abstraction layer to learn. We implement the Anthropic Messages API, so your existing integration keeps working.

1
Swap your base URL

Set the SDK base URL to https://api.dijitul.ai/v1 and use the API key we issue you. Both Authorization: Bearer and x-api-key are accepted.
2
Use your existing SDK

The official anthropic packages for Python, TypeScript and PHP work unchanged, as do LangChain, LlamaIndex and anything else that lets you set a base URL.
3
Done

Requests are invoked on AWS Bedrock in London. Usage is metered per key and billed in pounds. Every response carries an X-Gateway-Regions header naming the regions the request was eligible to run in.

import os

from anthropic import Anthropic

client = Anthropic(
    api_key=os.environ["GATEWAY_API_KEY"],
    base_url="https://api.dijitul.ai/v1",          # the only line that changes
)

message = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=1024,
    messages=[
        {"role": "user", "content": "Summarise this clause in plain English."}
    ],
)

print(message.content[0].text)

import Anthropic from '@anthropic-ai/sdk';

const client = new Anthropic({
  apiKey: process.env.GATEWAY_API_KEY,
  baseURL: 'https://api.dijitul.ai/v1',            // the only line that changes
});

const message = await client.messages.create({
  model: 'claude-sonnet-4-6',
  max_tokens: 1024,
  messages: [
    { role: 'user', content: 'Summarise this clause in plain English.' },
  ],
});

console.log(message.content[0].text);

curl https://api.dijitul.ai/v1/messages \
  -H "authorization: Bearer $GATEWAY_API_KEY" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-sonnet-4-6",
    "max_tokens": 1024,
    "messages": [
      {"role": "user", "content": "Summarise this clause in plain English."}
    ]
  }'

$response = Http::withToken(config('services.gateway.key'))
    ->post('https://api.dijitul.ai/v1/messages', [
        'model' => 'claude-sonnet-4-6',
        'max_tokens' => 1024,
        'messages' => [
            ['role' => 'user', 'content' => 'Summarise this clause in plain English.'],
        ],
    ]);

echo $response->json('content.0.text');

Data residency

Two tiers, described precisely.

We will not tell you a model is UK-only when it is not. Each tier below states exactly which AWS regions can process your request, and the model catalogue is enforced accordingly.

Where your data is processed

Switch tier to see the difference.

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 · eu-west-2

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

Requests are invoked In-Region against AWS Europe (London), eu-west-2. Inference happens in London and nowhere else.

Models on this tier

Claude Sonnet 4.6
Claude Opus 4.6

These are the only two Claude models AWS currently offers for In-Region invocation in London.

EEA tier

EU cross-region inference

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

All other models use AWS's EU cross-region inference profile. AWS may process the request in any of the seven regions below. It is not UK-only, and we do not describe it as such.

Possible processing regions

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

Zero data retention

AWS Bedrock is zero-data-retention by default: AWS does not store your prompts or completions.

Zero operator access

Bedrock uses zero-operator-access. Anthropic has no access to prompts or completions sent through Bedrock.

Processor and sub-processor

We are the data processor to you. AWS is our sub-processor. Nobody else touches the request.

The residency page sets out what we can and cannot promise in full, including the certifications AWS holds, the ones we do not claim, and the exact contractual position on the DPA, the EU Standard Contractual Clauses and the ICO's International Data Transfer Addendum. Read the data residency page.

What you get

A gateway, not a wrapper.

Residency routing is the reason to buy it. Everything below is the reason it stays bought.

Reversible tokenisation

Your application sends

Draft a chaser to Margaret Ellis, NHS number 943 476 5919.

Claude sees identifiers removed

Draft a chaser to «PERSON_1», NHS number «NHS_NUMBER_1».

You get back

The mapping lives in memory for one request and is never written to disk. Pseudonymisation, not anonymisation — what that means.

Residency

region on the UK tier

London, eu-west-2, and nowhere else. A tier is a ceiling — ask for a model with no UK route and the request is refused, not rerouted.

See the map →

Retention

Zero

prompts stored, by default

Bedrock is zero-retention and zero-operator-access. We keep metadata for metering — never bodies, unless you switch on debug capture, which expires itself.

What we store →

Metering

Know what each team spends.

Every request is metered per key, in GBP, with margin visible to you. Budgets, per-key limits and a CSV export that doubles as an AI Act audit log.

Compatibility

Your SDK already works.

We speak the Anthropic Messages API — same request shape, same streaming events, same tool-use blocks, same error envelope. There is no gateway SDK to learn.

Python TypeScript PHP cURL LangChain WordPress

Metering & billing

Know what each team is spending.

Every request is metered against the API key that made it, so cost is attributable to a project, a department or a client matter without you building any of it.

Per-key attribution

Issue a key per application, per team or per client. Input, output and cache tokens are counted separately against each one.

Priced in pounds

Token prices, allowances and overage are all quoted and invoiced in GBP. No dollar invoices, no exchange-rate surprises on the expense claim.

Hard stops, not surprises

Requests are refused once a tenant runs far enough past its allowance, so a runaway loop cannot quietly generate a five-figure bill.

Usage headers on every call

Rate-limit and usage headers come back on every response, so your own dashboards can track consumption without polling a separate API.

See pricing How we handle keys and logs →

Keep your prompts in the UK.

Point your existing Anthropic SDK at a new base URL. Nothing else changes.

Get an API key Read the docs

Questions about a specific compliance requirement? olly@dijitul.co.uk