GDPR AI Compliance Checklist for European Businesses

1. Why GDPR still matters when agents run the work

Agents can move personal data through several tools in one process: an email inbox, a CRM, a model API, a knowledge store and a reporting system. That makes the whole data flow—not an individual prompt—the right unit of assessment. Names, professional email addresses, identifiable opinions and inferred profiles can all be personal data. Public availability does not automatically remove GDPR obligations.

• Map the trigger, inputs, intermediate stores, outputs and external actions.
• Separate the business purpose from the technical steps used to achieve it.
• Identify the people whose data is processed, including staff and business contacts.

2. Choose and document the lawful basis

Determine an Article 6 lawful basis for each processing purpose before launching the pipeline. Consent is not the only possible basis, and legitimate interests is not a universal permission. Assess necessity, context and the rights of the individuals. Special-category data and criminal-offence data require separate attention under Articles 9 and 10.

• Record the purpose, data categories, necessity and selected basis.
• Where relying on legitimate interests, document the assessment and applicable objection handling.
• Check relevant electronic-marketing rules separately; a GDPR basis does not automatically authorise an outreach channel.

3. A practical pipeline checklist

Use this checklist to locate gaps and assign owners. It is a working implementation tool, not a declaration that ticking the boxes makes every use lawful.

• Name an accountable business owner and document controller/processor roles.
• Minimise inputs and keep model/tool permissions tied to the required work.
• Give appropriate privacy information and maintain a route for questions and rights requests.
• Review processor agreements, subprocessors and relevant international transfers.
• Set retention and deletion rules for every copy, including logs and agent memory.
• Test access control, incident response, recovery and meaningful human intervention.
• Record the decisions and reassess when the purpose, supplier or process changes.

4. When a DPIA is required

Article 35 requires a data protection impact assessment where a type of processing is likely to result in a high risk to people’s rights and freedoms, taking account of its nature, scope, context and purposes. New technology is relevant, but using AI does not automatically mean that every project requires a DPIA. Check the examples in the Regulation and the applicable supervisory authority’s published lists.

• Screen the actual use case for systematic evaluation, sensitive data, scale and monitoring.
• Where required, complete the DPIA before the relevant processing starts.
• Assess necessity, proportionality, risks and the measures used to address them.
• Involve the data protection officer where applicable and consider Article 36 prior consultation if high residual risk remains.

5. Processor agreements and the supply chain

Where another organisation processes personal data on your behalf as a processor, put the Article 28 requirements in a binding contract or other applicable legal act. Check documented instructions, confidentiality, security, subprocessors, assistance, return/deletion and audit provisions. If you are a processor for a client, assess your own downstream processing chain and the client’s authorisation.

• Match the agreement to the exact service and contracting entities.
• Keep versions and evidence of incorporation or acceptance.
• Review international transfers separately from the existence of a DPA.
• Use the AI DPA guide to structure the provider checks; do not rely on a generic compliance badge.

6. Rights, transparency and automated decisions

Design a practical way to respond to access, rectification, erasure, restriction, portability and objection requests where the relevant right applies. Those rights have conditions and exceptions; they are not interchangeable. Trace the data across the connected systems rather than only searching the original inbox.

• Explain relevant purposes, recipients and retention in the appropriate privacy information.
• Identify whether Article 22 applies to solely automated decisions with legal or similarly significant effects.
• Where human review is relied on, make it meaningful: the reviewer needs authority, context and a genuine ability to change the outcome.
• Do not confuse an ordinary automation approval with an assessment of Article 22 and its exceptions.

7. GDPR and the EU AI Act are separate checks

GDPR governs personal-data processing. The AI Act adds a different framework for AI systems and actors, including prohibited practices, risk-based obligations, transparency and AI literacy. A GDPR assessment does not decide your AI Act status, and using a general-purpose model does not make every downstream business workflow the same risk category.

• Identify your role and the intended use of the actual system.
• Check whether a prohibited or high-risk use is involved and which obligations apply.
• Check current application dates and amendments in official EU sources rather than treating every provision as having one deadline.
• Include staff competence and appropriate oversight in the operating model.

8. Keep an operating record, not a forgotten document

Maintain the records of processing required by Article 30. Its limited exemption for some organisations with fewer than 250 employees is conditional; it is not a blanket small-business exemption. A practical inventory is useful even where a particular record-keeping obligation does not apply.

• Keep purposes, categories, recipients, transfers and retention aligned with the running pipeline.
• Record the responsible owner, processor terms, assessments and material configuration choices.
• Retain evidence of changes and reviews without collecting excessive personal data in the audit logs themselves.

9. Common mistakes to avoid

The most common failures come from assuming that a vendor feature settles the whole assessment. EU hosting, a DPA or a “no training” setting can each matter, but none establishes compliance on its own. Building the software yourself also does not remove your responsibilities.

• Do not use real customer data in prototypes when a synthetic example is sufficient.
• Do not treat a publicly available contact as permission for any kind of outreach.
• Do not assume self-hosting means no subprocessors, support access or international transfers.
• Do not retain every prompt indefinitely “just in case”.
• Do not let agents make up missing identity or consent evidence.

10. Turn the checklist into an action plan

Choose one pipeline and walk through it from input to outcome. Record the gaps, assign owners and agree which changes are needed before routine operation. Test the difficult paths—rights requests, access mistakes, incidents and cancellation—not only the successful demonstration.

• Start with a data-flow map and role/purpose assessment.
• Resolve contract, retention and access gaps before using real personal data.
• Complete any required DPIA and specialist review for the actual circumstances.
• Test the controls, record acceptance and plan review triggers.
• Build the next pipeline using the lessons from the first, not an unchecked copy of its legal assumptions.

Primary sources and next steps

• GDPR: Regulation (EU) 2016/679 — Articles 5–6, 9–10, 12–22, 28, 30, 32, 35–36 and Chapter V.
• European Commission: AI Act overview and current implementation information.
• European Data Protection Board: small-business data protection guide.

Continue with the AI provider DPA guide, agent security and management oversight or practical team training.