GDPR and AI assistants for UK private practitioners: a practical compliance view

At a glance

• UK GDPR applies to any AI assistant that processes personal data, regardless of whether the data is "merely a name" or detailed sensitive information. The threshold for being in scope is low.
• A hosted cloud AI provider is almost always a processor when the buyer routes prompts containing personal data to it, and a Data Processing Agreement is required. Some configurations involve joint controller analysis.
• The third-country transfer question is the single biggest compliance friction. UK personal data routed to a US-based AI provider needs a transfer mechanism: applicable UK adequacy regulations, appropriate safeguards or a relevant exception. Selecting a UK or EU cloud endpoint does not by itself settle overseas access and transfer obligations.
• A DPIA is required where AI processing is high-risk. For most private-practice AI deployments, the precautionary read is to run a DPIA regardless.
• On-premises deployment is the lowest-friction compliance route. It can keep model inference on owned hardware, but messaging, storage, support and connected services still need a full data-flow assessment.
• This article is technical and architectural, not legal advice. The DPO or external counsel signs off the legal analysis; we provide the technical input that supports it.

What UK GDPR actually requires for AI tooling

UK GDPR is the post-Brexit UK equivalent of the EU GDPR, supplemented by the Data Protection Act 2018. The framework is largely unchanged from the EU position in substance, with a small number of UK-specific divergences and the UK ICO as the supervisory authority.

For a UK private practitioner deploying an AI assistant, the obligations that recurrently come up are:

• Lawful basis for processing. The practice needs a lawful basis under Article 6 for any personal data the AI assistant touches. For most professional services, this is "performance of a contract" with the client or "legitimate interests" of the practice, with the appropriate legitimate interest assessment where relevant. Special category data (health, racial or ethnic origin, religion, biometrics) needs an Article 9 condition in addition.
• Transparency. The practice's privacy notice has to describe the categories of recipient that personal data is shared with. An AI assistant routed to a US-based hosted provider is a category of recipient that needs to appear in the privacy notice.
• Data minimisation. Only the personal data necessary for the specific purpose should be processed. Sending a full client file to an AI for a question that only requires a subset of fields is a data minimisation question, not just a workflow question.
• Accountability. The practice has to be able to demonstrate compliance, not just be compliant. The DPIA, the AI policy, the records of processing, and the supplier due diligence file are the documents that demonstrate it.
• Security. Article 32 requires appropriate technical and organisational measures. For AI tooling this typically means access controls, encryption in transit and at rest, audit logging, and a documented incident response process.
• International transfers. A restricted transfer needs an applicable UK transfer mechanism; assess the actual data flow and recipient.

Is the AI provider a processor?

The answer in almost every commercial AI deployment is yes. A processor under UK GDPR is any third party that processes personal data on the controller's behalf. When the practice sends a prompt containing personal data to a hosted LLM, the provider is processing that personal data on the practice's behalf and is therefore a processor.

The implications:

• A Data Processing Agreement is required. Anthropic and OpenAI publish DPAs for their commercial business services and APIs, not only Enterprise plans. Check the agreement for the exact product. Consumer-tier subscriptions typically do not provide a DPA, which is one of the principal reasons consumer subscriptions are usually not appropriate for personal data processing in a practice context.
• The DPA has to address Article 28's required terms: subject-matter, duration, nature and purpose of processing, types of personal data, categories of data subject, sub-processors, security measures, audit rights, and so on.
• Some configurations involve joint controller analysis. Where the AI provider has independent purposes for processing the data (training, product improvement), the boundary between processor and joint controller is sometimes contested.

Local inference can avoid sending prompts to a hosted model provider. It does not establish that no other supplier processes data: email, messaging, connected drives, backups and support may introduce separate providers. Map the entire workflow and assess each party’s role, terms and access. Do not describe the practice as both controller and its own third-party processor.

Hybrid mode reintroduces the processor question for the workloads that are routed to the cloud LLM. The DPA, the supplier due diligence, and the transparency obligations all apply for that subset of processing.

