GDPR + Generative AI: The EDPB Opinion 28/2024 Implementation Playbook for CISOs

On 17 December 2024 the European Data Protection Board adopted Opinion 28/2024 on the processing of personal data in the context of AI models. It does three load-bearing things: (1) sets a strict, case-by-case anonymity test for trained AI models (most large language models will not pass it by default), (2) anchors any legitimate interest claim for training on a three-step necessity and balancing test that demands documented mitigations, and (3) splits the GDPR analysis cleanly between the development (training) phase and the deployment (inference) phase, treating them as distinct processing operations with distinct lawful bases. If a model is found to have been trained unlawfully, that unlawfulness can contaminate downstream deployment unless specific remediation steps are taken. This playbook is what Areebi's compliance team uses to operationalise the Opinion across the LLM lifecycle. Updated 2026-05-20.

The Irish Data Protection Commission asked the EDPB four questions under Article 64(2) GDPR. The Opinion answers them, but its real force is in the reasoning. CISOs reading the Opinion for the first time tend to extract two things and miss the third. The two that get extracted: the anonymity test and the three-stage legitimate interest test. The third, which is the most operationally consequential, is the doctrine of cross-phase contamination - if training is unlawful, deployment can be too.

Source: EDPB Opinion 28/2024, adopted 17 December 2024. The Opinion is not binding on national supervisory authorities in the strict sense, but Article 64(2) opinions are routinely treated as the operative GDPR interpretation in enforcement and audit contexts. France's CNIL, Germany's BfDI, Italy's Garante, and the UK's ICO (post-Brexit, with the Data Protection Act 2018 substantially mirroring GDPR) have all aligned guidance with the Opinion within the first quarter of 2026.

Opinion 28/2024 treats training and deployment as separate processing operations with distinct lawful bases. This is the single most important conceptual shift for compliance teams that have so far treated "the AI system" as one undifferentiated thing. Different bases apply to different phases, and the Opinion's discussion of which bases are plausible is the framework CISOs should anchor to. The table below is the version Areebi's compliance team uses with regulated customers.

The trap to avoid: treating the deployment Article 6 basis as inherited from the training basis. They are independent and must be independently documented. Areebi's audit log records the basis claimed for each processing operation, with the policy engine refusing to process when the basis is missing or expired.

An LIA is a written document; if you cannot produce it on demand you do not have a legitimate interest basis. The template below is what Areebi's compliance team recommends as the baseline; many regulated customers extend it with sector overlays. It maps to the EDPB Opinion three-stage test and to ICO's AI and data protection guidance (updated 2025) and to CNIL's AI How-To Sheets (Series 2, 2024-2025).

• Section 1 - Purpose test. What is the specific business purpose? Why is the AI system the right tool? Is the purpose lawful, articulated, and real and present? Cite the business case and the named accountable executive.
• Section 2 - Necessity test. Why is processing personal data necessary? Have less invasive alternatives (synthetic data, licensed datasets, federated learning) been considered? Cite the data minimisation assessment and the volume of personal data used.
• Section 3 - Balancing test. Identify the rights and freedoms of data subjects, including the right to object under Article 21 GDPR. List sensitive categories (Article 9), vulnerable populations, public-vs-private data, web-scraped data, and the irreversibility of training. State the mitigations - differential privacy, output filtering, retention limits, opt-out mechanisms.
• Section 4 - Conclusion and review cadence. State the conclusion of the LIA, the next review date, and the triggers for re-assessment (material change to the model, new training data, new deployment context).

The Areebi platform's policy engine refuses to allow AI processing where the LIA is missing, expired, or unsigned by the named executive.

Under GDPR Article 35, a DPIA is required where processing is likely to result in a high risk to rights and freedoms. The EDPB and most national supervisory authorities treat large-scale processing of personal data for AI training, and most consequential AI-driven decisions, as high-risk processing that requires a DPIA. The template below extends the standard ICO and CNIL DPIA structures with AI-specific sections.

1. Description of the processing. Include the model architecture, training-data composition, deployment context, and the data flows. Reference the Areebi architecture walkthrough for the standard reference diagram.
2. Necessity and proportionality assessment. Map to the Article 6 basis, the Article 9 condition if special category data is in scope, and the data minimisation analysis.
3. Risk assessment. Identify the AI-specific risks: memorisation, prompt injection that leaks personal data, model inversion, hallucinated personal data, bias against protected classes, automated decision-making impacts under Article 22.
4. Mitigations. Document the controls. Areebi customers typically reference the policy engine, audit log, prompt filtering, output redaction, and the DPO sign-off workflow.
5. Consultation. Document the consultation of the DPO and, where required under Article 36, the prior consultation of the supervisory authority.
6. Review. State the review cadence. CNIL's AI How-To Sheets recommend annual review at minimum, plus event-driven reviews.

Areebi's compliance team designs the DPIA workflow so each AI use case carries a versioned DPIA artefact that can be exported to a supervisory authority on request.

