Витоки PHI відбуваються у ваших логах, а не в базі даних

Запитайте healthcare-інженерну команду, як вони захищають медичну інформацію пацієнтів, і ви отримаєте впевнену відповідь про шифрування в спокої, шифрування в транзиті, RBAC у базі даних та журнал аудиту на кожен запит. Все це правильно, і все це захищає місце, звідки PHI майже ніколи насправді не витікає.

Витоки трапляються в оточуючій інфраструктурі. Логи. Сервіс звітування про помилки. Аналітичні події. Дебаг-експорти продукту. AI-промпти. Slack-канал, куди інженери вставляють фрагменти даних, щоб попросити одне одного про допомогу.

Саме тут потрапляються виробничі команди. Не в базі даних — вона добре захищена. На швах.

П'ять місць, де ми продовжуємо знаходити PHI там, де його не повинно бути

Роками ті самі п'ять категорій з'являються майже в кожному healthcare-аудиті.

Логи застосунку. Рядок логу на кшталт Updated patient 12345: { name: "...", dob: "..." } нешкідливий під час розробки і є подією розкриття HIPAA у виробництві. Логи надсилаються до централізованих агрегаторів із ширшим доступом, ніж база даних. Логи архівуються. Логи запитуються інженерами, у яких немає клінічних підстав бачити дані. Кожне "дай мені просто залогую, щоб налагодити" — це майбутній інцидент.

Сервіси звітування про помилки. Sentry, Rollbar та подібні інструменти захоплюють стек-трейси разом із локальними змінними, що були активні під час падіння. Якщо функція обробляла запис пацієнта, коли кинула виключення — запис тепер в інструменті помилок. Інструмент помилок розміщений, індексований і доступний усій інженерній команді. Жодна з цих властивостей не підходить для PHI.

Аналітичні події. Менеджер продукту з добрими намірами хоче знати, які функції використовуються. Реалізація захоплює user-id і назву події — це нормально — плюс контекстний блоб — що зазвичай не нормально. "Patient_search_performed" із рядком пошуку як властивістю каже вам, що зробив користувач, і водночас витікає ім'я пацієнта вашому аналітичному постачальнику.

Дебаг-експорти та скриншоти. Коли щось іде не так, інженери та співробітники підтримки вивантажують дані для розслідування. Вивантаження, як правило, — JSON-блоб, CSV або скриншот. Він прикріплюється до тікета в Jira, скидається в чат або зберігається на робочому столі. Жодне з цих місць не має контролів доступу виробничої бази даних.

AI-промпти та трейси. Нова категорія, яка застає команди зненацька в 2026 році. Копілот або RAG-система надсилає промпти до зовнішньої моделі, і промпти містять контекст пацієнта. Провайдер моделі логує промпти. Навіть за наявності BAA поверхня "скрізь, де побували наші промпти" ширша, ніж більшість команд усвідомлює, а трейси для налагодження часто живуть в інструментах, що не були закуплені з урахуванням PHI.

Що реально робити

Виправлення — не "будьте обережнішими." "Будьте обережнішими" — це те, що думала кожна команда прямо перед інцидентом. Три речі, що реально працюють:

Редагуйте на джерелі. Побудуйте єдину утиліту, що перетворює об'єкт пацієнта на придатне для логування представлення — з PHI, заміненим стабільними хешованими ідентифікаторами — і зробіть її єдиним санкціонованим способом логувати пацієнта. Ускладніть використання сирого представлення. Перевіряйте в code review рядки логування, що включають доменні об'єкти. Мета — зробити так, щоб випадкове розкриття вимагало зусиль.

Фільтруйте на кордоні. Який би інструмент не агрегував ваші логи, помилки, аналітику, AI-трейси — поставте перед ним фільтр, що очищає відомі PHI-патерни: дати народження, імена з таблиці пацієнтів, MRN. Фільтр щось пропустить. Але поверхню він все одно зменшить суттєво.

Ставтеся до AI-поверхні як до предмету аудиту. Кожен промпт, який ваша система надсилає LLM — це потенційний PHI в транзиті до третьої сторони. Інвентаризуйте промпти. Де можна — укладайте BAA; де не можна — маршрутизуйте до self-hosted моделей. Логуйте промпти до HIPAA-придатного сховища, а не до загального інструменту спостережуваності. Ставтеся до трейс-даних як до даних пацієнта — бо це вони і є.

Складніша культурна частина

Найскладніша частина не технічна. Вона в тому, щоб команда почувалася комфортно, повідомляючи про майже-інциденти без страху звинувачення. Інженер, що помічає "зачекайте, чи наш останній деплой почав логувати імена пацієнтів?" — має мати можливість підняти це без наслідків, крім виправлення. Команди, що карають за розкриття, отримують менше повідомлень про них — а не менше самих розкриттів.

Програма відповідності — це підлога. Культура — це те, що визначає, чи вона тримається.