GDPR Lawful Basis for AI: Practical SMB Guide

TL;DR: Pick and document a lawful basis for every AI processing purpose; consent is not always the right answer and legitimate interest often fits operational AI use cases if you complete a balancing test and safeguards.

Why the GDPR lawful basis matters for AI projects

Choosing the correct GDPR lawful basis for AI is not a checkbox — it determines your legal risk, transparency duties and which data subject rights apply.

A wrong or undocumented choice increases enforcement exposure and weakens your ability to defend automated decision-making and model training choices.

The chosen basis affects whether you need a DPIA, how you communicate processing, and how you handle requests like erasure or objection.

Takeaway: Document your lawful basis early — it shapes DPIAs, rights handling and regulator exposure.

Quick overview: the GDPR lawful bases (Article 6) and Article 9

Article 6 lists six lawful bases for processing personal data: consent, contract, legal obligation, vital interests, public task (or public interest), and legitimate interests. For a concise legal reference see Art. 6 GDPR.

Article 9 covers special-category (sensitive) data — health, biometric, racial/ethnic origin and similar — which needs an additional legal ground and stronger safeguards.

For AI projects this means: most routine features rely on one Article 6 basis, but any processing of special-category data adds Article 9 complexity and extra technical/organisational measures.

Takeaway: You must pick an Article 6 basis for each purpose; add an Article 9 ground if you use special-category data.

A practical decision flow: which gdpr lawful basis for ai should you pick?

Use this step-by-step flow for each AI purpose:

• Is processing necessary to perform a contract with the data subject? If yes — Article 6(1)(b).

• Is there a legal obligation that forces processing? If yes — Article 6(1)(c).

• Can you get freely given, specific, informed and withdrawable consent? If yes and practical — Article 6(1)(a).

• If none of the above, consider legitimate interests and run a balancing test (LIA).

• If processing special-category data, identify an Article 9 ground and add safeguards.

When to default to consent vs another basis: consent works for clearly optional features (e.g., personalization addons). It is a poor default for large-scale training where withdrawing consent later breaks model integrity. See EDPB guidance on consent requirements EDPB Guidelines.

Takeaway: Follow a purpose-by-purpose flow and avoid blanket consent for infra-level AI processing.

"Consent is powerful — but often impractical for model-training at scale. Design your lawful basis per purpose, not per product."

Consent for AI: when it works — and common pitfalls

Valid consent must be freely given, specific, informed and withdrawable. The EDPB sets a high bar for AI-related consent; vague model descriptions won't cut it.

Pitfalls: bundling consent with terms, using broad vague language, or making core functions conditional on consenting to unrelated AI uses.

Design tips:

• Offer granular toggles (training, personalization, analytics).

• Make withdrawal simple and effective.

• Log timestamps and scope of consent for audits.

Takeaway: Use explicit, granular consent only when practical and make withdrawal real and easy.

Using Legitimate Interests for AI: how to do the balancing test

Legitimate interests is a common choice for operational AI (fraud detection, system security, basic personalization) but requires a documented Legitimate Interests Assessment (LIA).

Structure an LIA as: purpose and necessity → benefits to controller → impact to data subjects → safeguards and balancing conclusion. The ICO offers clear guidance on what to include ICO — What are legitimate interests?.

Practical examples where LIA often succeeds: fraud detection, abuse prevention, basic personalization for logged-in users.

Takeaway: Legitimate interest is workable for many AI uses — but document a solid LIA and apply strong safeguards.

Special-category data and AI: extra rules and safeguards

If your AI uses health data, biometrics or other special-category data, you need both an Article 6 basis and a separate Article 9 ground.

Safeguards include pseudonymisation, strict access controls, minimal retention and a DPIA. ENISA discusses AI-specific protection measures in useful detail ENISA — AI and Data Protection.

Takeaway: Treat special-category data as high risk — add Article 9 grounds, DPIAs and strong technical controls.

Contractual & legal obligation bases: typical AI scenarios

Article 6(1)(b) (contract) fits when the AI feature is necessary to deliver a paid service — e.g., a recommendation engine powering a paid subscription.

Legal obligation or public interest bases apply where law mandates processing or public authorities use AI for statutory tasks.

Takeaway: Use contract or legal obligation only when processing is strictly necessary for those purposes.

Documenting and communicating your choice

Privacy notice items to include about AI:

• Purpose(s) of AI processing and lawful basis.

• Whether decisions are automated and the logic/impact.

• Retention and retraining policy and data subject rights.

Example privacy notice excerpt:

"We process personal data for product recommendations under legitimate interests (fraud prevention and personalization). You can object to personalization at any time via your settings."

Record-keeping: log your lawful basis per purpose, store LIAs and DPIAs, retention schedules and review dates.

Takeaway: Be explicit in notices and keep auditable records of basis, LIA/DPIA outcomes and reviews.

Operational checklist for SMBs launching an AI model

Pre-launch:

• Purpose specification per feature.

• Lawful basis decision documented.

• DPIA trigger check and consent or LIA ready.

Post-launch:

• Monitor performance and privacy impact.

• Handle rights requests and explain automated decisions.

• Define retention and retraining cadence.

Takeaway: Treat lawful basis and DPIA as launch gates, and monitor after deployment.

3 short SMB case studies

Lead scoring: B2B lead enrichment and scoring can sit on legitimate interests with an LIA and easy opt-out for contacts. This avoids unreliable consent flows in outreach.

Automated CV screening: high-risk because of profiling and special data; prefer explicit consent or a robust Article 6+9 approach with a DPIA and transparent explanations.

Fraud detection: legitimate interest works well if you minimise data, pseudonymise where possible, and document safeguards in the LIA.

Takeaway: Match basis to risk — more invasive uses need consent or stronger safeguards.

Next steps & resources

Templates to prepare: LIA checklist, consent text samples, privacy notice excerpt and a DPIA prompt list.

For regulator guidance see the ICO and EDPB links above, and consult a lawyer for high-risk or complex uses.

Explore our services and case studies to see how other SMBs built compliant AI: services • case studies.

Takeaway: Use templates, regulator guidance and expert advice for high-risk projects.

"Regulators expect DPIAs for high-risk AI and clear transparency about automated decision-making — don’t treat this as optional."

Plan a free intro call to review your AI lawful basis and DPIA: Plan a free intro call — or reach out to start a compliance review.

Takeaway: Choose and document the right lawful basis now — it reduces legal risk and improves trust.