Svennis AI
9 min read

UK GDPR for an AI assistant and what to check before you deploy one

Before an AI assistant touches customer or staff data, settle roles, lawful basis, the DPIA, decision rules, access, data location and retention. This guide gives you the checklist.

Abstract layered shapes passing through a series of gates, suggesting data checked at each stage before moving on

UK GDPR for an AI assistant comes down to six checks before launch

Getting UK GDPR for an AI assistant right means settling six things before launch. You need to decide who is controller and who is processor, and which lawful basis covers each purpose. You also need to know whether a DPIA is due and whether the assistant decides things about people. Finally, settle who can see what and how long records are kept.

An AI assistant is a tool that uses a generative AI model to answer questions, draft replies or route requests. It works on the customer or staff data you connect to it. The UK government's AI Playbook names Claude, ChatGPT and Gemini among the publicly accessible generative AI tools.

Buying a ready-made assistant does not hand your obligations to the vendor. The ICO says you need a lawful basis whenever you process personal data. That applies whether you train a system or make predictions with an existing one. Data protection law also applies when you use a model on a person, even if their data was never in the training set.

This guide is not legal advice. For the text of the articles themselves, see our annotated guide to the key UK GDPR articles for AI.

Controller and processor roles must be named in the contract

For an AI assistant, you are usually the controller: the organisation that decides why and how personal data is processed. The AI vendor is usually a processor, meaning a third party that processes the data on your behalf and on your instructions. Buckinghamshire Council's privacy notice for its AI virtual assistant sets this out plainly. The Council is the controller, each supplier is a processor, and a signed agreement is in place with each one. The ICO puts the same point as an obligation in its guidance on AI in recruitment. You must identify who is controller and who is processor. That split must be recorded clearly in a contract with the provider and scrutinised carefully. If the provider is a processor, you must give it explicit and comprehensive written instructions. Those instructions are where you shape how the assistant behaves. The ICO suggests you could add performance measures, such as statistical accuracy and bias targets. For an assistant drafting replies in Zoho Desk, the instructions would name the ticket fields it may read and the actions it may take. They would also state what it must never do with the data. Check one clause with particular care: whether the vendor uses your data to improve its own products. Buckinghamshire states that none of the personal data is used solely by the AI provider to improve its AI products. If a supplier cannot give you a clear answer, treat that as a finding. Our guide to judging an AI supplier by results in production covers the other questions to ask.

Lawful basis is chosen per purpose, not once for the whole assistant

A lawful basis is the legal ground under Article 6 of UK GDPR that permits a given use of personal data. An AI assistant usually serves several purposes: answering a customer, logging the conversation, quality checks and perhaps improving the service. Each purpose needs its own basis. The ICO's guidance on lawfulness in AI makes four points that matter for assistants:
  • Development and deployment are distinct purposes. It may be more appropriate to choose a different lawful basis for each.
  • If you implement a third party's system, the developer processed data for a different purpose. You may need a different basis from the one it used.
  • If you rely on consent during deployment, people must be able to withdraw it as easily as they gave it.
  • You are unlikely to be able to rely on performance of a contract for "service improvement" of your AI system.
Legitimate interests is the ICO's "most flexible" basis, but it warns that it is not always the most appropriate one. Buckinghamshire Council shows what a per-purpose approach looks like in practice. Its notice for the virtual assistant and live chat lists consent, contractual obligation, legal obligation and public task. A private business will not use public task. The method still transfers: write down each purpose and match it to one basis.

Special category data and AI inferences need a second legal condition

Special category data is personal data that needs more protection because it is sensitive, such as health, racial or ethnic origin data. To process it, you need a lawful basis under Article 6 and a separate condition under Article 9. The ICO notes the two do not have to be linked. An AI assistant can create special category data without anyone typing it in, by inferring it. The ICO added content on inferences, affinity groups and special category data to its lawfulness chapter. Its guidance no longer treats how certain an inference is as a factor in deciding whether it counts as special category data. The ICO says its underlying position has not changed. The practical effect is simple. If your assistant might conclude that a customer is ill or of a particular religion, plan as if it holds special category data. Some organisations rule this out entirely. The Single Source Regulations Office says it does not use AI on special category personal data. Fairness sits alongside this. The ICO's audit of AI recruitment tools found some let recruiters filter out candidates with certain protected characteristics. The Equality Act 2010 lists those characteristics, including age, disability, race, religion or belief, sex and sexual orientation. Test your assistant's outputs against them before launch.
An assistant handling health or ethnicity data needs an Article 9 condition on top of its lawful basis. Article 6 lawful basis / Article 9 condition. Covers: Any use of personal data / Special category data, such as health or ethnic origin; When need

