EDPS Sharpens GenAI Guidance: From Abstract Principles to Concrete Compliance

What the revised EDPS guidelines mean for public and private organizations working with generative AI

Why this revision reaches beyond EU institutions

The European Data Protection Supervisor (EDPS) has revised its guidance on the use of generative AI by EU institutions, published on October 28, 2025. The document makes more concrete what is expected from organizations when developing and deploying generative AI.

Even if you work outside EU institutions, this is relevant. The reasoning, emphases, and definitions of the EDPS often find their way to national supervisory authorities and public institutions. For private parties collaborating with governments, it helps to sharpen expectations and explicitly allocate responsibilities.

As EDPS Supervisor Wojciech Wiewiórowski emphasizes: "This first revision of our Orientations is more than an update; it's a reaffirmation of our dual mission: enabling human-centric innovation within the EU while rigorously safeguarding individual's personal data."

What's new in version 2?

The revision brings together four important improvements that directly impact how organizations must work with generative AI.

1. A sharpened definition of generative AI

The guidance clarifies the scope and emphasizes the chain of model development, fine-tuning, and application in concrete processes. This helps determine when the guidance applies and where responsibilities lie.

2. An action-oriented compliance checklist

Not abstract principles, but assessment questions you can directly apply in policy, design, and documentation. The checklist helps organizations systematically work through different phases of the system and verify that all requirements are met.

3. Role clarification along the lifecycle

The distinction between controller, joint controllers, and processor is elaborated along five phases of the lifecycle:

Important: These data protection roles are not equivalent to AI market terms such as provider, developer, or deployer. A supplier can be a processor in one phase and an independent controller in another phase.

4. Practical guidance on legal basis, purpose limitation, and data subject rights

This includes handling prompts and outputs that may contain personal data, model memory and logging, and establishing processes for access, deletion, and objections. The EDPS emphasizes that generative AI does not provide a free pass to handle data more broadly.

Why this matters for public and semi-public organizations

For ministries, implementing agencies, municipalities, water boards, and educational institutions, the guidance offers a framework to combine innovation with diligence. It helps resolve discussions that often remain unresolved in practice:

• Who determines the purpose and who chooses the essential means?
• What is the legal basis per step in the lifecycle?
• Who handles data subject requests?
• How do you document decisions about data quality and bias mitigation?

By using the checklist as a framework, you prevent a DPIA or AI impact assessment from remaining vague. This makes audit conversations more efficient and increases support among security, privacy, and procurement teams.

The core: roles and responsibilities across the lifecycle

The EDPS explicitly asks for role determination per phase. In the development phase, different parties may be responsible than in the usage phase. Two points stand out:

Controller, processor, and joint controller are data protection roles. These are not one-to-one equivalent to terms used in the AI market or AI legislation. A supplier can be a processor in one phase and an independent controller in another phase. You must explain this in writing and ensure it in your processing register and contracts.

Case-based thinking helps. For example: an EU institution develops an internal tool to accelerate HR processes using an LLM from a third party. During development, the institution determines the purpose and essential means. In that phase, the institution is the controller for the training and tests it orchestrates. As soon as another institution deploys the tool in its own HR process with its own data and prompts, that institution becomes controller for that use. If you work jointly on development and purpose determination, you quickly arrive at joint controllership, with clear task division.

Where personal data comes into view

Personal data can appear at multiple moments, sometimes less visibly than you think. The guidance distinguishes three critical moments.

Training and evaluation

Datasets can contain personal data, even if you primarily work with public sources. Assuming anonymity is risky. According to EDPB Opinion 28/2024, you must demonstrate that re-identification is reasonably excluded. For AI models, this means that extraction of personal data must be "insignificant" using all reasonably available means - a high bar.

Prompting and output

Input texts and generated responses can contain personal data. Think of summaries of internal notes or names in tickets. Retention periods, access, and logging are part of this. Each of these elements requires its own justification and technical measure.

Model memory and unintended reproduction

Unintended reproduction of training data is a real risk. Limit exposure through isolation, redaction, and technical controls such as output filtering. The EDPS emphasizes that security risks specific to generative AI include:

Web scraping: sharp choices needed

Especially web scraping requires sharp choices. The EDPS is explicit here: the technique itself is not prohibited, but a legal basis is not self-evident. For public tasks, the mandate must follow from legislation.

Furthermore: limit to manifestly made public data, document the necessity, and take measures that minimize impact on data subjects. This is not only legally necessary but also prevents reputational damage.

Legal basis, purpose limitation, and proportionality in practice

The tendency to apply one generic legal basis to the entire system often leads to discussions. It's better to work per processing phase. The guidance emphasizes that for EU institutions, Article 5(1)(a) of Regulation 2018/1725 - performance of tasks in the public interest - is most applicable, provided you can demonstrate that the institution has legitimate authority for this.

Consent as a legal basis proves difficult in practice. The EDPS emphasizes that consent must be: freely given, specific, informed, unambiguous, and revocable. With large training sets, it's practically almost impossible to meet all these criteria.

Development

Record which datasets you work with, on what basis, and for what purpose. If you use your own personnel data for validation, assess whether this falls within the purpose of HR administration or requires new processing.

Deployment in processes

Link use cases to a clear task description or legal basis. For example: summarizing citizen letters within the task of correspondence handling. Make visible why AI is an appropriate means and what limitations apply.

Management and support

Access by suppliers, error analyses, and logging must have their own justification. Where possible, work with pseudonymization, data minimization, and clear data retention.

DPIA and AI impact assessment: one workflow

The EDPS checklist is usable as the backbone for your DPIA and AI impact assessment. Organize the workflow so that you answer the same questions per use case: purpose, data flows, roles, risks, measures, monitoring. Link this to your processing register, your model card or system file, and your technical documentation.

This creates one file that withstands internal audits and is externally explainable to citizens and partners.

Contracting with suppliers and partners

Contracts must confirm the story you describe in your DPIA and register. Points of attention:

Role delineation

Name explicitly per phase who is responsible for what and how escalations work. Record joint controllership in an Article 26 agreement with transparent task division. Don't forget that suppliers who determine purposes themselves or choose essential means are controllers for those activities.

Supporting rights

Supplier or partner must be able to help practically with access, rectification, and deletion, including filtering logs and masking prompts and outputs. The guidance emphasizes eight core rights that must remain guaranteed: information, access, rectification, erasure, objection, restriction, portability, and withdrawal of consent.

Data quality and retention

Establish requirements for dataset management, evaluation sets, and retention periods. Prevent support channels from unnecessarily storing personal data. The guidance emphasizes that bias in generative AI can stem from stereotypes in training data, underrepresented populations, missing variables, and developer prejudices. Contracts must make bias mitigation explicit.

Security and location

Specifications about encryption, key management, locations of model hosting, and sub-processors. Describe fallback options and exit. Pay specific attention to the previously mentioned GenAI-specific risks such as prompt injection and model inversion.

Transparency toward end users

Provide communication materials that explain when AI is used, what limitations apply, and how to object.

Data subject rights and automated decision-making

When using generative AI in decision support, you must show how human intervention is arranged. Think of file formation, a visible right to deviate, and preventing AI output from effectively determining outcomes without control.

Ask yourself per process whether automated decision-making is involved within the applicable regime and ensure arranged objection, access, and correction. For organizations outside EU institutions, the reasoning is similar: specify when AI output is only advice and when it gets decision-making weight.

Practical example 1: Municipality with GenAI summarizer in the contact center

Situation

The contact center wants to summarize incoming emails and generate response proposals. A SaaS supplier provides the model and interface.

Approach according to EDPS guidance

The municipality is controller for use in the contact center. The supplier is in principle processor for hosting, fine-tuning, and support, but can itself be controller for its own model development with other data. In contracts and register, you describe the processing per phase.

Prompts and output can contain personal data, so you arrange retention, isolation, and a process for access and deletion. The deployment falls under the task of correspondence handling, with necessity assessment and less intrusive alternatives considered.

