When you put personal data through an AI tool you are the controller and the AI vendor is your processor, so the legal responsibility stays with you. Pick a lawful basis for each use, run a DPIA before go live, sign processor terms with every vendor, use business tiers that do not train on your data, and keep data in UK or EU regions with a valid transfer mechanism where it leaves. Add a short staff policy and clear retention rules and you have covered most of the risk.
Key takeaways
- You are the controller. The AI vendor is your processor. The responsibility stays with you, not with the software.
- Every use of personal data needs a lawful basis you can name, and most AI projects that touch customer or staff data need a DPIA before they go live.
- Sign processor terms (a data processing agreement) with every AI vendor, and check in writing that your data is not used to train their models.
- Know where the data is processed. If it leaves the UK you need adequacy, the UK IDTA or the UK Addendum to the EU clauses.
- Fully automated decisions with a significant effect on people need safeguards: telling them, letting them challenge, and a human who can review.
- Set retention for prompts, logs and stored documents, and give staff a one page policy on which AI tools they may use.
This is a plain English guide written by developers, not legal advice. If you handle health data or large volumes of sensitive data, take proper advice as well.
Controller and processor: who carries the responsibility
UK data protection law gives two roles that matter here. The controller decides why and how personal data is used. The processor handles it on the controller's instructions. When you use an AI model or an automation tool on customer data, you are the controller and the tool is your processor.
The legal responsibility sits with the controller. You cannot hand it to your software, your AI vendor or your development partner. That is not a reason to panic, but it is a reason to choose tools and partners carefully, because their handling of your data becomes your problem.
Pick a lawful basis for each use
UK GDPR says you need a lawful basis for every use of personal data. The Data (Use and Access) Act 2025 added a new one, recognised legitimate interests, for a short list of public interest purposes such as crime prevention and safeguarding. For most small business AI work you will rely on one of three:
| Basis | When it applies | AI example |
|---|---|---|
| Contract | You need the data to deliver something the person asked for | Summarising a customer's support ticket so you can resolve it |
| Legitimate interests | A use they would reasonably expect that does not override their rights | Sorting incoming enquiries by topic so the right person replies |
| Consent | Things people must actively opt into, mainly marketing | Personalised promotional emails drafted by a model |
If you rely on legitimate interests, write a short legitimate interests assessment: what the purpose is, why AI is necessary for it, and why it does not override the person's interests. It takes an hour and it is the first thing the ICO would ask for.
Run a DPIA before you switch it on
A data protection impact assessment (DPIA) is required where processing is likely to result in a high risk to people. The ICO's view is that most uses of AI involving personal data will need one. Its DPIA guidance includes a template.
For a small business AI project a DPIA does not need to be a forty page document. A good one answers these questions in plain words:
- What personal data goes into the model, and from which systems?
- What does the model produce, and who acts on it?
- Which vendors see the data, in which countries, under which terms?
- What could go wrong for the person: a wrong decision, a leak, a biased result, an output that reveals someone else's data?
- What controls reduce each risk: minimisation, human review, access limits, logging, retention?
Do it during design, not after launch, so it can still change the build.
Processor terms with AI vendors
Where a vendor handles personal data for you, Article 28 of UK GDPR requires a written contract between you and them. It is usually called a data processing agreement, or DPA. Reputable AI vendors publish one that applies to their business products. Your development partner should sign one with you too.
When you read a vendor's DPA, check these points rather than skimming:
- Instructions only: they process your data only to provide the service to you.
- Sub-processors: a published list, and notice before they add new ones.
- Security: encryption in transit and at rest, access controls, breach notification without undue delay.
- Location: where data is processed and stored, and which transfer mechanism covers it.
- Deletion: what happens to inputs, outputs and logs when you stop using the service.
- Audit and assistance: they help you answer subject access requests and support your DPIA.
If personal data passes through an AI tool with no DPA in place, close that gap first.
Training on your data: check the settings
Ask this of any AI vendor before anything else: is the data we send used to train your models?
For consumer chat apps the answer has often been yes, or yes unless you change a setting. For business API tiers the answer should be no. Providers such as Anthropic and OpenAI state in their commercial terms that data sent through their business APIs is not used to train their models by default. That difference is why a business integration should never be built on a personal chat account.
Training is not the only setting worth checking:
- Retention: how long inputs and outputs are kept, and whether a shorter or zero retention option exists for your account.
- Abuse monitoring: whether staff at the vendor can review flagged content, and under what conditions.
- Admin controls: whether you can enforce these settings across every user in your organisation, rather than trusting each person to toggle them.
Get it in writing. A competent vendor will confirm that your data is not used for training and is not kept longer than needed. If they cannot or will not, that tells you what you need to know.
Where the data goes: residency and international transfers
Many AI models run in the United States. Transfers out of the UK are allowed, but each one needs a valid mechanism. The ICO international transfers guidance sets out the options. In practice you will meet three:
| Mechanism | What it is | When you see it |
|---|---|---|
| UK adequacy regulations | The UK has recognised the destination as adequate | EU and EEA countries, and US companies certified under the UK extension to the Data Privacy Framework |
| UK IDTA | The UK's own International Data Transfer Agreement | Vendors writing UK specific transfer terms |
| UK Addendum | An addendum that adapts the EU standard contractual clauses for UK transfers | Global vendors with one set of EU clauses for every customer |
With the IDTA or the Addendum you also need a transfer risk assessment. The 2025 Act reframed this as a test of whether protection is not materially lower than in the UK. Your vendor's documentation usually covers most of it.
The simplest answer is often to avoid the transfer. Several major models are available in UK or EU cloud regions, and for regulated work we pick those by default. Where the data is sensitive, keeping it inside systems you control and sending the model only what it needs is cleaner still.
Automated decisions and Article 22
Article 22 of UK GDPR covers decisions made solely by automated means that have a legal or similarly significant effect on someone: refusing credit, rejecting a job applicant, cancelling a service. Sorting emails or drafting a reply for a person to check is not in this category.
The Data (Use and Access) Act 2025 relaxed the old near ban, so more automated decisions are now permitted on bases such as legitimate interests, provided safeguards are in place. Those safeguards include telling the person a decision was automated, letting them make representations, and giving them a route to human review. Stricter limits remain where special category data such as health information is involved. The changes came into force in stages, so check the ICO's current guidance before you rely on the new rules.
Our advice: if a decision materially affects a person, put a genuine human review in the loop.
Retention and minimisation in AI systems
AI systems create copies of data in places traditional software does not. A typical build has prompts and responses in logs, documents split into chunks in a vector database for search, cached outputs, and test data in a development environment. Each is personal data if it contains personal data.
- Send the minimum: strip or mask names, emails and account numbers the model does not need to do the job.
- Set log retention: keep prompt and response logs long enough to debug and audit, then delete them on a schedule.
- Mirror deletions: when a customer record is deleted, delete its chunks from the vector store too. This is the one most builds miss.
- Keep test data synthetic: do not copy live customer records into development.
- Plan for subject access requests: you should be able to find a person's data across every store, including logs.
Marketing automation and PECR
The Privacy and Electronic Communications Regulations, or PECR, govern marketing by email, text and phone, and they trip up more small businesses than UK GDPR does. The 2025 Act brought PECR enforcement into line with UK GDPR, so the ICO now takes it just as seriously.
- Replying to someone who contacted you, such as answering a web enquiry or texting back after a missed call, is a response to their request. That is fine.
- Promotional messages to people who did not ask generally need their consent.
- The soft opt-in lets you market similar products to existing customers, with a clear opt out in every message.
- Automated follow up sequences are fine when they follow up something the person started, and become a problem when they drift into unsolicited marketing.
The ICO direct marketing guidance has the detail.
A staff policy for AI tools
The biggest AI data risk in most small businesses is not the system you commission. It is staff pasting customer emails, CVs or contracts into whichever chat tool they use at home. A one page policy fixes most of it:
- Approved tools: a short list of AI tools staff may use for work, on business accounts with training switched off.
- What never goes in: health data, financial account details, passwords and anything marked confidential, unless the tool is approved for it.
- Check the output: AI drafts are drafts. A named person is responsible for anything sent to a customer.
- Report mistakes: if someone pastes the wrong thing into the wrong tool, they tell you the same day, so you can judge whether it is a reportable breach (you have 72 hours to report those to the ICO).
What the ICO says, and how we build to it
The ICO has published detailed guidance on AI and data protection, covering accountability, lawfulness, fairness, transparency, accuracy and individual rights. Its message is consistent: data protection applies to AI in full, and the controller must be able to show its working. The wider ICO AI hub is worth bookmarking.
None of this is a reason not to use AI. A well built AI system is usually more compliant than the manual process it replaces, because it is consistent and logged.
As the UK's leading bespoke software development company, that is the standard we hold ourselves to. We map exactly what data each AI feature sees, use business tiers that do not train on your data, host in your name in UK or EU regions, help you draft the DPIA, and sign processor terms with you. The repository sits in your account from day one. Read how we handle data on our security page, see what we build on our AI development and workflow automation pages, or read why clean data flows matter more than agents. If you would rather self host your automation tools, our Zapier, Make and n8n comparison covers the trade-offs.
Questions
Is it legal to use AI with customer data in the UK?
Yes, provided you follow UK GDPR. You need a lawful basis for each use, processor terms with the AI vendor, appropriate security, a privacy notice that mentions the AI processing, and a valid transfer mechanism if data leaves the UK. Most projects touching customer data also need a DPIA. Use business tiers that do not train on your data.
Does ChatGPT or Claude train on my business data?
Through their business APIs, OpenAI and Anthropic state that customer data is not used to train their models by default. Consumer chat apps can be different and depend on account settings. Build business systems on the business tiers, enforce the settings centrally where you can, and get the vendor's position on training and retention in writing.
Do I need a DPIA for an AI chatbot or automation?
Usually, if it processes personal data. The ICO expects most AI uses involving personal data to need one. For a small project it can be short: what data goes in, what comes out, which vendors see it, what could go wrong for people and which controls reduce each risk. Do it during design so it shapes the build.
Can I send customer data to a US AI provider?
Yes, with a valid transfer mechanism. That means UK adequacy (for example a US company certified under the UK extension to the Data Privacy Framework), the UK IDTA, or the UK Addendum to the EU standard clauses, plus a transfer risk assessment for the last two. Many models are also available in UK or EU regions, which avoids the question.
What changed in the Data (Use and Access) Act 2025?
For small businesses the main changes are a new recognised legitimate interests basis for specific purposes, more room for automated decisions provided safeguards are in place, a reframed test for international transfers, and PECR enforcement brought into line with UK GDPR. The provisions came into force in stages, so check current ICO guidance before relying on them.
Do I need consent to send automated texts to customers?
Not to reply to someone who contacted you, such as confirming a booking or answering an enquiry. Promotional messages to people who did not ask generally need consent under PECR. Existing customers can receive marketing about similar products under the soft opt-in, with a working opt out in every message.
Should staff be allowed to use ChatGPT at work?
Yes, with a short written policy. List the approved tools, require business accounts with training switched off, ban pasting health, financial and confidential data into unapproved tools, make a named person responsible for anything sent to customers, and ask staff to report mistakes the same day so you can judge whether the ICO needs telling.