By · Last updated 2026-06-05

Vissza a BlograGDPR & Megfelelés

GDPR és régi szkennelt dokumentumok: OCR + személyes adatok

A GDPR törléshez való joga a személyes adatokra vonatkozik „formátumtól függetlenül”. A papíralapú archívumokból származó képalapú PDF-fájlok nem mentesek ez alól.

June 5, 20267 perc olvasás
legacy documentsOCR PII detectionGDPR erasurescanned documentsdocument archive

GDPR és régi szkennelt fájlok: OCR a személyes adatok kezeléséhez

Frissítve 2026-ra

A GDPR-auditok rendszeresen ugyanazt a rejtett kockázatot tárják fel: régi, képalapú PDF-archívumokat.

Az ügyvédi irodák 20 évnyi szkennelt ügyfélaktát őriznek. A kórházak évtizedes betegkartonokat tárolnak. A kormányzati szervek szkennelt iratokat archiválnak. A bankok digitalizált kölcsönszerződéseket tartanak nyilván.

Ezeket az archívumokat egyetlen közös vonás jellemzi. A fájlok raszterképek — szkennelt PDF-ek, TIFF- vagy JPEG-formátumú fájlok. Nincs szöveges rétegük. A szabványos személyesadat-felismerő eszközök nem tudják beolvasni őket. A legtöbb anonimizálási eszköz számára ezek a fájlok egyszerűen nem léteznek.

Gakori tévhit: „Ezek képfájlok — a GDPR nem vonatkozik rájuk.”

A GDPR 17. cikkének (1) bekezdése biztosítja az embereknek a törléshez való jogot. A 26. preambulumbekezdés kimondja, hogy az anonimizálás eltávolítja a személyes adatokat a szabályozás hatálya alól. Egyik rendelkezés sem tesz kivételt a képformátum alapján. Az az ügyvédi iroda, amely nem tud eleget tenni egy 15 évvel ezelőtti ügyfélre vonatkozó törlési kérelemnek, megfelelőségi hiányossággal küzd — nem mentességgel rendelkezik.

Lásd megfelelőségi áttekintőnket és biztonsági gyakorlatainkat a GDPR-támogatásról.

Az észlelési folyamat működése

A folyamat három szakaszban zajlik.

1. szakasz — OCR

Az OCR-motor beolvassa a képet és kinyeri a szöveget. Rögzíti minden szó helyzetét. A kimenet géppel olvasható szöveg koordinátákkal. A pontosság csökken, ha kézírás, fakuló tinta vagy régi betűtípus van jelen.

2. szakasz — NLP-alapú entitásfelismerés

A névelem-felismerő (NER) rendszer átvizsgálja az OCR-szöveget. Megtalálja a személyneveket, szervezeteket és helyszíneket. A mintafelismerés kiegészíti a TAJ-számokkal, telefonszámokkal és számlaszámokkal. Minden találat megbízhatósági pontszámot kap.

3. szakasz — Anonimizálás

Az észlelt entitások helyébe tokenek kerülnek a szöveges kimenetben. Az eredeti kép nem változik. A kép módosításához külön redakciós eszközre van szükség. Az anonimizált szöveg törlési kérelmek, adatvédelmi incidensek kezelése (DSAR) és megfelelőségi nyilvántartások céljára használható.

A modern OCR-motorok 98–99%-os karakterpontossággal dolgoznak tisztán nyomtatott oldalakon. Kézírás vagy leromlott minőségű szkennelt képek esetén ez 85–92%-ra esik vissza. Az entitásszintű pontosság általában magasabb a karakterszintűnél. Egy nevet akkor is fel lehet ismerni, ha néhány betű hibás.

A gyakorlati következmény: az OCR-pontosság befolyásolja az észlelt entitások számát, de nem határozza meg a módszer megbízhatóságát. Még 90%-os pontosság esetén is megtalálható a nevek és számok nagy része. Minőségi szintek beállítása mégis szükséges. Maga a módszer megalapozott.

Nagy archívum feldolgozása

A nagy, öröklött archívumok kezelése négyfázisú munkafolyamatot követ.