Quality control happens through random sampling and human review, with logging that is not retained longer than necessary. Specific attention to bias: are responses to emails in different languages equally accurate? Are certain types of questions underrepresented in the training set?

Lessons

Role determination per phase prevents misunderstandings. By translating the EDPS checklist into contact center work agreements, you can seamlessly incorporate the system into privacy and security management.

Practical example 2: Private supplier builds HR support for ministry

Situation

A company develops a tool using a foundation model that drafts vacancy texts and summarizes applications. The ministry wants to run the tool in its own environment.

Approach according to EDPS guidance

During joint development for a shared purpose, joint controllership may apply. Record this with task division, including who handles data subject requests and how technical support is arranged.

After delivery and deployment by the ministry with its own data, the ministry is controller for the usage phase. The supplier remains controller for its own development processes and datasets it uses outside the assignment. In both phases, transparency is needed toward candidates and employees.

The data policy explicitly describes how training data and evaluation sets are selected (for example: representativeness of diverse candidate profiles), how bias is measured (such as: comparable quality of summaries for different demographic groups) and reduced, and how logs are cleaned up.

Lessons

By centralizing the lifecycle, it becomes visible when responsibilities shift and what documentation belongs to this. The EDPS approach forces making explicit what often remains implicit.

How to make the EDPS checklist operational in your organization

A workable approach consists of three lines that you pursue in parallel:

1. Inventory

Map all GenAI use cases with purpose, data, model type, connections, and user groups. Link each item to an owner and to your processing register. Use the five lifecycle phases as structure.

2. Role and legal basis matrix

Draw the lifecycle per use case. Determine per phase the role division and assign per processing a legal basis. Anchor this in contracts, process owners, and procedures.

3. Quality and rights protection

Record how you test quality, how human oversight works, and how data subject requests are handled. Use technical controls for redaction, output filtering, and data retention.

These three lines together form a workflow you can repeatedly apply to new use cases and suppliers.

Accountability requirements: document everything

The EDPS repeatedly emphasizes that controllers must document all mitigation measures, risk assessments, and compliance decisions. This is not just a formality but a practical necessity during audits.

What you can do tomorrow

Directly applicable steps to activate the guidance in your organization:

With these steps, you make the new guidance directly applicable. You build AI applications that demonstrably handle personal data carefully and are therefore more sustainable within your organization.

The broader context: EDPS as a harbinger for national supervisory authorities

It's important to understand that EDPS guidance is often a precursor to broader European interpretations. While this guidance formally only applies to EU institutions under Regulation 2018/1725, national supervisory authorities such as data protection authorities will very likely look at this reasoning when interpreting GDPR.

Additionally, there's a clear line between this guidance and the upcoming joint guidelines from EDPB and the European Commission on the AI Act and GDPR, expected in Q1 2026. The system of lifecycle approach, explicit role division, and technical mitigation measures will very likely return in that broader guidance.

Conclusion: from principles to workable compliance

The revised EDPS guidelines for generative AI mark an important shift from abstract principles to concrete, executable compliance requirements. Through the focus on lifecycle phases, explicit role division, and practical checklists, it becomes clearer what organizations must do.

The core message is clear: generative AI requires the same diligence with personal data as any other processing, with extra attention to specific risks such as bias, unintended reproduction, and manipulation through prompts.

For public organizations, the guidance offers directly applicable tools. For private parties, it's a warning that expectations about GenAI compliance are becoming more concrete and that proactive implementation prevents later rework.

Organizations that start implementing according to this line now, build not only compliance but trust with users, employees, and supervisory authorities. In a time when AI applications increasingly interact directly with citizens and customers, that trust is strategic capital.

Sources and further reading

• EDPS: Guidance on Generative AI, strengthening data protection in a rapidly changing digital era (October 28, 2025)
• EDPS: Press release: EDPS unveils revised Guidance on Generative AI (October 28, 2025)
• EDPS: Revised Generative AI Orientations - Full document (PDF) (October 28, 2025)
• EDPB: Opinion 28/2024 on anonymisation (October 2024)
• Regulation (EU) 2018/1725: EU Data Protection Regulation for institutions