By · Last updated 2026-06-05

Zurück zum BlogDSGVO & Compliance

Forschungsveröffentlichung PII: Warum Ihre...

Wissenschaftliche Arbeiten enthalten regelmäßig pandas DataFrames und R-Ausgaben, die echte Patientenakten als Methodologiebeispiele zeigen.

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

Aktualisiert für 2026 — Die DSGVO-Durchsetzung gegen Forschungsgruppen hat zugenommen. Dieses Risiko bleibt in veröffentlichten Arbeiten weit verbreitet.

Das Problem mit Methoden-Screenshots

Viele wissenschaftliche Arbeiten enthalten Screenshots von Analyse-Tools. Das Ziel ist, die Methode zu zeigen. Aber diese Screenshots können echte personenbezogene Daten preisgeben. Die meisten Forscher bemerken dieses Risiko nicht.

Hier sind vier häufige Fälle:

  • Eine Machine-Learning-Studie zeigt einen pandas DataFrame. Die ersten 10 Zeilen enthalten echte Patientennamen und IDs.
  • Eine klinische Studie zeigt R-Ausgaben. Patientenwerte sind auf dem Bildschirm. Patienten-IDs sind am Rand sichtbar.
  • Eine sozialwissenschaftliche Arbeit zeigt SPSS-Tabellen. Antworten echter Befragter sind sichtbar.
  • Ein Journal-Tutorial zeigt ein Jupyter Notebook. Echte Nutzerdatensätze dienen als Beispieldaten.

In jedem Fall wollte der Autor die Methode zeigen. Die personenbezogenen Daten waren nicht der Fokus. Sie sollten das Beispiel nur greifbar machen.

Aber „nicht im Fokus" bedeutet nicht sicher. DSGVO Artikel 4(1) besagt, dass personenbezogene Informationen alle Angaben über eine identifizierte oder identifizierbare Person umfassen. Ein Patientendatensatz in einer veröffentlichten Arbeit ist eine personenbezogene Information. Es spielt keine Rolle, ob er in einem Screenshot erscheint. Eine Veröffentlichung ohne Einwilligung oder Rechtsgrundlage nach Artikel 6 verstößt gegen die DSGVO.

Mehr zu Veröffentlichungspflichten finden Sie in der DSGVO-Konformitätsübersicht.

Warum das ein rechtliches Risiko darstellt

Forschungsgruppen sehen sich wachsender DSGVO-Durchsetzung gegenüber. Veröffentlichungsfehler sind ein häufiger Auslöser. Vier Risiken stechen hervor.

Zeitschriften-Rückruf. Artikel 17 gibt Personen das Recht auf Löschung. Das gilt auch für veröffentlichte Informationen. Findet eine Person ihre Daten in einer Arbeit, kann sie deren Entfernung verlangen. Für eine Fachzeitschrift bedeutet das oft einen Rückruf oder eine Korrektur. Ein Rückruf schadet der Karriere eines Forschers.

Ethikkommissions-Feststellungen. Ethikkommissionen prüfen veröffentlichte Arbeiten auf DSGVO-Konformität. Sie haben begonnen, Arbeiten zu markieren, die personenbezogene Datensätze in Screenshots zeigen. Diese Feststellungen beeinflussen künftige Forschungsvorhaben.

Verstöße gegen Datenzugangsvereinbarungen. Forschungsdatensätze kommen mit Datenzugangsvereinbarungen. Diese regeln, was veröffentlicht werden darf. Ein Screenshot mit personenbezogenen Datensätzen kann die Vereinbarung verletzen. Die Folge ist oft der Verlust des Datenzugangs.

Grenzen von Artikel 89. Artikel 89 erlaubt die Verarbeitung personenbezogener Informationen für die Wissenschaft. Er erleichtert einige Anforderungen. Aber nur, wenn geeignete Schutzmaßnahmen bestehen. Personenbezogene Datensätze ohne De-Identifikation in einem Screenshot zu zeigen, ist keine Schutzmaßnahme. Es ist ein Verstoß.

Die vollständige Übersicht finden Sie auf unserer Seite zu Schutz und Sicherheitsmaßnahmen.

Wie häufig passiert das?

Das Problem ist nicht selten. Es betrifft veröffentlichte Arbeiten in vielen Bereichen.

Einige Faktoren treiben es an.

