Do you need a Transfer Risk Assessment to use AI? A decision tree

You need a transfer risk assessment only if you are relying on an Article 46 safeguard — standard contractual clauses or the UK IDTA — to make a restricted transfer lawful. Where the transfer is covered by UK adequacy regulations, including the UK–US data bridge, no TRA is required. A good number of AI deployments fall into the second group.

That is the whole rule. Everything below is how to work out which group you are in, and how to check rather than assume.

The rule, stated properly

A TRA is not a general obligation that attaches to "using AI". It attaches to one specific thing: relying on an Article 46 appropriate safeguard for a restricted transfer. The ICO's updated international transfer guidance, which took effect on 5 February 2026, is explicit that where UK adequacy regulations cover the destination, the transfer can proceed on that basis without relying on Article 46 and without a TRA.

So the question is never "is this an AI tool?" It is "what is the lawful basis for this particular transfer, and does that basis carry an assessment obligation?"

Step 1: is there personal data in the prompt?

If nothing in your prompts, attachments or outputs is personal data, Chapter V of the UK GDPR does not engage and there is no transfer to assess. Stop here.

Be honest at this step, because most teams get it wrong. Prompts routinely contain client names, email threads, CVs, case notes, medical detail and identifiable free text that nobody classified as personal data because it arrived by copy-paste.

Note also that pseudonymising data before it leaves your estate reduces risk and is worth doing, but pseudonymised data is still personal data. It does not take you out of Chapter V.

Step 2: is it a restricted transfer?

It is a restricted transfer only if all three of these are true:

1. UK GDPR applies to your processing of the personal data.
2. You are sending the data to, or making it accessible to, a receiver located outside the UK.
3. That receiver is a separate legal entity from you.

Two consequences people miss. An overseas entity having remote access to UK-hosted data is enough — physical storage location is not the whole answer. And if the receiver is a UK entity with no overseas access, there is no restricted transfer at all, and nothing in this article applies to you.

Step 3: which mechanism does the receiver rely on?

This is the branch that decides it.

Adequacy regulations → no TRA. Transfers from the UK to the EEA are covered by UK adequacy. So are transfers to other countries covered by UK adequacy regulations, and transfers to US organisations covered by the UK Extension to the EU–US Data Privacy Framework — the "UK–US data bridge" — in force since 12 October 2023, for data within the scope of that certification. In these cases there is no Article 46 safeguard in play and therefore nothing to assess.

Article 46 safeguards → TRA required. SCCs, the UK IDTA, the UK Addendum to the EU SCCs, or binding corporate rules. If your vendor's DPA relies on any of these, you owe a TRA. Note whose obligation it is: the exporter's. That is you, not the vendor. The vendor providing the SCCs does not discharge it.

Article 49 derogations → no TRA, but be careful. Explicit consent, contractual necessity and the other derogations do not require a TRA, but the ICO treats them as exceptions for occasional, non-routine transfers. Do not build a production AI workflow on one.

The decision tree, compressed

• Personal data in the prompt? No → stop.
• Receiver outside the UK and a separate legal entity? No → stop.
• Vendor relies on adequacy (EEA, or a US entity covered by the UK Extension for this data type)? Yes → no TRA. Record the basis and move on.
• Vendor relies on SCCs, the IDTA or the UK Addendum? Yes → TRA required.
• Relying on an Article 49 derogation? Yes → no TRA, but document why it is occasional and non-routine.

How to check which mechanism your vendor actually uses

Do not take this from a marketing page or a trust centre badge. Go to the contract.

Find the DPA, then find the transfers clause. Usually headed "International transfers" or "Transfers of personal data", with the operative detail in an annex or addendum.

Look for Article 46 language. A reference to Commission Implementing Decision (EU) 2021/914, module numbers (Module Two for controller-to-processor, Module Three for processor-to-processor), or an "International Data Transfer Addendum" / "UK Addendum" means SCCs. That is Article 46, and you owe a TRA.

