Skip to main content
AI Prompts and GDPR: Why Most Teams Pick the Wrong Legal BasisLaws and Regulations
5 min readFor Privacy Officers

AI Prompts and GDPR: Why Most Teams Pick the Wrong Legal Basis

The Challenge

Your marketing team wants to draft personalized emails using a large language model. Your support desk wants to summarize customer complaints with AI assistance. Your HR department wants to generate performance review templates that reference employee data. Each scenario involves feeding personal information into an AI prompt, and each one requires a defensible legal basis under the GDPR.

The issue isn't that organizations are unaware of the need for a lawful purpose. It's that they're choosing the wrong one, or worse, treating the choice as a formality rather than a technical decision with compliance consequences.

When you process personal information through an AI prompt, you're triggering GDPR Article 4(2)'s definition of processing. That means you must anchor your activity to one of six legal bases enumerated in Article 6(1). European supervisory authorities have provided little guidance on when each basis applies to AI prompts specifically, leaving privacy officers to navigate this gap without a regulatory map.

Legal Basis Options

The GDPR offers six lawful processing purposes: consent, contract necessity, legal obligations, vital interests, public interest, and legitimate interests. In theory, any of these could justify including personal information in a prompt. In practice, most organizations default to one of two: consent or legitimate interests.

This binary thinking creates its own trap. Consent feels safe, it's explicit, documented, and defensible. But obtaining valid consent under the GDPR isn't as simple as adding a checkbox to your terms of service. You need freely given, specific, informed, and unambiguous indication of the data subject's wishes. If your AI use case involves opaque processing (and most do), explaining what you'll do with the data in a way that meets the "informed" requirement becomes genuinely difficult. You can't tell users exactly how the model will process their information when you don't control the model's internal logic.

Legitimate interests sound more flexible, but Article 6(1)(f) requires that your interest not be "overridden by the interest or fundamental rights and freedoms of the data subject which require protection of personal data." That's not a checkbox, it's a balancing test. And if you can't document how you weighed your business need against the data subject's rights, you don't have a legitimate interest; you have an audit risk.

The other four bases rarely apply to routine AI prompt scenarios. Contract necessity works only when the AI processing is genuinely required to deliver a service the individual has contracted for. Legal obligations apply when a European law mandates the processing. Vital interests cover life-or-death situations. Public interest applies primarily to public authorities. If you're stretching to fit one of these categories, you're probably on the wrong path.

Effective Approaches

Organizations that handle this well start by mapping their AI use cases to the nature of the processing, not to their preferred legal basis. They ask: Is this processing something the individual expects? Does it create new risks the individual didn't anticipate? Can we explain what happens to the data in concrete terms?

For customer-facing AI tools where the individual initiates the interaction, think chatbots that help users find products, contract necessity often fits better than consent. The user is asking you to perform a service, and processing their query through an AI is necessary to deliver that service. You're not asking permission; you're fulfilling the terms of use.

For internal operations where the individual has no direct relationship to the AI processing, such as using a model to categorize support tickets or draft internal summaries, legitimate interests becomes the more honest choice. But only if you document the balancing test. That means writing down: what business interest you're pursuing, what data protection risks the processing creates, what safeguards you've implemented, and why your interest isn't overridden by the data subject's rights.

The documentation matters more than the choice. If you pick legitimate interests and can't produce a written assessment during an audit, you've effectively admitted you had no lawful basis at all.

Results and Metrics

The source material doesn't provide specific organizational outcomes or metrics from teams that made these choices. What's clear from the regulatory framework is that the choice of legal basis determines your downstream obligations. If you rely on consent, you must implement withdrawal mechanisms and honor them immediately. If you rely on legitimate interests, you must honor objections under Article 21 and maintain records of your balancing assessments.

The real measure of success isn't avoiding enforcement, it's building a process that survives scrutiny when a data subject exercises their rights or when a supervisory authority asks you to justify your AI processing. That scrutiny will focus on whether you chose a legal basis that matches the actual nature of the processing, not whether you picked the easiest option.

Lessons Learned

Most organizations that stumble do so because they treat the legal basis as a one-time decision made during procurement or deployment. They don't revisit it when the AI use case evolves. A model that starts as an internal productivity tool often expands into customer-facing features, changing the risk profile and potentially invalidating the original legal basis.

If you're building this process from scratch, separate the legal basis decision from the vendor contracting process. Your data processing agreement with an AI provider doesn't determine your lawful purpose, it just defines roles and responsibilities. You still need to assess whether your intended use of the technology fits within one of the six bases.

Also, don't assume that because another organization uses the same AI tool under consent, you should too. The legal basis depends on your specific processing activity and your relationship with the data subjects, not on the technology itself.

Takeaways for Your Team

Start by inventorying where personal information enters your AI prompts. For each use case, ask whether the individual would reasonably expect this processing given your relationship and the context. If yes, contract necessity or legitimate interests probably fit. If no, you need consent, and you need to explain the processing clearly enough that the consent is actually informed.

Document your legal basis assessment before you deploy, not after an audit request arrives. If you're relying on legitimate interests, write down your balancing test and update it when the processing changes. If you're relying on consent, build the withdrawal mechanism at the same time you build the consent flow.

And recognize that "most companies" relying on consent or legitimate interests doesn't mean those are always the right choices. It means those are the only two bases flexible enough to cover the messy reality of AI processing without clear regulatory guidance. Your job is to pick the one that actually matches what you're doing, and to prove you made that choice deliberately.

GDPR Article 6

You Might Also Like