A GDPR Checklist for AI Writing Tools

If an AI writing tool ever receives text containing personal data, and work email almost always does, GDPR applies. The tool becomes a processor, you remain the controller, and a specific set of obligations attaches to that relationship.

None of this is exotic. It is the same analysis you already did for your CRM and your email provider. It just gets skipped for AI tools because they arrive through a browser tab rather than through procurement.

This is a practical checklist, not legal advice. Your data protection officer is the authority for your organization.

The Nine Items

1. Identify whether personal data is involved. A colleague’s name in an email is personal data. So is a customer complaint, a CV, a meeting note naming attendees. In practice, assume yes unless the text is genuinely abstract.

2. Establish a lawful basis. Usually legitimate interests for internal operational use. Document the balancing test: what the interest is, why the processing is necessary, and why it does not override the individual’s rights. It is a short document and its absence is what regulators notice.

3. Put a data processing agreement in place. Article 28 requires a written contract with any processor. Check the vendor publishes a DPA and that it covers the plan you are actually on. Consumer tiers frequently have no DPA at all.

4. Map the transfers. Where is the processing physically done? If personal data leaves the EEA, you need a transfer mechanism: an adequacy decision, standard contractual clauses, or a valid framework participation. Establish this before use, not after an incident.

5. List the subprocessors. Most AI products are built on another provider’s model API. Your data typically reaches at least two organizations. The DPA should name them and commit to notifying you of changes.

6. Apply data minimisation. Article 5 requires you to process no more than necessary. Pasting an entire email thread to fix one paragraph fails this test. Train people to paste the paragraph.

7. Set and verify retention. How long does the vendor hold inputs, outputs, and logs? Retention should be defined and justified, not indefinite by default.

8. Preserve data subject rights. If someone requests erasure, can you comply for data sitting in a vendor’s logs? If the honest answer is no, that is a gap you need to close before it is tested.

9. Update your record of processing. Article 30 requires you to maintain one. Adding a new AI tool means adding an entry: purpose, categories of data, recipients, transfers, retention. Two lines, routinely forgotten.

Where a DPIA Becomes Necessary

A data protection impact assessment is required for processing likely to result in high risk. For AI writing tools, that threshold is generally crossed when you process special category data such as health, biometric, or trade union information, when the processing involves systematic monitoring of employees, or when it feeds decisions with legal or similarly significant effects on individuals.

A tool used to tidy the grammar of internal emails usually does not require one. A tool inserted into recruitment screening or performance evaluation very likely does.

What Local Processing Changes

If text is processed entirely on a device your organization already controls, and nothing is transmitted, the analysis contracts sharply.

There is no processor, so no Article 28 contract is required for that processing. There is no international transfer, so no transfer mechanism is needed. There is no vendor-side retention to define or erase. The data has not left the environment you already documented for that workstation.

You still have obligations, because you are still processing personal data. But they are the ones you already meet for the laptop itself: security, access control, retention within your own systems.

This is why on-device tools are often the fastest path to a compliant deployment rather than merely the most private one. Fewer parties means fewer things to paper.

Making the Ask Readable

Compliance requests fail when they arrive as a wall of article references.

Before:

Pursuant to Articles 28, 30, and 44 to 49 of Regulation (EU) 2016/679, the organization requires confirmation of the processor relationship, transfer mechanisms, and subprocessor arrangements prior to any deployment being sanctioned.

After:

Before we approve this tool, we need three things: your data processing agreement, confirmation of which countries process the data and under what transfer mechanism, and your current subprocessor list. If the tool processes text on-device with no transmission, tell us that instead and we will document it differently.

A Wrivio Context for this could say:

Rewrite this as a clear compliance request to a vendor. Professional register, complete sentences, no legal citations unless they are in the original. State exactly what documents or confirmations are needed and by when. Keep it under one hundred and fifty words. Keep every requirement, name, and date exactly as written and do not add requirements that are not in the original.

Press Ctrl+Shift+Space, paste the dense version, and check the diff. On compliance text, confirm that “required” did not become “preferred.”

Common Questions

Does GDPR ban AI writing tools?

No. It requires you to establish a basis, contract properly, control transfers, and document it.

Does the EU AI Act change this?

It adds a separate obligations layer based on risk classification. General writing assistance is low risk, but the GDPR analysis still applies independently.

Are we liable if an employee uses an unapproved tool?

As controller, generally yes. Which is why an approved alternative matters more than a prohibition.

Download Wrivio for Windows to process drafts on-device and remove the transfer, subprocessor, and retention questions from the analysis.