anonym.legal

By · Last updated 2026-06-05

Назад на блоготGDPR & Усогласеност

Лични податоци во истражувања: Скриншоти и GDPR

Академски трудови редовно вклучуваат pandas DataFrame и R-излез кои прикажуваат реални пациентски записи како примери за методологија. Еве зошто ова претставува прекршување на GDPR.

June 5, 20267 мин читање
research dataacademic GDPRpublication privacyOCR image detectionArticle 89

Ажурирано за 2026 — Примената на GDPR врз истражувачките групи се зголеми. Овој ризик останува вообичаен во објавените трудови.

Проблемот со скриншотите на методологијата

Многу академски трудови вклучуваат скриншоти од алатките за анализа. Целта е да се прикаже методот. Но тие скриншоти можат да откријат реални лични записи. Повеќето истражувачи не го забележуваат овој ризик.

Еве четири вообичаени случаи:

  • Труд за машинско учење прикажува pandas DataFrame. Првите 10 редови содржат реални имиња и ID-броеви на пациенти.
  • Клиничка студија прикажува R-излез. Вредностите на пациентите се на екранот. ID-броевите на пациентите се прикажани во маргините.
  • Труд за општествени науки прикажува SPSS-табели. Видливи се одговорите на анкетата од реални луѓе.
  • Туторијал во списание прикажува Jupyter notebook. Реалните записи на корисниците служат како примерни редови.

Во секој случај, авторот имал намера да го прикаже методот. Личните записи не биле поентата. Биле само таму за да го направат примерот да изгледа реален.

Меѓутоа, "не е поента" не значи безбедно. Член 4(1) на GDPR вели дека личните записи вклучуваат секакви факти за идентификувана личност. Записот на пациентот во објавен труд е лична информација. Не е важно дали е во скриншот. Нивното објавување без согласност или законска основа согласно член 6 е прекршување на GDPR.

Видете го прегледот за усогласеност со GDPR за повеќе за правилата за објавување.

Зошто ова создава правен ризик

Истражувачките групи сега се соочуваат со поголема примена на GDPR. Неуспесите при објавување се клучен покренувач. Четири ризика се издвојуваат.

Повлекување на трудот. Член 17 им дава на луѓето право на бришење. Ова важи и за objавени записи. Ако некое лице ги пронајде своите детали во труд, може да побара нивно отстранување. За списание, ова честопати значи повлекување. Повлекувањето ја штети кариерата на истражувачот.

Наоди на етичкиот одбор. Етичките одбори ги разгледуваат objавените трудови. Ја проверуваат усогласеноста со GDPR. Почнале да обележуваат трудови кои прикажуваат лични записи во скриншоти. Овие обележувања влијаат на идната работа на истражувачот.

Прекршувања на договорот за пристап до податоци. Истражувачките бази на податоци доаѓаат со Договори за пристап до податоци. Овие правила ја утврдуваат дозволената содржина за objавување. Скриншот со лични записи може да го прекрши договорот. Резултатот честопати е губење на пристапот до базата на податоци.

Ограничувања на член 89. Член 89 дозволува употреба на лични информации за науката. Ги ублажува некои правила. Но само каде постојат соодветни заштитни мерки. Прикажувањето лични записи во скриншот без деидентификација не е заштитна мерка. Тоа е прекршување.

Видете ја нашата страница за заштита и заштитни мерки за целосен преглед.

Колку често се случува ова?

Овој проблем не е реткост. Влијае на objавени трудови во многу области.

Неколку фактори го поттикнуваат.

Норми за репродуктивност. Списанијата бараат детали за методот. Истражувачите користат скриншоти за да ја задоволат оваа потреба. Не секогаш проверуваат што е видливо на секоја слика.

Тесни рокови. Притисокот на времето води до брзи скриншоти. Нема време да се прегледа секоја слика за изложени записи.

Мала видливост во сликите. DataFrame може да има 20 колони. Имиња и ID-броеви може да бидат во колона далеку надесно. Истражувачот гледа во клучната колона, не во ID-колоната.

Без проверка при поднесување. Порталите на списанијата извршуваат проверки на форматот и скрининг за плагијат. Ниту еден не ги проверува сликите за лични ентитети. Ништо не го обележува проблемот пред трудот да биде objавен.

Работен тек за скрининг на истражувачки групи

Процесот на скрининг пред поднесување може да ги спречи овие проблеми. Има седум чекори.

  1. Истражувачот го завршува нацртот на ракописот со сите фигури.
  2. Нацртот оди на внатрешен рецензент — PI или контакт за приватност.
  3. Откривање лични податоци во слики се извршува на сите сликовни датотеки во ракописот.
  4. Извештајот ги обележува сликите со читлив текст кој одговара на шаблони на лични ентитети.
  5. Истражувачот ги прегледува обележаните слики.
  6. За секоја обележана слика: заменете ја со чист скриншот. Заменете го ID на пациентот 12847 со ID 00001. Заменете ги реалните имиња со "Пациент А."
  7. Конечниот ракопис оди во списанието со чисти слики.

Технички опции:

  • Рачно: Извезете ги сликите на ракописот. Извршете пакетно откривање лични податоци. Прегледајте го извештајот.
  • Полуавтоматизирано: Користете споделена папка за нацрти. Извршувајте пакетна обработка секоја недела на нови датотеки.
  • Интегрирано во работниот тек: Додајте чекор за скрининг во порталот за поднесување.

Скринингот е брз. За ракопис со 15 фигури, откривањето лични податоци во слики трае помалку од две минути. Повлекувањето трае месеци.

Посетете го ЧПП или речникот за повеќе за функциите за откривање.

Студија на случај: Европски универзитет

Една истражувачка група го додала скринингот на слики со лични податоци во нејзиниот работен тек за ракописи. Промената ја предизвикал инцидент на само-косо. Труд под рецензија имал имиња на пациенти во скриншот на DataFrame.

Она што го направиле:

  • Сите нацрти трудови биле обработувани за лични податоци во слики пред поднесување до списанието.
  • Скринингот опфаќал сите PNG, JPG и PDF фигури во секој нацрт.
  • Контакт за приватност ги прегледувал резултатите.

Резултати во текот на шест месеци:

  • Прегледани 23 ракописи.
  • 7 ракописи (30%) имале барем една слика со лични ентитети.
  • Пронајдени типови: имиња на пациенти во DataFrame (4 труда).
  • Кориснички ID-броеви кои одговараат на формати на пациенти (2 труда).
  • Адреси за е-пошта во маргините на скриншоти (1 труд).
  • Сите 7 поправени пред поднесување.
  • Нула барања за повлекување или наоди на етичкиот одбор по поднесувањето.

Етичкиот одбор сега го наведува овој работен тек како модел на "соодветна заштитна мерка" согласно член 89. Ја поддржува идните апликации за истражувачко исклучување на групата.

Прочитајте ја изјавата на основачот за да дознаете зошто anonym.legal е изграден за овој вид проблем.

Извори

Подготвени да ги заштитите вашите податоци?

Започнете со анонимизација на PII со 285+ типови на ентитети на 48 јазици.

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.