Wycieki PHI zdarzają się w Twoich logach, nie w bazie danych

Zapytaj zespół inżynierski w ochronie zdrowia, jak chronią informacje zdrowotne pacjentów, a uzyskasz pewną odpowiedź o szyfrowaniu w spoczynku, szyfrowaniu w tranzycie, RBAC na bazie danych i logu audytowym na każdym zapytaniu. To wszystko jest poprawne i wszystko to chroni miejsce, skąd PHI prawie nigdy faktycznie nie wycieka.

Wycieki zdarzają się w otaczającej infrastrukturze. W logach. W serwisie raportowania błędów. W zdarzeniach analitycznych. W eksportach debugowania produktu. W promptach AI. Na kanale Slack, gdzie inżynierowie wklejają fragmenty danych, żeby sobie nawzajem pomóc.

To właśnie tutaj wpadają produkcyjne zespoły. Nie przy bazie danych — baza danych jest dobrze broniona. Przy szwach.

Pięć miejsc, gdzie stale znajdujemy PHI, których tam nie powinno być

Przez lata te same pięć kategorii pojawia się niemal w każdym audycie medycznym.

Logi aplikacji. Linia logu jak Updated patient 12345: { name: "...", dob: "..." } jest niegroźna w trakcie developmentu i jest zdarzeniem ujawnienia HIPAA w produkcji. Logi są wysyłane do scentralizowanych agregatorów z szerszym dostępem niż baza danych. Logi są archiwizowane. Logi są odpytywane przez inżynierów, którzy nie mają klinicznego powodu, żeby widzieć dane. Każde „zalogujmy to tylko, żebym mógł zdebugować" to przyszły incydent.

Serwisy raportowania błędów. Sentry, Rollbar i podobne narzędzia przechwytują stack trace z lokalnymi zmiennymi, które były aktywne w momencie crasha. Jeśli funkcja przetwarzała rekord pacjenta, gdy rzuciła wyjątek, rekord jest teraz w narzędziu do błędów. Narzędzie do błędów jest hostowane, indeksowane i współdzielone z całym zespołem inżynierskim. Żadna z tych właściwości nie jest odpowiednia dla PHI.

Zdarzenia analityczne. Dobrze nastawiony product manager chce wiedzieć, które funkcje są używane. Implementacja przechwytuje user-id i event-name, co jest w porządku, plus blob kontekstu, który zazwyczaj nie jest. „Patient_search_performed" z ciągiem wyszukiwania jako właściwością mówi Ci, co zrobił użytkownik — i jednocześnie ujawnia nazwisko pacjenta Twojemu dostawcy analityk.

Eksporty debugowania i zrzuty ekranu. Gdy coś idzie nie tak, inżynierowie i pracownicy wsparcia eksportują dane do zbadania. Eksport zazwyczaj to blob JSON, CSV lub zrzut ekranu. Eksport trafia do ticketu Jira, jest wrzucany na chat lub zapisywany na pulpicie. Żadne z tych miejsc nie ma kontroli dostępu, jaką ma produkcyjna baza danych.

Prompty AI i ślady. Nowa kategoria i ta, która zaskakuje zespoły w 2026 roku. Copilot lub system RAG wysyła prompty do zewnętrznego modelu, a prompty zawierają kontekst pacjenta. Dostawca modelu loguje prompty. Nawet z BAA na miejscu, powierzchnia „wszędzie, gdzie były nasze prompty" jest szersza, niż większość zespołów zdaje sobie sprawę, a ślady przechowywane do debugowania często żyją w narzędziach, które nie były zakupione z myślą o PHI.

Co faktycznie zrobić

Naprawa to nie „bądź bardziej ostrożny." Bądź bardziej ostrożny to to, o czym każdy zespół myślał, że był — tuż przed incydentem. Trzy rzeczy, które faktycznie działają:

Redakcja u źródła. Zbuduj jeden utility, który konwertuje obiekt pacjenta do reprezentacji nadającej się do logowania — z PHI zastąpionym przez stabilne zahaszowane identyfikatory — i uczyń go jedynym usankcjonowanym sposobem logowania pacjenta. Spraw, żeby surowa reprezentacja była trudna w użyciu. Przeglądaj kod pod kątem instrukcji logowania zawierających obiekty domeny. Celem jest sprawienie, żeby przypadkowe ujawnienie wymagało wysiłku.

Filtrowanie na granicy. Cokolwiek agreguje Twoje logi, błędy, analitykę, ślady AI — postaw przed tym filtr, który oczyszcza znane wzorce PHI: daty urodzenia, imiona pasujące do Twojej tabeli pacjentów, numery MRN. Filtr będzie przegapiał rzeczy. Nadal znacznie zmniejszy powierzchnię.

Traktuj powierzchnię AI jako w zakresie. Każdy prompt, który Twój system wysyła do LLM, to potencjalnie PHI w tranzycie do strony trzeciej. Zinwentaryzuj prompty. Negocjuj BAA tam, gdzie możesz; routuj do modeli self-hosted tam, gdzie nie możesz. Loguj prompty do magazynu kwalifikowanego dla HIPAA, nie do ogólnego narzędzia obserwowalności inżynierskiej. Traktuj dane śladu jako dane pacjentów — bo nimi są.

Trudniejsza część kulturowa

Najtrudniejszą częścią nie jest technika. To sprawienie, żeby zespół czuł się komfortowo z sygnalizowaniem prawie-incydentów bez obawy o winę. Inżynier, który zauważa „hej, czy nasze ostatnie wdrożenie zaczęło logować imiona pacjentów?" musi być w stanie to zgłosić bez konsekwencji innych niż naprawienie problemu. Zespoły, które karzą za ujawnienie, dostają mniej zgłoszonych ujawnień — nie mniej ujawnień zdarzających się.

Program compliance jest podłogą. Kultura decyduje o tym, czy podłoga wytrzyma.