anonym.legal

By · Last updated 2026-06-05

Назад к блогуGDPR и соблюдение

Персональные данные в научных публикациях: скриншоты и GDPR

Академические статьи регулярно содержат датафреймы pandas и вывод R с реальными записями пациентов в качестве примеров методологии. Вот почему это является нарушением GDPR.

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

Обновлено в 2026 году — Правоприменение GDPR в отношении исследовательских организаций усилилось. Этот риск по-прежнему широко распространён в публикуемых работах.

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

Многие академические статьи содержат снимки экрана с инструментами анализа. Цель — показать методику. Но такие скриншоты могут раскрывать реальные персональные записи. Большинство исследователей не замечают этого риска.

Вот четыре распространённых случая:

  • В статье о машинном обучении показан датафрейм pandas. В первых 10 строках — реальные имена и идентификаторы пациентов.
  • В клиническом исследовании показан вывод R. Значения пациентов видны на экране. Идентификаторы пациентов отображаются на полях.
  • В статье по социальным наукам показаны таблицы SPSS. Видны ответы реальных людей на опросы.
  • В обучающем материале журнала показана записная книжка Jupyter. Реальные пользовательские записи служат примерами строк.

В каждом случае автор намеревался показать методологию. Персональные записи не были главным. Они просто делали пример более реалистичным.

Но «не главное» не означает безопасное. Статья 4(1) GDPR гласит, что персональные данные включают любые сведения об идентифицированном лице. Запись пациента в опубликованной статье является персональной информацией. Не важно, находится ли она на скриншоте. Её публикация без согласия или правового основания по Статье 6 нарушает GDPR.

Подробнее о правилах публикации — в обзоре соответствия GDPR.

Почему это создаёт правовой риск

Исследовательские организации всё чаще сталкиваются с правоприменением GDPR. Нарушения при публикации — один из ключевых триггеров. Выделяются четыре риска.

Отзыв из журнала. Статья 17 даёт людям право на удаление данных. Это распространяется и на опубликованные записи. Если человек обнаружит свои данные в статье, он может потребовать их удаления. Для журнала это часто означает отзыв публикации. Отзыв наносит серьёзный урон карьере исследователя.

Выводы этических комитетов. Этические комитеты проверяют опубликованные работы. Они проверяют соответствие GDPR. Они начали помечать статьи, показывающие персональные данные на скриншотах. Такие пометки влияют на будущие работы исследователя.

Нарушения соглашений о доступе к данным. Исследовательские наборы данных предоставляются с Соглашениями о доступе к данным. В них прописано, что можно публиковать. Скриншот с персональными данными может нарушить соглашение. Результатом часто является потеря доступа к набору данных.

Ограничения Статьи 89. Статья 89 разрешает использование персональных данных в научных целях. Она смягчает некоторые правила. Но только при наличии надлежащих защитных мер. Показ персональных данных на скриншоте без деидентификации не является защитной мерой. Это нарушение.

Полный анализ — на странице защиты данных и защитных мер.

Как часто это происходит?

Эта проблема не редкость. Она затрагивает публикации в самых разных областях.

Несколько факторов её обуславливают.

Нормы воспроизводимости. Журналы требуют детального описания методов. Исследователи используют скриншоты для выполнения этого требования. При этом они не всегда проверяют, что видно на каждом изображении.

Сжатые сроки. Цейтнот приводит к быстрым скриншотам. На проверку каждого изображения на предмет раскрытых данных времени не остаётся.

Низкая заметность в изображениях. Датафрейм может содержать 20 столбцов. Имена и идентификаторы могут находиться в крайнем правом столбце. Исследователь смотрит на ключевой столбец, а не на столбец с идентификатором.

Отсутствие проверки при подаче. Порталы журналов выполняют форматную проверку и проверку на плагиат. Ни один из них не проверяет изображения на наличие персональных сущностей. Ничто не сигнализирует о проблеме до выхода статьи в свет.

Рабочий процесс проверки для исследовательских групп

Процесс предварительной проверки перед подачей может предотвратить эти проблемы. Он состоит из семи шагов.

  1. Исследователь завершает черновик рукописи со всеми рисунками.
  2. Черновик передаётся внутреннему рецензенту — руководителю группы или контактному лицу по вопросам конфиденциальности.
  3. Обнаружение персональных данных в изображениях запускается для всех графических файлов рукописи.
  4. Отчёт помечает изображения с читаемым текстом, соответствующим шаблонам персональных сущностей.
  5. Исследователь проверяет помеченные изображения.
  6. Для каждого помеченного изображения: замените его чистым скриншотом. Замените идентификатор пациента 12847 на 00001. Замените реальные имена на «Пациент А».
  7. Финальная рукопись подаётся в журнал с чистыми изображениями.

Технические варианты:

  • Ручной: Экспортируйте изображения рукописи. Запустите пакетное обнаружение персональных данных. Изучите отчёт.
  • Полуавтоматический: Используйте общую папку для черновиков. Запускайте пакетную обработку новых файлов еженедельно.
  • Интегрированный в рабочий процесс: Добавьте шаг проверки в портал подачи.

Проверка занимает немного времени. Для рукописи из 15 рисунков обнаружение персональных данных в изображениях занимает менее двух минут. Отзыв публикации — месяцы.

Подробности — в FAQ или глоссарии.

Практический случай: европейский университет

Одна исследовательская группа добавила проверку изображений на персональные данные в рабочий процесс подготовки рукописей. Изменение произошло после инцидента, едва не ставшего серьёзной проблемой. В рецензируемой статье обнаружились имена пациентов на скриншоте датафрейма.

Что они сделали:

  • Все черновики статей проверялись на наличие персональных данных в изображениях перед подачей в журнал.
  • Проверка охватывала все файлы PNG, JPG и PDF в каждом черновике.
  • Результаты анализировал контактный специалист по вопросам конфиденциальности.

Результаты за шесть месяцев:

  • Проверено 23 рукописи.
  • 7 рукописей (30%) содержали хотя бы одно изображение с персональными данными.
  • Обнаруженные типы: имена пациентов в датафреймах (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.