Look for adequacy language. A reference to the Data Privacy Framework or the UK Extension should be verified, not accepted. Search the public list at dataprivacyframework.gov and check four things: that the participating entity is the same legal entity named in your contract; that participation status is Active, not withdrawn or lapsed; that the certification expressly covers the UK Extension and not only the EU–US framework; and that the covered data types include what you are sending, since HR and non-HR data are scoped separately.

Check the sub-processor list. Your direct vendor's mechanism does not cure onward transfers. Model providers, hosting providers and support functions may sit in different places under different mechanisms.

Watch for cascade clauses. Many DPAs say "we rely on adequacy where available, and otherwise on the SCCs". That is not an answer. You have to work out which limb applies to your transfer, and record the reasoning.

If you cannot tell, ask in writing. A one-line email to the vendor's DPO asking "which Chapter V mechanism do you rely on for transfers of UK personal data under our agreement?" gets a definitive answer and gives you an accountability record.

A worked example: Claude via Anthropic's US API

Anthropic's Data Processing Addendum incorporates the EU Standard Contractual Clauses — Module Two and Module Three, under Commission Implementing Decision (EU) 2021/914 — with the UK International Data Transfer Addendum applied to processing subject to UK GDPR. Their privacy policy names standard contractual clauses and adequacy decisions as the transfer mechanisms.

SCCs are an Article 46 safeguard. So calling Claude directly against Anthropic's US API is a restricted transfer covered by SCCs, and relying on SCCs means a TRA is required. That obligation is the customer's.

We have not verified Anthropic's Data Privacy Framework status in either direction, and we are not going to assert one. Check it yourself using the steps above before you rely on anything else.

What about ChatGPT, Copilot and Gemini?

We are not going to tell you what mechanism those vendors rely on, because we have not verified it from their current contractual documents, and a page that guesses is worse than no page. Run the check above against the DPA that actually applies to your subscription. That last point matters: consumer, team and enterprise tiers of the same product frequently sit under different terms, with different transfer clauses and different sub-processor lists.

And a blunt aside. If your exposure is staff pasting client data into a consumer chatbot on a personal account, the transfer mechanism is the least of your problems. There is no DPA, no controller-to-processor terms, no retention control and no confirmed position on training use. That is an unmanaged processing problem, and it is what actually gets firms into trouble. Fix that before you spend a fortnight on TRA paperwork.

If you do need one, what does a TRA involve?

The ICO publishes a TRA tool built around six questions. Its emphasis is whether the transfer significantly increases the risk to people's privacy and other rights compared with the data staying in the UK, and it lets you assign risk by data category, so lower-risk data can proceed while higher-risk categories are treated separately. You can use the EDPB's transfer impact assessment approach instead if you prefer, though it is framed more narrowly around government access.

Treat the output as a living document. It needs revisiting when the vendor changes sub-processors, when you start sending a materially different category of data, or when the legal position in the destination country moves.

Where we fit, and where we do not

The narrow, honest case for us is this. On a UK-tier key, Claude Sonnet 4.6 and Claude Opus 4.6 are invoked in-region against bedrock-runtime.eu-west-2 in AWS Europe (London) using bare model ids, and the inference does not leave the UK. A request that cannot be served in London fails rather than quietly routing elsewhere. If there is no restricted transfer in the model call, there is nothing to assess and no supplier questionnaire about US processing to answer.

Now the part that costs us sales, and which we would rather you heard from us than from your own DPO. The TRA argument does not make UK hosting better than EU hosting. UK to EEA transfers are covered by UK adequacy, so a provider running in Dublin or Frankfurt reaches exactly the same outcome: no Article 46 reliance, no TRA. And if you have a platform engineer, you can point at Bedrock in London yourself — it is self-serve and roughly an afternoon's work.

Where UK genuinely wins is narrower and more practical: procurement and sector requirements that ask for a UK answer specifically. Public sector OFFICIAL data, financial services security reviews, and clients whose own contracts specify the UK. If none of those apply to you, EU hosting is a reasonable choice and we will say so on a call.

dijitul Ltd is not a law firm and this is not legal advice. Documents we provide are drafts for your own adviser to review and adopt.

This is general information about how the rules work, not legal advice about your circumstances. If a decision turns on it, take advice.