GDPR and AI: Protecting EU Employee and Customer Data in AI Tools

By the Shadow AI Policy team

If your company uses AI tools to process data about EU employees or customers, GDPR applies to you — regardless of where your company is headquartered.

This post covers the five GDPR requirements that matter most when AI tools enter the picture: establishing a lawful basis for processing, managing data transfers to non-EU AI vendors, navigating the overlap with the EU AI Act, honoring data subject rights in AI-processed data, and knowing when a Data Protection Impact Assessment is mandatory. If you have even one EU employee or serve any EU customers, this framework applies to you.

Why GDPR Applies to Your AI Tools Even If You're Not in the EU

GDPR's territorial scope is defined in Article 3. It covers any organization that processes personal data of people in the EU, even if the organization itself is based in the US, Canada, Australia, or anywhere else. "Processing" under GDPR Article 4(2) includes collecting, storing, transmitting, analyzing, and generating outputs from personal data — which is exactly what AI tools do.

This means that if an HR manager in Chicago runs EU employee performance data through ChatGPT, or a sales team in Austin uses an AI CRM to analyze EU customer behavior, both scenarios trigger GDPR obligations. The question isn't whether GDPR applies — it's whether you have the right controls in place.

The enforcement picture has sharpened considerably. The Irish Data Protection Commission fined Meta €1.2 billion in 2023 for unlawful EU-US data transfers. National DPAs across the EU have issued guidance specifically addressing AI systems. Treating GDPR as a European-only administrative concern is no longer a safe posture for any company with EU data exposure.

Lawful Basis for AI Processing of Personal Data

Before you process any personal data through an AI tool, you need a lawful basis under GDPR Article 6. There are six bases; in practice, most businesses rely on three:

• Legitimate interests (Article 6(1)(f)): The most flexible basis, but requires a Legitimate Interests Assessment (LIA) showing your interest outweighs the data subject's rights. Using AI to detect fraud or improve operational efficiency may qualify. Using it to profile employees in ways they'd find intrusive likely doesn't.
• Contract (Article 6(1)(b)): Processing is necessary to fulfill a contract with the data subject. This covers using AI to process an EU customer's order or generate a payslip for an EU employee — but it's narrower than most teams assume. "Necessary" means genuinely required, not just convenient.
• Consent (Article 6(1)(a)): Valid consent must be freely given, specific, informed, and unambiguous. Consent from employees is almost always problematic under GDPR because of the power imbalance — regulators generally view it as not freely given. Don't rely on employee consent as your primary basis for AI processing at work.

For special category data — health information, biometric data, union membership, racial or ethnic origin — Article 9 applies an additional layer. You need both an Article 6 basis and a specific Article 9(2) exception. If your AI tools process anything in those categories (including wellness platform data or video analytics), your legal team needs to explicitly identify both.

A lawful basis isn't a checkbox — it determines what you can do with the data, how long you can keep it, and what rights the data subject can exercise. Pick the wrong one and you've built your entire AI data practice on a defective foundation.

Data Transfer Mechanisms for AI Vendors Outside the EU

Most enterprise AI vendors — OpenAI, Anthropic, Google, Microsoft — are headquartered in the United States. Under GDPR Chapter V, transferring personal data from the EU to these vendors requires a valid transfer mechanism. The EU-US Data Privacy Framework (DPF), adopted in July 2023, is currently the primary mechanism for US-based vendors. Organizations certified under the DPF can receive EU personal data lawfully. You can verify certification status at the official DPF list maintained by the US Department of Commerce.

If your AI vendor isn't DPF-certified, the fallback is Standard Contractual Clauses (SCCs), updated in June 2021 by the European Commission. SCCs must be incorporated into your contract with the vendor and supplemented by a Transfer Impact Assessment (TIA) if there's meaningful risk that the destination country's surveillance laws could override the protections. This is not a formality — the Schrems II ruling invalidated the previous framework precisely because organizations weren't doing this analysis seriously.

The practical checklist for any AI vendor receiving EU personal data:

• Confirm they are DPF-certified (check dataprivacyframework.gov) OR that you have executed SCCs with them
• Ensure a Data Processing Agreement (DPA) is signed under GDPR Article 28 — this is non-negotiable for any processor relationship
• Document whether the vendor uses subprocessors (sub-SCCs or DPF coverage required there too)
• Conduct and document a Transfer Impact Assessment if using SCCs with a US vendor

Many AI vendors publish their DPA as a standard document. Microsoft 365 Copilot, for example, includes EU data processing commitments in its standard agreements. Review the actual document rather than relying on vendor marketing claims about compliance.

EU AI Act Overlap with GDPR for Employers