A DPIA for an AI assistant belongs at the procurement stage

A Data Protection Impact Assessment (DPIA) is a structured assessment of the risks a processing activity poses to people and how you will reduce them. The ICO says a DPIA should be carried out before you use an AI tool, ideally at the procurement stage. It also says a DPIA helps you ask the right questions of your provider. Timing matters because a DPIA done after launch tends to justify decisions already made. Done during procurement, the same questions change what you buy and how you configure it. Where will transcripts live? Can the vendor reuse them? Which fields can the assistant read? Who reviews its answers? The ICO has added new content on what to consider in a DPIA to the accountability and governance chapter of its AI guidance. Use that chapter as your question list. Then work through the threats the government's AI Playbook names as specific to AI: data poisoning, perturbation attacks, prompt injections and hallucinations. At Svennis we start the DPIA in the same workshop where we map which systems and fields the assistant will touch. The answers then set the build scope instead of being written up afterwards. When we review assistants built elsewhere, the missing piece is usually an early decision about what the assistant should never see.

Automated decisions about people need a named human reviewer

Automated decision-making means a system makes a decision about a person without meaningful human involvement. It is the point where an AI assistant most often moves from low risk to high risk. Since 5 February 2026, Articles 22A to 22D of UK GDPR have replaced Article 22 for significant decisions based solely on automated processing. Those articles allow such decisions more widely, but only with safeguards. You must tell people about the decision and let them make representations and challenge it. You must also give them a way to get human intervention. The ICO's fairness chapter still has useful questions, but it was written for the old Article 22. Treat the detail with care at the moment. The ICO says its AI guidance is under review because of changes made by the Data (Use and Access) Act, and may be subject to change. Check the current text before you rely on any summary, including ours. Public bodies using AI keep humans in the decision. Buckinghamshire Council states that AI tools are not used in decision-making and that Council officers make all decisions. The SSRO says staff review and approve all Copilot outputs before use. Two further points apply if your assistant does influence outcomes. The AI Playbook says humans should validate any high-risk decisions influenced by AI. In recruitment, the ICO says candidates must be told how they can challenge automated decisions made by the tool. The Playbook also recommends labelling automated replies, with wording such as "this response has been written by an automated AI chatbot".

Access controls and data location limit what an AI assistant sees and where it goes

The safest data for an AI assistant is data it never receives. The ICO's recruitment audit found tools that collected far more personal information than necessary. Start instead from the smallest set of records and fields the task needs, and grant access to those alone. In practice, an assistant should act with a service account whose permissions you can list. If it reads from Zoho CRM, restrict it to the modules and fields its task requires. The SSRO takes a similar line with classification. It only uses AI on information classified at the OFFICIAL level, and classification stays entirely a human job. Data location is the other half. A transfer happens when personal data goes to a country outside the territorial scope of UK data protection law. Ask every supplier in the chain where data is stored and processed. Buckinghamshire states that its data is stored and processed in the UK or EU, and still records that it transfers data outside the UK, including to EEA countries. The SSRO says Copilot data stays within its Microsoft 365 tenancy and is not used to train Microsoft's models. One UK detail catches teams using EU material. The ICO says European Data Protection Board guidelines are no longer directly relevant to the UK regime and are not binding under it. Base your transfer assessment on UK sources.

Retention rules for AI assistant transcripts should be set before launch

Every AI assistant produces records: transcripts, summaries, tags and sometimes scores. Each needs a retention period and a way to delete it. The ICO's recruitment audit found tools that kept personal information indefinitely, building large candidate databases without people's knowledge. That is the failure to design out. Buckinghamshire Council's notice shows three decisions worth copying:
  • What is kept: normally a summary of the interaction, with a full copy only where appropriate.
  • What is derived: an AI-determined sentiment rating (positive, neutral or negative) stored against the chat.
  • How long: live chat conversations are deleted automatically after two years.
The derived data deserves attention. A sentiment score is personal data about the customer once it is stored against their conversation. It needs the same retention rule as the transcript. If your chat runs through Zoho SalesIQ and feeds a helpdesk, both systems hold copies, and both need a rule. Retention should also match the purpose. Buckinghamshire uses chat information for training, audit and quality assurance, among other purposes, and says so. If you keep transcripts to check the assistant's quality, say so in your notice and keep them only as long as the review needs. Our post on measuring an AI assistant by outcomes covers which records a quality review actually needs.

Worked example: Buckinghamshire Council's AI virtual assistant notice

Buckinghamshire Council's privacy notice for its AI Virtual Assistant and live chat answers most of the checklist in one public page. Read it against your own plans, one heading at a time.

Roles

