PII-Guard научился находить персональные данные в русском тексте

В open source появился PII-Guard — детектор персональных данных для русского текста, который умеет находить не только номера документов, но и имена, адреса и телефоны. Автор решения собрал гибридную схему: правила проверяют форматы и контрольные суммы, а модель отвечает за смысл и контекст.

Проект важен для компаний, которые гоняют рабочие тексты через языковые модели и не хотят отдавать наружу лишние данные. Речь не только о явных строках вроде номера карты или СНИЛС, но и о привычных фрагментах переписки, где имя клиента или адрес легко ускользают от обычных шаблонов.

Что произошло

Андрей Иванов из R&D-лаборатории red_mad_robot показал открытую систему для поиска персональных данных в русском тексте. В основе — попытка решить старую проблему: обезличить текст перед отправкой в модель, а потом вернуть скрытые данные на место без потери смысла.

Именно это меняет задачу. Раньше компании искали в тексте только то, что можно закрыть маской. Теперь им нужно не просто спрятать данные, а ещё и точно восстановить их в ответах модели, если она работала уже с обезличенной версией текста.

Как это работает

Сначала команда пошла по самому очевидному пути — через регулярные выражения. Для телефонов, ИНН, номеров карт и части других сущностей такой подход действительно срабатывает быстро: у данных есть длина, структура и понятные разделители.

Но на живом тексте всё быстро усложняется. Номера пишут через пробелы, дефисы и скобки, добавляют лишние символы, а один и тот же набор цифр может означать и карту, и номер заказа, и просто случайную последовательность. Тогда в ход пошли контрольные суммы: алгоритм Луна для карт и ОМС, проверки для ИНН и СНИЛС, а также анализ префиксов и диапазонов для БИК и почтовых индексов.

Одних формул всё равно не хватило. Если рядом с числом стоит слово «паспорт» или «ИНН», это помогает, но не спасает от ложных срабатываний: рядом с номером отправления может встретиться тот же «паспорт», а лишнее окно контекста только шумит. Поэтому PII-Guard смотрит на близость подсказки к кандидату, учитывает приоритет типов и сверяет конфликтующие находки между собой.

Дальше в игру вошла модель на основе ruBert-base. Она закрыла то, что правилам не по силам: имена, адреса и другие сущности, где форма записи почти ничего не говорит без смысла фразы. Внутри системы две ветки идут параллельно, а потом арбитр выбирает, чьей находке доверять в спорных случаях.

Кого это затрагивает и зачем это нужно

В первую очередь решение полезно тем, кто работает с клиентскими данными, внутренними документами и перепиской сотрудников. Если компания хочет чистить тексты перед отправкой в модели, ей нужен инструмент, который не только маскирует данные, но и не ломает рабочий сценарий.

Это касается и бытовых сценариев. В запросах к поиску люди часто спрашивают, что делать если не работает дискорд на пк, почему не работает мобильный интернет что делать, или как войти в аккаунт с телефона без пароля и логина сразу моя страница войти — а заодно нередко вставляют в такие сообщения личные данные. Для сервисов поддержки и аналитики это прямой риск: лог может оказаться слишком подробным.

Отдельный плюс проекта — открытый код и датасеты для теста и обучения. Это позволяет сравнивать решение с другими подходами и проверять, где правила действительно выигрывают у модели, а где модель лучше ловит контекст.

Что делать сейчас

Если вы работаете с текстами клиентов, чатов или обращений, стоит проверить, умеет ли ваша система искать не только шаблонные номера, но и имена, адреса, должности и другие сущности по смыслу. Для русского языка это особенно важно: простые регулярки закрывают лишь часть картины.

Если сотрудники отправляют рабочие тексты в внешние сервисы или обсуждают личные данные в открытых сетях, полезно заранее уменьшить следы в трафике и в журналах. Для командировок и поездок за границу можно рассмотреть инструмент для приватной связи в поездке как один из слоёв защиты, но он не заменяет обезличивание текста и дисциплину обращения с данными.

Полезно также пересмотреть внутренние правила: кто и где хранит сырые логи, как долго они лежат, что из них уходит в аналитику и что попадает в ИИ-инструменты. Чем раньше убрать лишнее из потока, тем меньше шансов, что оно всплывёт в самом неудобном месте.

Практический чек-лист

• Проверьте, ищет ли ваша система не только номера документов, но и имена, адреса и телефоны по смыслу текста.
• Добавьте проверку контрольных сумм и форматов для карт, ИНН, СНИЛС, ОМС и других числовых сущностей.
• Сверьте, не утекают ли сырые логи и обращения в сторонние ИИ-сервисы без обезличивания.
• Уберите из текстов и журналов лишние персональные данные до отправки в модель.
• Настройте правила разрешения конфликтов между детектором по шаблонам и моделью по контексту.
• Пересмотрите сроки хранения логов и доступ к ним внутри компании.
• Если сотрудники работают из поездок, заранее продумайте защиту связи и рабочих данных.