1. fázis — Leltár: Fel kell sorolni az összes képalapú archívumot. Rögzíteni kell a forrásrendszert és a dátumtartományt. A magas törlési kockázatú iratokat érdemes előre sorolni. Az ügyfelekkel kapcsolatos fájlok megelőzik a belső dokumentumokat.

2. fázis — Kötegelt feldolgozás: Az OCR és a személyesadat-felismerés kötegelt futtatása javasolt. Kötegenkénti ötezer–tízezer fájl tipikus méret. A feldolgozás éjszaka zajlik. Kimenetként minden fájlhoz személyes adatokról szóló jelentés és anonimizált szövegkivonat keletkezik.

3. fázis — Törlési kérelmek teljesítése: Az érintett elküldi a kérelmét nevével és az időszakkal. Az anonimizált kivonatokban rákeresünk a tokenekre. Megtaláljuk a fájlokat. Redakálunk. Naplózzuk a műveletet.

4. fázis — Folyamatos megfelelés: Az új szkennelt fájlok ugyanezen a folyamaton mennek át archiválás előtt. A személyesadat-jelentéseket a GDPR 30. cikke szerinti adatkezelési tevékenységek nyilvántartásának bizonyítékaként őrzik meg.

Esettanulmány: Ügyvédi iroda archívuma

Egy ügyvédi irodai audit során 80 000 képalapú PDF-es ügyfélszerződést találtak, amelyeket 1998 és 2010 között szkenneltek be. A szabványos személyesadat-eszközök nullát mutattak. A képformátum láthatatlan volt.

Tizenöt volt ügyfél nyújtott be törlési kérelmet az előző 12 hónapban. Az iroda azt válaszolta: „Nem tudjuk megerősíteni, hogy adatait töröltük.” Ez a válasz nem felel meg a GDPR 17. cikkének.

Az iroda lépései:

  • Az összes 80 000 fájlon elvégezte az OCR-t és a személyesadat-felismerést 5000-es kötegekben
  • A feldolgozás körülbelül három hétig tartott
  • Eredmény: 80 000 anonimizált szövegkivonat fájlonkénti jelentéssel
  • Kereshető index felépítése, amely összekapcsolja az entitásokat a fájlazonosítókkal

A feldolgozás után:

  • Egy érintett fájljainak megtalálása: átlagosan 4 perc
  • Fájlok száma kérelmenként: átlagosan 6–8
  • Redakálási idő kérelmenként: 20–30 perc

Mind a 15 nyitott kérelmet 30 napon belül teljesítették.

A lényeg: a megfelelőségi kötelezettség a feldolgozás előtt is fennállt. Az irodának csupán nem volt meg az eszköze a teljesítéséhez. Az OCR-alapú feldolgozás nem teremtett új kötelezettséget — csupán lehetővé tette a meglévő kötelezettség teljesítését.

Az OCR korlátai és minőségi szintek

A kézírás alacsonyabb OCR-pontossággal jár. Kézzel írt tartalom feldolgozása előtt alacsonyabb megbízhatósági küszöböt kell beállítani.

A gyenge szkennelési minőség csökkenti a pontszámokat. A kontraszt javítása és a ferdítés korrigálása segít az OCR futtatása előtt.

Szokatlan elrendezések — többhasábos oldalak, régi jogi betűtípusok — szintén alacsonyabb pontszámot eredményezhetnek.

Minőségi szintek beállítása a megfelelőségi munkához:

  • 95% fölötti oldalpontosság esetén: automatikus feldolgozás
  • 80–95% között: automatikus feldolgozás, majd emberi ellenőrzés a megjelölt entitásoknál
  • 80% alatt: kézi ellenőrzésre küldés

A szintezett megközelítés egyértelmű választ ad a szabályozóknak arról, hogyan értékelték a megbízhatóságot. A legtöbb automatizált eszköz a magas megbízhatóságú fájlokat kezeli. A kézi sor a többit fogadja. Az áteresztőképesség magas marad. A megfelelőségi minőség szintén.

GYIK-oldalunk az OCR-alapú feldolgozással és az auditnaplók követelményeivel kapcsolatos gyakori kérdéseket tartalmazza.

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.