Dlaczego binarna detekcja PII nie spełnia wymogów zgodności
Zaktualizowano na rok 2026
Każde narzędzie PII stoi przed jednym trudnym problemem. Ten sam ciąg znaków może być daną osobową w jednym miejscu, a w innym — nie.
„Jan” w pliku klienta to podmiot danych. „Jan” w artykule historycznym o Janie Pawle II — już nie. Dziewięciocyfrowy numer w dokumentacji medycznej to kod HIPAA. Te same dziewięć cyfr w kodzie produktu — nie.
Flaga tak/nie nie poradzi sobie z tym. Wymusza jeden z dwóch złych wyborów: redaguj wszystkie ciągi, które mogą być PII, albo redaguj tylko pewne dopasowania. Oba podejścia zawodzą w kontekście prawnym, gdzie każda decyzja musi być jasna i udokumentowana.
Ocena na poziomie encji w skali od 0 do 100 oferuje trzecią ścieżkę. Umożliwia warstwowe reguły, kolejki do weryfikacji przez człowieka i pełną dokumentację audytową.
Ograniczenia flag tak/nie
Kontekst zmienia znaczenie danych. Dwa pliki mogą zawierać ten sam ciąg znaków. W jednym to dana osobowa. W drugim — nie. Flaga tego nie pokaże. Liczba — tak.
Mając tylko flagę, masz do wyboru dwie złe opcje. Nadmierna redakcja niszczy wartość dokumentu. Zbyt mała redakcja tworzy ryzyko prawne. Żadne z podejść nie wytrzymuje próby sądowej.
Odkrywanie prawne: dlaczego oceny są niezbędne
Procedura odkrycia prawnego ma zasady, które czynią ocenioną detekcję obowiązkową.
Problem nadmiernej redakcji. Redagowanie nazwisk adwokatów lub cytatów z orzeczeń sądowych niszczy wartość dowodową. Sądy nakładały kary na adwokatów za nadmierną redakcję. To samo orzecznictwo, które dotyczy niewystarczającej redakcji, obejmuje ten problem.
Problem niewystarczającej redakcji. Pominięcie rzeczywistego PII tworzy ryzyko. Obejmuje to naruszenia prywatności klientów, skargi do organów adwokackich, a w niektórych jurysdykcjach — odpowiedzialność karną.
Konieczność uzasadnienia każdej decyzji. Gdy sąd pyta, dlaczego element został zredagowany, adwokaci muszą to wyjaśnić. „Narzędzie to oznaczyło” jest niewystarczające. „Narzędzie oceniło ten element na 94% jako numer ubezpieczenia społecznego. Nasza reguła automatycznie redaguje powyżej 85%.” To wystarczy.
Flaga tak/nie nie udzieli tej odpowiedzi. Narzędzie z oceną i ustalonymi regułami — tak. Zobacz też: Obrona redakcji: wyniki AI przed sądem.
Trójwarstwowy system weryfikacji
Najskuteczniejsza konfiguracja używa trzech warstw opartych na ocenie encji.
Warstwa 1 — Automatyczna (powyżej 85%):
- Elementy zgodne z formatami o wysokiej pewności (SSN, IBAN, MRN)
- Automatyczna redakcja bez udziału człowieka
- Dziennik rejestruje typ encji, ocenę, metodę i czas
- Przykład: „571-44-9283” przy 97% jako SSN — automatycznie zredagowany
Warstwa 2 — Weryfikacja przez człowieka (50–85%):
- Elementy mogące być PII, ale wymagające oceny sytuacyjnej
- Przesyłane do weryfikatora w celu akceptacji, odrzucenia lub reklasyfikacji
- Dziennik rejestruje typ encji, ocenę, ID weryfikatora, decyzję i czas
- Przykład: „Jan Kowalski” w dokumencie technicznym przy 67% — weryfikator potwierdza, że to imię i nazwisko — zredagowany
Warstwa 3 — Tylko sugestia (poniżej 50%):
- Elementy o niskiej pewności wyświetlane jako wskazówki
- Brak automatycznej redakcji; weryfikator może działać lub pominąć
- Dziennik rejestruje typ encji, ocenę i wybór weryfikatora
- Przykład: „Nowak” w dokumencie produktowym przy 42% — weryfikator ustala, że to nazwa firmy — nie redagowany
Tylko Warstwa 2 wymaga pracy człowieka. Wszystkie trzy warstwy tworzą dokumentację audytową.
Jak budowane są oceny
Narzędzia PII łączą sygnały, aby uzyskać jedną liczbę na encję.
Wzorce regex. Dokładne dopasowanie formatu SSN daje wysoki wynik bazowy. Częściowe dopasowanie — niższy.
Wynik modelu. Modele rozpoznawania encji nazwanych przypisują prawdopodobieństwo na klasę. Wynik 0,93 dla PERSON daje wynik o wysokiej pewności.
Sygnały kontekstu. Tekst wokół encji koryguje wynik. „Mój numer PESEL to 571-44-9283” go podnosi. „Kod produktu 571-44-9283” go obniża.
Reguły zespołowe. Systemy łączą sygnały regex, modelu i kontekstu z ustalonymi wagami. Końcowa liczba odzwierciedla wszystkie dowody.
Ta liczba kieruje każdą decyzją progową w Twoim przepływie pracy. Więcej o fałszywych alertach z narzędzi tak/nie w artykule: Podatek na fałszywe alarmy w narzędziach PII.
Roszczenia ubezpieczeniowe: rzeczywisty przykład
Pliki ubezpieczeniowe zawierają czytelne PII — imię i nazwisko ubezpieczonego, adres, SSN — oraz dane zależne od kontekstu: nazwiska świadków, nazwy firm, podpisy likwidatorów.
Narzędzie tak/nie albo redaguje wszystkie nazwiska (błąd w przypadku firm) albo pomija nazwiska świadków (ryzyko). Narzędzie z oceną traktuje każdy element indywidualnie:
- SSN z etykietą „SSN ubezpieczonego” przy 96% — automatycznie zredagowany
- Imię i nazwisko ubezpieczonego oznaczone jako PERSON przy 91% — automatycznie zredagowane
- Firma wykonawcza oznaczona jako ORG przy 78% — zweryfikowana — weryfikator odrzuca redakcję
- Imię świadka oznaczone jako PERSON przy 82% — zweryfikowane — weryfikator akceptuje
- Imię likwidatora oznaczone jako PERSON przy 71% — zweryfikowane — weryfikator akceptuje (dane stron trzecich)
Każda decyzja ma podstawę liczbową. Ścieżka audytu jest kompletna.
Budowanie dokumentacji zgodności
Dla Art. 5(1)(f) RODO i Reguły Bezpieczeństwa HIPAA, narzędzia z oceną automatycznie generują dokumentację.
Dokumentacja audytowa na poziomie encji rejestruje typ encji, ocenę, typ decyzji (automatyczna lub ręczna), ID weryfikatora i czas. Eksport w formacie CSV dla zapytań organów ochrony danych.
Dokumentacja progów rejestruje bieżące ustawienia i każdą zmianę. Każda zmiana obejmuje osobę, czas i uzasadnienie. Pokazuje zarządzaną i przemyślaną politykę.
Raporty statystyczne obejmują wskaźniki detekcji według typów encji, wskaźniki weryfikacji w Warstwie 2 i wskaźniki nadpisań. Odpowiadają na pytanie organu ochrony danych: „Pokażcie nam swoje środki kontroli”.
Wytyczne dotyczące ścieżki audytu HIPAA znajdziesz w artykule: Wyjaśnialna redakcja: audyty HIPAA.
Flaga tak/nie to domysł. Ocena to dowód.