Usually yes. Pasting personal data into a public AI tool is an unauthorised disclosure, which meets the UK GDPR definition of a personal data breach. Assess the risk to the people affected, and report to the ICO within 72 hours if that risk is likely. Record the decision either way, including your reasons for not reporting.
Does pasting data into a public AI tool count as a personal data breach?
In most cases, yes. The UK GDPR definition of a personal data breach covers unauthorised disclosure of, or access to, personal data, not only theft or loss. When someone pastes a client's personal data into a tool your organisation has not assessed and has no contract with, that data has been disclosed outside your control. The ICO sets out the definition and the reporting duty in its breach guide: Personal data breaches: a guide.
Two things catch people out. The first is intent. A breach does not require malice or a hacker. A paralegal trying to summarise a long statement before a deadline creates one just as effectively. The second is the assumption that a paid account changes the legal position on its own. What matters is whether the processing was authorised, whether there is a lawful basis, and whether a data processing agreement was in place before the data moved. A card on file is none of those things.
Sometimes the answer is no. If nothing in the pasted text identifies a living person, directly or combined with anything else you hold, you have a confidentiality problem rather than a data protection one. Still a problem, and I come back to it below.
What should we do in the first hour?
Establish facts, and do not destroy any. The most common mistake I see is telling the employee to delete the conversation before anyone has captured what was in it. That removes your evidence and does nothing to undo the disclosure.
Record the exact time your organisation became aware, because that is when the 72 hour clock starts. Capture what was pasted, from the screen, the browser history, or your egress logs. Work out whose data it is, how many people, and whether any of it is special category or criminal offence data. Identify the account used, personal or corporate, and which terms applied at that moment. Check whether the same thing has happened before with that person or team, because a pattern changes the risk and the remedy. Then bring in your DPO, or whoever holds that responsibility, and open the breach record.
You will not have every answer in an hour. Write down what you know, what you do not, and who is finding out.
How do we assess the risk to the individuals affected?
The test is risk to the people in the data, not embarrassment to your firm. Those two feel similar in a Monday meeting. They are not the same question.
Work through the specifics. What type of data is it, and how sensitive: a business email address sits a long way from a criminal record, bank details, or immigration status. How many people are affected, and how easily could they be identified from the text alone. What could actually happen to them: identity fraud, financial loss, distress, reputational harm, discrimination, or nothing meaningful at all. Can the fragment be combined with other information to build a fuller picture of someone. And how permanent is it: you cannot recall what was sent, so treat it as persistent.
Write the assessment down while the detail is fresh, with the reasoning and not just the conclusion. The ICO's guidance on AI and data protection is useful background.
When does it have to be reported to the ICO?
If the breach is likely to result in a risk to people's rights and freedoms, you report it to the ICO without undue delay and within 72 hours of becoming aware of it. If you conclude that a risk is unlikely, you do not report, but you must document that decision and the reasoning behind it. The ICO expects to be able to see how you got there. Separately, every breach goes into your own internal record whether it is reported or not.
Do not spend 71 hours assembling a perfect account. Partial reporting is allowed: send what you have, say what is still being established, and follow up. A late report with a tidy story reads worse than a prompt one with gaps.
Do we have to tell the client or the people affected?
There are two separate duties, and which applies depends on your role.
If you were handling that data as a processor for your client, the client is the controller. You notify them without undue delay and they decide on ICO notification. Read your contract before you read the statute, because commercial agreements routinely impose a tighter deadline than the law does, often 24 hours.
If you are the controller and the breach is likely to result in a high risk to the individuals, you have to tell those individuals without undue delay, in plain language: what happened, what data was involved, what you have done about it, and what they can do.
Tell the client early. A call where you explain what happened, what you assessed, and what you have changed is a survivable conversation. The same call six weeks later, prompted by somebody else, usually is not.
What if the data was confidential but not personal data?
Then the UK GDPR may not apply and the exposure is still real. Draft contract terms, tender pricing, source code, deal documents and board papers carry confidentiality obligations that live in contracts and NDAs, not in data protection law. There may be no regulator to notify, but there is often a contractual duty to notify the counterparty, and there is always a client who will want to know how you handled it.
If you are in a regulated sector, your own record-keeping and notification obligations sit alongside the data protection ones. That is a question for your compliance function on the day, not an assumption that silence is safe.
Can we get the data back or have it deleted?
Not in the sense people want. You can ask the provider to delete it, you should ask, and keep the response in your record. What you cannot do is verify it yourself. Deleting a conversation removes it from your view of an interface. It tells you nothing about how many systems held a copy, what was written to logs, whether a person read any of it, or what retention period applied under the terms in force that day.
So ask, keep the reply, and write your risk assessment on the basis that the disclosure happened and cannot be unwound. That gap is the real lesson here. You were relying on a description of what happens to data instead of evidence of what happened to it.
How do we stop it happening again without banning AI outright?
You replace the paste rather than forbid it: a sanctioned assistant inside your own boundary, a written rule that names data categories and tasks, and a technical control behind it. Ban the tools with nothing behind the ban and the work moves to personal phones, where you cannot see it at all. Staff paste because the tool is genuinely useful and the approved route is slower or does not exist.
Four things change the outcome. Name what is allowed in specifics, by data category and by task, not as a paragraph about using good judgement. Give people a sanctioned assistant at least as quick as the thing they were reaching for, or the policy loses on merit. Make the boundary technical as well as written, so the control does not depend on somebody remembering it at 18:00. And make use of the tool leave a record you can check afterwards, because assurance you cannot inspect is only a claim. The NCSC's guidelines for secure AI system development are a sensible reference when you are setting that up.
This is where I have spent the last few years. The Mickai Sovereign Intelligence Operating System runs on hardware the customer owns, offline capable, with no data egress. It does not make an organisation breach proof: nothing does. What it removes is the reason to paste, because the assistant is already inside the boundary, so the useful thing and the safe thing become the same action. Consequential actions wait for a named person to approve them, and each one is sealed into the Open Audit Record under ML-DSA-65, the post-quantum signature scheme NIST published as FIPS 204 in 2024. That record is tamper-evident, which is a narrower and more useful claim than tamper-proof: anyone can alter a file, and altering this one makes verification fail. An auditor exports the record and checks it offline with a public key, using tools that are not ours.
None of this is an argument against the companies building the compute and cloud layer. Cloud remains the right answer for a great deal of work. It is an argument against the assumption that a regulated organisation must rent its intelligence, ship client data offsite, then take somebody's word for what happened to it. The offline AI assistant and sovereign AI pages carry the practical detail. The closed beta is open, with one regulated company onboarding as a design partner.
Frequently asked questions
Is pasting client data into a public AI chatbot a GDPR breach?
Usually, yes. If the text contained personal data and the tool was never assessed or contracted for, that data has been disclosed without authorisation, which meets the UK GDPR definition of a personal data breach. Whether it is reportable is a separate question, answered by the risk to the people in the data rather than by how the paste happened.
Do we have to report it to the ICO within 72 hours?
Only where the breach is likely to result in a risk to people's rights and freedoms. Where it is, you report without undue delay and within 72 hours of becoming aware of it. Where it is not, you do not report, but you must document that decision and the reasoning. Every breach goes in your internal record either way.
Delete this FAQ item in full (question and answer). Its point is already made in the body paragraph beginning "Two things catch people out", which leaves five self-contained FAQ questions as the spec requires.
It can change the terms, the retention settings and whether the provider will sign a data processing agreement. On its own it does not change the breach analysis. What matters is whether that processing was authorised before the data moved, whether a lawful basis existed, and whether the agreement was actually in place at the moment of the paste.
Can we ask an AI provider to delete what was pasted?
You can ask, you should, and you should keep the reply for your breach record. What you cannot do is verify it independently. Deleting a conversation clears your view of an interface, not copies held in logs, backups or review queues. Write the risk assessment on the basis that the disclosure happened and cannot be reversed.
Should the employee face disciplinary action?
Treat the two questions separately. The breach assessment is about risk to individuals and is not improved by blaming anyone. The employment question turns on what your policy actually said, whether training existed, and whether a sanctioned alternative was available. Where there was no usable approved route, the organisation owns most of that failure, not the employee.
How do we give staff AI without this risk?
Put the assistant inside your boundary, so the useful route no longer sends client data outside it. The Mickai Sovereign Intelligence Operating System runs on hardware the customer owns, offline capable, with no data egress. Consequential actions wait for a named person to approve them, and each is sealed into the tamper-evident Open Audit Record. The closed beta is open now.
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
- AI Call Transcription and UK GDPR: What Firms Must Do
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)