"Research" is one of the most overused words in data protection.
A university research project may be research. A clinical study may be research. A public health registry may be research. A commercial AI lab training a model on user data may claim to be research. A product team analyzing user behavior may also call its work research.
But under GDPR, calling something research is not enough.
On 16 April 2026, the European Data Protection Board opened a public consultation on Guidelines 1/2026 on processing of personal data for scientific research purposes. The consultation runs until 25 June 2026. The EDPB says the guidelines cover topics including health, controller and processor roles, legal basis, consent, and data subject rights.
These guidelines matter because many modern research activities rely on large datasets, health data, genetic data, behavioral data, real-world evidence, AI systems, and long-term data infrastructures. The EDPB's draft guidance is one of the most important GDPR research documents in years.
The practical lesson is:
Scientific research can benefit from GDPR flexibility, but only when the activity is genuinely scientific, legally grounded, transparent, and protected by appropriate safeguards.
1. Why this matters in 2026
The timing is important.
Research data is now central to:
| Field | Example |
|---|---|
| Healthtech | Clinical studies, real-world evidence, disease registries |
| AI development | Model training, evaluation, benchmarking, synthetic data testing |
| Universities | Longitudinal studies, behavioral research, social science datasets |
| Pharma and biotech | Clinical trials, genetic research, safety monitoring |
| Public sector | Public health research, epidemiology, policy analysis |
| Analytics teams | Product behavior studies, cohort analysis, experimentation |
| Data platforms | Research databases, biobanks, federated data infrastructures |
At the same time, regulators are under pressure to clarify how GDPR applies when data is reused for research or when research purposes are not fully known at the time of data collection.
The EDPB guidelines directly address these issues. The draft covers the concept of scientific research, legal bases, special category data, broad consent, transparency, rights, roles, and safeguards.
This is especially relevant for organizations building AI systems because AI projects often reuse existing datasets for training, testing, validation, or evaluation. "Research" may be a valid purpose in some cases, but it is not a magic word that removes GDPR obligations.
2. What counts as scientific research?
The EDPB states that if a controller wants to rely on GDPR provisions for scientific research, it must substantiate and demonstrate that the purpose is to carry out scientific research. The guidelines also say the concept covers processing in research activities that are genuinely scientific.
That is important because not every internal analysis is scientific research.
A useful distinction:
| Activity | Likely research? | Why |
|---|---|---|
| Clinical study with protocol and ethics review | Yes | Methodological and ethical standards |
| University longitudinal health study | Yes | Structured scientific purpose |
| Public health epidemiology project | Yes | Scientific and public interest purpose |
| Product A/B test to increase conversions | Usually no | Commercial optimization, not necessarily scientific research |
| Marketing segmentation | Usually no | Business targeting, not scientific research |
| AI model training for product features | Depends | Must assess purpose, method, safeguards, and legal basis |
| Security anomaly study | Depends | May be operational security or research depending on design |
A practical test:
| Question | Good sign |
|---|---|
| Is there a defined research question? | Yes |
| Is there a methodology or protocol? | Yes |
| Are ethical standards followed where relevant? | Yes |
| Is the result intended to produce generalizable knowledge? | Often yes |
| Are researchers or qualified experts involved? | Yes |
| Are safeguards documented? | Yes |
| Is the purpose more than product optimization or marketing? | Yes |
For compliance teams, the first step is therefore not "which legal basis do we use?" The first step is "is this actually scientific research?"
3. Compatibility is not the same as lawfulness
One of the most important clarifications is the relationship between purpose compatibility and legal basis.
GDPR Article 5(1)(b) contains a special rule: further processing for scientific research purposes is not considered incompatible with the initial purposes, subject to Article 89(1) safeguards. Legal commentary on the draft guidelines explains that the EDPB treats further processing for scientific research as presumed compatible, meaning the Article 6(4) compatibility test is not required.
But this does not mean the controller can ignore lawful basis.
The draft guidelines distinguish compatibility from lawfulness. Even if further processing for scientific research is compatible with the original purpose, the controller still needs a valid Article 6 legal basis, and if special category data is involved, an Article 9 condition or derogation.
This distinction is critical.
Bad reasoning:
"We already collected the data, and research is compatible, so we can use it."
Better reasoning:
"The further research purpose may be compatible, but we still need a valid legal basis, Article 9 condition where relevant, transparency, safeguards, and role allocation."
A compliance checklist should separate the two questions:
| Question | Meaning |
|---|---|
| Is the new research purpose compatible? | Purpose limitation analysis |
| What is the Article 6 lawful basis? | Lawfulness analysis |
| Is Article 9 involved? | Special category data analysis |
| Are Article 89 safeguards implemented? | Research safeguards |
| Are data subjects informed? | Transparency |
| Are rights respected or lawfully limited? | Data subject rights |
4. Legal bases for research
Research processing can rely on different legal bases depending on the organization, context, data type, and Member State law.
Possible Article 6 bases include:
| Legal basis | Research example |
|---|---|
| Consent | Participant agrees to a study |
| Public interest | Public university or health authority research under law |
| Legal obligation | Required safety monitoring or statutory research duty |
| Legitimate interests | Private-sector non-sensitive research with balancing test |
| Contract | Rarely suitable for genuine research, but may apply to some participant relationships |
The EDPB draft notes that genuine scientific research, whether non-profit or commercial, may carry significant weight in a legitimate interest balancing test because scientific research can benefit society.
However, legitimate interest is not automatic. The controller still needs:
- a legitimate interest,
- necessity of the processing,
- balancing against the rights and freedoms of data subjects,
- safeguards,
- transparency,
- respect for objections where applicable.
For AI teams, this matters because many commercial AI projects may try to rely on legitimate interest for research-like development. That may be possible in some cases, especially for non-sensitive data and genuine research, but it requires evidence and safeguards.
5. Special category data needs extra care
Scientific research often involves special category data.
Examples include:
| Data type | Example |
|---|---|
| Health data | Diagnosis, treatment, lab results, wearable data |
| Genetic data | Genome sequencing, inherited disease markers |
| Biometric data | Face, voice, gait, fingerprint templates |
| Data revealing ethnicity | Population health or social science research |
| Data revealing political opinions | Political behavior studies |
| Data revealing religion or beliefs | Social research |
| Sex life or sexual orientation data | Public health or social studies |
GDPR Article 9 generally prohibits processing special categories of personal data unless a specific condition applies. The EDPB draft notes that if no Union or Member State law permits processing special categories of data for a scientific research purpose, controllers may instead ask for explicit consent. The draft also says consent for special category data in scientific research can be broad or dynamic.
Practical implication:
For health, genetic, biometric, or other sensitive datasets, Article 6 is not enough. You also need an Article 9 route.
A research data review should therefore include:
| Check | Why |
|---|---|
| Does the dataset include special category data? | Article 9 applies |
| Is there Union or Member State law supporting research use? | May provide Article 9 derogation |
| Is explicit consent needed? | Often relevant if no legal route exists |
| Are additional national conditions triggered? | GDPR leaves room for Member State law |
| Are safeguards stronger than for ordinary data? | Higher risk to individuals |
The EDPB also notes that Member State law can impose additional conditions or limitations for health, genetic, or biometric data.
This means research compliance cannot be fully solved with one EU-wide template. National law may matter.
6. Broad consent and dynamic consent
One of the most practical questions in research is this:
Can participants consent to a research area when the exact future research questions are not fully known?
The draft guidelines recognize that in scientific research, controllers may rely on consent to collect and process personal data in a specific area of scientific research where the purposes are not fully known at the time of collection. Legal commentary describes this as official recognition of broad consent by research area.
This is important for long-term studies, biobanks, registries, and AI research datasets.
| Consent type | Meaning |
|---|---|
| Specific consent | Consent to a clearly defined study or processing purpose |
| Broad consent | Consent to a specific area of scientific research where exact future purposes are not fully known |
| Dynamic consent | Ongoing, interactive consent model where participants can update preferences over time |
Broad consent is not blank consent.
A bad broad consent statement:
"I agree that my data may be used for future research."
A stronger statement:
"I agree that my health data may be used for future cardiovascular research conducted by approved researchers under ethical review, with pseudonymisation and no use for marketing or insurance eligibility."
Broad consent should define:
| Element | Example |
|---|---|
| Research area | Cardiovascular disease, oncology, public health, AI safety |
| Data categories | Health records, lab values, imaging data |
| Governance | Ethics review, access committee, approved researchers |
| Safeguards | Pseudonymisation, access controls, audit logs |
| Exclusions | No marketing, no employment decisions, no insurance scoring |
| Withdrawal | How participants can withdraw where applicable |
| Updates | How participants will be informed of new research uses |
Dynamic consent can be useful where long-term trust matters, especially in health research, biobanks, and citizen science.
7. Transparency must continue over time
Research projects often last years.
The EDPB draft emphasizes that if controllers process personal data for long periods for scientific research, they should adopt appropriate measures to ensure transparency during the entire processing period and provide updates if processing changes.
This is a major operational point.
A privacy notice at the start of a study may not be enough if:
| Change | Transparency issue |
|---|---|
| New research purpose | Participants may need updated information |
| New data recipient | Vendor or collaborator changes |
| New AI use | Data used for model training or validation |
| New transfer | Data moved outside the EU/EEA |
| New linkage | Dataset linked with another dataset |
| New retention period | Data kept longer than originally expected |
| New risk | Re-identification or profiling risk changes |
Research transparency should be a lifecycle process.
A good research transparency system includes:
| Mechanism | Purpose |
|---|---|
| Study privacy notice | Initial information |
| Participant portal | Ongoing updates |
| Public research registry | Transparency for datasets and studies |
| Versioned notices | Evidence of what participants were told |
| Change notifications | Updates when processing changes materially |
| Contact point | Data protection and rights requests |
| Governance board records | Accountability |
8. Data subject rights in research
Data subject rights still apply in research, but GDPR contains specific research-related flexibility in some situations.
The EDPB draft discusses rights such as erasure and objection. It notes that GDPR contains a specific exception where processing is necessary for scientific research purposes and exercising the right to erasure is likely to render impossible or seriously impair the research objective, provided appropriate safeguards are adopted.
This does not mean research projects can ignore rights.
A research rights process should define:
| Right | Research handling |
|---|---|
| Access | Can participant receive information about their data? |
| Rectification | Can incorrect data be corrected or annotated? |
| Erasure | Is erasure possible, or would it seriously impair research? |
| Restriction | Can processing be paused for a participant? |
| Objection | Does the controller have grounds to continue? |
| Portability | Does it apply in this context? |
| Withdrawal of consent | What happens to data already used? |
The key is to decide and document rights handling before the study begins, not when the first request arrives.
9. Controller, processor, and joint controller roles
Research often involves multiple parties:
- universities,
- hospitals,
- pharma companies,
- CROs,
- AI vendors,
- cloud providers,
- data repositories,
- public authorities,
- research consortia.
The EDPB draft says that where several entities are involved, it is necessary to assess and document how responsibility is allocated, especially in public-private partnerships or where multiple actors contribute to a research protocol.
This matters because role confusion creates accountability gaps.
| Scenario | Possible role issue |
|---|---|
| University and hospital design study together | Joint controllers |
| Pharma sponsor defines protocol; CRO executes | Controller/processor or joint controller depending on facts |
| Cloud vendor hosts data | Processor |
| AI vendor trains model on research data | Processor or controller depending on independence |
| Data repository grants access to many researchers | Controller or joint governance model |
| Public-private consortium | Complex role allocation required |
Practical documentation should include:
| Document | Purpose |
|---|---|
| Role assessment | Controller, processor, joint controller |
| Data sharing agreement | Rules for controller-to-controller sharing |
| Processor agreement | Article 28 obligations |
| Joint controller arrangement | Article 26 responsibilities |
| Research protocol | Purpose, methods, roles |
| Access policy | Who can use the data and why |
| Audit logs | Who accessed what and when |
If an AI vendor can reuse research data for its own model development, it may not be a simple processor. That must be assessed carefully.
10. Appropriate safeguards under Article 89
GDPR Article 89 requires appropriate safeguards for processing for scientific research purposes.
The EDPB draft emphasizes data minimisation and says anonymised, or alternatively pseudonymised, data should be used as long as the research purpose can be fulfilled using such data. Processing directly identifying personal data is allowed only where strictly necessary and proportionate to achieve the research purpose.
Safeguards may include:
| Safeguard | Purpose |
|---|---|
| Anonymisation | Remove personal data where possible |
| Pseudonymisation | Reduce direct identifiability |
| Data minimisation | Use only necessary variables |
| Access controls | Restrict who can view data |
| Encryption | Protect data in storage and transit |
| Separation of keys | Keep identifiers separate from research data |
| Secure research environment | Prevent uncontrolled copying/export |
| Ethics review | Independent review of research risks |
| Data access committee | Approve secondary uses |
| Audit logs | Trace access and usage |
| Retention controls | Limit or justify long-term storage |
| Output checking | Prevent re-identification through results |
| DPIA | Assess high-risk processing |
For AI training, safeguards should also include:
| AI-specific safeguard | Why |
|---|---|
| Dataset documentation | Know provenance and lawful basis |
| De-identification review | Reduce re-identification risk |
| Membership inference testing | Check whether model leaks training data |
| Prompt/output monitoring | Prevent personal data leakage |
| Model access control | Limit who can query or extract |
| Fine-tuning records | Track which datasets influenced which models |
| Evaluation for sensitive attributes | Detect bias and discriminatory performance |
| Data deletion feasibility | Understand whether deletion from model is possible |
This is where GDPR research governance and AI governance overlap.
11. AI training: when is it scientific research?
AI teams often claim that model development is "research."
Sometimes that may be true. Sometimes it is just product development.
A practical classification table:
| AI activity | Research claim strength |
|---|---|
| Academic study on model safety with protocol and publication goal | Strong |
| Medical AI validation study under ethics review | Strong |
| Internal model benchmarking on anonymised data | Depends |
| Fine-tuning chatbot on customer tickets to improve support | Weak to moderate |
| Training ad targeting model on user behavior | Weak |
| Developing commercial recommendation model | Usually product development, not scientific research |
| Evaluating bias in deployed AI system | Could be research or compliance testing |
| Building public-interest dataset with governance and safeguards | Stronger |
Questions to ask:
| Question | Why |
|---|---|
| Is the activity genuinely scientific? | EDPB threshold |
| Is there a protocol or methodology? | Scientific character |
| Is there ethical review where appropriate? | Governance |
| Are results intended for scientific knowledge or only product gain? | Purpose |
| Is personal data necessary? | Data minimisation |
| Are safeguards in place? | Article 89 |
| Is there a legal basis independent of compatibility? | Lawfulness |
| Are data subjects informed? | Transparency |
| Is special category data involved? | Article 9 |
For AI companies, the safest approach is not to label all AI development as research. Instead, classify each dataset use separately.
12. Practical compliance workflow
Use this workflow before using personal data for research or AI training.
Step 1: Define the research purpose
Write:
| Field | Example |
|---|---|
| Research question | Does model X detect diabetic retinopathy accurately across age groups? |
| Research area | Ophthalmology / medical AI |
| Methodology | Retrospective dataset analysis |
| Expected output | Validation report, publication, model performance evidence |
| Data needed | Retinal images, age group, diagnosis labels |
| Why personal data is needed | Individual-level labels required for validation |
Step 2: Confirm scientific character
Document:
| Check | Evidence |
|---|---|
| Methodological standard | Protocol |
| Ethical standard | Ethics approval or equivalent review |
| Qualified personnel | Research team |
| Governance | Data access committee |
| Purpose | Scientific knowledge or validated research outcome |
Step 3: Identify legal basis
Separate:
| GDPR layer | Decision |
|---|---|
| Article 6 legal basis | Consent, public interest, legitimate interests, etc. |
| Article 9 condition | Explicit consent, research derogation under law, public health, etc. |
| Member State requirements | National health/genetic/biometric data rules |
| Transfer mechanism | SCCs, adequacy, or no transfer |
| DPIA need | Likely for sensitive or large-scale data |
Step 4: Apply safeguards
Minimum:
| Safeguard | Required action |
|---|---|
| Data minimisation | Remove unnecessary variables |
| Pseudonymisation | Replace direct identifiers |
| Access control | Limit access by role |
| Logging | Record access and exports |
| Retention | Define retention and deletion |
| Security | Encrypt and monitor |
| Transparency | Provide or update notice |
| Rights process | Define access, erasure, objection handling |
Step 5: Document role allocation
For each party:
| Party | Role |
|---|---|
| Sponsor | Controller or joint controller |
| Research site | Controller, joint controller, or processor |
| CRO | Processor or controller depending on tasks |
| Cloud provider | Processor |
| AI vendor | Processor or controller depending on reuse rights |
| Data repository | Controller or joint controller |
Step 6: Maintain lifecycle transparency
Keep:
| Record | Purpose |
|---|---|
| Notice version | What participants were told |
| Dataset version | What data was used |
| Protocol version | What purpose and method applied |
| Access logs | Who accessed data |
| Model version | Which model used which data |
| Change log | New purposes, recipients, safeguards |
| Rights log | Requests and responses |
13. Common mistakes
Mistake 1: "Research" used as a blanket justification
Research status must be substantiated. It is not enough to call a business analytics project research.
Mistake 2: Confusing compatibility with legal basis
Further research may be compatible, but a lawful basis is still needed.
Mistake 3: Ignoring Article 9
Health, genetic, biometric, and other sensitive data require an additional condition.
Mistake 4: Treating broad consent as unlimited consent
Broad consent must still define a research area, governance, safeguards, and boundaries.
Mistake 5: Forgetting transparency after collection
Long-term research needs ongoing transparency, especially when purposes, recipients, AI uses, or transfers change.
Mistake 6: Assuming pseudonymised data is anonymous
Pseudonymised data is still personal data if re-identification is possible through additional information.
Mistake 7: Letting AI vendors reuse data without role review
If a vendor reuses data for its own model development, the role and legal basis may change.
14. Checklist for research and AI data teams
| Question | Good answer |
|---|---|
| Is the purpose genuinely scientific? | Documented |
| Is there a protocol or methodology? | Yes |
| Is ethical review needed or completed? | Assessed |
| Is Article 6 legal basis documented? | Yes |
| Is Article 9 needed for special category data? | Assessed |
| Is Member State law relevant? | Checked |
| Is broad or dynamic consent used correctly? | Yes, if applicable |
| Is further processing compatibility separated from lawfulness? | Yes |
| Are participants informed throughout the lifecycle? | Yes |
| Are roles allocated among all parties? | Yes |
| Are Article 89 safeguards implemented? | Yes |
| Is data minimised or anonymised where possible? | Yes |
| Is pseudonymisation used where anonymisation is not possible? | Yes |
| Are AI training and model reuse documented? | Yes |
| Are data subject rights procedures defined? | Yes |
| Are access and export logs maintained? | Yes |
Conclusion
The EDPB's 2026 scientific research guidelines are important because they clarify a difficult balance.
Europe wants scientific research to be possible. GDPR recognizes the social value of research and gives it specific flexibility.
But that flexibility is not unlimited.
Scientific research processing must still be:
- genuinely scientific,
- lawful,
- transparent,
- safeguarded,
- proportionate,
- accountable,
- respectful of data subject rights.
For AI and data teams, the most important warning is this:
"Research" is not a shortcut around GDPR.
If you want to use personal data for research or AI training, you need to prove the purpose, legal basis, safeguards, role allocation, transparency, and lifecycle controls.
The organizations that do this well will not only reduce legal risk. They will create research datasets and AI systems that are more trustworthy, auditable, and defensible.
Sources
- EDPB, Guidelines 1/2026 on processing of personal data for scientific research purposes, public consultation opened 16 April 2026, comments due 25 June 2026.
- EDPB, Guidelines 1/2026 PDF, adopted version for public consultation, April 2026.
- Ropes & Gray, The European Data Protection Board Releases New Guidelines on the Processing of Personal Data for Scientific Research, 24 April 2026.
- Studio Legale Stefanelli, EDPB Guidelines 1/2026 on the processing of personal data for scientific research purposes, 21 April 2026.
- Covington / Global Policy Watch, New EDPB Guidelines on the Use of Personal Data in Scientific Research, 23 April 2026.