ChatGPT at work: what data protection law actually requires
ChatGPT is already in use in most companies — often with no contract, no rule and no knowledge on the part of the management. Using it for work is not prohibited. It is conditional, and the conditions can be met in a single morning.
By Patrick de Kathen, Founder of KlarComply · Reviewed on
The starting point: permitted, but not unconditional
There is no provision that bans the use of generative AI in a business. What applies is ordinary data protection law, and it asks three questions. On what legal basis are you processing? Who is processing on whose behalf? And are the data adequately protected while that happens?
As long as no personal data goes into the tool, the GDPR is not engaged at all. That is the normal case for drafting help, brainstorming, code explanations or summarising publicly available text. The moment a customer name, an email address, a job application or a meeting transcript goes in, it applies in full.
The distinction that simplifies everything
Separate two kinds of use and regulate only the second one strictly:
- Without personal data — draft text, translations with no names, idea generation, explanations. Unproblematic in data protection terms. What remains here is the trade secrets question, dealt with below.
- With personal data — anything from which a person can be identified. Legal basis, processor arrangements, data subject rights and documentation duties all apply.
The practical effect: around eighty per cent of everyday office use falls into the first category. Treating both alike produces a rule nobody follows.
Free personal account or business agreement — the decisive difference
The most common mistake is not the use. It is the account. A personal free account is generally unsuitable for work content, for four reasons at once.
| Criterion | Personal free account | Business agreement (Team, Enterprise, API) |
|---|---|---|
| Data processing agreement | generally not concluded | available, often pre-drafted and attached |
| Inputs used to improve models | depends on a setting, often on by default | usually excluded in business tiers |
| Control by the company | none — the account belongs to the individual | central administration, access can be withdrawn when someone leaves |
| Ability to evidence anything | no logs, no contractual documents | contract, configuration and user list can be produced |
Check the actual terms of your own tier in the provider's contractual documents, not in a blog post. Provider terms change, and they differ considerably between product lines from the same house.
Processing on your behalf: Article 28 GDPR
Where personal data goes into an AI tool, the provider processes those data for you. That is normally a processor relationship, and Article 28(3) GDPR requires a contract with defined content: subject matter, duration, nature and purpose, categories of data, the obligation to act only on instructions, confidentiality, security, sub-processors, assistance with data subject rights, deletion at the end of the contract, and the duty to make information available for audits.
Most large providers make a corresponding document available, concluded or downloaded from the account area. Two points are regularly overlooked:
- Who is your counterparty? Where a provider has several group entities, this determines which law applies and whether a third-country transfer arises. Record the name in your AI inventory.
- Sub-processors. AI providers rely on data centre operators. Check whether the list is visible and whether you are notified of changes.
Third-country transfers — look it up rather than assume it
Where data flow to the United States or another third country, you need a basis under Chapter V of the GDPR. The options are an adequacy decision of the European Commission — for certified US organisations, the EU-US Data Privacy Framework — or standard contractual clauses with a supplementary transfer impact assessment.
This area moves. Earlier decisions have been annulled by the Court of Justice. Record therefore which basis you rely on and when you last checked it. That is precisely what you will be asked.
If you are established in the UK, the equivalent questions arise under the UK GDPR, with its own adequacy regulations and the international data transfer agreement or addendum. The structure of the assessment is the same; the instruments have different names.
Article 32 GDPR: the provision that governs daily practice
Article 32 requires technical and organisational measures appropriate to the risk. That sounds abstract. In an AI context it is very concrete. A central organisational measure is that staff know which data they may enter.
So the training question does not hang on the AI Act alone. Article 4 of the AI Act carries no separate fine — the reason is set out here. Article 32 GDPR very much does: breaches fall under Article 83(4) GDPR. Anyone asking where the real exposure sits will find it at this point, not in the AI Act.
In practice Article 32 in an AI setting calls for:
- a written rule stating which categories of data may be entered and which may not
- business accounts rather than personal ones, centrally administered and revocable when someone leaves
- two-factor authentication on those accounts
- a documented briefing of the people who use the tools
- a route for reporting mistaken entries that carries no consequences
Legal basis: which one do you need, and for what?
Processing needs a basis under Article 6 GDPR. Three come into play in ordinary AI use.
| Situation | Basis | Note |
|---|---|---|
| Preparing contract-related correspondence with customers | Art. 6(1)(b) — performance of a contract | Only so far as the AI use is necessary for performance; often (f) is the better fit |
| Internal analysis, draft text referring to customers | Art. 6(1)(f) — legitimate interests | Record the balancing exercise; three sentences is usually enough |
| Employee data | contested | see the box below |
Employee data: the position is genuinely unsettled
Article 88 GDPR allows member states to provide more specific rules for processing in the employment context, by law or by collective agreement. They have used that opening clause very differently. Some states enacted a dedicated employment data provision; others rely on the general bases in Article 6. The Court of Justice has held that a national provision does not create an independent legal basis alongside Article 6 unless it genuinely goes beyond the regulation and contains suitable safeguards. Several national provisions have been questioned in the literature as a result.
What that means in practice. Do not build your position on a national employment-data provision alone. Check Article 6(1) GDPR in addition, and where you have staff in more than one country, expect the answer to differ between them. Above all, take legal advice before introducing AI-supported assessment of employees — such systems may also fall in the high-risk area, see classifying AI risk.
Records, impact assessment, data subject rights
Record of processing activities
If you use an AI tool for personal data, that processing belongs in your record under Article 30 GDPR — either as its own entry or as an addition to the existing activity within which the AI is used. The latter is usually cleaner, because the purpose has not changed.
Data protection impact assessment
An assessment under Article 35 GDPR is not automatically required just because AI is involved. It becomes necessary where the processing is likely to result in a high risk — systematic evaluation of individuals, large-scale processing of special categories, or systematic monitoring. For drafting text that occasionally contains a customer name, it generally is not.
Check your supervisory authority's list as well. Under Article 35(4) GDPR, authorities publish lists of processing operations for which an assessment is always required, and those lists are not identical across member states.
Data subject rights
You have to be able to satisfy access, rectification and erasure requests — including for data that reached an AI tool. So clarify before approval: can conversation histories be deleted selectively? Is there a retention period? Can retention be switched off? Those three answers belong in the AI inventory.
The second risk: trade secrets
Data protection is only half of it. The other half concerns pricing models, formulations, bid strategies and source code. Where such content goes into a tool with no confidentiality undertaking, the protection as a trade secret can fall away, because Directive (EU) 2016/943 requires that the information has been subject to reasonable steps under the circumstances to keep it secret. The mechanism is explained in detail on trade secrets and AI tools.
The rule you need in writing
One paragraph in your AI policy covers the data protection side, provided it is specific. Abstract phrasing such as “no sensitive data” is not followed, because nobody knows what it means.
Wording that holds up day to day
“Approved AI tools must not be given customer names, addresses, contract numbers, application documents, health data, pricing calculations, or any third-party material held in confidence. Anyone who needs to work on content containing such details replaces them with placeholders beforehand. If in doubt, ask [role]. Anyone who has entered something by mistake reports it to [role] without delay; a prompt self-report carries no consequences.”
The placeholder sentence is the most effective one in there. It does not forbid the work; it shows the permitted route. That is why it gets followed.
What you expressly do not need
- No consent from your customers merely because you use an AI tool in the background. What matters is the legal basis for the processing itself, not which program performs it.
- No blanket ban. Bans produce shadow AI. What works instead is on shadow AI in the workplace.
- No impact assessment for every AI use. Only where a high risk is likely.
- No line in your privacy notice saying “we use AI”. Articles 13 and 14 GDPR require purposes, legal bases and recipients. A provider to whom personal data flow is a recipient and belongs there by name. The word “AI” as such is not a required disclosure.
- No AI label under every email. What actually has to be disclosed is set out on labelling under Article 50; free labels for the cases that genuinely arise are on our AI labels page.
Implementation in one morning
- Take stock: who uses which account? Identify the personal ones.
- Take out a business tier, create users centrally, and stop personal accounts being used for work content.
- Conclude the data processing agreement and file it. Note the counterparty and the date.
- Check the settings: use of inputs for model improvement, retention period, logging.
- Add the entry to your record of processing activities.
- Write the rule, present it to the team, record acknowledgement.
- Record the outcome with a date — that is your evidence.
How far you have got takes two minutes to establish with the free quick check. If a customer questionnaire is what brought you here, the twelve standard questions are worth reading in the same sitting.
Frequently asked questions
Is using ChatGPT for work permitted under the GDPR?
Yes, subject to conditions. Without personal data the GDPR is not engaged. Once personal data are entered, you need a legal basis under Article 6, normally a processor contract under Article 28, appropriate measures under Article 32, and a basis for any third-country transfer under Chapter V.
Is a free ChatGPT account good enough for work?
For work content, generally not. There is no data processing agreement, inputs may be used to improve models, the company has no control over the account and cannot evidence anything. For purely private use with no connection to the business, none of that matters.
Do we need a data processing agreement with the AI provider?
As soon as personal data reach the tool, yes. Article 28(3) GDPR sets out what it must contain. The large providers make a document available; check which group entity is your counterparty and whether the list of sub-processors is visible.
Do we have to carry out a data protection impact assessment?
Not simply because AI is involved. It becomes necessary under Article 35 GDPR where a high risk is likely — systematic evaluation of individuals, large-scale processing of special categories, systematic monitoring. Check your authority's Article 35(4) list as well, since those lists differ between member states.
May staff enter customer data into ChatGPT?
Only where the legal basis, the processor contract and the protective measures are in place and the internal rule permits it. The more practical route is placeholders: replace names, addresses and contract numbers before entry. That largely removes the data protection question.
What applies to employee data?
The position is unsettled. Article 88 GDPR lets member states adopt more specific rules for the employment context, and they have done so very differently. The Court of Justice has held that a national provision is not an independent legal basis alongside Article 6 unless it genuinely goes further and adds safeguards. Do not rely on a national employment-data provision alone, and take legal advice before introducing AI-supported assessment of employees.
Do we have to mention in our privacy notice that we use AI?
The word AI is not a required disclosure. Articles 13 and 14 GDPR require purposes, legal bases, recipients and, where relevant, third-country transfers. A provider to whom personal data flow is a recipient and belongs there by name.
We are outside the EU. Does any of this apply to us?
The GDPR reaches you under its own Article 3 where you offer goods or services to people in the Union or monitor their behaviour, and the UK GDPR applies its own equivalent test. Separately, the AI Act reaches you under Article 2 where the output of your AI system is used in the Union. The two questions are independent and both are worth answering.
Where does your company stand?
The free quick check walks through ten points — AI inventory, training status, transparency duties, responsibilities. Two minutes, no sign-up, an honest result and your concrete gaps.
Start the quick check — freeArticle 28 GDPR — processor
Article 32 GDPR — security of processing
Article 35 GDPR — data protection impact assessment
Article 88 GDPR — processing in the employment context
Article 6 GDPR — lawfulness of processing
Directive (EU) 2016/943 — protection of trade secrets
European Data Protection Board — guidelines and recommendations