By · Last updated 2026-06-05

Torna al BlogGDPR e Conformità

Dati Personali nella Ricerca: Screenshot e GDPR

I paper accademici includono regolarmente DataFrame pandas e output R con dati reali di pazienti come esempi metodologici. Ecco perché questo costituisce una violazione del GDPR.

June 5, 20267 min di lettura
research dataacademic GDPRpublication privacyOCR image detectionArticle 89

Aggiornato al 2026 — L'enforcement del GDPR nei confronti dei gruppi di ricerca è aumentato. Questo rischio rimane comune nelle pubblicazioni.

Il Problema degli Screenshot di Metodologia

Molti paper accademici includono screenshot di strumenti di analisi per illustrare il metodo. Ma quegli screenshot possono rivelare veri dati personali. La maggior parte dei ricercatori non si accorge di questo rischio.

Ecco quattro casi frequenti:

  • Un paper di machine learning mostra un DataFrame pandas con i nomi e gli ID reali di pazienti nelle prime 10 righe.
  • Uno studio clinico mostra output R con i valori dei pazienti e gli ID paziente visibili nel margine.
  • Un paper di scienze sociali mostra tabelle SPSS con risposte a sondaggi di persone reali.
  • Un tutorial su una rivista mostra un notebook Jupyter con veri record utente come righe di esempio.

In ciascun caso, l'autore intendeva mostrare il metodo. I dati personali non erano il punto. Erano lì semplicemente per rendere l'esempio più realistico.

Ma «non era il punto» non significa sicuro. L'Articolo 4(1) del GDPR stabilisce che i dati personali includono qualsiasi informazione su una persona identificata. Un record paziente in un paper pubblicato è un dato personale, indipendentemente dal fatto che sia in uno screenshot. Pubblicarlo senza consenso o senza una base giuridica ai sensi dell'Articolo 6 viola il GDPR.

Consulta la panoramica sulla conformità GDPR per ulteriori informazioni sulle regole di pubblicazione.

Perché Questo Crea Rischio Legale

I gruppi di ricerca affrontano oggi un enforcement GDPR più stringente. Le violazioni nelle pubblicazioni sono un fattore scatenante fondamentale. Emergono quattro rischi principali.

Ritiro della pubblicazione. L'Articolo 17 riconosce alle persone il diritto alla cancellazione, applicabile anche ai record pubblicati. Se una persona trova i propri dati in un paper, può chiederne la rimozione. Per una rivista, questo spesso significa la ritrattazione, che danneggia la carriera del ricercatore.

Rilievi del comitato etico. I comitati etici esaminano le pubblicazioni e verificano la conformità al GDPR. Hanno iniziato a segnalare i paper che mostrano dati personali negli screenshot. Questi rilievi influenzano il lavoro futuro del ricercatore.

Violazioni dei Data Access Agreement. I dataset di ricerca vengono forniti con Data Access Agreement che stabiliscono cosa può essere pubblicato. Uno screenshot con dati personali può violare l'accordo, con conseguente perdita dell'accesso al dataset.

Limiti dell'Articolo 89. L'Articolo 89 consente l'utilizzo di dati personali per finalità scientifiche, attenuando alcune regole, ma solo in presenza di adeguate misure di salvaguardia. Mostrare dati personali in uno screenshot senza de-identificazione non è una misura di salvaguardia — è una violazione.

Consulta la nostra pagina sulla protezione e le misure di sicurezza per un'analisi completa.

Con Quale Frequenza Accade?

Il problema non è raro: riguarda pubblicazioni in molti ambiti disciplinari.

Several fattori lo alimentano.

Norme sulla riproducibilità. Le riviste richiedono dettagli metodologici. I ricercatori usano gli screenshot per soddisfare questa esigenza, senza sempre verificare cosa è visibile in ogni immagine.

Scadenze ravvicinate. La pressione temporale porta a screenshot rapidi, senza tempo per esaminare ogni immagine alla ricerca di dati personali esposti.

Bassa visibilità nelle immagini. Un DataFrame può avere 20 colonne. Nomi e ID possono trovarsi in una colonna lontana dalla colonna principale. Il ricercatore guarda la colonna di interesse, non quella con gli ID.

Nessuna verifica in fase di submission. I portali delle riviste eseguono controlli di formato e anti-plagio, ma nessuno controlla le immagini alla ricerca di entità personali. Nulla segnala il problema prima della pubblicazione.

Flusso di Verifica Pre-Submission per i Gruppi di Ricerca

Un processo di screening pre-submission può prevenire questi problemi. Si articola in sette passaggi.

  1. Il ricercatore completa la bozza del manoscritto con tutte le figure.
  2. La bozza viene inviata a un revisore interno — il PI o il referente per la privacy.
  3. Il rilevamento PII nelle immagini viene eseguito su tutti i file immagine del manoscritto.
  4. Il report segnala le immagini con testo leggibile che corrisponde a pattern di entità personali.
  5. Il ricercatore esamina le immagini segnalate.
  6. Per ogni immagine segnalata: sostituire con uno screenshot pulito — ID paziente 12847 diventa ID 00001, i nomi reali diventano «Paziente A».
  7. Il manoscritto finale viene inviato alla rivista con immagini pulite.

