By · Last updated 2026-06-05

Vissza a BlograJogi Technológia

Vegyes formátumú elektronikus felismerés: Megfelelőségi hézag

Az elektronikus felismerési termelések és a GDPR DSAR-ok kiterjednek PDF-ekre, Word-dokumentumokra, Excelre és JSON-exportokra. A különböző formátumokhoz különböző eszközök használata következetességi hézagokat hoz létre.

June 5, 20267 perc olvasás
e-discoverymixed formatDSAR compliancelegal redactiondocument production

A formátumtöredezettség valósága

Megérkezik egy jogi dokumentumtermelési kérés. A termelés a következőkre terjed ki:

  • PDF-szerződések a dokumentumkezelő rendszerből
  • Word-dokumentumok a jogi felülvizsgálatból
  • Excel-táblázatok a pénzügyről
  • CSV-exportok a CRM-ből
  • JSON-naplók az API-auditnyomvonalból

Öt formátum. Az iroda jelenlegi eszközkészlete: Adobe Acrobat PDF-redakcióhoz, egy Word-makró DOCX-hez, az Excel beépített „keresés és csere” funkciója XLSX-hez, kézi felülvizsgálat CSV-hez és semmi JSON-hoz.

Ez nem szokatlan. Egy 2025-ös Everlaw elektronikus felismerési jelentés a formátumtöredezettséget a legfőbb operatív kihívások egyikeként azonosítja, ahol a jogi csapatok átlagosan 3,2 különböző eszközt használnak vegyes formátumokat érintő dokumentumtermeléseknél. A működési terhelés jelentős. A megfelelőségi kockázat még jelentősebb.

Miért okoz a töredezett eszközhasználat megfelelőségi hézagokat?

Különböző formátumokhoz különböző eszközök használata három megfelelőségi sebezhetőséget teremt:

Entitáslefedettségi következetlenség: Az Adobe Acrobat beépített redakciója explicit szöveges karakterláncokat keres — nem futtat entitásfelismerést. Az Acrobattal produkált PDF csak azokat a szöveges karakterláncokat redakálja, amelyeket az üzemeltető explicit módon keres. A Word-makró csak az entitástípusokat ismeri fel, amelyekre programozták (jellemzően nevek és e-mailek, nem mind a 285+ entitástípus). Az Excel keresés-csere semmit sem fog, amit nem vittek be explicit módon. Az ugyanaz a TAJ-szám egy PDF-szerződésben és egy Excel-táblázatban két különböző eszközzel, két különböző felismerési szabvánnyal kezelhető.

Auditnyomvonal-töredezettség: Minden eszköz saját naplóját (vagy semmilyen naplót) állítja elő. Egy GDPR érintetti hozzáférési kérelem esetén, ahol az adatvédelmi hatóság megkérdezi, hogy „bizonyítsa, hogy az egyénről szóló összes személyes adatot azonosították és megfelelően kezelték”, háromból egy dokumentumkészlet különböző részét lefedő három különböző eszközből származó különálló auditnaplók nem alkotnak meggyőző megfelelőségi narratívát.

Konfigurációs eltérés: A különböző eszközök különböző konfigurációkkal rendelkeznek. A hat hónappal ezelőtt a jogi operatív csapat által beállított PDF-redakciós szabvány nem feltétlenül egyezik a múlt héten egy másik csapattag által frissített Word-makró beállításaival. A következetlenség láthatatlan marad, amíg termelési hibát nem okoz.

A következetességi követelmény nem elméleti. Az elektronikus felismerési termelési hibák miatti bírósági szankciók kifejezetten foglalkoztak a következetlenségi problémával: különböző szabványok alkalmazása különböző dokumentumtípusokra ugyanazon termelésben azt a szisztematikus folyamatot sérti, amelyet a bíróságok elvárnak.

A DSAR következetességi követelménye

A GDPR DSAR-ok explicit következetességi követelményt tartalmaznak a jogi szabványba ágyazva. A 15. cikk megköveteli, hogy az érintett „az összes” tárolt személyes adatokra vonatkozó tájékoztatást kapjon, nem „az összes személyes adatot PDF-ekben és a legtöbb személyes adatot Word-dokumentumokban”.

Az ICO DSAR-útmutatása explicit: a szervezeteknek szisztematikus megközelítést kell alkalmazniuk az érintettről tárolt összes személyes adat azonosításához, az összes rendszeren és formátumon. A szisztematikus megközelítés definíció szerint következetes módszertant igényel — nem formátumspecifikus eszközöket különböző szabványokkal.

Adatvédelmi hatósági vizsgálatokban a DSAR-panasz nyomán az auditor megkérdezi:

  1. Milyen folyamatot alkalmaztak az összes személyes adat azonosítására?
  2. Milyen eszközök dolgozták fel melyik dokumentumtípusokat?
  3. Milyen entitástípusokat kerestek minden formátumban?
  4. Milyen auditnyomvonal dokumentálja a válasz teljességét?

