This is a practical note, not legal advice. If you are making a significant decision about processing personal data, talk to a solicitor. But a surprising amount of this is navigable without one, provided you understand the shape of the rules and where the genuine decisions sit. What follows is the shape.

The UK’s data protection regime rests on two documents — the UK GDPR (a tailored version of the EU GDPR, in force since January 2021) and the Data Protection Act 2018 — and a body of guidance issued by the Information Commissioner’s Office, which is the UK’s data-protection regulator. When a small business starts using AI on data that contains information about identifiable people, these rules apply. This is true whether the AI is a chatbot, a classification model, a transcription service, a CRM enrichment tool, or a language model deployed in any of their guises.

The rest of this piece maps the terrain.

Who this applies to, and when

The rules apply when you are processing personal data — any information that relates to an identifiable living person. “Processing” is a very broad term: collecting, storing, analysing, transmitting, combining, and deleting are all processing. The moment you pass a customer’s name, email address, support enquiry, meeting transcript, resume, or behavioural data through an AI system, you are processing personal data.

The rules apply to you regardless of whether you process that data yourself, use a cloud provider, use a third-party API, or use a self-hosted model. The obligations are on you as the controller — the entity deciding the purposes of the processing. Your cloud provider is likely a processor acting on your instructions, which means some of the compliance burden flows to them contractually, but ultimately the buck stops at the controller.

The rules do not apply to processing that is genuinely anonymous (in the technical sense — irreversibly de-identified, not “we removed the name field”) or to processing that concerns no personal data at all (running a language model over public company financials, for example).

The six obligations that tend to bite

There are many compliance obligations. In practice, for a UK SMB adopting AI, six of them are where most of the work sits.

1. Have a lawful basis

You need a lawful basis, chosen before the processing starts, for every processing activity. For most AI use cases in a business context, the relevant bases are contract (processing necessary for a contract with the person), legitimate interests (a balance test you perform), or consent. Consent is often the wrong answer despite being the most visible; it is hard to get cleanly and easily withdrawn.

Legitimate interests is the most common basis for operational AI uses and requires a legitimate interests assessment — a short document in which you describe the interest, why the processing is necessary, and how you have balanced it against the person’s rights. This is not a form to fill in; it is a real piece of thinking. The ICO publishes a template.

2. Be transparent

You must tell people, at the point you collect their data, what you will do with it. If you are going to use AI to process it — for example, “we analyse support tickets with a language model to categorise and route them” — say so, in plain language, in your privacy notice. Vague phrases like “we may use your data for automated processing” do not meet the bar.

Transparency is one of the areas where we regularly see small businesses underdelivering without realising it. Adding AI processing to an existing system often requires updating the privacy notice. The update is cheap; the non-update is a regulatory risk.

3. Think about automated decision-making

Article 22 of the UK GDPR gives people a right not to be subject to decisions made solely by automated means that have legal or similarly significant effects. Hiring decisions, credit decisions, tenancy decisions — these are the obvious examples. A decision is “solely automated” if no human meaningfully reviews the output before it takes effect.

Most AI uses in a small UK business do not fall into this category, because humans are in the loop. But there are gotchas: an automated CV filter that routes candidates to different stages is arguably a solely-automated decision affecting someone significantly, even if a human eventually interviews the shortlisted set. If you are automating anything that affects whether someone gets hired, lent to, rented to, or significantly served, get specific advice.

4. Mind the special categories

The UK GDPR treats some data as special category: health, ethnicity, religion, political opinion, sexual orientation, trade union membership, genetic and biometric data when used to identify someone. Processing this data requires both a lawful basis and a separate condition under Article 9. The bar is higher. AI processing over medical records, counselling notes, or biometric identifiers should be approached with significantly more caution.

This is where the case for local inference (processing on your own hardware) becomes specifically strong. A local model keeps special-category data within your own controllable boundary. This doesn’t remove the obligations — you still need a lawful basis, a condition, and documentation — but it simplifies the chain of processing. Fewer actors, fewer transfer questions, fewer surprises.

We wrote about the local/cloud decision in more detail in Local versus cloud AI for UK SMBs.

5. Know when you need a DPIA

