A practical GDPR checklist for AI tools
Most GDPR problems with AI tools trace back to skipping one of five questions before signing up, not to some exotic edge case. This is a working checklist for the evaluation you'd want to run on any AI tool before it touches personal data, not a substitute for counsel. Not legal advice; verify current requirements against the regulation text and your own DPO or lawyer before relying on any of this for a compliance decision.
1. Lawful basis for processing
GDPR requires a lawful basis before you process personal data at all, and that requirement doesn't relax because the processing happens inside an AI tool instead of a spreadsheet. Consent, legitimate interest, contractual necessity, and the other Article 6 bases each carry their own conditions and documentation burden. The question to ask isn't "is AI processing generally allowed", it's "what's the lawful basis for this specific data flowing into this specific tool for this specific purpose." If you can't answer that in a sentence, that's the gap to close before anything else on this list matters.
- Write down, per AI tool in use, what personal data (if any) reaches it and why.
- Check whether the lawful basis you're relying on for the underlying business process still holds once an AI tool is added to that process, some bases don't automatically extend to a new processor.
- Flag any tool where the answer is "we're not sure": that's the one to review first.
2. Data minimization
Send the AI tool what the task needs, not what happens to be sitting in the same document or database. This gets missed constantly with AI tools specifically because pasting an entire ticket, email thread, or customer record into a prompt is one click easier than pulling out the two relevant lines. A support agent summarizing a ticket doesn't need the customer's full account history in the same prompt; a drafting tool doesn't need the whole contact record when it's only referencing a name and a date.
- Look at what your team is actually pasting into AI tools, not what the intended workflow assumes they paste.
- Where a tool integrates directly with a data source (a CRM, a ticketing system), check what fields it pulls by default and whether that's more than the task needs.
- Redact or template prompts for recurring tasks so minimization doesn't depend on each person remembering to trim what they send.
3. The international-transfer question
If personal data is going to leave the EU/EEA to reach an AI vendor, or a vendor with an EU-based product is still ultimately controlled by a company with a US parent, that's an international-transfer question under GDPR, not just a hosting-location question. We've covered this in depth separately, including what the Schrems II ruling actually decided and why an "EU region" checkbox doesn't fully answer it: see our data residency guide. Don't re-derive that analysis here. Read that page for the transfer mechanics, and come back to this checklist for the rest.
- Identify which AI tools on this list involve any non-EU/EEA processing, including through a US-parented vendor with an EU data center.
- For each one, confirm what transfer mechanism (adequacy decision, Standard Contractual Clauses, or another safeguard) the vendor's own documentation cites.
4. Data processing agreements
Where an AI vendor processes personal data on your behalf, GDPR Article 28 requires a written agreement between you and the vendor covering that processing, typically called a DPA. A DPA worth having spells out what the processor may do with the data, who its sub-processors are, how it handles deletion, and what happens on a breach. Not every AI tool needs the same DPA; the requirement and its exact content turn on the actual processing relationship, which is a legal question, not a checkbox to assume satisfied because a vendor's site mentions "GDPR compliant."
- Get a signed Article 28 DPA from every AI vendor that processes personal data on your behalf, before rollout, not retroactively.
- Read the actual sub-processor list rather than the DPA's summary paragraph, and check whether it's kept current.
- Note the deletion terms specifically: how long data persists after you stop using the tool or delete an account, and whether that includes backups.
Our own guide on what to look for in an AI vendor's DPA goes into more depth on reading one of these documents; GPUwerk's own Article 28 DPA is available as one example of what's in scope, though like the rest of GPUwerk's legal pages it hasn't been reviewed by outside counsel and shouldn't be treated as a model contract on its own.
5. Records of processing
Article 30 generally requires organizations above a certain size, or engaged in certain kinds of processing, to maintain records of their processing activities. Adding an AI tool to a workflow usually means adding an entry, or updating an existing one, in that record: what data it touches, the purpose, the lawful basis, retention, and who it's shared with. This is the step that gets skipped most often because it's paperwork rather than a technical control, but it's also the one a regulator or auditor will ask for first.
- Maintain a running list of AI tools in use, mapped to the personal data categories each one touches.
- Update the record whenever a tool changes what data it processes, not only when it's first adopted.
- Assign one owner for keeping the AI-tool section of your records of processing current: a checklist that nobody owns goes stale within a quarter.
Putting it together
None of these five questions are unique to AI tools; they're the same GDPR questions you'd ask about any new processor. What's different with AI tools is the pace of adoption, teams often start using a new tool before anyone runs it through a review, which means the checklist above is worth applying retroactively to what's already in use, not just to the next tool someone wants to add. Whatever the review turns up, treat this page as a starting structure and take the specifics to counsel before making a compliance decision on them.