Does an AI provider need a UK GDPR Article 28 DPA?

Why Article 28 matters before an AI tool touches client data

If an AI platform processes personal data on behalf of your firm, the UK GDPR expects the controller and processor relationship to be documented. For a professional services firm, that usually means you need a Data Processing Agreement before staff put client, matter, audit, claims, valuation, employee or prospect data into the system.

This is not a paperwork exercise. Article 28 terms are how you prove that a vendor understands its role, follows written instructions, protects confidential data, controls sub-processors, supports deletion and helps you answer client, regulator or data subject questions. Without those terms, the firm is relying on marketing copy rather than an auditable control.

The short answer for professional services firms

Yes, if the AI provider processes personal data for you, you should expect Article 28-compliant processor terms before using the tool with real business data. If the supplier refuses, gives only consumer terms, or cannot explain whether it is a processor or controller for your prompts, files and outputs, keep the tool away from client and staff data until the risk is resolved.

For law firms, accountancy practices, financial advisers, insurers, brokers and consultants, the practical threshold is simple: if a person can be identified from the data, and the AI vendor receives or stores it to provide a service to your firm, procurement needs a processor due diligence step. That step should be recorded in the approval trail for the tool.

Check your AI vendor risk position

What a good AI DPA should cover

A useful DPA should state the subject matter, duration, nature and purpose of processing, the categories of personal data, the categories of data subjects and each party's obligations. For AI tools, the detail matters because prompts, uploaded documents, generated outputs, logs and support records may be handled differently.

At minimum, ask whether the provider will:

• process personal data only on documented instructions from your firm;
• keep your data confidential and restrict staff access to authorised support or security purposes;
• apply appropriate technical and organisational measures, including encryption, access control and monitoring;
• name sub-processors and give notice of material changes;
• help with data subject rights, breach notification, DPIAs and regulator queries;
• delete or return data at the end of the service; and
• provide audit, assurance or certification evidence that matches the product tier you will actually use.

The DPA should also be consistent with the product settings. If the contract promises no training on customer data, the admin console, retention settings and support process should line up with that promise.

The AI-specific questions to ask before signing

Generic processor wording is often too thin for AI procurement. A firm should ask what happens to each data type: prompts, attachments, embeddings, outputs, logs, user feedback, telemetry and support tickets. It should also ask whether any data is used to train, fine-tune, evaluate or improve models, including models run by third-party foundation model providers.

Key questions include:

• Are you a processor, controller or independent controller for each feature we plan to use?
• Which sub-processors and model providers receive our data, and in which countries?
• Can customer prompts, files or outputs be used for model training or product improvement?
• What retention periods apply to prompts, outputs, files, logs and backups?
• Can we disable features that expose client confidential or special category data?
• How do you evidence deletion, incident response and support access controls?

Answers should be specific enough for your data protection lead, risk owner and service owner to approve or reject the use case. If the answer is unclear, reduce the data scope, use synthetic data only, or choose a different tool.

How this fits into an AI governance process

The DPA is one control inside a wider AI governance process. You still need a use case owner, a data classification decision, a DPIA or screening where relevant, access controls, user guidance, output review, evidence capture and a route for incidents or exceptions. The firm should be able to show who approved the tool, what data it may receive and what controls were checked.

For regulated or client-confidential work, do not let teams self-approve a tool because it is convenient. Put the Article 28 check into the same intake flow as security, confidentiality, privilege, Consumer Duty or professional conduct considerations. The purpose is not to block sensible AI use. It is to make useful automation safe enough to operate at the right scale.

Build a practical AI governance rhythm

Red flags that should pause the rollout

Pause or limit deployment if the provider only offers consumer terms, cannot identify sub-processors, reserves broad rights to use customer data for training, gives no deletion commitment, lacks enterprise access controls, or cannot provide a meaningful security and privacy evidence pack. These gaps may be manageable for public research prompts, but they are not acceptable for client files or identifiable staff data.

Another red flag is a mismatch between sales assurances and contract terms. If the salesperson says data is private but the contract allows broad product improvement use, treat the contract as the control point. Record the gap, ask for corrected terms and keep the tool out of sensitive workflows until the evidence supports the decision.

A simple approval checklist

Before approving an AI vendor for personal data, keep a short evidence pack:

1. Use case description and data categories.
2. Controller or processor role assessment.
3. Signed or accepted Article 28 DPA.
4. Sub-processor and international transfer review.
5. Training, retention and deletion position.
6. Security evidence mapped to the product tier.
7. Named business owner and human review controls.
8. Decision record with conditions, expiry date and review trigger.

This gives the firm an audit trail if a client, insurer, regulator or internal risk committee asks why the tool was allowed.

Conclusion

An Article 28 DPA is not optional when an AI provider processes personal data for your firm as a processor. It is the contract layer that turns AI vendor promises into accountable obligations. Use it alongside data minimisation, access control, human review and ongoing monitoring so that AI adoption is useful, controlled and defensible.

Turn AI vendor checks into an implementation plan