The Council is the controller. Its processors include its customer relationship management tools provider and its AI virtual assistant and live chat provider.

Decisions

AI tools are not used in decision-making, and the Council states it carries out no automated decision-making on this information.

Vendor reuse and location

No personal data is used solely by the AI provider to improve its products. All data is stored and processed in the UK or EU.

Retention

A summary is normally kept, a full copy where appropriate, and live chat is deleted after two years.

To apply this, write your own version of each heading before you sign with a vendor. A heading you cannot fill in is an open question for the supplier or for your DPIA. The finished text also becomes most of your privacy notice.
Buckinghamshire Council's notice settles roles, basis, decisions and retention on one public page. What the notice states. Roles: Council is controller; CRM and AI chat providers are processors; Contracts: Signed agreement in place with each supplier

The UK GDPR checklist for an AI assistant, in one table

The table below gathers the checks from this guide, with the question to answer and the record to keep for each. Work through it with whoever owns data protection in your organisation, and with the supplier for the rows that concern them.
CheckQuestion to answerRecord to keep
RolesWho is controller, who is processor, for each supplier?Signed contract with written processing instructions
Vendor reuseCan the vendor use your data to improve its products?Contract clause or written confirmation
Lawful basisWhich Article 6 basis covers each purpose?Purpose list with one basis each
Special categoryCould the assistant receive or infer sensitive data?Article 9 condition, or a documented exclusion
DPIAHas the assessment been done before procurement closes?DPIA with a review date
DecisionsDoes the assistant decide anything about a person?Named human reviewer and challenge route
AccessWhich records and fields can it read or change?Permission list for the service account
LocationWhere is data stored and processed, and does it leave the UK?Supplier data map and transfer assessment
RetentionHow long are transcripts, summaries and scores kept?Retention schedule and deletion method
TransparencyDo people know they are talking to AI?Privacy notice and on-screen label
A row with no record to point to is not finished. Treat it as a blocker for launch, not a task for later.

What UK GDPR means for an AI assistant in a UK business today

For a UK business, the law on AI assistants is settled. All the data protection changes in the Data (Use and Access) Act are now in force. What is still moving is the ICO's guidance, which it says is under review because of the Act. The core duties in this guide still apply: a lawful basis, clear roles, fair processing and sensible retention. The ICO's main AI guidance was last updated on 15 March 2023, after UK industry asked for clarity on fairness. The ICO itself expects further updates because technology is developing quickly. Date-stamp your DPIA and review it when the ICO publishes changes. UK businesses should also stop borrowing EU guidance by default. A policy copied from an EU parent company may need rewriting. Public bodies carry extra duties that private firms can learn from. Central government departments and in-scope arm's length bodies must use the Algorithmic Transparency Recording Standard. The SSRO appointed a Responsible AI Senior Officer and a working group to oversee its AI use. A small business does not need that structure, but it does need one named person who owns the assistant's data protection records. Sector rules add more on top: accountants, for example, work under the money laundering regulations as well. Our page on AI for accountants in the UK shows how that plays out.

Next steps before you deploy an AI assistant

Take the checks in order. Each one depends on the one before it.
  1. List the purposes the assistant will serve and the systems it will read from.
  2. Name the controller and each processor, and ask every supplier where data is stored, where it is processed and whether they reuse it.
  3. Match each purpose to one lawful basis, and decide whether special category data is in or out.
  4. Start the DPIA now, using the ICO's accountability chapter as your question list.
  5. Decide which outputs a person must approve, and who that person is.
  6. Set retention periods for transcripts, summaries and any scores, then confirm deletion runs.
  7. Draft the privacy notice using Buckinghamshire Council's headings as a model.
If you cannot fill in a row of the checklist table, stop there and resolve it before building further. Changing scope costs little at this stage and a great deal after launch. When the data protection groundwork is clear, the next question is which tasks the assistant should take on first. Our overview of AI automation for growing businesses shows how we connect assistants to the systems you already run, with access and retention covered as part of the build.

Sources

  1. 1. ICO: Guidance on AI and data protection
  2. 2. ICO: How do we ensure lawfulness in AI?
  3. 3. ICO: Thinking of using AI to assist recruitment? Our key data protection considerations
  4. 4. Buckinghamshire Council: Privacy for our AI Virtual Assistant and live chat
  5. 5. Single Source Regulations Office: SSRO's approach to responsible AI use
  6. 6. GOV.UK: Artificial Intelligence Playbook for the UK Government
  7. 7. legislation.gov.uk: Equality Act 2010
  8. 8. legislation.gov.uk: The Money Laundering, Terrorist Financing and Transfer of Funds (Information on the Payer) Regulations 2017

Related articles