Reproduzierbarkeits-Normen. Fachzeitschriften wollen detaillierte Methodenbeschreibungen. Forscher nutzen Screenshots, um diesem Anspruch zu genügen. Sie prüfen nicht immer, was in jedem Bild sichtbar ist.

Enge Deadlines. Zeitdruck führt zu schnellen Screenshots. Es bleibt keine Zeit, jedes Bild auf offengelegte Datensätze zu prüfen.

Geringe Sichtbarkeit in Bildern. Ein DataFrame kann 20 Spalten haben. Namen und IDs befinden sich möglicherweise in einer weit rechts gelegenen Spalte. Der Forscher schaut auf die Analysespalte, nicht auf die ID-Spalte.

Keine Prüfung bei Einreichung. Zeitschriftenportale führen Formatprüfungen und Plagiatscreenings durch. Keines prüft Bilder auf personenbezogene Entitäten. Nichts markiert das Problem vor der Veröffentlichung.

Screening-Workflow für Forschungsgruppen

Ein Pre-Submission-Screening-Prozess kann diese Probleme verhindern. Er umfasst sieben Schritte.

  1. Forscher schließt das Manuskript mit allen Abbildungen ab.
  2. Entwurf geht an einen internen Prüfer — den PI oder einen Datenschutzbeauftragten.
  3. Bild-PII-Erkennung läuft über alle Bilddateien im Manuskript.
  4. Der Bericht markiert Bilder mit lesbarem Text, der persönlichen Entitätsmustern entspricht.
  5. Forscher prüft markierte Bilder.
  6. Für jedes markierte Bild: Ersetzen durch einen sauberen Screenshot. Patient-ID 12847 wird zu ID 00001. Echte Namen werden zu „Patient A."
  7. Das endgültige Manuskript geht mit sauberen Bildern an die Zeitschrift.

Technische Optionen:

  • Manuell: Manuskriptbilder exportieren. Batch-PII-Erkennung ausführen. Bericht prüfen.
  • Halbautomatisch: Gemeinsamen Ordner für Entwürfe nutzen. Wöchentliche Stapelverarbeitung neuer Dateien.
  • Workflow-integriert: Screening-Schritt im Einreichungsportal ergänzen.

Das Screening ist schnell. Bei einem 15-Abbildungen-Manuskript dauert die Bild-PII-Erkennung unter zwei Minuten. Ein Rückruf dauert Monate.

Weitere Informationen zu Erkennungsfunktionen finden Sie in den FAQ oder im Glossar.

Fallstudie: Europäische Universität

Eine Forschungsgruppe ergänzte ihren Manuskript-Workflow um Bild-PII-Screening. Ein Beinahe-Vorfall löste die Änderung aus. In einer Arbeit im Review-Prozess fanden sich Patientennamen in einem DataFrame-Screenshot.

Was sie taten:

  • Alle Manuskript-Entwürfe wurden vor der Einreichung auf Bild-PII geprüft.
  • Das Screening umfasste alle PNG-, JPG- und PDF-Abbildungen in jedem Entwurf.
  • Ein Datenschutzbeauftragter prüfte die Ergebnisse.

Ergebnisse über sechs Monate:

  • 23 Manuskripte gescreent.
  • 7 Manuskripte (30 %) hatten mindestens ein Bild mit personenbezogenen Entitäten.
  • Gefundene Typen: Patientennamen in DataFrames (4 Arbeiten).
  • Nutzer-IDs im Patienten-Registrierungsformat (2 Arbeiten).
  • E-Mail-Adressen in Screenshot-Rändern (1 Arbeit).
  • Alle 7 vor der Einreichung korrigiert.
  • Null Rückrufanfragen oder Ethikkommissions-Feststellungen nach Einreichung.

Die Ethikkommission zitiert diesen Workflow nun als Musterbeispiel für „geeignete Schutzmaßnahmen" nach Artikel 89. Er unterstützt künftige Forschungsfreistellungsanträge der Gruppe.

Lesen Sie die Gründer-Erklärung, um zu erfahren, warum anonym.legal für diese Art von Problem entwickelt wurde.

Quellen

Bereit, Ihre Daten zu schützen?

Beginnen Sie mit der Anonymisierung von PII mit über 285 Entitätstypen in 48 Sprachen.

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.