Opzioni tecniche:

  • Manuale: Esportare le immagini del manoscritto. Eseguire il rilevamento PII in batch. Esaminare il report.
  • Semi-automatico: Usare una cartella condivisa per le bozze. Eseguire l'elaborazione in batch ogni settimana sui nuovi file.
  • Integrato nel flusso di lavoro: Aggiungere una fase di screening al portale di submission.

Lo screening è rapido. Per un manoscritto con 15 figure, il rilevamento PII nelle immagini richiede meno di due minuti. Una ritrattazione richiede mesi.

Visita le FAQ o il glossario per ulteriori informazioni sulle funzionalità di rilevamento.

Caso di Studio: Un'Università Europea

Un gruppo di ricerca ha integrato lo screening PII nelle immagini nel proprio flusso di lavoro per i manoscritti dopo un quasi-incidente: un paper in revisione aveva nomi di pazienti in uno screenshot DataFrame.

Cosa hanno fatto:

  • Tutti i paper in bozza vengono processati per il rilevamento PII nelle immagini prima della submission alla rivista.
  • Lo screening copre tutte le figure PNG, JPG e PDF in ogni bozza.
  • Il referente per la privacy esamina i risultati.

Risultati in sei mesi:

  • 23 manoscritti analizzati.
  • 7 manoscritti (30%) contenevano almeno un'immagine con entità personali.
  • Tipi rilevati: nomi di pazienti nei DataFrame (4 paper), ID utente corrispondenti a formati paziente (2 paper), indirizzi email nei margini degli screenshot (1 paper).
  • Tutti i 7 corretti prima della submission.
  • Zero richieste di ritrattazione o rilievi etici dopo la submission.

Il comitato etico cita ora questo flusso di lavoro come esempio di «adeguata misura di salvaguardia» ai sensi dell'Articolo 89, a supporto delle future richieste di esenzione per la ricerca del gruppo.

Leggi la dichiarazione del fondatore per capire perché anonym.legal è stato costruito per questo tipo di problema.

Fonti

Pronto a proteggere i tuoi dati?

Inizia ad anonimizzare i PII con oltre 285 tipi di entità in 48 lingue.

About this page

We update this page when our platform or the law changes.

Read our founder note for how we work.

Each change shows up in the timestamp at the top.

Related reading

We follow these rules

  • GDPR (EU 2016/679).
  • ISO/IEC 27001:2022.
  • NIS2 (EU 2022/2555).
  • HIPAA safe harbor under 45 CFR § 164.514(b)(2).

Our promise

We do not sell your data.

We do not train models on your text.

We store your files in Germany.

You can delete your account at any time.

You own your work.

Where we run

Our servers live in Falkenstein, Germany.

We use Hetzner. They hold ISO 27001 certification.

All data stays in the EU.

Backups run every day.

Need help?

Email support@anonym.legal.

We reply within one business day.

How we test

We run a full check suite on every release.

Each surface gets its own sweep script and report.

Human reviewers spot-check the output each week.

We track recall and precision on a labelled set.

Bad runs block the deploy.

What we never do

  • We never sell your information to third parties.
  • We never train models on what you upload.
  • We never keep your work after you delete it.
  • We never share keys with any outside firm.
  • We never run ads inside the product.

Plans in plain words

We sell credits, not seats.

One credit covers one short job.

Long jobs use a few credits each.

You can top up at any time.

Unused credits roll over each month.

Read the plans page for current rates.

Who built this

A small team of engineers and lawyers built this.

We ship from Europe and work in the open.

Our founder note spells out why we started.

Where to start

How the parts fit

A browser add-on cleans text inside Chrome.

A Word plug-in handles drafts in Office.

A small desktop tool works on whole folders.

An agent protocol link feeds large models safely.

All four share one core engine and one rule set.

Words from our team

We started this work after a lunch about cookies.

One friend kept getting odd ads on her phone.

We asked why a court file leaked through a draft.

We sketched the first build on a napkin that week.

By month three we had a tiny demo for a friend.

She used it on her first case the next day.

Common questions we hear

Can the tool read scanned PDFs? Yes, with OCR.

Does it work on long files? Yes, in small chunks.

Can I roll my own rule set? Yes, save it as a preset.

Does it run offline? The desktop build runs offline.

Do you keep my files? No, the cloud build wipes after each run.

Will it learn from my work? No, we never train on inputs.

A short tour of the workflow

Upload a file or paste a snippet of prose.

Pick the entities you want gone from the draft.

Choose a method: replace, mask, hash, encrypt, or redact.

Press run and watch the side panel show each hit.

Skim the result and tweak any rule that misfired.

Save the cleaned file or send it to a teammate.