Zasto binarna detekcija licnih podataka ne zadovoljava uskladjenost
Azurirano za 2026
Svaki alat za licne podatke se suocava sa jednim teskim problemom. Isti niz moze biti licni podatak na jednom mestu, a ne na drugom.
"Jovan" u datoteci klijenta je subjekt podataka. "Jovan" u istorijskom radu o Jovanu F. Kenediju nije. Devetocifreni broj u medicinskom kartonu je HIPAA kod. Isti devet cifara u sifri proizvoda nije.
Oznaka da/ne ne moze da obradjuje ovo. Primorava na dva losa izbora: redaktovati sve nizove koji bi mogli biti licni podaci, ili redaktovati samo sigurne podudarnosti. Oba zakazuju u pravu, gde svaka odluka mora biti jasna i dokumentovana.
Skor po entitetu od 0 do 100 nudi treci put. Pokree nivovska pravila, redove za pregled od strane ljudi i potpune revizorske zapise.
Ogranicenje oznaka da/ne
Kontekst menja znacenje podataka. Dve datoteke mogu da sadrze isti niz. U jednoj, to su licni podaci. U drugoj, nisu. Oznaka to ne moze da pokaze. Broj moze.
Sa samo oznakom, vase dve opcije su lose. Preterana redakcija ubija vrednost dokumenta. Nedovoljna redakcija stvara pravni rizik. Ni jedna ne opstoji na sudu.
Pravno otkrivanje: Zasto su skorovi neophodni
Pravno otkrivanje ima pravila koja cine skor detekcije obaveznim.
Problem preterane redakcije. Redaktovanje imena advokata ili sudskih citata steti dokazima. Sudovi su kaznjavali advokate zbog preterane redakcije. Ista sudska praksa koja pokriva nedovoljnu redakciju pokriva i ovo.
Problem nedovoljne redakcije. Propustanje stvarnog licnog podatka stvara rizik. To ukljucuje krsenje privatnosti klijenta, zalbe Advokatskoj komori i u nekim mestima krivicne prijave.
Potreba da se objasni svaka odluka. Kada sud pita zasto je stavka redaktovana, advokati moraju to da objasne. "Alat ju je oznacio" nije dovoljno. "Alat je skorovao ovo na 94% kao Social Security Number. Nase pravilo automatski redaktuje iznad 85%." To je dovoljno.
Oznaka da/ne ne moze da da taj odgovor. Alat sa skorovima i postavljenim pravilima moze. Pogledajte takodje: Odbrana redakcija: AI skorovi na sudu.
Sistem pregleda sa tri nivoa
Najdelotvorniji postav koristi tri nivoa zasnovana na skoru entiteta.
Nivo 1 - Automatski (iznad 85%):
- Stavke koje odgovaraju formatima visokog pouzdanja (SSN, IBAN, MRN)
- Automatski redaktovano bez koraka od strane covjeka
- Zapis beleyi tip entiteta, skor, metodu i vreme
- Primer: "571-44-9283" na 97% kao SSN - automatski redaktovano
Nivo 2 - Pregled od strane covjeka (50-85%):
- Stavke koje mogu biti licni podaci ali zahtevaju procenu
- Poslato pregledacu da prihvati, odbaci ili prekvalifikuje
- Zapis beleyi tip entiteta, skor, ID pregledaca, odluku i vreme
- Primer: "Jovan Nikolic" u tehnickom dokumentu na 67% - pregledac potvrauje da je ime - redaktovano
Nivo 3 - Samo sugestija (ispod 50%):
- Stavke niskog pouzdanja prikazane kao saveti
- Nisu automatski redaktovane; pregledac moze da deluje ili preskoce
- Zapis beleyi tip entiteta, skor i izbor pregledaca
- Primer: "Petrovic" u dokumentu o proizvodu na 42% - pregledac nalazi da je naziv firme - nije redaktovano
Samo Nivo 2 zahteva rad od strane covjeka. Sva tri nivoa proizvode revizorske zapise.
Kako se gradju skorovi
Alati za licne podatke kombinuju signale da bi proizveli jedan broj po entitetu.
Regex uzorci. Tacno podudaranje SSN formata dobija visok bazni skor. Delimicno podudaranje dobija nizi.
Izlaz modela. Modeli za prepoznavanje entiteta dodeljuju verovatnocu po klasi. Skor od 0,93 za OSOBU daje rezultat visokog pouzdanja.
Kontekstualni signali. Tekst oko entiteta prilagodjava skor. "Moj SSN je 571-44-9283" ga povecava. "Sifra proizvoda 571-44-9283" ga smanjuje.
Pravila ansambla. Sistemi kombinuju regex, model i kontekstualne signale sa postavljenim tezinama. Konacni broj odrazava sve dokaze.
Taj broj pokree svaku odluku o pragu u vasem radnom toku. Za vise o laznim pozitivima od da/ne alata, pogledajte: Porez na lazne pozitive u alatima za licne podatke.
Zahtevi osiguranja: Pravi primer
Datoteke osiguranja mesaju jasne licne podatke - ime vlasnika police, adresu, SSN - sa podacima koji zavise od konteksta: imena svedoka, nazivi firmi, potpisi procenitelja.
Da/ne alat ili redaktuje sva imena (pogresno za firme) ili propusta imena svedoka (rizik). Alat sa skorom obradjuje svaku stavku posebno:
- SSN sa oznakom "SSN vlasnika police" na 96% - automatski redaktovano
- Ime vlasnika police oznaceno OSOBA na 91% - automatski redaktovano
- Dobavljac oznacen ORGANIZACIJA na 78% - pregledan - pregledac odbija redakciju
- Ime svedoka oznaceno OSOBA na 82% - pregledan - pregledac prihvata
- Ime procenitelja oznaceno OSOBA na 71% - pregledan - pregledac prihvata (podaci trece strane)
Svaka odluka ima numericku osnovu. Revizorski trag je kompletan.
Izgradnja zapisa uskladjenosti
Za GDPR clan 5(1)(f) i HIPAA Security Rule, alati sa skorovima generisu zapise sami.
Revizorski zapisi na nivou entiteta beleye tip entiteta, skor, tip odluke (automatska ili manuelna), ID pregledaca i vreme. Izvozimo kao CSV za upite organa za podatke.
Zapisi o pragovima dokumentuju trenutna podesavanja i svaku promenu. Svaka promena ukljucuje ko ju je napravio, kada i zasto. Ovo pokazuje upravljanu, nameru politiku.
Statisticki izvestaji pokrivaju stope detekcije po tipu entiteta, stope pregleda Nivoa 2 i stope ponistavanja. Odgovaraju organu za podatke koji pita da "pokazete nase kontrole".
Za HIPAA vodic o revizorskom tragu, pogledajte: Objasnjiva redakcija: HIPAA revizije.
Oznaka da/ne je nagadjanje. Skor je dokaz.