FinanceGadget
Guide

GDPR Lawful Basis for AI Tools at Work: A Compliance Guide

By Haileslassie Desalegn, Cybersecurity Leader · IAM & SOC Architect · Secure Systems Expert
Published 30 July 2026 · Updated 10 August 2026

The short answer

Deploying AI tools that process personal data (such as employee code contributions, customer communications, or user support logs) requires a valid legal basis under GDPR Article 6.

In employment and B2B contexts, relying on employee “consent” is invalid due to the inherent imbalance of power between employer and employee. Organizations must establish either Legitimate Interests (Art. 6(1)(f)) or Performance of a Contract (Art. 6(1)(b)), supported by a formal Legitimate Interests Assessment (LIA) and strict technical data controls.

The 6 GDPR Article 6 Legal Bases Applied to AI

Under GDPR Article 6(1), processing personal data is lawful only if at least one of six legal bases applies. Here is how each evaluates for corporate AI deployment:

1. Consent (Art. 6(1)(a)) — Generally Invalid for Workplace AI

EU Data Protection Authorities (DPAs) consistently hold that employees cannot freely give consent due to the power imbalance in employment relationships. If an organization mandates or expects AI tool usage, consent is legally invalid. Furthermore, consent can be withdrawn at any time, which creates operational chaos if models or logs must be purged upon withdrawal.

2. Performance of a Contract (Art. 6(1)(b)) — Strictly Scoped

Applies when processing is strictly necessary to fulfill a contractual obligation to the data subject (e.g., processing a customer’s query via an automated AI support bot). It cannot be used to justify broader internal model training or analytics.

3. Legitimate Interests (Art. 6(1)(f)) — The Primary Workplace Basis

Allows processing necessary for the legitimate interests of the organization or a third party, provided those interests are not overridden by the fundamental rights and freedoms of the data subject. To rely on this basis, organizations must perform a documented Legitimate Interests Assessment (LIA).

Rarely applies to voluntary AI deployments, unless processing is required by specific statutory mandates (e.g., automated AML screening in banking).

Performing a Legitimate Interests Assessment (LIA) for AI

An LIA consists of a three-part test:

  1. The Purpose Test: Identify the legitimate interest (e.g., improving developer productivity, enhancing code quality, speeding up customer support).
  2. The Necessity Test: Demonstrate that using the AI tool is necessary and proportionate to achieve that purpose, and that no less invasive alternative exists.
  3. The Balancing Test: Weigh the organization’s interest against the data subject’s privacy expectations. Factors that tip the balance against legitimate interests include:
    • Using prompts to train public foundation models.
    • Prolonged log retention without transparent deletion schedules.
    • Lack of vendor data processing addendums (DPAs).

GDPR Requirements for Workplace AI Deployments

To ensure your legal basis holds up under regulatory scrutiny:

Execute a Business Data Processing Addendum (DPA)

Under GDPR Article 28, you must execute a binding DPA with the AI provider. As noted in our breakdown of free vs paid AI tools terms, individual consumer accounts do not provide an Article 28 DPA.

Address Cross-Border Data Transfers

Verify whether prompt inference or data storage involves transferring personal data outside the EEA. Review our analysis on EU data residency for AI: inference vs storage to evaluate cross-border risk.

Transparency (Articles 13 & 14)

Inform employees and users clearly about how AI tools process their data, what data is collected, who has access, and how long logs are retained.

  1. Map Personal Data Inputs: Identify whether prompts sent to AI assistants contain personal identifiers (e.g., employee names, customer emails, IP addresses).
  2. Document the LIA: Complete and store a formal Legitimate Interests Assessment before rolling out AI tools to staff.
  3. Enforce Enterprise Workspace Seats: Upgrade from personal accounts to enterprise subscriptions backed by signed DPAs.
  4. Implement Data Minimization: Deploy pre-processing filters to strip personal data before prompts reach external AI APIs.

Whose personal data, and in which role

Before choosing a basis, be precise about two questions that determine everything downstream. Teams routinely write a single LIA covering a situation that actually contains three different processing operations.

Whose data is it? A coding assistant typically processes the employee’s data — their prompts, their activity, their identifiers — and, whenever the code or logs contain it, the personal data of customers or third parties. A support assistant processes the customer’s data primarily. These are different data subjects with different expectations, and the balancing test resolves differently for each.

Are you controller or processor for it? You are the controller deciding to deploy the tool. The vendor is generally your processor for the content you send. But most providers are controllers in their own right for some of what they collect — account and billing data, and often usage telemetry and abuse monitoring. That means part of the relationship is controller-to-processor and part is controller-to-controller, and the DPA only governs the first part.

The practical consequence: your Article 30 record should list the tool’s processing operations separately rather than as one line, and your transparency notice needs to cover the parts the vendor decides for itself.

What makes a legitimate interests assessment survive scrutiny

An LIA that concludes “our interest prevails” without engaging the hard parts is worth nothing in an investigation. Three things distinguish a real one.

The necessity test is where most fail. Necessity means the purpose cannot reasonably be achieved by a less intrusive route. If the same productivity gain is available from a tool that processes less data, retains it for less time, or keeps it in the EEA, the more intrusive option is not necessary — it is merely preferred. Document the alternatives you considered and why they were rejected. “We chose the tool the team already liked” is not a necessity argument.

Reasonable expectations do real work in the balancing test. Would an employee reasonably expect that their prompts are logged, retained for a period, and readable by an administrator? Would a customer expect their support message to be processed by a third-party model in another jurisdiction? Where the answer is no, you do not necessarily lose — but you must either change the processing or make the expectation reasonable through genuine transparency.

Safeguards are what tip a marginal case. These are the concrete measures you can point to: training disabled at the tenant level, a short and enforced retention period, personal data filtered before it reaches the API, access restricted and logged, an executed DPA, and a mechanism for people to object. Each one narrows the intrusion and each one is checkable. An LIA that lists safeguards you have not actually implemented is worse than none.

Record the assessment, date it, and re-run it when the tool, the vendor’s terms, or the scope of use changes. An LIA describing a pilot with six engineers does not cover a rollout to four hundred.

Special category data and the Article 9 problem

Article 6 is only the first gate. If the processing involves special category data — health, biometrics, trade union membership, political or religious belief, sex life or orientation, racial or ethnic origin — you need an additional Article 9 condition, and legitimate interests is not one of them.

This matters more for AI tools than teams expect, because these categories arrive incidentally. Support tickets mention illness. HR systems contain occupational health records and union membership. Free-text fields collect whatever people write. An assistant with access to a document store will retrieve whatever is in it.

The realistic conditions available in a workplace context are explicit consent — which carries the same power-imbalance problem, though it is not always unavailable outside a mandated tool — or Article 9(2)(b) for employment and social security obligations, within the limits of national law. Member State law varies considerably here, and this is a point to take to a data protection lawyer rather than resolve by reading.

The pragmatic engineering answer is to keep special category data out of the tool entirely: exclude the systems that hold it from any retrieval index, filter it before it reaches an API, and treat its appearance as an incident rather than an edge case.

The employee monitoring dimension

There is a second issue running alongside the lawful basis, and it is frequently the one that generates complaints.

AI tooling produces detailed telemetry about individual working patterns: acceptance rates, prompt volumes, activity timing. Using that data to evaluate employees is a materially different processing purpose from using the tool to help them work, with a different balancing outcome and, in many jurisdictions, additional obligations.

Several Member States require works council or employee representative consultation before introducing systems capable of monitoring performance — Germany and the Netherlands notably so — and this obligation is independent of whether your GDPR analysis is sound. Introducing a tool without that consultation is a labour law problem that no LIA will fix.

Two commitments are worth making explicitly and in writing: state the purposes telemetry will be used for, and state the purposes it will not. A published commitment not to use assistant metrics in performance management costs little and removes the objection that most reliably turns a rollout into a dispute.

  1. Map Personal Data Inputs: Identify whether prompts sent to AI assistants contain personal identifiers (e.g., employee names, customer emails, IP addresses).
  2. Document the LIA: Complete and store a formal Legitimate Interests Assessment before rolling out AI tools to staff.
  3. Enforce Enterprise Workspace Seats: Upgrade from personal accounts to enterprise subscriptions backed by signed DPAs.
  4. Implement Data Minimization: Deploy pre-processing filters to strip personal data before prompts reach external AI APIs.
  5. Separate the operations in your Article 30 record, rather than recording the tool as a single processing activity.
  6. Check whether a DPIA is required — high-risk processing, systematic monitoring, and large-scale special category data each trigger it. Do you need a DPIA for an AI tool? covers the thresholds.
  7. Update your privacy notices under Articles 13 and 14 before deployment, not after. Transparency is a precondition of legitimate interests, not a follow-up task.
  8. Provide a route to object. Article 21 gives data subjects the right to object to processing based on legitimate interests, and having no mechanism to handle an objection undermines the basis you are relying on.

To evaluate vendor contracts against GDPR standards, read our framework on how to judge an AI provider, and how to get a DPA for an AI tool for the Article 28 step this analysis assumes is in place.