The third-country transfer question

The single biggest compliance friction in UK GDPR for AI tooling is the third-country transfer analysis. Most major AI providers are US-based companies with US-based core processing, even where they operate UK or EU regional endpoints.

For a safeguards-based transfer, UK GDPR Article 46(1A) requires the exporter, acting reasonably and proportionately, to consider that the data protection test is met. The ICO’s guidance calls the documented assessment a transfer risk assessment. Check the current statute, guidance and recipient before transferring data.

The transfer mechanisms available in 2026:

• The UK-US Data Bridge. A UK-specific extension of the EU-US Data Privacy Framework, in force since October 2023. Allows transfers to certified US recipients without further safeguards. Do not assume a provider is certified. Anthropic’s current DPA incorporates the UK Addendum to the EU SCCs for relevant UK transfers; review the actual contract and transfer assessment.
• IDTA or UK Addendum. The ICO’s International Data Transfer Agreement and its Addendum to the EU SCCs are alternative contractual safeguards. Document the Article 46(1A) data protection test and any supplementary measures needed for the transfer.
• Regional endpoints. As at 14 October 2026, AWS lists London (eu-west-2) in-region availability for Claude Sonnet 4.6 on bedrock-runtime, but the same model card gives its in-region endpoint as N/A. Confirm the endpoint and account access with AWS before relying on UK inference. AWS separately lists Claude Haiku 4.5 on bedrock-mantle for in-region inference in Ireland (eu-west-1) and Stockholm (eu-north-1). Storage, retention and transfers need separate assessment. Regional inference does not remove the need to assess other data flows and restricted transfers.
• Adequacy. The UK-US Data Bridge is an adequacy route for eligible US recipients certified under the Data Privacy Framework with the UK Extension. It does not cover every US recipient. Check certification and the scope of the transfer.

Assess international transfers across the complete workflow, even when inference is local. The agent gateway documentation, checked on 14 October 2026, describes adapters for external messaging and email services. Those channels can involve third parties; encryption, hosting and access differ by configuration. Mark a transfer question “not applicable” only after checking that path.

Hybrid mode is optional and requires written consent. Assess the model, endpoint, permitted data classes, retention and transfer mechanism for each approved cloud workflow. As at 14 October 2026, AWS lists London (eu-west-2) in-region availability for Claude Sonnet 4.6 on bedrock-runtime, but the same model card gives its in-region endpoint as N/A. Confirm the endpoint and account access with AWS before relying on UK inference. AWS separately lists Claude Haiku 4.5 on bedrock-mantle for in-region inference in Ireland (eu-west-1) and Stockholm (eu-north-1). Storage, retention and transfers need separate assessment.

When is a DPIA required?

UK GDPR Article 35 requires a DPIA where processing is "likely to result in a high risk" to the rights and freedoms of data subjects. The ICO publishes a list of indicators that point to high risk. For AI tooling in a private practice, the indicators that recurrently apply include:

• Innovative use of new technology.
• Processing of special category data (health, in clinical practice; potentially religious or ethnic data in immigration practice).
• Processing on a large scale: an individual professional’s client base is not automatically large-scale processing; assess the volume, duration, scope and data involved.
• Processing that involves automated decision-making or profiling, even where the human-in-the-loop pattern is followed.

For most private-practice AI deployments, the precautionary read is to run a DPIA regardless of whether one is strictly required. The DPIA is the document that demonstrates accountability if the ICO ever asks, and it is a document of professional record that survives changes of staff, changes of provider, and changes of practice ownership.

A DPIA structure for a Private AI Concierge deployment

The structure below is a starting template. It is the technical and architectural form of the DPIA; the lawful-basis analysis and the data subject rights impact assessment remain the work of the DPO or external counsel.

