UK GDPR and AI tools: a client-data checklist for small firms

Author: Adam Khalid, Founder and CEO, Intel Made Simple. Sources last checked 28 October 2026.

A member of staff pastes a client's email into an AI chatbot to get a summary. Under the UK GDPR that is processing of personal data, and the firm is responsible for it whether or not it approved the tool. This guide is for owners and compliance leads at small UK firms who want a short, sourced route through the rules before an AI tool touches client information.

It is general information drawn from the legislation and regulator pages linked below. It is not legal advice, and the Information Commissioner's Office (ICO) has noted that parts of its guidance are under review, which we flag where it matters.

Why does UK GDPR apply to AI tools?

The SRA's report on AI records that the ICO is clear that consumers' data protection rights remain when their information is used for training or operating an AI (opens in a new tab). The ICO has a dedicated guidance on AI and data protection (opens in a new tab), which was updated on 15 March 2023. At the time we read it, the page carried a notice that, due to changes made by the Data (Use and Access) Act, the guidance is under review and may be subject to change. Check that page for the current position before you rely on this guide or any other summary.

The SRA lists the particular threats for law firms: a staff member using online AI to answer a question on a client's case, confidential data being revealed when it is transferred to an AI provider for training, and output from an AI system replicating confidential details from one case in its response to another. The same threats apply to any firm that handles client records, including accountants, brokers and advisers.

What do the Article 5 principles mean for an AI tool?

Article 5 of the UK GDPR (opens in a new tab) sets out six principles. Personal data must be processed lawfully, fairly and transparently; collected for specified, explicit and legitimate purposes; adequate, relevant and limited to what is necessary (data minimisation); accurate and kept up to date; kept no longer than necessary; and processed securely. Article 5(2) adds that the controller shall be responsible for, and be able to demonstrate compliance with, those principles. The legislation.gov.uk page shows amendments made by the Data (Use and Access) Act 2025, in force from 5 February 2026 where not already in force.

For an AI tool, three of the principles do most of the work. Purpose limitation asks whether using client data in the tool fits the purpose it was collected for. Data minimisation asks whether the tool needs the whole file or only a redacted extract. Accuracy matters because AI output can be plausibly wrong, and the SRA reports the term for this as hallucination.

Do you need a contract with an AI vendor under Article 28?

Where a vendor processes personal data on your behalf, you are the controller and the vendor is a processor. The ICO publishes guidance on controllers and processors (opens in a new tab), including a page on contracts and liabilities. Article 28 (opens in a new tab) says the controller shall use only processors providing sufficient guarantees to implement appropriate technical and organisational measures, and that processing shall be governed by a binding contract covering the subject matter, duration, nature and purpose of processing, the type of personal data and the obligations and rights of the controller.

The contract must stipulate, among other things, that the processor processes the data only on documented instructions from the controller, makes sure its people are bound by confidentiality, takes the security measures required by Article 32, does not engage another processor without authorisation, assists with data subject requests, deletes or returns the data at the end of the service, and makes available the information needed to demonstrate compliance, including allowing audits.

The practical test for an AI vendor: can you find these terms in a data processing agreement, and does the vendor state whether it uses your inputs to train its models? If the answer to either is unclear, do not enter client data until it is.

What does Article 32 require on security?

Article 32 (opens in a new tab) requires the controller and the processor to implement technical and organisational measures appropriate to the risk, taking into account the state of the art, costs, and the nature, scope, context and purposes of processing. The measures listed include pseudonymisation and encryption, ongoing confidentiality, integrity, availability and resilience of systems, the ability to restore access to data after an incident, and a process for regularly testing and evaluating the measures. It also requires steps to ensure that anyone acting under your authority who has access to personal data processes it only on your instructions.

For a small firm, that last point is the staff policy. A written rule on which AI tools staff may use, and for what, is how you show instructions were given. The SRA suggests supervision should cover the difference between casual use of online AI such as ChatGPT and systems the firm has formally adopted, and notes that some firms prohibit all staff use of online systems beyond their direct control.

When do you need a DPIA under Article 35?

Article 35 (opens in a new tab) requires a data protection impact assessment (DPIA) before processing, in particular using new technologies, that is likely to result in a high risk to the rights and freedoms of individuals. It names three cases that always require one: a systematic and extensive evaluation of personal aspects based on automated processing on which decisions with legal or similarly significant effects are based; large-scale processing of special category or criminal offence data; and large-scale systematic monitoring of a public area.

The ICO's page When do we need to do a DPIA? (opens in a new tab) adds that its list of high-risk processing includes innovative technology, including AI, in combination with another criterion from the European guidelines, for example evaluation or scoring, or sensitive data. It explains that innovative technology concerns developments in technological knowledge in the world at large, not technology that is new to you. It also says that if no mandatory obligation applies, you are responsible for assessing whether your intended processing is likely to result in high risk.

