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

Your AI calls are leaving the UK.

Calling Claude in the US is a restricted transfer under UK GDPR. Anthropic covers it with standard contractual clauses — an Article 46 safeguard, which obliges you to complete a transfer risk assessment. The ICO made that mandatory in February 2026. Most teams have never done one.

dijitul.ai runs Claude on AWS in London. Every plan is UK‑only, so the inference never leaves the country and there is no transfer to assess.

Start a free trial See exactly where it runs

14 days free · nothing charged today · cancel any time

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

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

Calling Anthropic 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

Through dijitul.ai

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

One tier. UK only.

Every plan we sell processes in London and nowhere else. Below is what that means, and what we deliberately do not offer — because "EU residency" elsewhere often means something quite different from what buyers assume.

Where your data is processed

Compare what we do with what we deliberately do not.

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.

An EU cross-region profile can run anywhere in the EEA. AWS may execute the request in any of these seven regions. That is what "EU data residency" usually means elsewhere, and it is why we do not sell it. Your requests never take these routes.

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.

What we do not offer

EU cross-region inference

The newest Claude models cannot be pinned to London, so we do not sell them.

Claude Opus 5, Sonnet 5 and Haiku 4.5 are published only as an EU cross-region inference profile. AWS may serve such a request from any of the seven regions below. That is lawful under UK adequacy and plenty of providers sell it as “EU data residency” — but it is not UK-only, so it has no place on a UK tier and we would rather not have the model than blur the claim.

Where those requests could be processed

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.

Start a free trial Read the docs

14 days free · cancel any time · nothing charged today

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