Every time we talk to a business about automation, the same worry surfaces eventually, usually phrased as 'but is this GDPR-compliant?'. It's the right question, and it's also the wrong question, because 'GDPR-compliant' isn't a switch you flip on a piece of software. It's a set of decisions about how you handle people's data, and automation just makes those decisions more visible.
The good news is that for a normal small business, there are only a handful of things you actually need to get right. This is the plain-English version. It is not legal advice, and if you handle a lot of sensitive data you should take proper advice, but it will tell you what to look for and what to ask.
First: the responsibility is yours, not the software's
In UK data protection law there are two roles that matter. The 'controller' decides why and how personal data is used. The 'processor' handles it on the controller's instructions. When you use an automation tool, you are the controller and the tool is your processor.
That distinction matters because the legal responsibility sits with the controller. You cannot outsource it to your software or your agency. This isn't a reason to panic; it's a reason to choose your tools and your partners carefully, because their handling of data becomes your liability.
The question that matters most: does the AI train on your data?
This is the one to ask first, loudly, of any AI provider. When you send customer information to an AI model, is that information used to train the model?
For the consumer versions of AI tools, the answer has often historically been yes. For the business API tiers that a serious automation is built on, the answer is no: providers like Anthropic and OpenAI contractually commit not to train their models on data sent through their business APIs. That difference is the whole ballgame, and it is why an automation should never be built on a consumer chat tool.
Your lawful basis
UK GDPR says you need a 'lawful basis' for using personal data. There are six, but for most small-business automation you'll rely on three:
| Basis | When it applies | Example |
|---|---|---|
| Contract | You need the data to provide something the person asked for | Booking the appointment they requested |
| Legitimate interests | A reasonable use they'd expect, that doesn't override their rights | Replying to an enquiry they sent you |
| Consent | For things they must actively opt into, mainly marketing | Adding them to a promotional email list |
You don't need to agonise over this for every automation, but you should be able to say, for each use of personal data, which of these applies. If you can't, that's a sign the automation is doing something the customer wouldn't expect.
Marketing automation: this is where PECR bites
There's a second law that trips people up more often than GDPR itself: PECR, the Privacy and Electronic Communications Regulations. It governs marketing by email, text and phone, and it's stricter than people assume.
- ●Replying to someone who contacted you (a missed-call text back, answering a web enquiry) is a response to their request. That's fine.
- ●Sending promotional messages to people who didn't ask generally needs their consent. Buying a list and blasting it is exactly what gets small firms fined.
- ●There's a narrow 'soft opt-in' for existing customers about similar products, but it still requires a clear, working opt-out in every message.
- ●Automated follow-up sequences are fine when they follow up on something the person started, and become a problem when they turn into unsolicited marketing.
The practical rule: automation that helps you respond to people is low-risk. Automation that reaches out to people who didn't ask needs consent and a real opt-out built in. Any automation partner worth using builds the opt-out handling in as standard.
Get a Data Processing Agreement
Where a provider handles personal data on your behalf, UK GDPR requires a written agreement between you (the controller) and them (the processor). It's called a Data Processing Agreement, or DPA, and it sets out what they can do with the data and their obligations to protect it.
This sounds intimidating and isn't. Reputable providers publish a standard DPA you can accept, and your automation partner should sign one with you too. If you're processing personal data through a tool and nobody has a DPA in place, that's a gap worth closing.
Where the data lives, and where it goes
You should know, roughly, where your customer data is stored and whether it leaves the UK or EU. Transfers outside the UK are allowed, but they need a safeguard, usually the UK's International Data Transfer Agreement or an 'adequacy' decision for countries deemed to offer equivalent protection.
For most small businesses the sensible default is to keep data in UK and EU regions wherever possible, and to know which of your providers are the exceptions and why. For regulated sectors, keeping sensitive data inside systems you control (rather than passing it through third parties at all) is often the cleanest answer.
Sensitive data needs extra care
Some data is 'special category': health, and a handful of other sensitive types. If you're a clinic, a dental practice or anyone handling health information, the bar is higher, and this is genuinely the part to take advice on. The safest automation designs for these sectors keep the sensitive data inside your existing practice-management system and only let the automation see the minimum it needs.
Don't forget the basics
- ●Register with the ICO as a data controller if you need to. Most businesses that process personal data do, and it costs around £40 to £60 a year.
- ●Have a privacy policy that actually describes what you collect and why, including your automation tools.
- ●Only collect what you need, and don't keep it longer than you should.
- ●Be able to honour a request from someone to see, correct or delete their data.
- ●Be careful with fully automated decisions that have a legal or significant effect on someone: people have a right not to be subject to those in certain cases.
None of this is a reason not to automate
It's worth saying clearly: compliance is not an argument against automation. A well-built automation is usually more compliant than the manual process it replaces, because it's consistent, it's logged, and it doesn't leave customer details on a sticky note or in a shared inbox everyone can see. The risk isn't automation. The risk is automation built by someone who treats your data as their feature rather than your liability.
That's how we approach every build: we're explicit about what data each automation sees, we keep it in the UK and EU, we use business APIs that don't train on it, and we'll sign a DPA. You can read exactly how we handle data on our security page, and if you want to talk through your specific situation, that first call is free.