Every serious conversation we have about automation arrives at the same question, usually about twenty minutes in, usually asked slightly apologetically:

“If we let this thing read our customer emails… are we allowed to do that?”

It’s the right question. It’s also one that tends to get answered badly — either with a breezy “oh, it’s fine, everyone’s doing it,” or with a wall of jargon designed to make you stop asking. Here’s a straight version.

The usual caveat, meant sincerely: we build systems, we’re not solicitors. Nothing here is legal advice, and if you’re in a regulated sector — financial services, healthcare, legal — you’ll want your compliance people in the room. But you should at least be able to follow the argument, so let’s lay it out.

The short answer

Yes, in most cases, and the reason is less exciting than people expect: an AI system processing your customer data is, legally, just another piece of software processing your customer data.

You already let software read your customers’ emails. Your mail provider does it. Your CRM does it. Your spam filter reads every single message before you ever see it, and nobody’s ever lost sleep over that. UK GDPR doesn’t have a special hostile category for “AI” — it has rules about personal data, and those rules apply to any processing, clever or otherwise.

So the framework you need isn’t new. It’s the one you should already have.

The four questions that actually matter

1. What’s your lawful basis?

You need one to process personal data at all — this isn’t an AI question, it’s a Tuesday question, and if you can’t answer it for your existing systems then AI is not your most pressing problem.

For most business automation, you’re relying on either contract (you’re processing a customer’s data in order to deliver the service they’ve bought) or legitimate interests (you have a genuine business reason, it’s proportionate, and it doesn’t override the individual’s rights). Running an enquiry through a triage system so you can respond to it faster sits comfortably within both.

Where it gets genuinely thornier is if you start doing something the customer wouldn’t reasonably expect — profiling them, scoring them, feeding their data into a model that learns from it. That’s a different conversation, and it needs a proper Legitimate Interests Assessment or a DPIA behind it.

2. Where is the data going?

This is the one that trips people up, and it’s a real technical question, not a paperwork one.

When your automation calls an AI model, the data leaves your building. It goes to a provider’s servers. Which provider, in which jurisdiction, under what terms — these are things you need actual answers to, not assurances.

What to establish before anything goes live:

• Is the provider under a data processing agreement with you? The major providers all offer them. Get one signed.
• Are they training on your data? On the enterprise and API tiers of the main providers, the answer is generally no by default — but “generally” and “by default” are doing work in that sentence. Check the terms for the specific tier you’re on. The free consumer tier of a chatbot is not the same product as the API, and using the former for customer data is a genuinely bad idea.
• Where are the servers? Post-Brexit, transfers out of the UK need a legal mechanism — the UK’s adequacy decision for the EU, the UK Extension to the EU–US Data Privacy Framework, or an International Data Transfer Agreement. This is solvable, but it needs to have actually been solved, in writing, before your customer data starts moving.

3. What’s the human’s role?

Article 22 of UK GDPR gives people the right not to be subject to solely automated decisions that have legal or similarly significant effects on them. Declining someone’s credit application. Rejecting a job applicant. Cancelling a service.

Note the word solely. This is why we design almost everything with a human approval step, and it’s not only for legal cover — it’s because it produces better systems. A human in the loop on consequential decisions means the automation is doing the tedious 90% and a person is exercising judgement on the 10% that warrants it.

If your automation is drafting a follow-up email and a human clicks send, you’re nowhere near Article 22 territory. If your automation is autonomously deciding who gets a refund, you need to think much harder.

4. Can you explain it?

If a customer asks what happened to their data, someone in your business needs to be able to answer without ringing a supplier. That means a record of processing — what the system does, what data it touches, who it shares with, how long it retains for. If your automation partner can’t hand you that documentation, that tells you something about your automation partner.

What we do about it

Every system we build at Sonwa AI Lab starts from a small set of principles that we’d rather over-explain than have you discover later:

Minimise what gets sent. If a triage system only needs to know the subject of an enquiry to route it, it doesn’t need the customer’s full account history. Most automations can be designed to send a fraction of what a lazy implementation would send. That’s an architecture decision, made early, and it’s the single most effective privacy measure available.

Redact by default where it’s cheap to do so. Names, account numbers, and card details can very often be stripped before data reaches the model and reattached afterwards. Where that’s feasible, we do it.

Log everything. Every automated decision leaves a trail: what came in, what the system concluded, what it did. When something goes wrong — and eventually something will — the difference between a manageable incident and a genuine crisis is whether you can reconstruct what happened.

Keep the off switch obvious. Every automation we build can be turned off by someone non-technical, in under a minute, without ringing us. You should never be in a position where a misbehaving system keeps misbehaving because the person who understands it is on holiday.

The risk nobody mentions

There’s a final point worth making, because the “is AI safe?” conversation tends to be one-sided.

The comparison isn’t between an AI system and a perfect world. It’s between an AI system and what you’re doing now — which, in a lot of businesses, is customer data sitting in a shared inbox that six people have the password to, spreadsheets on someone’s personal laptop, and a WhatsApp group with a former employee still in it.

Automation done properly is often an upgrade in data governance, because it forces you to write down what happens to information, who touches it, and why. Most businesses have never done that exercise. It’s uncomfortable. It’s also overdue.

Sonwa AI Lab builds AI automation for UK businesses, with the compliance work treated as part of the build rather than an afterthought. If you’d like to talk through what this would look like in your organisation, get in touch.