Авторы проверяют на 8 примерах, что остаётся в тексте после маскировки перед LLM

Восемь искусственных текстов, один заранее заданный список «остатков» и два отключаемых узла пайплайна. Из этого собран разбор на Хабре о проверке маскировки персональных данных перед отправкой текста в LLM. Исходный тезис: убрать ФИО недостаточно. Если рядом остался номер, который находится в открытом реестре, человека всё равно можно установить.

Публикация пока доступна только в виде анонса. Ниже изложено то, что заявлено, и логика подхода. Конкретные результаты замеров из полного текста сюда не вынесены.

Маска закрыла имя, но не человека

Типичная схема выглядит так. Перед запросом к внешней модели текст проходит через маскировщик. Он заменяет ФИО, телефоны и адреса плейсхолдерами вроде [PERSON] или [PHONE]. После этого команда отмечает, что персональные данные удалены.

Но идентифицирует человека не только имя. Номер ИП, ИНН, номер судебного дела, госномер автомобиля, номер договора могут вести к конкретному лицу через открытые реестры и картотеки. Если маскировщик настроен на имена и телефоны, такие значения проходят дальше нетронутыми. Модель, лог запроса и сторонний провайдер получают данные, которые формально «обезличены», а фактически нет.

Авторы предлагают сменить вопрос. Они не спрашивают, что нашёл маскировщик, а проверяют, что осталось в тексте после его работы.

Как устроена проверка

Подход строится на малом, но воспроизводимом наборе. Параметры эксперимента, как они заявлены в анонсе:

• 8 синтетических примеров, реальных персональных данных в выборке нет;
• заранее заданный список остатков: значений, которых в выходном тексте быть не должно;
• сверка выхода маскировщика со списком, то есть проверка по факту, а не по отчёту детектора;
• эксперимент с отключением нормализации;
• эксперимент с отключением распознавания имён.

Два последних режима выбраны не случайно. Нормализация приводит текст к единому виду: убирает лишние пробелы и дефисы в номерах, выравнивает регистр, сводит разные записи одного значения к одной. Без неё правило или словарь могут пропустить номер, записанный чуть иначе, чем в шаблоне. Распознавание имён отвечает за ФИО, которых нет в словарях, а также за склонения и формы записи вроде «Иванову А. П.». Если отключить один из узлов, видно, какую часть защиты он обеспечивал. Сколько именно, покажут цифры из полного разбора.

Что ограничивает метод

Восемь примеров годятся как демонстрация и регрессионный тест, но не как бенчмарк. По такой выборке нельзя судить о полноте и точности маскировщика на реальном потоке. Синтетика обычно чище живых данных. В ней меньше опечаток, шума после OCR, обрывков расшифровок звонков и смешения языков. Заранее заданный список тоже ограничивает проверку: она найдёт только то, что в него внесли. Неожиданный идентификатор, о котором команда не подумала, останется незамеченным.

У подхода есть и сильная сторона. Он превращает расплывчатое «мы маскируем данные» в проверяемое утверждение с конкретным списком и конкретным результатом.

Как применить у себя

Чтобы перенести идею в свой проект, нужны пять шагов:

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

Маскировка остаётся инженерной мерой, а не юридическим заключением. Решение о том, достаточно ли её для требований закона о персональных данных, принимают отдельно. Но без проверки остатков даже корректно настроенный маскировщик остаётся непроверенной гипотезой.