1. Description of the processing. The on-premises hardware, the agent framework, the inference engine, the model, and the channels and tools the agent has access to. State the deployment mode (local-only or Hybrid).
2. Necessity and proportionality. Why the AI assistant is necessary for the practice and why the on-premises route was chosen over alternatives. The minimisation analysis: which data classes the agent has access to and why.
3. Risk identification. The risks specific to AI deployment, including hallucination affecting client work, prompt injection from external content, accidental disclosure through channels, and the operational risk of a drifted local stack.
4. Mitigations. The technical and organisational measures applied to each risk. Includes the agent's tool surface, the channels' access controls, the device security posture, the retainer's CVE response process, and the human-in-the-loop pattern for any client-facing output.
5. Hybrid policy (where Hybrid mode is enabled). The data classes permitted to be routed, the routing rules, the cloud endpoint, the transfer mechanism, and the supplier DPA reference.
6. Data subject rights. The practice's process for handling subject access requests, rectification, erasure, and the Article 22C safeguards for solely automated significant decisions, including information, representations, human intervention and contesting the decision.
7. Review schedule. Quarterly review of the DPIA against the current technical and operational state. Trigger conditions for an out-of-cycle review (model upgrade, hybrid policy change, channel addition, major CVE).

The DPIA document does not need to be long to be defensible. Most well-structured private-practice DPIAs run 8 to 15 pages.

A defensible AI policy for a small UK private practice

The DPIA describes the deployment. The AI policy describes how staff use it. For a 5-person practice, a defensible AI policy typically covers:

• Permitted use. The named workflows the assistant is configured for, and the implicit boundary that anything outside those workflows is not approved.
• Prohibited use. Categories of data that must not be entered (for example, third-party privileged material received under undertaking, material covered by court orders, material from clients who have not been informed of AI use).
• Human-in-the-loop. The requirement that any output reaching a client, a court, or a regulator has been reviewed by a competent human. The assistant produces drafts, not finished work.
• Logging and audit. The expectation that interactions with the assistant are logged and may be reviewed.
• Incident reporting. The internal process for reporting suspected AI errors, accidental disclosure, or any other incident.
• Training. The mandatory induction for new staff and the periodic refresh requirement.

The policy should be short, readable, and signed by every staff member. A 4-page policy that everyone has read is more defensible than a 30-page policy that nobody finished.

Why on-premises is the lowest-friction compliance route

Working through the above, the on-premises route is materially easier to document for UK GDPR than the cloud route. The reasons:

• No hosted model processor for inference when the selected model runs entirely locally; check other suppliers separately.
• Assess channel, storage, backup and support transfers separately from local inference.
• Processor agreements and supplier due diligence remain relevant for any connected external services.
• The transparency obligation in the practice's privacy notice is shorter and simpler.
• The DPIA's international transfer assessment must still cover messaging, storage, backup and support paths, even when model inference is local.
• The supervisory authority risk profile is lower because the deployment topology is more conservative.

This is not the same as saying the cloud route is non-compliant. Cloud LLMs under proper DPAs at UK or EU regional endpoints are workable for most UK businesses, and the major hosted providers have invested heavily in the compliance infrastructure to make that route defensible.

The honest framing is that for UK private practitioners, particularly solo solicitors, IFAs, family offices, and clinicians, the cloud-route compliance overhead is high enough that the on-premises route is sometimes the simpler answer commercially as well as legally. The decision is not about which route is "compliant"; it is about which route best matches the data sensitivity, workflow mix, and operational tolerance of the specific practice.

Where to start

If you are considering an AI assistant in a UK private practice and need to work through the GDPR analysis as part of the procurement, the starting point is a free 30-minute scoping call. We work through the data classes the assistant would touch, the workflows in scope, the transfer position you are willing to accept, and the deployment topology that fits.

The relevant service page for the on-premises route is Private AI Concierge. The companion articles on local AI vs cloud AI and Private AI for solicitors cover related angles.

This article is a technical and architectural view. The legal sign-off remains with the practice's DPO or external counsel.