Your AI Vendor Is a Data Processor — And That Changes Everything Under UK GDPR
The moment a member of staff submits a prompt containing client data to ChatGPT, Microsoft Copilot, or Google Gemini, the vendor operating that service becomes a Data Processor under UK GDPR Article 4(8). That single act triggers a cascade of mandatory legal obligations that most regulated professional services firms have not begun to address — obligations that cannot be satisfied retroactively, cannot be waived by contract, and carry enforcement consequences of up to £17.5 million or 4% of global annual turnover.
This article dissects exactly when and why Data Processor status is triggered, the contractual and operational obligations it creates for the firm as Data Controller, and why the only architectural model that eliminates ongoing active-access liability is Zero-Touch Provisioning — a deployment pattern in which the deployment provider retains no standing access and no credentials after handover, operating under a Zero Standing Privileges architecture.
What Article 4(8) Actually Says
UK GDPR Article 4(8) defines a processor as:
“a natural or legal person, public authority, agency or other body which processes personal data on behalf of the controller”
The definition is functional, not contractual. It does not matter whether a Data Processing Agreement exists. It does not matter whether the vendor calls itself a processor. It does not matter whether the firm intended to appoint a processor. If a third party processes personal data on behalf of the firm — and submitting client data to an AI inference endpoint plainly constitutes processing — that third party is a processor as a matter of law.
There is no opt-out. There is no grace period. The status attaches the instant the processing occurs.
How Every Cloud AI Vendor Becomes Your Processor
Consider the data flow when a solicitor uses Microsoft 365 Copilot to summarise a client’s contract:
- The solicitor types a prompt containing client-confidential information
- The prompt is transmitted from the solicitor’s browser to Microsoft’s Azure infrastructure
- Microsoft’s orchestration layer queries Microsoft Graph to retrieve relevant emails, files, and context
- The prompt and context are submitted to a large language model hosted on Azure OpenAI
- The response is generated on Microsoft’s servers and returned to the solicitor
At step 2, Microsoft begins processing personal data on behalf of the firm. Microsoft is a Data Processor. This is not disputed — Microsoft’s own documentation confirms that Microsoft 365 Copilot operates under the Microsoft Products and Services Data Protection Addendum, with Microsoft acting as a data processor.
The same analysis applies to every cloud AI service:
- OpenAI (ChatGPT): OpenAI processes prompts and completions on its infrastructure. OpenAI is a processor.
- Google (Gemini): Google processes prompts within its cloud. Google is a processor.
- Anthropic (Claude, via Microsoft): Since January 2026, Anthropic’s Claude models are enabled by default as a Microsoft sub-processor in Copilot. Anthropic processes data under Microsoft’s DPA — adding another link to the chain.
Every vendor. Every service. Every prompt. The firm acquires a new processor relationship (or extends an existing one) with each submission.
The Obligations Article 28 Creates — For You
Once a processor relationship exists, UK GDPR Article 28 imposes a set of obligations on the Data Controller — that is, your firm. These obligations are not optional. They are statutory. The ICO has enforcement power over every one of them.
Mandatory Written Contract (Article 28(3))
The firm must have a binding contract with every processor that sets out the subject matter and duration of processing, the nature and purpose of processing, the type of personal data processed, and the categories of data subjects. The contract must require the processor to act only on the controller’s documented instructions, ensure personnel are bound by confidentiality, implement appropriate technical and organisational measures, and assist the controller with data subject rights requests and breach notification.
For enterprise AI products, this contract typically takes the form of the vendor’s standard DPA. Microsoft’s runs to 40+ pages. Google’s, OpenAI’s, and Anthropic’s each have their own. The firm’s Compliance Officer must read, interpret, and reconcile each one with the firm’s data protection policies.
For free-tier consumer AI tools — ChatGPT’s free tier, Gemini’s free tier — no Article 28-compliant contract exists. The user agrees to the vendor’s general terms of service, which are not a DPA, do not contain processor obligations, and do not give the controller any of the rights Article 28 requires. Every prompt submitted through a free-tier AI tool is an unauthorised transfer to an uncontracted processor. Every single one.
Sub-Processor Disclosure and Approval (Article 28(2))
The processor must not engage a sub-processor without the controller’s prior authorisation. Where general written authorisation is given, the processor must inform the controller of any intended changes to the sub-processor list, giving the controller an opportunity to object.
Microsoft’s sub-processor list is published on the Microsoft Service Trust Portal. It spans dozens of entities across multiple jurisdictions. Since January 2026, that list includes Anthropic as a sub-processor for Copilot experiences — and Anthropic models are currently excluded from the EU Data Boundary and in-country processing commitments. If a firm’s tenant has Anthropic enabled (which is the default for non-EU/UK tenants, and available by opt-in for UK tenants), client data may be processed by a sub-processor outside the firm’s expected geographic boundary.
The firm must monitor this list. The firm must assess each sub-processor. The firm must object if a new sub-processor introduces unacceptable risk. This is an ongoing operational obligation, not a one-time procurement exercise.
International Transfer Compliance (Article 44+)
If any processor or sub-processor processes data outside the United Kingdom, the firm must ensure appropriate transfer safeguards are in place — Standard Contractual Clauses, adequacy decisions, or other mechanisms permitted under Chapter V of the UK GDPR. Microsoft, Google, and OpenAI are US-headquartered corporations. Their infrastructure spans global jurisdictions. The firm must verify that every data flow — including flows to sub-processors — is covered by a lawful transfer mechanism.
Audit Rights (Article 28(3)(h))
The processor must make available to the controller all information necessary to demonstrate compliance and must allow for and contribute to audits conducted by the controller or an appointed auditor. In practice, large AI vendors satisfy this through SOC 2 reports, ISO certifications, and standardised audit documentation rather than allowing individual client audits of their data centres. The firm’s Compliance Officer must assess whether these standardised mechanisms provide sufficient assurance for the specific categories of data being processed — legally privileged client files, HMRC correspondence, financial records.
The Compound Effect: Processor Liability at Scale
A single AI vendor creates a manageable processor relationship. The compound effect of multiple AI tools is where compliance collapses.
Consider a mid-sized professional services firm where:
- The firm uses Microsoft 365 Copilot (Microsoft is processor; Anthropic is sub-processor)
- Individual staff members use ChatGPT Plus on personal accounts (OpenAI is an uncontracted processor)
- The accounts department uses Google Gemini for drafting (Google is an uncontracted processor)
- A trainee uses a free AI summarisation tool (an unknown entity is processing data with no DPA, no transfer mechanism, and no audit trail)
The firm now has four processor relationships — two with enterprise DPAs, two completely uncontracted. The firm’s GDPR Article 30 Records of Processing Activities must document every processor. The firm’s DPIA must assess every data flow. The firm’s international transfer register must verify every jurisdiction.
Most firms have not done any of this. Most firms do not know how many AI processors they have.
The Architectural Escape: Zero-Touch Provisioning
There is one deployment model that eliminates processor liability at the AI layer entirely. Not by negotiating better contracts. Not by choosing a “more compliant” vendor. By removing the third-party processor from the architecture.
Zero-Touch Provisioning is Private AI Ltd’s deployment model. Here is how it works:
During deployment, Private AI Ltd configures the entire sovereign AI environment on the client’s own contracted infrastructure: the inference layer, the vector database, the user interface, the access layer, the egress controls, and the system service configuration. The client independently provisions and owns the infrastructure account, and invites Private AI Ltd via restricted role-based access.
Upon completion, the client explicitly revokes Private AI Ltd’s access. All root passwords, SSH keys, and API tokens are held exclusively by the client. Private AI Ltd retains no standing access to the client’s systems, infrastructure, or data.
In the Default Operating State, Private AI Ltd holds no credentials granting access to Client Data at rest or in transit. Although Private AI Ltd acts as a Standing Data Processor under Article 4(8) UK GDPR, the Zero Standing Privileges architecture means it holds no active connection, no credentials, and no means of accessing Client systems during normal operations. Active processing by Private AI Ltd is limited to authorised Just-In-Time Support Sessions and Professional Services Engagements conducted under a signed Statement of Work.
This is not merely a contractual promise — it is the architecture. You cannot actively process data if you hold no credentials. You hold no credentials because the client revoked them at handover.
The firm’s processor map at the AI layer reduces to a single entity:
- A UK-registered bare-metal infrastructure provider supplying dedicated compute and hypervisor-encrypted storage. The client executes a domestic Article 28 UK GDPR DPA directly with the infrastructure provider. No international transfer mechanism required.
The access layer is client-controlled infrastructure — it introduces no additional processor. Private AI Ltd is not a party to the infrastructure processing relationship. The pre-filled DPA template is delivered alongside the Standing DPA, DPIA template, and Data Flow Narrative.
The Standing DPA: What Happens During Support
A legitimate question: what happens when the firm needs technical support?
Private AI Ltd’s standard support model is Over-the-Shoulder (OTS) — the client’s IT lead executes all commands while sharing a screen with Private AI Ltd’s engineer via video call. Under OTS Support, Private AI Ltd’s engineer observes but does not operate, access, or control any system. Private AI Ltd does not access Client systems under OTS.
If OTS Support is insufficient and the client requests Just-In-Time (JIT) Support, the IT lead grants Private AI Ltd temporary time-limited access for a defined maintenance window. This constitutes a Level 1 or Level 2 access event under Schedule 2 of the standing DPA, with strict prohibitions against data extraction and a full keystroke audit log. Upon completion, the IT lead closes the gateway port and revokes the access credential.
The standing Data Processing Agreement is operative continuously from signature. Audit rights, breach notification, Article 32 technical and organisational measures, confidentiality, and liability apply at all times — not only during support sessions.
The Compliance Officer’s Decision
Your firm faces a binary architectural choice:
Option A: Cloud AI. Every AI vendor is a processor. Every sub-processor is your compliance problem. Every international data flow requires a transfer mechanism. Every sub-processor change requires re-assessment. Your DPIA grows. Your Article 30 register grows. Your attack surface grows. Your exposure to ICO enforcement grows.
Option B: Sovereign AI with Zero-Touch Provisioning. Private AI Ltd acts as a Standing Data Processor with a Zero Standing Privileges architecture — in the Default Operating State holding no active access to your systems. The firm’s infrastructure DPA is domestic — a UK-registered bare-metal provider. No third-party authentication, access gateway, or network transit provider in the access path. Your DPIA is a single, stable document. Your Article 30 register is clean. Your Compliance Officer sleeps.
The technology delivers the same capability. The compliance posture is incomparable.
What to Do Next
Step 1: Read our detailed walkthrough of how the standing DPA and Zero Standing Privileges architecture work together to understand the contractual and architectural precision behind the Zero Standing Privileges model.
Step 2: Read our analysis of Article 28 sub-processor chains in cloud AI deployments to see the full processor map comparison.
Step 3: Talk to our team to walk through the full processor liability analysis — and see why Zero-Touch Provisioning is the only model that eliminates it.
Private AI Ltd (SC881079) acts as a Standing Data Processor under Article 4(8) UK GDPR, operating a Zero Standing Privileges architecture. We deploy sovereign, zero-egress AI environments for regulated professional services. In the Default Operating State, we hold no active connection and no credentials to client systems.