By · Last updated 2026-06-05

Tornar al BlogGDPR i Compliment

PII en recerca: captures de pantalla i el RGPD

Els articles academics inclouen regularment DataFrames de pandas i sortides de R que mostren registres reals de pacients com a exemples de metodologia. Aqui s'explica per que aixo es una violacio del RGPD.

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

Actualitzat per al 2026 - L'aplicacio del RGPD als grups de recerca ha crescut. Aquest risc continua sent habitual en el treball publicat.

El problema de les captures de pantalla de metodologia

Molts articles academics inclouen captures de pantalla d'eines d'analisi. L'objectiu es mostrar el metode. Pero aquestes captures poden revelar registres personals reals. La majoria dels investigadors no noten aquest risc.

Aqui teniu quatre casos habituals:

  • Un article d'aprenentatge automatic mostra un DataFrame de pandas. Les primeres 10 files tenen noms i ID reals de pacients.
  • Un estudi clinic mostra la sortida de R. Els valors dels pacients apareixen en pantalla. Els ID dels pacients es veuen al marge.
  • Un article de ciencies socials mostra taules d'SPSS. Les respostes a enquestes de persones reals son visibles.
  • Un tutorial de revista mostra un quadern Jupyter. Registres reals d'usuaris serveixen com a files de mostra.

En cada cas, l'autor volia mostrar el metode. Els registres personals no eren el punt central. Simplement hi eren per fer l'exemple mes real.

Pero "no era el punt central" no vol dir que sigui segur. L'Article 4(1) del RGPD estableix que els registres personals inclouen qualsevol fet sobre una persona identificada. Un registre de pacient en un article publicat es informacio personal. No importa si es troba en una captura de pantalla. Publicar-lo sense consentiment ni una base juridica en virtut de l'Article 6 viola el RGPD.

Consulteu el resum de conformitat RGPD per a mes informacio sobre les normes de publicacio.

Els grups de recerca s'enfronten ara a una major aplicacio del RGPD. Les fallades en la publicacio son un desencadenant clau. Quatre riscos destaquen.

Retraccio de la revista. L'Article 17 dona a les persones el dret a la supressio. Aixo s'aplica tambe als registres publicats. Si una persona troba les seves dades en un article, pot demanar la seva eliminacio. Per a una revista, aixo sovint implica la retraccio. La retraccio perjudica la carrera d'un investigador.

Constatacions del comite d'etica. Els comites d'etica revisen el treball publicat. Comprovem l'alineacio amb el RGPD. Han comenat a marcar els articles que mostren registres personals en captures de pantalla. Aquestes marques afecten el treball futur d'un investigador.

Violacions dels acords d'acces a dades. Els conjunts de dades de recerca venen acompanyats d'acords d'acces a dades. Aquestes normes especifiquen que es pot publicar. Una captura de pantalla amb registres personals pot trencar l'acord. El resultat solia ser la perdua d'acces al conjunt de dades.

Limits de l'Article 89. L'Article 89 permet l'us d'informacio personal per a la ciencia. Alleuja algunes normes. Pero nomes quan existeixen les salvaguardes adequades. Mostrar registres personals en una captura de pantalla sense desidentificacio no es una salvaguarda. Es una violacio.

Consulteu la nostra pagina de proteccio i salvaguardes per al desglossament complet.

Amb quina frequencia passa aixo?

Aquest problema no es rar. Afecta el treball publicat en molts camps.

Hi ha alguns factors que ho impulsen.

Normes de reproduibilitat. Les revistes volen detalls del metode. Els investigadors utilitzen captures de pantalla per satisfer aquesta necessitat. No sempre comproven que es visible en cada imatge.

Terminis ajustats. La pressio del temps porta a captures de pantalla rapides. No hi ha temps per revisar cada imatge en cerca de registres exposats.

Baixa visibilitat en les imatges. Un DataFrame pot tenir 20 columnes. Els noms i els ID poden estar en una columna a la dreta. L'investigador mira la columna clau, no la columna d'ID.

Sense comprovacio en la tramesa. Els portals de revistes fan comprovacions de format i de plagiariat. Cap comprova les imatges per a entitats personals. Res no marca el problema abans que l'article es publiqui.

Flux de treball de cribratge per a grups de recerca

Un proces de cribratge previs a la tramesa pot aturar aquests problemes. Te set passos.

  1. L'investigador completa l'esborrany del manuscrit amb totes les figures.
  2. L'esborrany va a un revisor intern: el IP o un contacte de privacitat.
  3. La deteccio de PII en imatges s'executa en tots els fitxers d'imatge del manuscrit.
  4. L'informe marca les imatges amb text llegible que coincideix amb patrons d'entitats personals.
  5. L'investigador revisa les imatges marcades.
  6. Per a cada imatge marcada: substitueix-la per una captura neta. Canvia l'ID de pacient 12847 per l'ID 00001. Substitueix els noms reals per "Pacient A".
  7. El manuscrit final va a la revista amb imatges netes.

Opcions tecniques:

  • Manual: Exporta les imatges del manuscrit. Executa la deteccio de PII per lots. Revisa l'informe.
  • Semi-automatitzat: Utilitza una carpeta compartida per als esborranys. Executa el processament per lots cada setmana en els fitxers nous.
  • Integrat al flux de treball: Afegeix un pas de cribratge al portal de tramesa.

El cribratge es rapid. Per a un manuscrit de 15 figures, la deteccio de PII en imatges triga menys de dos minuts. Una retraccio triga mesos.

Visiteu les FAQ o el glossari per a mes informacio sobre les funcions de deteccio.

Cas d'us: universitat europea

Un grup de recerca va afegir el cribratge de PII en imatges al seu flux de treball de manuscrits. Un quasiaccident va desencadenar el canvi. Un article en revisio tenia noms de pacients en una captura de pantalla d'un DataFrame.

Que van fer:

  • Tots els esborranys d'articles es van processar per a PII en imatges abans de la tramesa a la revista.
  • El cribratge cobria tots els fitxers PNG, JPG i PDF de cada esborrany.
  • Un contacte de privacitat revisava els resultats.

Resultats al llarg de sis mesos:

  • 23 manuscrits cribrats.
  • 7 manuscrits (30%) tenien almenys una imatge amb entitats personals.
  • Tipus trobats: noms de pacients en DataFrames (4 articles).
  • ID d'usuari que coincidien amb formats de pacients (2 articles).
  • Adreces de correu electronic als marges de captures de pantalla (1 article).
  • Tots 7 corregits abans de la tramesa.
  • Zero sollicituds de retraccio o constatacions d'etica despres de la tramesa.

El comite d'etica cita ara aquest flux de treball com una "salvaguarda adequada" model en virtut de l'Article 89. Dona suport a les futures sollicituds d'exempcio per recerca del grup.

Llegiu la declaracio del fundador per saber per que anonym.legal va ser creada per a aquest tipus de problema.

Fonts

Preparat per protegir les vostres dades?

Comenceu a anonimitzar PII amb més de 285 tipus d'entitats en 48 idiomes.

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.