„Az Adobe-ot használtuk PDF-ekhez, egy makrót Wordhoz és az Excel keresési funkcióját táblázatokhoz, de nincsenek specifikus entitástípus-naplóink mindegyikről” nem kielégítő válasz a 3. és 4. kérdésre.

Az egységes motor előnye

Az egységes feldolgozó motor az összes formátumot ugyanazzal a felismerési logikával kezeli, lehetővé téve:

Egységesen alkalmazott konfigurációs előbeállítások: Egy „EU magánszemély DSAR-a” előbeállítás 32 entitástípussal feldolgoz egy PDF-et, DOCX-et, XLSX-et és CSV-t ugyanabból a DSAR-ból azonos entitáslefedettséggel. Az Excel-táblázatban lévő TAJ-számot ugyanolyan megbízhatósági küszöbbel ellenőrzik, mint a PDF-szerződésben lévőt.

Egyetlen auditnyomvonal: Egyetlen feldolgozási napló, amely a köteg összes fájlját lefedi, formátumtól függetlenül. Az auditjelentés megmutatja: fájlnév, fájltípus, felismert entitások, megbízhatósági értékek, végrehajtott műveletek — a termelési készlet minden fájljára vonatkozóan. Egyetlen dokumentum biztosítja az egész termelés megfelelőségi bizonyítékát.

Referenciális integritás formátumokon keresztül: Ha „Nagy Eszter” megjelenik egy PDF-szerződésben, egy Word-levelezési rekordban és egy Excel-számlázási táblázatban, az összes három formátumon következetes pszeudoanonimizálás ugyanazzal a tokennel helyettesítheti a nevét (PERSON_0001) mindháromban — lehetővé téve az érintettnek, hogy nyomon kövesse saját nyilvántartását a termelésben.

Vegyes formátumú kötegelt feldolgozás: Helyezze 15 különböző formátumú fájlt egyetlen kötegbe. Dolgozza fel egyetlen előbeállítással. Kapjon 15 anonimizált kimenetet és egy összesített auditjelentést. A működési munkafolyamat lényegesen egyszerűbb, mint három különálló eszköz-munkafolyamat kezelése.

Szövetségi ügynökség FOIA-alkalmazás

Az USA szövetségi kormányának 2025-ös, FOIA-automatizálást sürgető erőfeszítései kifejezetten a többformátumú kezelést azonosítják kulcsfontosságú követelményként. A szövetségi ügynökségek olyan FOIA-kéréseket kapnak, amelyek minden elképzelhető formátumban tárolt nyilvántartásokra terjednek ki — örökölt nagyszámítógép-exportok rögzített szélességű szövegben, modern együttműködési rendszerekből származó Word-dokumentumok, papíralapú archívumokból szkennelt PDF-ek, és adatbázis-exportok CSV és JSON formátumban.

A DOJ és a HHS is kísérletezett automatizált redakciós rendszerekkel kifejezetten azért, mert a kézi többformátumú feldolgozás nem méretezi a kérések mennyiségét. Ezen rendszerek alapkövetelménye: ugyanazok a mentességi szabványok következetes alkalmazása az összes formátumra, dokumentált auditnyomvonallal.

A szövetségi kormányon kívüli, hasonló többformátumú megfelelőségi követelményekkel szembesülő szervezetekre ugyanez az elv vonatkozik: a formátumok közötti kezelési következetesség a védhető megfelelőségi dokumentáció alapja.

Megvalósítás egy ügyvédi iroda DSAR-gyakorlatához

Egy közepes méretű ügyvédi iroda, amely vállalati ügyfeleknek nyújt GDPR DSAR-szolgáltatásokat, bevezette az egységes formátumfeldolgozást a DSAR-válasz munkafolyamatukhoz:

Előtte:

  • PDF-szerződések: Adobe Acrobat (kézi szöveges keresés)
  • DOCX-levelezés: Word-makró (csak név + e-mail)
  • XLSX-számlanyilvántartások: Excel keresés-csere (kézi bevitel)
  • CSV-exportok: Kézi felülvizsgálat
  • Feldolgozási idő DSAR-onként: 8-12 óra
  • Következetesen ellenőrzött entitástípusok az összes formátumban: 2-3 (név, e-mail)

Utána (egységes motor, kötegelt feldolgozás):

  • Összes formátum: egyetlen köteg „EU magánszemély DSAR-a” előbeállítással
  • 32 entitástípus következetesen ellenőrizve az összes formátumban
  • Feldolgozási idő DSAR-onként: 45 perc (beleértve a kimenet felülvizsgálatát)
  • Egyetlen auditjelentés DSAR-onként az adatvédelmi tisztviselő jóváhagyásához
  • Következetesen ellenőrzött entitástípusok az összes formátumban: 32

A megfelelőségi javulás: az iroda most be tudja mutatni a következetes entitáslefedettséget egy DSAR-termelés összes dokumentumtípusán, egyetlen auditdokumentummal válaszonként. A DSAR-onkénti 8-12 óra 1 óra alá csökkent — lehetővé téve az irodának, hogy a DSAR-megfelelőséget skálázható szolgáltatásként kínálja.

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.