The EU AI Act (Regulation (EU) 2024/1689), which began phasing in from August 2024, runs in parallel with GDPR — it doesn't replace it. For employers, the most relevant overlap is in the Act's treatment of high-risk AI systems. Annex III of the AI Act classifies AI systems used in employment, worker management, and access to self-employment as high-risk. This includes AI tools used for recruitment screening, performance evaluation, task allocation, and monitoring behavior at work.

If you use any AI system that falls into these categories for EU employees, you face obligations under both frameworks simultaneously:

• Under the AI Act: High-risk systems require conformity assessments, technical documentation, human oversight mechanisms, and registration in the EU database before deployment.
• Under GDPR: The same system likely requires a DPIA (see below), a lawful basis, and restrictions on solely automated decision-making under Article 22.

The AI Act's prohibited practices (Article 5) also matter for HR. AI systems that use subliminal techniques to manipulate behavior, or that exploit vulnerabilities of specific groups, are prohibited outright. Biometric categorization systems that infer sensitive attributes from employee data also fall under this prohibition. If a vendor is marketing an AI tool that categorizes employees by inferred personality type or emotional state, that's a significant red flag under both the AI Act and GDPR.

Understanding how your existing tools map to these risk tiers is now a core HR compliance task. For a broader look at how shadow AI use complicates this picture, see our guide on what shadow AI is and why it matters.

Data Subject Rights in AI-Processed Data

GDPR gives EU individuals a set of enforceable rights over their personal data. When AI tools are in the processing chain, these rights get complicated — but they don't disappear. Here's how they apply in AI contexts:

• Right of access (Article 15): If an EU employee asks what personal data you hold and how it's processed, that includes data that went through an AI system. You need to be able to describe what AI tools were used, for what purpose, and what outputs were produced.
• Right to erasure (Article 17): If a data subject requests deletion, you must delete their data from your own systems — and instruct your AI vendors to delete it from theirs. Whether the vendor's model has "learned" from that data is a developing legal question, but at minimum you must delete identifiable training or input data.
• Right to explanation for automated decisions (Article 22): If an AI system makes a decision that significantly affects someone — a hiring rejection, a performance flag, a loan denial — and that decision is made solely by automated means, the individual has the right to request human review, to contest the decision, and to receive a meaningful explanation. Article 22 is one of the most frequently overlooked GDPR requirements in AI deployments.
• Right to object (Article 21): Where your lawful basis is legitimate interests, data subjects can object to processing. You must stop processing unless you can demonstrate compelling legitimate grounds that override the individual's interests.

Practical implication: your AI acceptable use policy needs to specify which tools process EU personal data, and your internal processes need a workflow for responding to data subject requests that includes those tools. If you haven't built that workflow, your AI acceptable use policy template is the right starting point.

DPIA Requirements for AI-Driven Decisions

A Data Protection Impact Assessment (DPIA) is required under GDPR Article 35 whenever processing is "likely to result in a high risk to the rights and freedoms of natural persons." The Article 29 Working Party (now the EDPB) guidelines identify several indicators that trigger this requirement — and AI tools hit multiple triggers simultaneously:

• Automated decision-making with legal or similarly significant effects
• Large-scale processing of sensitive data
• Systematic monitoring of employees or publicly accessible areas
• Processing that involves new technologies
• Processing that prevents individuals from exercising rights or using services

If your AI use meets two or more of those criteria, a DPIA is mandatory — not optional. A DPIA isn't a bureaucratic form. It's a structured analysis that covers: the purpose and necessity of the processing, assessment of risks to data subjects, and the measures you're taking to mitigate those risks. It must be documented and, in some cases, shared with your Data Protection Authority before you start processing.

For most SMBs deploying AI in HR contexts — especially tools that screen candidates, monitor productivity, or analyze communication patterns — a DPIA is required before deployment, not after a complaint arrives. Build the DPIA process into your AI tool approval workflow. To structure that workflow into a policy employees actually follow, consider using our tool to generate a tailored policy kit as a foundation.

One practical framing: if you wouldn't be comfortable explaining your AI processing to the data subjects whose data is involved, that discomfort is a signal that a DPIA would surface real risks. Run the assessment before deployment, document your conclusions, and revisit it when the tool or its use changes materially.

AI Use Case	Likely Lawful Basis	DPIA Required?	Article 22 Risk?
AI resume screening (EU candidates)	Legitimate interests / Contract	Yes	Yes — hiring decisions
AI meeting transcription (EU employees)	Legitimate interests	Likely yes	Low (if not used for decisions)
AI productivity monitoring (EU staff)	Legitimate interests (narrow)	Yes	Yes — performance impact
AI drafting tool (internal docs, no EU PII)	N/A — no personal data	No	No
AI customer segmentation (EU customers)	Legitimate interests / Consent	Yes	Depends on segmentation use

About Shadow AI Policy: We build AI acceptable use policy tools for HR and operations teams at 50–500 person companies. We publish guides on shadow AI, acceptable use policies, and AI governance, updated as regulations and AI tools change.