If any training data includes special category data under Article 9 GDPR (racial or ethnic origin, political opinions, religious beliefs, trade union membership, genetic and biometric data, health, sex life, or sexual orientation), an additional Article 9(2) condition is required. The Opinion does not formally address this, but the EDPB's Guidelines 3/2019 on the processing of personal data through video devices and CNIL's How-To Sheets have made clear that web-scraped training data routinely captures Article 9 data, and that controllers cannot ignore it just because they did not intend to collect it.

The practical implications:

• Web-scraping a public dataset does not cleanse Article 9 data. The Opinion's anonymity test must be evaluated on the trained model with explicit attention to Article 9 categories.
• The "manifestly made public by the data subject" condition (Article 9(2)(e)) is narrow. Posting a photo to a social-media profile is not the same as manifestly making one's biometric template public.
• Explicit consent (Article 9(2)(a)) is rarely feasible at training scale. Substantial public interest (Article 9(2)(g)) is the most common alternative for regulated controllers, but it requires a basis in Member State law.

Areebi's policy engine ships a pre-built Article 9 filter that detects suspected special category content in prompts and completions and triggers the configured handling (block, redact, escalate).

Most generative AI systems are configured for human review, but the moment a decision becomes consequential and automated, Article 22 GDPR applies. A decision is "based solely on automated processing" if there is no meaningful human review - and the CJEU's December 2023 SCHUFA judgment (Case C-634/21) made clear that "meaningful" sets a higher bar than rubber-stamping. AI-generated outputs that drive credit, employment, insurance, or access decisions are squarely in scope.

The required safeguards under Article 22(3) and Recital 71 include: the right to obtain human intervention, the right to express a point of view, the right to contest the decision, and the right to an explanation. Areebi's audit log captures every human-in-the-loop intervention, the reasoning chain (where the model exposes it), and the decision outcome - so the controller can demonstrate Article 22 compliance to a supervisory authority on request.

If your AI vendor processes personal data outside the EEA, GDPR Chapter V applies. The CJEU's Schrems II judgment (Case C-311/18, July 2020) invalidated the EU-US Privacy Shield and tightened the Standard Contractual Clauses (SCCs) regime. The EU-US Data Privacy Framework (adopted July 2023) restored an adequacy decision for certified US recipients, but the EDPB has continued to scrutinise transfers tightly.

For LLM systems, the practical implications:

• Verify the vendor's DPF certification at dataprivacyframework.gov before relying on adequacy.
• For non-DPF transfers, use the EDPB-approved SCCs (2021 controller-to-processor or processor-to-processor modules) with a Transfer Impact Assessment (TIA) under EDPB Recommendations 01/2020.
• Document supplementary measures where the TIA finds the destination jurisdiction inadequate. For US transfers, this typically includes encryption with EEA-held keys, contractual restrictions on US government access, and audit rights.

Areebi's platform supports residency configuration so EU customers can pin training, inference, and audit data to EEA regions, with EEA-controlled key management for transit and at-rest encryption.

The right of access (Article 15), right to erasure (Article 17), and right to object (Article 21) are particularly difficult to satisfy in trained models. The Opinion does not solve this problem but it accepts the difficulty. The practical pattern that has emerged across EDPB national authorities:

• Right of access: the controller must provide a meaningful answer about whether the data subject's data was used in training, the categories of recipients (downstream deployers), and the safeguards. Areebi customers maintain a training-data manifest that supports access requests.
• Right to erasure: the EDPB accepts that erasure from a trained model is technically difficult; the practical answer is a combination of (a) erasing the source data from the training pipeline so it does not appear in future retraining, (b) demonstrating that the trained model does not reproduce the data subject's data via memorisation testing, and (c) where neither is feasible, retraining.
• Right to object: where legitimate interest is the basis, the data subject can object at any time. Controllers must have a workflow that handles objections and either (a) ceases processing or (b) demonstrates compelling legitimate grounds that override the data subject's interests.

Areebi's compliance team designs this control so each data subject request is logged, routed, and answered within the statutory one-month window under Article 12(3).

The translation from Opinion 28/2024 to operational control is what most CISOs struggle with. The 90-day plan below is what Areebi's compliance team uses with regulated customers entering the EDPB framework for the first time.

The Areebi GDPR compliance hub walks through each step with concrete control mappings.

Most GDPR-for-AI guidance stops at the conceptual level. Opinion 28/2024 demands operational artefacts: a documented LIA per use case, a DPIA per high-risk system, an Article 22 human-review workflow, a data subject rights pipeline, a TIA per international transfer, and an anonymity assessment per trained model. Areebi's policy engine enforces this control set by default: any AI use case that is missing one of these artefacts is blocked from production until the gap is closed.

This is not because we believe the EDPB will audit every controller next month. It is because the gap between "we have a policy" and "we have a control" is where regulatory findings actually live. The Areebi platform closes that gap with auditable artefacts the supervisory authority can read.