A DPIA must contain at least a systematic description of the processing and its purposes, an assessment of necessity and proportionality, an assessment of the risks to individuals, and the measures envisaged to address those risks. For a small firm, a two-page DPIA for each AI tool, kept with the contract, meets that shape. Our reading is that using an AI tool to score or evaluate individual clients, or to process health or financial vulnerability data, is where a DPIA is most clearly needed. Summarising a firm's own internal billing data, with no personal data in the input, is at the other end.

What if an AI tool exposes client data? Article 33

Article 33 (opens in a new tab) sets the breach clock. In the case of a personal data breach, the controller shall without undue delay and, where feasible, not later than 72 hours after becoming aware of it, notify the regulator, unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons. A late notification must be accompanied by reasons for the delay. The processor must notify the controller without undue delay after becoming aware of a breach.

That last sentence matters for an AI vendor. Your 72 hours run from when you, the controller, become aware, so your data processing agreement should say how fast the vendor must tell you. The notification must at least describe the nature of the breach, the categories and approximate numbers of people and records affected, the contact point for more information, the likely consequences, and the measures taken or proposed. The article text on legislation.gov.uk carries amendments, so check the current version for the name of the receiving body.

Our rule for a small firm: write a one-page breach note per approved AI tool before it goes live. It lists who tells whom, in what order, and where the contact details for the vendor are kept. The first hour of a breach is a poor time to find the contract.

How does this apply to private healthcare groups?

Article 35 names large-scale processing of special category data as a case that always requires a DPIA. A group that runs clinics and handles patient records should decide with its data protection lead whether a given AI use falls within that wording before any record goes into a tool. Billing and debtor lists at a healthcare group may carry patient identifiers, so our suggested first step is to test a tool on data with the identifiers removed. Our page on revenue recovery for private healthcare groups covers where the money leaks in that sector.

What should a staff AI-use policy say?

Article 32 expects staff to process data only on your instructions, and the SRA notes that some firms prohibit all staff use of online systems beyond their direct control. A one-page policy that carries these headings is enough to start:

1. Approved tools, listed by name, and the tasks each is approved for.
2. Data that must never go into any AI tool, such as special category data without a recorded DPIA.
3. Redaction rules: what to remove before a document is pasted.
4. Where the output is checked, and by whom, before it reaches a client.
5. Who to tell, and how fast, if something is pasted into the wrong tool.

Which ten questions should you answer before a tool goes live?

1. What personal data will go into the tool, and could the task be done with that data removed or redacted?
2. Which clients or categories of client does it relate to, and does any of it fall into special category data?
3. Who is the vendor, and are you the controller with the vendor as processor?
4. Is there a data processing agreement with the Article 28 terms?
5. Does the vendor use your inputs to train its models, and can that be switched off in writing?
6. Where is the data stored, and what does the vendor say about security and deletion?
7. Does the tool evaluate or score individuals, or only summarise documents?
8. Have you completed a DPIA, or recorded why one is not needed?
9. Does your privacy notice tell clients how their data is used, including by this tool?
10. Which staff may use the tool, for what, and where is that written down?

Keep the answers on file. Article 5(2) asks you to be able to demonstrate compliance, and a dated checklist per tool is the cheapest form of evidence.

Where can a small firm get help?

The ICO runs an advice hub for small and medium organisations (opens in a new tab) with tools such as a check on whether data protection applies to your business and a privacy notice generator. For a staff policy and training session built around the questions above, see our AI training and use policy service, and read our own AI policy as an example of the level of detail we think is useful. Our page for IFAs and wealth managers covers a sector where client financial data makes the DPIA question live. The pricing page lists the fixed fees, and the free Leak Scan sits outside client data entirely, so it is a safe place to start.

UK GDPR and AI questions firms ask

Does UK GDPR apply when staff paste client data into an AI chatbot?

Yes. It is processing of personal data, and the firm is responsible for it whether or not it approved the tool. The SRA's report records that the ICO is clear that data protection rights remain when information is used for training or operating an AI.

Do you need a contract with an AI vendor?

Where the vendor processes personal data on your behalf, Article 28 requires a binding contract that covers processing on documented instructions, confidentiality, Article 32 security, sub-processor authorisation, help with data subject requests, deletion or return of data, and audits.

When is a DPIA needed for an AI tool?

Article 35 requires one before processing likely to result in a high risk to individuals. It names three always-required cases, and the ICO adds that innovative technology, including AI, in combination with another criterion such as evaluation or scoring, or sensitive data, is on its list of high-risk processing.

How fast must a data breach be reported?

Article 33 says without undue delay and, where feasible, not later than 72 hours after becoming aware of it, unless the breach is unlikely to result in a risk to people's rights and freedoms. A late report needs reasons for the delay.

Is the ICO's AI guidance final?

At the time we read it, the ICO's guidance on AI and data protection carried a notice that it is under review because of the Data (Use and Access) Act. Check the page for the current position.