By · Last updated 2026-06-05

Tilbake til BloggGDPR & Overholdelse

Personopplysninger i forskning: Skjermbilder og GDPR

Akademiske artikler inneholder regelmessig pandas DataFrames og R-utdata som viser ekte pasientjournaler som metodologieksempler. Her er grunnen til at dette er et GDPR-brudd.

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

Oppdatert for 2026 - GDPR-handhevelse mot forskningsgrupper har okt. Denne risikoen er fortsatt vanlig i publisert arbeid.

Problemet med metodeskjermbilder

Mange akademiske artikler inneholder skjermbilder av analyseverktoy. Malet er a vise metode. Men disse skjermbildene kan avslore ekte personjournaler. De fleste forskere legger ikke merke til denne risikoen.

Her er fire vanlige tilfeller:

  • En maskinlaeringsartikkel viser en pandas DataFrame. De forste 10 radene har ekte pasientnavn og ID-er.
  • En klinisk studie viser R-utdata. Pasientverdier er synlige pa skjermen. Pasient-ID-er vises i margen.
  • En samfunnsvitenskapelig artikkel viser SPSS-tabeller. Svarene fra ekte mennesker er synlige.
  • En journalveiledning viser en Jupyter-notatbok. Ekte brukerregistre fungerer som eksempelrader.

I hvert tilfelle mente forfatteren a vise metode. De personlige journalene var ikke poenget. De var bare der for a gjore eksemplet mer realistisk.

Men "ikke poenget" betyr ikke trygt. GDPR Artikkel 4(1) sier at personjournaler inkluderer alle fakta om en identifisert person. En pasientjournal i en publisert artikkel er personopplysninger. Det spiller ingen rolle om det er i et skjermbilde. A publisere det uten samtykke eller et lovlig grunnlag under Artikkel 6 bryter GDPR.

Se GDPR-samsvarsoversiket for mer om publiseringsregler.

Hvorfor dette skaper juridisk risiko

Forskningsgrupper star na overfor mer GDPR-handhevelse. Publiseringsfeil er en viktig utloser. Fire risikoer skiller seg ut.

Tilbaketrekking av journal. Artikkel 17 gir personer rett til sletting. Dette gjelder ogsa publiserte journaler. Hvis en person finner sine opplysninger i en artikkel, kan de be om fjerning. For en journal betyr dette ofte tilbaketrekking. Tilbaketrekking skader en forskers karriere.

Funn fra etikkutvalg. Etikkutvalg gjennomgar publisert arbeid. De sjekker for GDPR-samsvar. De har begynt a flagge artikler som viser personjournaler i skjermbilder. Disse flaggene pavirker en forskers fremtidige arbeid.

Brudd pa datatilgangsavtaler. Forskningsdatasett leveres med datatilgangsavtaler. Disse reglene fastsetter hva som kan publiseres. Et skjermbilde med personjournaler kan bryte avtalen. Resultatet er ofte tap av datasettilgang.

Artikkel 89-grenser. Artikkel 89 tillater bruk av personopplysninger til vitenskapelige formal. Det letter noen regler. Men bare der riktige sikkerhetstiltak finnes. A vise personjournaler i et skjermbilde uten de-identifisering er ikke et sikkerhetstiltak. Det er et brudd.

Se var beskyttelses- og sikkerhetstiltaksside for den fullstendige oversikten.

Hvor ofte skjer dette?

Dette problemet er ikke sjeldent. Det pavirker publisert arbeid pa tvers av mange felt.

Noen faktorer driver det.

Reproduserbarhetsnormer. Journaler vil ha metodiske detaljer. Forskere bruker skjermbilder for a imotekkomme dette behovet. De sjekker ikke alltid hva som er synlig i hvert bilde.

Stramme tidsfrister. Tidspress forer til raske skjermbilder. Det er ikke tid til a gjennomga hvert bilde for eksponerte journaler.

Lav synlighet i bilder. En DataFrame kan ha 20 kolonner. Navn og ID-er kan vaere i en kolonne langt til hoyre. Forskeren ser pa nokkelkolonnen, ikke ID-kolonnen.

Ingen sjekk ved innlevering. Journalportaler kjoerer formatsjekker og plagiatskanning. Ingen sjekker bilder for personlige enheter. Ingenting flagger problemet for artikkelen gar live.

Screeningarbeidsflyt for forskningsgrupper

En forhandsscreeningsprosess kan stoppe disse problemene. Den har syv trinn.

  1. Forsker fullforer manuskriptutkastet med alle figurer.
  2. Utkastet gar til en intern gjennomgar - PI-en eller en personvernkontakt.
  3. Bilde-personopplysningsdeteksjon kjoerer pa alle bildefiler i manuskriptet.
  4. Rapporten flagger bilder med lesbar tekst som matcher personlige enhetsmonstre.
  5. Forsker gjennomgar flaggede bilder.
  6. For hvert flagget bilde: erstatt det med et rent skjermbilde. Bytt pasient-ID 12847 med ID 00001. Erstatt ekte navn med "Pasient A".
  7. Det endelige manuskriptet sendes til journalen med rene bilder.

Tekniske alternativer:

  • Manuelt: Eksporter manuskriptbilder. Kjor batch-personopplysningsdeteksjon. Gjennomga rapporten.
  • Halvautomatisert: Bruk en delt mappe for utkast. Kjor batchbehandling ukentlig pa nye filer.
  • Arbeidsflyt-integrert: Legg til et screeningtrinn i innleveringsportalen.

Screening er raskt. For et 15-figurers manuskript tar bilde-personopplysningsdeteksjon under to minutter. En tilbaketrekking tar maneder.

Besok FAQ eller ordboken for mer om deteksjonsfunksjoner.

Casestudie: Europeisk universitet

En forskningsgruppe la til bilde-personopplysningsscreening i sin manuskriptarbeidsflyt. Et narnaer-missetilfelle utloste endringen. En artikkel under gjennomgang hadde pasientnavn i et DataFrame-skjermbilde.

Hva de gjorde:

  • Alle artikkelutkast ble behandlet for bilde-personopplysninger for journalinnlevering.
  • Screening dekket alle PNG-, JPG- og PDF-figurer i hvert utkast.
  • En personvernkontakt gjennomgikk resultatene.

Resultater over seks maneder:

  • 23 manuskripter screenet.
  • 7 manuskripter (30 %) hadde minst ett bilde med personlige enheter.
  • Typer funnet: pasientnavn i DataFrames (4 artikler).
  • Bruker-ID-er som matcher pasientformater (2 artikler).
  • E-postadresser i skjermbildemarger (1 artikkel).
  • Alle 7 rettet for innlevering.
  • Null tilbaketrektingsforesporsler eller etikkfunn etter innlevering.

Etikkutvalget siterer na denne arbeidsflyten som et modell "hensiktsmessig sikkerhetstiltak" under Artikkel 89. Det stotter gruppens fremtidige soknader om forskningsunntak.

Les grunnleggerens uttalelse for a lare mer om hvorfor anonym.legal ble bygget for denne typen problem.

Kilder

Klar til å beskytte dataene dine?

Begynn å anonymisere PII med 285+ enhetstyper på 48 språk.

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.