AI and GDPR: what you can and cannot do with customer data
How data protection rules apply when customer data goes into AI tools: bases, minimisation, transparency, transfers and the lines not to cross.
The short answer
Sending customer data to an AI tool is processing personal data, and the ordinary rules apply: a purpose, a legal basis, only the data the purpose needs, transparency to the people concerned, a processing agreement with the provider, a lawful position on where the data is processed, retention limits, and security. None of that is exotic, and most business uses of AI on customer data can be built to satisfy it. What fails in practice is almost never the legal analysis and almost always the tool choice: staff using personal consumer accounts whose terms permit the provider to train on inputs, which turns a routine drafting task into an unlawful disclosure. The second failure is scope creep, sending whole records when three fields would do. Special category data, health, biometrics, and the rest, needs a specific condition and in a small business should stay out of general AI tools entirely. And decisions about people stay with people, both because of the rules on automated decision-making and because it is the right design.
Applying the rules to AI uses
| Requirement | What it means for AI | Common failure |
|---|---|---|
| Purpose | Define what the AI use is for, specifically | Vague adoption of a general assistant |
| Legal basis | Contract, legitimate interest properly balanced, or consent where required | Assuming consent is needed, or assuming nothing is |
| Minimisation | Send only the fields the task needs; pseudonymise where possible | Pasting whole records or full email threads |
| Transparency | Say in the privacy statement that AI tools are used and for what | Silence |
| Processor agreement | With the AI provider, with training excluded and retention limited | Consumer accounts with no agreement |
| Transfers | Know the processing location; use a lawful mechanism | Unknown region |
| Retention | How long the provider keeps prompts and outputs | Unlimited by default |
| Security | Access control, secrets, logging of what was sent | No record of what was processed |
| Automated decisions | Keep a human deciding anything significant about a person | A model ranking or scoring people |
| Special categories | A specific condition; usually keep out of general tools | Health details in a chat assistant |
Building AI uses that hold up
- Write the rule first: which tools are approved, under which terms, for which data classes.
- Move everyone to business accounts with training excluded and processing agreements in place.
- Minimise at the integration: send fields, not records; strip identifiers the task does not need.
- Choose processing locations deliberately and document them.
- Set retention with the provider where configurable.
- Update the privacy statement to describe the AI processing plainly.
- Keep decisions human for anything affecting a person significantly, with reasons recorded.
- Log what was sent, so you can answer a question about a specific customer later.
- Assess before starting anything higher risk, with an impact assessment where required.
Where the line is
Using AI to help serve a customer, drafting a reply to their message, summarising their file for the person handling it, extracting data from a document they sent, is ordinarily defensible with the right tool and minimisation. Using AI to profile customers for marketing, to score or rank them, to infer sensitive characteristics, or to make decisions about them without a person, crosses into territory that needs a specific basis, an impact assessment, and in some cases is prohibited outright. If a use is closer to the second list than the first, get advice before building it.
What this means for you
AI on customer data is ordinary processing with ordinary requirements: purpose, basis, minimisation, transparency, processing agreement, known location, retention, security. The practical work is the tool rule and business accounts, minimising what you send, updating the privacy statement and keeping decisions about people with people. Avoid training on identifiable customer data; ground instead. This is general information rather than legal advice; higher-risk uses need a qualified opinion.
Frequently asked questions
Can we paste customer emails into an AI assistant to draft replies?
Only into a tool operating under business terms that exclude training on your data, with a processing agreement, appropriate processing location and retention limits, and after minimising what you send. Under those conditions, drafting a reply to a customer's message is ordinarily a defensible processing activity connected to serving them. Into a personal consumer account it is an unlawful disclosure of their data to a third party, which is the situation wherever staff use personal accounts.
Do we need consent to use AI on customer data?
Not usually as a separate consent. The processing still needs a basis, and where AI is a means of delivering the service the customer asked for, or a legitimate interest properly balanced, consent is not the right basis. Where the processing goes beyond what the customer would expect, such as profiling for marketing, you need the appropriate basis for that purpose. What you always need is transparency: your privacy statement should say that AI tools are used and for what.
What about training a model on our customer data?
That is a further purpose beyond the original collection and needs its own analysis: is it compatible with the purpose the data was collected for, what is the basis, what are the rights implications, can the data be removed from a model later. The workable answer for a small business is to avoid training on identifiable customer data entirely, and to use grounding and retrieval instead, which keeps the data in your systems and out of the model.
Sources
- EUR-Lex: Regulation (EU) 2016/679 (accessed 2026-09-12)
- Autoriteit Persoonsgegevens: Algoritmes en AI (accessed 2026-09-12)