By · Last updated 2026-06-05

Vissza a BlograGDPR & Megfelelés

Kutatási személyes adatok: képernyőfelvételek és a GDPR

Az akadémiai cikkek rendszeresen tartalmaznak pandas DataFrame-eket és R-kimeneteket, amelyek módszertani példaként valódi betegadatokat mutatnak. Íme, miért jelent ez GDPR-jogsértést.

June 5, 20267 perc olvasás
research dataacademic GDPRpublication privacyOCR image detectionArticle 89

Frissítve 2026-ra — A GDPR-végrehajtás kutatócsoportokkal szemben erősödött. Ez a kockázat a közzétett munkákban továbbra is általános.

A módszertani képernyőfelvétel problémája

Sok akadémiai cikk tartalmaz elemzőeszközök képernyőfelvételeit. A cél a módszer bemutatása. Ezek a felvételek azonban valódi személyes adatokat tárhatnak fel. A legtöbb kutató nem veszi észre ezt a kockázatot.

Íme négy tipikus eset:

  • Egy gépi tanulással foglalkozó cikk pandas DataFrame-et mutat. Az első 10 sor valódi betegneveket és azonosítókat tartalmaz.
  • Egy klinikai tanulmány R-kimenetet jelenít meg. A betegértékek láthatók a képernyőn. A betegazonosítók a margón szerepelnek.
  • Egy társadalomtudományi cikk SPSS-táblákat mutat. Valódi személyek felmérési válaszai láthatók.
  • Egy folyóirat-útmutató Jupyter notebookot mutat. Valódi felhasználói rekordok szolgálnak mintasorokként.

Mindkét esetben a szerző a módszert kívánta bemutatni. A személyes adatok nem voltak a lényeg. Csupán ott voltak, hogy a példa életszerűnek tűnjön.

A „nem ez volt a lényeg” azonban nem jelent biztonságot. A GDPR 4. cikkének (1) bekezdése szerint a személyes adatok közé tartozik minden azonosított személyre vonatkozó tény. Egy közzétett cikkben szereplő betegrekord személyes adat. Nem számít, ha képernyőfelvételen van. A 6. cikk szerinti hozzájárulás vagy jogalap nélkül közzétenni a GDPR-t sérti.

A kiadványokra vonatkozó szabályokról bővebben lásd a GDPR-megfelelőségi áttekintőt.

Miért jelent ez jogi kockázatot

A kutatócsoportokkal szemben egyre erősebb a GDPR-végrehajtás. A közzétételi hibák kulcsfontosságú kiváltó tényezők. Négy kockázat emelkedik ki.

Folyóirat-visszavonás. A 17. cikk biztosítja az embereknek a törléshez való jogot. Ez a közzétett adatokra is vonatkozik. Ha valaki megtalálja az adatait egy cikkben, kérheti az eltávolítást. Egy folyóirat esetén ez gyakran visszavonást jelent. A visszavonás a kutató karrierjét károsítja.

Etikai bizottság megállapításai. Az etikai bizottságok áttekintik a közzétett munkákat. Ellenőrzik a GDPR-megfelelőséget. Elkezdték megjelölni azokat a cikkeket, amelyek személyes adatokat mutatnak képernyőfelvételeken. Ezek a megjelölések hatással vannak a kutató jövőbeli munkájára.

Adatfelhasználási megállapodások megsértése. A kutatási adatkészletekhez adatfelhasználási megállapodások kapcsolódnak. Ezek a szabályok rögzítik, mi tehető közzé. A személyes adatokat tartalmazó képernyőfelvétel megszegheti a megállapodást. Az eredmény általában az adatkészlet-hozzáférés elvesztése.

A 89. cikk korlátai. A 89. cikk lehetővé teszi a személyes adatok tudományos célú felhasználását. Egyes szabályokat enyhít. De csak akkor, ha megfelelő biztosítékok állnak fenn. A személyes adatok képernyőfelvételen való megjelenítése anonimizálás nélkül nem biztosíték. Adatvédelmi incidens.

Lásd az adatvédelmi és biztosítéki oldalt a teljes elemzésért.

Milyen gyakran fordul elő?

Ez a probléma nem ritka. Számos tudományterületen érinti a közzétett munkákat.

Néhány tényező hajtja.

