No AI customer service chatbot is compliant with UK GDPR on its own. Compliance comes from your lawful basis, your transparency notice, your retention rules and your transfer position. Running it on hardware you own removes the outside processor and the international transfer question. Mickai signs every consequential action into the Open Audit Record so the rest can be evidenced.
Does UK GDPR apply to an AI customer service chatbot?
Yes, in almost every deployment. The moment a customer types an order number, an address or a complaint into a box, you are processing personal data, and UK GDPR applies to that processing whether a person or a model reads it.
This is why the question in the title has an awkward answer. A chatbot is not a regulated object. The processing is what the law addresses, so "is this chatbot compliant" resolves into a set of narrower questions: what is your purpose, what is your lawful basis, what did you tell the customer, who else can read the text, how long do you keep it, and can you show any of that to someone who asks.
The ICO's guidance on AI and data protection works the same way. It applies the existing principles to AI rather than setting up a separate AI rulebook. The FCA's published approach to AI is similar in spirit for regulated firms: existing requirements apply, and the regulator does not certify or approve an AI tool as compliant. So when a supplier tells you their chatbot is GDPR compliant, they are describing features of their product. They are not describing your processing, and they are not carrying your liability.
What lawful basis covers chatbot conversations?
For handling an enquiry from an existing customer, most UK firms land on performance of a contract or on legitimate interests. Consent is usually the wrong basis for the core support function, because a customer who cannot decline and still get help has not freely given anything.
The basis attaches to the purpose, not to the software. Answering the enquiry is one purpose. Quality monitoring is another. Training or tuning a model on the transcript is another again, as are product analytics and any marketing follow-up. Each needs its own basis, its own entry in your record of processing, and its own retention period. Firms get into trouble by writing one basis for "the chatbot" and then quietly using the same data for three things.
Special category data is the other live issue. Customers volunteer financial hardship, criminal matters and other special category details unprompted, in the first message, without being asked. Either you have an Article 9 condition for holding that, or you design the flow so it is not retained. Write the legitimate interests assessment down. It is short, and it is the first thing anyone will ask for.
What must you tell customers before they start typing?
That they are dealing with an AI system rather than a person, and what happens to the words they type. The first is what the ICO expects of a fair and transparent AI deployment. The second is what Articles 13 and 14 require, and neither is satisfied by a privacy policy three clicks away when the disclosure matters at the exact moment someone is deciding what to disclose.
In practice the inline notice needs to be short and the linked notice needs to be complete: who the controller is, the purposes and bases, retention, whether text is used to train anything, which processors are involved, whether data leaves the UK, how to reach a human, and how to exercise rights. Do not bury the escalation route. A customer who wants a person and cannot find one becomes a complaint, and complaints about AI support tend to arrive with a data protection question attached.
Version and date every notice, and keep the superseded ones. An auditor will not ask what your notice says today. They will ask what it said in March, when the conversation they are looking at took place.
Where does chatbot data go, and who else can read it?
In a hosted deployment it goes to your supplier, to whoever hosts the model for them, and often to further sub-processors behind that. Mapping that chain and contracting for it properly is most of the work, and it is where the difficult answers sit: sub-processor changes, supplier staff access for debugging, how long they retain prompts on their side, and restricted transfers outside the UK.
None of that is unmanageable. It is a standing obligation that has to be maintained, re-papered when the supplier's stack changes, and explained to a regulator who reads your transfer risk assessment more carefully than your marketing.
We took the other route. Mickai's Sovereign Intelligence Operating System runs on hardware the customer owns, is capable of operating offline, and does not send data out. That does not make anyone compliant, and I will not pretend otherwise. What it does is delete a category of question: there is no third-party processor reading support conversations, and no restricted transfer to assess, because nothing left the building. Cloud stays valuable for work that is not regulated. What I dispute is the assumption that a regulated organisation has to rent its intelligence, ship customer conversations offsite, and take a vendor's word for what happened to them. There is more on that on our sovereign AI page.
One honest caveat, since support queues attract attachments. A local OCR runtime has read scanned PDFs in controlled tests, but extraction and ingestion into SIOS is still being completed, so I would not build a document-heavy support flow on it yet.
How long should chat transcripts and prompts be kept?
There is no statutory number. Storage limitation requires you to set a period for each purpose, justify it, and actually delete on schedule, which is the part that fails most often.
Run separate clocks. The live transcript supports complaint handling and has a short life. Aggregate analytics can usually survive on figures rather than text. Regulated firms normally carry record-keeping obligations that outlast anything a support team would keep on its own, so reconcile the two before go-live rather than discovering the conflict during an erasure request.
The hard case is what the model retains. If transcripts feed tuning, deleting the transcript does not necessarily remove its influence from the resulting weights. Decide before launch whether customer text trains anything, because that decision is expensive to reverse.
Keep the evidence store separate from the content store. In SIOS the Open Audit Record holds a signed record that an action occurred, who approved it and when. That is a different thing from the conversation itself, and separating them is what lets you honour a deletion request without destroying the proof that you handled the case properly. Where exactly that line sits is a design decision to settle with your DPO, early.
Is the chatbot making a solely automated decision?
Sometimes, and it changes your obligations when it does. If the system closes a complaint, refuses a refund, or alters a customer's standing with no meaningful human involvement, you are in Article 22 territory rather than ordinary support.
This is also the area in motion. The Data (Use and Access) Act 2025, on legislation.gov.uk, rewrites the UK's automated decision-making provisions, with commencement handled through regulations rather than all at once, and parts of the ICO's AI guidance carry a note that they are under review as a result. I am not going to state a date here. Check the position with your DPO or counsel at the time you deploy, because the answer in this paragraph has a shelf life and your deployment does not.
The design that survives either version is the same. Consequential actions in SIOS wait for a named person to approve them, and the approval is recorded against that person's identity. Answering a delivery question does not need that. Closing a complaint does. Drawing that line explicitly, action by action, is more useful than arguing about whether a support bot counts as a decision-maker.
What evidence will the ICO or an internal auditor ask for?
Documents first, then proof that the documents describe what actually happened. Expect to produce the DPIA, the record of processing, the lawful basis assessment, dated notice versions, the retention schedule, processor contracts and the transfer assessment.
The gap is in the second half. Paper describes intent. Logs describe reality, and application logs are normally written by the same system whose behaviour is under question, stored where a sufficiently privileged administrator can edit them. Asking a firm to prove what its AI did, using records that firm could have rewritten, is not much of a control.
That is the problem the Open Audit Record exists to close. Every consequential action is sealed under ML-DSA-65, the post-quantum signature scheme NIST published as FIPS 204 in 2024. You export the record and your auditor verifies it offline, with a public key, using tools that are not ours. The distinction matters: this is tamper-evident, not tamper-proof. I cannot stop someone with enough access from altering a record. I can make sure the altered record fails verification, which turns a silent edit into a finding.
Our closed beta is open, with one regulated company onboarding as a design partner. If you are working through the questions above for a support deployment, those are the conversations worth having.
Frequently asked questions
Does running a chatbot on our own servers make us UK GDPR compliant?
No. It removes the outside processor and restricted transfer questions, and it narrows who can read customer conversations. Everything else still applies: lawful basis, transparency, minimisation, retention, rights handling and a DPIA where one is needed. Self-hosting is a strong answer to one set of questions, and no answer at all to the rest.
Do we need consent to use an AI chatbot for customer support?
Usually not for the support itself. Most firms rely on performance of a contract or on legitimate interests, because consent a customer cannot refuse without losing help is not freely given. Consent becomes relevant for separate purposes, such as marketing follow-up, and for special category data, where an Article 9 condition is required instead.
Can we use customer chat transcripts to improve the AI?
Only if you decided that in advance, told customers plainly, recorded a basis for that specific purpose and can honour an objection. Treat training as separate from answering the enquiry. Remember that deleting a transcript later does not necessarily remove its influence from a model already tuned on it, so the default you set matters.
Do we need a DPIA for a customer service chatbot?
Usually yes. The ICO treats innovative technology, including AI, and large scale processing of special category data or large scale profiling as triggers, and most AI support deployments touch at least one. Do it before launch rather than after. The DPIA is where you settle retention, the route to a human, and what the model is permitted to keep from a conversation.
Who is the controller if the chatbot supplier hosts the model?
You almost certainly are, for the customer conversations, because you decide the purpose and the means that matter. The supplier is normally your processor. A supplier that also uses your data to improve its own product may become a controller for that purpose, which is worth reading their terms and their sub-processor list for closely.
Related briefings
Data protection and UK GDPR
- UK GDPR and AI: Does Your Data Have to Stay in the UK?
- UK Data Storage vs AI Processing: What Is the Difference
- Controller or Processor? AI Suppliers and UK GDPR Roles
- Right to Erasure in an AI Knowledge Base: How to Comply
- Employee Pasted Client Data Into AI: Is It a Breach?
Governance, audit and oversight
- Tamper-Evident vs Immutable Log: The Real Difference
- Human on the Loop vs In the Loop: AI Oversight Explained
Part of a series of 60 briefings on deploying and governing AI in UK regulated organisations, archived with a DOI at 10.5281/zenodo.22975756.
Evaluating AI for a regulated organisation? Mickai runs on hardware you own, offline. Consequential actions wait for a named person to approve them, and what the AI did is sealed into a signed record an auditor can check without us. Applications for the invitation-only closed beta are open. Apply for the closed beta.
Written by Micky Irons, founder and chief executive of Mickai LTD.
Top comments (0)