A heterogén dokumentumkörnyezet valósága
Kérdezze meg bármely megfelelőségi tisztviselőt, hogy milyen dokumentumformátumokat kell anonimizálnia DSAR-válaszokhoz, és a lista megjósolható: Word-szerződések, PDF-számlák, Excel ügyféladatok, CSV-rendszerexportok és néha JSON-naplók vagy XML-adatfolyamok.
Kérdezze meg, milyen eszközöket használnak, és a válasz jellemzően: három-öt különböző eszköz, mindegyik különböző entitáslefedettséggel, különböző konfigurációs felülettel és különböző auditnapló-formátumokkal.
Ez a töredezettség nem a tervezés hiányából ered. Annak hiányát tükrözi, hogy egyetlen eszköz sem kezeli valóban az összes éles dokumentumformátumot egyenértékű képességgel. Minden formátumhoz léteznek szakosodott eszközök. Az összes formátumot ugyanazzal a motorral, ugyanolyan entitástípusokkal és ugyanolyan auditnyomvonallal kezelő egységes eszköz a múltban ritka volt.
Ez a megfelelőségi probléma, amelyet ez létrehoz: a több dokumentumtípust átfogó DSAR-válaszokat különböző szabványokat alkalmazó több eszközzel anonimizálják. Az ebből eredő következetlenség — az X entitást anonimizálják a PDF-ben, de nem az Excel-exportban, mert az Excel-eszköz más entitáslistát használ — pontosan olyan megfelelőségi hiányosságot teremt, amelyet az adatvédelmi hatóságok auditjai felszínre hoznak.
Formátumspecifikus kihívások
Minden dokumentumformátum sajátos műszaki kihívásokat jelent a személyes adatok felismerése szempontjából:
A PDF-ek lehetnek natív szövegek (kijelölhetők) vagy képalapúak (szkenneltek). A képalapú PDF-ekhez szövegelemzés előtt OCR szükséges, ami hibaarányokat hoz be. A natív PDF-ek szövegfragmentumokat tartalmazhatnak (minden szó külön szövegobjektumként tárolva), amelyek megzavarják a szóhatárokon átívelő entitásfelismerést. A többhasábos elrendezések olvasási sorrendjének rekonstrukcióját igénylik a szövegelemzés előtt.
Word (DOCX)
A DOCX dokumentumok tartalmazzák a dokumentumszöveget XML-ben, de emellett: fejléceket, lábléceket, megjegyzéseket, nyomon követett változásokat, szövegdobozokat és lábjegyzeteket is. A fejlécekben/láblécekben lévő személyes adatok (levélpapír-címek, kapcsolattartási adatok) gyakran kimaradnak azon eszközöknél, amelyek csak a fő szövegtörzset elemzik. A nyomon követett változások olyan törölt szöveget tartalmazhatnak személyes adatokkal, amely nem látható a megjelenített dokumentumban, de jelen van a fájlszerkezetben.
Excel (XLSX)
Az Excel kétdimenziós szerkezete azt jelenti, hogy személyes adatok megjelenhetnek bármely cellában, száz oszlop és ezer sor bármelyikén. Az oszlopfejlécek kontextusjelzéseket biztosítanak („TAJ”, „E-mail”, „Telefon”), amelyeket az NER-modellek nem kapnak meg pusztán szövegelemzésből. A cellaértékek számként tárolódhatnak (dátumok, kötőjel nélküli TAJ-számok), amelyek formátumtudatos értelmezést igényelnek. Több munkalap tartalmazhat összefüggő személyes adatokat, amelyeket következetesen kell kezelni.
CSV
A CSV szerkezetileg hasonló az Excelhez, de sok implementációban oszlopfejlécek nélkül. A „megjegyzések” vagy „észrevételek” oszlopok mezőértékei szabad szövegűek, és személyes adatokat tartalmazhatnak nem személyes adatok mellett. A kódolási problémák (UTF-8 vs. Latin-1) felismerési hibákat okozhatnak az európai személyes adatokban előforduló nem ASCII karaktereknél.
JSON
A beágyazott szerkezet azt jelenti, hogy a személyes adatok mélyen el lehetnek rejtve (user.address.street.line1). A tömbértékek iterációt igényelnek. Ugyanaz a mezőnév különböző objektumokban különböző személyesadat-jellemzőkkel bírhat. A sémaalapú elemzést (tudva, hogy az „email” mezők mindig e-mail-címeket tartalmaznak) tartalmi felismeréssel kell kombinálni.
Miért jelent megfelelőségi problémát a formátumok közötti következetlenség?
A GDPR DSAR-forgatókönyv szemléletesen illusztrálja a következetlenségi kockázatot:
Egy érintett DSAR-t nyújt be, kérve a róla tárolt összes személyes adatot. A megfelelőségi csapat a következőket találja:
- 3 Word-dokumentum (szerződések, levelezés)
- 2 PDF-dokumentum (számlák, támogatási átirat)
- 1 Excel-táblázat (ügyfélszámla-adatok)
- 1 CSV-export (rendszerhozzáférési naplók)
A megfelelőségi csapat az A eszközt használja PDF-ekhez (kiváló lefedettség), a B eszközt Wordhoz (jó lefedettség, de kihagyja a fejléceket/lábléceket), egy Excel-makrót XLSX-hez (fedezi a nyilvánvaló oszlopokat, kihagyja a szabad szövegű mezőket) és semmit a CSV-hez (kézi felülvizsgálat).
Az érintett anonimizált csomagot kap. Az Excel-táblázatban a „kezelői megjegyzések” szabad szövegű oszlopot nem dolgozta fel a makró. A Word-dokumentumokban az ügyvédi iroda fejlécét tartalmazó oldal fejlécbeli lakcímet a B eszköz kihagyta. Mindkét elem olyan személyes adatokat tartalmaz, amelyeket az érintett nyilvántartásai szerint anonimizálni kértek.
A GDPR 17. cikke (törléshez való jog) vagy a 15. cikke (hozzáférési jog) értelmében a megfelelőségi csapat hiányos DSAR-választ állított elő. Ha az érintett vagy egy adatvédelmi hatóság felfedezi a hiányosságot, a következetlen eszközhasználat hozzájáruló tényező a megfelelőségi hibában.
A formátumok közötti következetesség mint megfelelőségi követelmény
A legszigorúbb DSAR-megfelelőségi keretek nem csupán azt határozzák meg, hogy mely személyesadat-típusokat kell anonimizálni, hanem azt is, hogy ugyanaz az anonimizálási szabvány alkalmazandó az összes formátumra egy adott válaszban.
Ez azt jelenti:
- Ugyanolyan entitástípusok ellenőrzése Wordban, PDF-ben, Excelben, CSV-ben és JSON-ban
- Ugyanolyan megbízhatósági küszöbök alkalmazása
- Ugyanolyan helyettesítő tokenek használata (egységes anonimizálási tokenek az egyetlen válaszkészletben lévő összes dokumentumban)
- Egyetlen auditnyomvonal, amely az összes formátumot lefedi a válaszban
Az egységes platformos formátumtámogatás lehetővé teszi az összes formátumra azonosan alkalmazható konfigurációs előbeállításokat. A szervezetéhez konfigurált „EU magánszemélyek DSAR-a” előbeállítás ugyanazt a 32 entitástípust ellenőrzi PDF-szerződésben, Excel ügyféladatban és CSV rendszernaplóban — mert mindhárom feldolgozásához ugyanaz a motor fut.
Vegyes formátumú készletek kötegelt feldolgozása
A DSAR-megfelelőség méretarányos kezeléséhez a kötegelt feldolgozásnak egy egységként kell kezelnie a vegyes formátumú készleteket:
Bemenet: 15 különböző formátumú fájlt tartalmazó mappa (PDF, DOCX, XLSX, CSV), amely egy érintett összes tárolt adatát tartalmazza
Feldolgozás:
- Formátumfelismerés fájlonként
- Megfelelő elemző minden formátumhoz (PDF-szövegkinyerés, DOCX XML-elemzés, XLSX cellaiteráció, CSV mezőelemzés)
- Ugyanaz az NLP-csatorna alkalmazva az összes formátumból kinyert szövegre
- Ugyanaz az előbeállítás-konfiguráció alkalmazva a köteg összes fájljára
- Egységes anonimizálási tokenkészlet (ha „Kiss János” 3 különböző dokumentumban szerepel, mind a 3-ban ugyanaz a helyettesítő token kerül alkalmazásra)
Kimenet:
- Mind a 15 fájl anonimizált verziója eredeti formátumukban
- Formátumközi auditjelentés, amely bemutatja az összes észlelt entitást, a dokumentumforrást, a megbízhatóságot és a végrehajtott műveletet
A formátumközi auditjelentés a megfelelőségi dokumentáció: egyetlen dokumentum bizonyítja, hogy mind a 15 fájlt ugyanazzal a szabvánnyal, ugyanolyan entitáslefedettséggel, ugyanolyan konfiguráció alatt dolgozták fel.
Adatvédelmi hatósági auditoknál ez lényegesen jobban védhető, mint az, hogy „a PDF-eket Adobe-bal, az Excelt makróval, a CSV-t kézzel dolgoztuk fel”.
Gyakorlati integráció DSAR-csapatok számára
Az egységes formátumtámogatással rendelkező rendszeres DSAR-mennyiségeket kezelő megfelelőségi csapatok számára a munkafolyamat:
- Az érintett összes dokumentumának összegyűjtése (manuális gyűjtés a rendszerekből)
- DSAR-köteg létrehozása az anonimizálási platformon (az összes fájl húzása formátumtól függetlenül)
- „EU magánszemélyek DSAR-a” előbeállítás kiválasztása (lefedi az összes GDPR-által megkövetelt entitástípust)
- Kötegelt feldolgozás futtatása
- Anonimizált kimenetek és összesített auditjelentés letöltése
- Minőségellenőrzés: a kötegkimenet 2-3 dokumentumának eseti ellenőrzése
- Anonimizált dokumentumok becsomagolása az érintett válaszához
- Auditjelentés csatolása a DSAR-esetrekordhoz
A kézi gyűjtés (1. lépés) marad az elsődleges időköltség. A 2–8. lépések egy tipikus DSAR-kötegnél 10 percen belül elvégezhetők. Az 5. lépésben generált auditjelentés biztosítja a GDPR elszámoltathatósági elvének megfelelési dokumentációját.
Az egységes anonimizálási csatornák korlátai
A formátumközi anonimizálási csatornák megoldják a formátumtöredezettséget, de bevezetnek bizonyos, megértést érdemlő megkötéseket:
Konverziós hűségi kompromisszumok: A DOCX feldolgozási formátumba konvertálása és visszaalakítása megváltoztathatja a dokumentum elrendezését, elveszítheti a változáskövetési előzményeket, módosíthatja a beágyazott metaadatokat, vagy megsérülhetnek összetett elemek (diagramok, beágyazott OLE-objektumok). Jogi dokumentumoknál, ahol a formázásnak bizonyítéki jelentősége van, a konverzióalapú csatornák gondos validálást igényelnek.
A formátumspecifikus személyesadat-minták karbantartást igényelnek: A strukturált CSV-adatokhoz hatékony entitásfelismerők különböznek a kézzel írt nyomtatvány OCR-kimenetéhez vagy örökölt WordPerfect-dokumentumokhoz szükségesektől. Az „egységes” csatorna gyakran formátumonkénti előfeldolgozást igényel, amely szintén folyamatos karbantartást igényel a dokumentumformátumok fejlődésével.
A pontosság romlik szokatlan formátumok esetén: A legtöbb NLP-modellt elsősorban webes szövegen és általános irodai dokumentumokon tanítják. Szokatlan formátumok (örökölt EDI, egyéni XML-sémák, szabadalmazott CAD fájl metaadatok) lényegesen rosszabb személyesadat-felismerési pontosságot adhatnak, mint az összesített mutatók sugallják.
Nem minden formátum rekonstruálható: Egyes dokumentumformátumok (bizonyos PDF-típusok, csak képeket tartalmazó fájlok) nem anonimizálhatók helyben — vizuálisan kell redakálni őket, ami elveszíti a géppel olvasható szerkezetet. A postanonimizálási keresésre vagy indexelésre támaszkodó szervezetek számára a vizuális redakciós csatornák nem feltétlenül elegendők.
Az anonym.legal kötegelt feldolgozó motorja egységes entitáskonfigurációval kezeli a DOCX, PDF, XLSX, CSV és JSON formátumokat. A kötegben lévő összes fájlt ugyanazzal az előbeállítással dolgozzák fel, és egységes auditjelentést hoznak létre a megfelelőségi dokumentációhoz.
Források: