Many UK firms already use Claude to draft, summarise and think through problems. The difficult question arrives when client personal data needs to go in: meeting transcripts, scanned statements, records from a CRM. Regulated firms, financial advisers especially, usually stop there.
They are right to pause, but it is not a dead end. There are three designs that let a firm keep Claude in the workflow and stay in control of where personal data goes. Which one fits depends on how much of the data is personal, how much you process, and what your own risk appetite allows.
What the rules actually say
UK GDPR does not ban US providers. Sending personal data outside the UK is a restricted transfer, and it is allowed with a valid mechanism: adequacy regulations, or safeguards such as the UK International Data Transfer Agreement, backed by a transfer risk assessment. The ICO's guidance on international transfers sets out the options.
The FCA has said it does not plan to introduce extra rules for AI. It expects firms to apply the frameworks they already work under, naming the Consumer Duty and the Senior Managers and Certification Regime (FCA: AI and the FCA, our approach). The firm stays accountable for the outcome, whatever tool produced it.
Many regulated firms go further than the legal minimum and set a simple internal rule: client personal data does not leave the UK. Clients find it easy to understand, and it removes a whole category of questions from audits. The three designs below all work under that rule.
Where Claude runs by default
Through Anthropic's own API, you choose where inference happens with a setting called inference geography. As of October 2026 there are two options, global and US, and stored data sits in the US (Anthropic: data residency). There is no UK or EU option on the first-party API.
Anthropic states that it does not use API data to train its models unless a customer has agreed otherwise (Anthropic Privacy Center). That answers the training question. It does not answer the location question.
Design one: mask personal data before it reaches Claude
A local step replaces names, addresses, National Insurance numbers and policy numbers with placeholders before anything is sent. Claude works on the masked text and is told to keep the placeholders intact. When the answer comes back, the real values are put back in locally. The lookup table never leaves your environment.
Two things to know. First, masked data is still personal data in your hands, because you hold the key. The ICO's pseudonymisation guidance says so directly, and adds that the same data may be anonymous in the hands of a recipient who does not have the key. Second, masking costs some accuracy. Names carry context, and a figure or a date can still point to a person. With careful design the loss is small, but it has to be measured on your own documents, not assumed.
Masking fits best when most of the work is reasoning and drafting, and the personal details are incidental to it.
Design two: run Claude inside a UK cloud region
Claude is also available through cloud platforms. On Amazon Bedrock, Claude Sonnet 5 can be invoked in-region in Europe (London), eu-west-2 (AWS: Claude Sonnet 5 model card). Requests and responses then stay in the London region, inside your own AWS account.
Watch the setting. Bedrock also offers EU and global inference profiles, which can route a request to other regions. Only in-region invocation keeps processing in London, so the deployment has to be configured, and checked, for that.
The cost is mostly not the tokens. It is the AWS account, the network and access controls, logging, and someone to run it all. For a large firm with an IT team that is routine. For a small firm whose IT is outsourced, it can be more infrastructure than the use case justifies.
Design three: a hybrid, with a local model doing the sensitive work
The work is split into small tasks. A smaller open-weight model, such as Qwen, runs on a single GPU server inside your own environment. It handles everything that touches personal data: reading documents, extracting fields, classifying who may see what. What it produces is a structured, anonymised picture.
Claude then gets only that anonymised context, for the parts where a larger model earns its keep: reasoning across facts, spotting gaps, drafting the summary. Results come back and are joined to the real records locally.
For a firm processing a few hundred client files a year, this is often the most economical design. One GPU server costs far less than a managed cloud deployment, and the personal data never leaves the building. The trade-off is accuracy on the local side: smaller models are good at narrow, well-defined tasks and weaker at open-ended ones. The tasks have to be cut small enough for them, and tested.
Choosing between them
If personal data is incidental and the work is mostly reasoning, start with masking. It is the quickest to build and keeps the familiar Claude workflow.
If Claude genuinely needs to see full client records, and there is an IT team to run cloud infrastructure, run it in-region on a UK cloud deployment.
If the data is sensitive, the volume is modest and the firm has little in-house IT, the hybrid usually wins on both cost and control.
Whichever you pick, the same three things are needed for a regulator. A data protection impact assessment written before go-live. An audit trail of what each step did. A named person who reviews and signs off the output before it is relied on.
Test it before you commit
Take 10 to 20 representative files, including the messy ones, with any real client details replaced by realistic fictitious ones. Run them through the design you are leaning towards and compare the output with what an experienced adviser would have written. Count what had to be corrected. That number, not a vendor's accuracy claim, tells you whether the design is ready.
We build these pipelines for regulated firms, starting with exactly that test on your own documents. Our document processing page explains how we work.
Sources
Checked on 6 October 2026: Anthropic data residency documentation, Anthropic Privacy Center on API data, AWS Bedrock model card for Claude Sonnet 5, ICO guidance on pseudonymisation, ICO guidance on international transfers and the FCA's approach to AI. Provider options change, so check them before designing. This article is general guidance, not legal advice.