A Data Protection Impact Assessment is a structured written assessment of the risks of a processing activity. You must do one when the processing is likely to result in a high risk to people’s rights. The ICO publishes a list of processing activities for which a DPIA is mandatory; using AI to make decisions with “significant effects” is on that list, as is “using new technologies” in certain contexts, and processing special-category data at scale.

In practice, if you are deploying AI that touches significant amounts of customer or employee data, err toward doing a DPIA. It doesn’t need to be long — ten pages is ample for most SMB deployments — but it should describe the processing, the necessity, the risks, and the mitigations. It forces you to think through the things you should be thinking through anyway.

6. Handle international transfers

If the processing happens outside the UK — which it almost certainly does if you are using any of the large cloud AI providers — you have obligations around international data transfers. The UK has adequacy decisions with a number of countries (including the EU and, conditionally, the US under the UK-US “data bridge”), and in other cases you rely on standard contractual clauses with appropriate additional safeguards.

Most cloud AI providers have already put the infrastructure in place for this; you sign a data-processing agreement and benefit from their posture. But you should know that the obligation is yours, not theirs, and that you should record which countries your processing touches. The UK’s Information Commissioner has published guidance on transfers that is worth an afternoon’s reading if this applies to you.

The practical checklist, for an SMB adopting AI

The above is the terrain. Here is the short version of what a competently-run UK SMB deploying AI should actually do.

Map the data. Write down, in one document, what personal data is being processed, where it flows (your own systems, cloud provider, any other third parties), and where it rests. Without this, compliance is guesswork.

Update the privacy notice. Add a paragraph about the AI processing, in plain language. Mention the third parties if applicable. Link to their privacy documentation where that’s useful.

Write (or update) the lawful basis. Usually a legitimate interests assessment, one to three pages, for each processing activity. Sign and date it.

Do a DPIA if warranted. When in doubt, do one — it’s rarely wasted effort and often clarifies the design.

Sign a DPA with each processor. The cloud provider, the AI provider, the analytics tool that sees this data. They will all have a standard data-processing addendum. Have a copy on file.

Check the transfers. For each processor, note where the processing happens. If outside the UK or the EEA, confirm the transfer safeguard (adequacy, SCCs, an approved certification scheme).

Keep a record of processing activities. If you are over a certain size (generally 250 employees, or processing likely to result in risk, or processing special categories), you must. Even below that, we recommend it as hygiene.

Review quarterly. Not a heavy ritual — a calendar entry, twenty minutes, checking whether anything has changed that makes any of the above outdated.

What “the ICO” actually expects

Data-protection regulation in the UK is not a game of “check the boxes”. The ICO takes a proportionate, risk-based approach, and genuinely prefers to see businesses thinking carefully rather than filling in forms. Their enforcement activity in the SMB space has historically focused on clear failures — ignoring subject access requests, losing large amounts of data through weak security, using data for purposes that were never disclosed — rather than on the technical compliance margin.

This means a well-intentioned small business that has made honest efforts to comply, can articulate its reasoning, has documentation that shows thought (not just template-filling), and can evidence a response when something goes wrong, is broadly in a defensible position. A business that has winged it, has no documentation, and cannot tell you which third parties see its data, is not.

Where we can help

A reasonable fraction of our engagements touch this territory. We are not solicitors and we do not give legal advice. What we do, as part of a setup engagement, is make the data flows visible, flag the obvious compliance gaps, and design the system so that the compliance posture is sustainable rather than one-off. For anything genuinely legally consequential, we work alongside the client’s lawyer.

If you are about to adopt AI meaningfully in your business and you are unsure whether your compliance footing is sound, we’d be happy to talk. The diagnosis will not give you legal cover — but it will, in our experience, identify eighty per cent of the practical issues before you commit to a path.

Further reading

  • ICO guidance on AI and data protection — official, useful.
  • ICO guidance on DPIAs.
  • The ICO’s Age-appropriate design code, if your business touches anyone under 18 — surprisingly often relevant.
  • The UK Information Commissioner’s International data transfer guidance — for the transfer question specifically.

None of these are beach reading, but they are written more plainly than most regulatory material, and an hour with them will cover most of the ground you need.