Reprodukálhatósági normák. A folyóiratok módszertani részleteket kérnek. A kutatók képernyőfelvételekkel felelnek meg ennek az igénynek. Nem mindig ellenőrzik, mi látható az egyes képeken.

Szoros határidők. Az időnyomás gyors képernyőfelvételekhez vezet. Nincs idő minden képet átnézni az esetlegesen kitett adatokért.

Alacsony láthatóság a képeken. Egy DataFrame-nek lehet 20 oszlopa. A nevek és azonosítók jobbra lévő oszlopokban lehetnek. A kutató a kulcsoszlopot nézi, nem az azonosítóoszlopot.

Nincs ellenőrzés benyújtáskor. A folyóiratok portáljai formátumellenőrzést és plágiumszűrést futtatnak. Egyik sem ellenőrzi a képeket személyes entitásokért. Semmi sem jelzi a problémát, mielőtt a cikk megjelenik.

Szűrési munkafolyamat kutatócsoportok számára

Egy benyújtás előtti szűrési folyamat megakadályozhatja ezeket a problémákat. Hét lépésből áll.

  1. A kutató befejezi a kéziratot az összes ábrával.
  2. A vázlat belső ellenőrzőhöz kerül — a témavezetőhöz vagy egy adatvédelmi felelőshöz.
  3. A képalapú személyesadat-felismerés lefut a kézirat összes képfájlján.
  4. A jelentés megjelöli azokat a képeket, amelyek olvasható szöveget tartalmaznak, és az személyesadat-mintáknak megfelelnek.
  5. A kutató átnézi a megjelölt képeket.
  6. Minden megjelölt képnél: cserélje le tiszta képernyőfelvételre. A 12847-es betegazonosítót cserélje le 00001-re. A valódi neveket cserélje le „A beteg”-re.
  7. A végső kézirat tiszta képekkel megy a folyóirathoz.

Technikai lehetőségek:

  • Kézi: Exportálja a kézirat képeit. Futtasson kötegelt személyesadat-felismerést. Tekintse át a jelentést.
  • Félig automatizált: Használjon megosztott mappát a vázlatokhoz. Futtasson kötegelt feldolgozást hetente az új fájlokon.
  • Munkafolyamatba integrált: Adjon hozzá szűrési lépést a benyújtási portálhoz.

A szűrés gyors. Egy 15 ábrás kézirat esetén a képalapú személyesadat-felismerés kevesebb mint két percet vesz igénybe. Egy visszavonás hónapokig tart.

Látogasson el a GYIK-oldalra vagy a szójegyzékre a felismerési funkciókkal kapcsolatos további információkért.

Esettanulmány: Európai egyetem

Egy kutatócsoport képalapú személyesadat-szűrést adott a kézirat-munkafolyamathoz. Egy majdnem baj indította el a változást. Egy bírálat alatt álló cikknek betegazonosítók szerepeltek egy DataFrame-képernyőfelvételen.

Mit tett a csoport:

  • Az összes vázlatcikket személyesadat-szűrésnek vetették alá a folyóirathoz való benyújtás előtt.
  • A szűrés minden vázlatban lefedett minden PNG-, JPG- és PDF-ábrát.
  • Egy adatvédelmi felelős tekintette át az eredményeket.

Eredmények hat hónap alatt:

  • 23 szűrt kézirat.
  • 7 kéziratnál (30%) legalább egy személyes entitásokat tartalmazó kép volt.
  • Talált típusok: betegazonosítók DataFrame-ekben (4 cikk).
  • Betegformátumoknak megfelelő felhasználói azonosítók (2 cikk).
  • E-mail-címek a képernyőfelvételek margóján (1 cikk).
  • Mind a 7 javítva lett benyújtás előtt.
  • Nulla visszavonási kérelem vagy etikai megállapítás benyújtás után.

Az etikai bizottság mostantól ezt a munkafolyamatot modell „megfelelő biztosítékként” idézi a 89. cikk alapján. Támogatja a csoport jövőbeli kutatási mentességi kérelmeit.

Olvassa el az alapítói nyilatkozatot, hogy megtudja, miért épült az anonym.legal ilyen típusú problémák megoldására.

Források

Készen áll az adatai védelmére?

Kezdje el a PII anonimizálását 285+ entitástípuson 48 nyelven.

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.