Персональные данные при работе с ИИ

26 октября 2026 · 11 минут чтения

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

Приложение отправляет большой языковой модели (LLM) переписку, чтобы та подготовила ответ клиенту. Удалить из последнего сообщения имя и телефон недостаточно: они могут остаться в истории, приложенном договоре или результате поиска. А после удаления всех имён модель может перепутать, кто кому обещал вернуть деньги.

Гайд для разработчика собственного приложения, который управляет отправкой через интерфейс программирования приложений (API). Для готового веб-чата ниже есть отдельная инструкция.

Цены, условия сделок и пароли могут требовать защиты и после удаления ФИО; для них нужны отдельные правила допуска к отправке. Примеры вымышлены.

Сначала убрать то, что модели не нужно

Для черновика ответа о переносе доставки обычно нужны причина обращения и доступные даты. Телефон, адрес и номер заказа можно вообще не извлекать из системы работы с клиентами.

Локальная запись:
Иван Примеров, ivan@example.test, заказ 73142.
Клиент просит перенести доставку. Доступны вторник и четверг.

Запрос модели:
Напиши короткий ответ: доставку можно перенести
на вторник или четверг. Попроси выбрать день.

Обращение по имени приложение добавит к готовому ответу локально. Здесь не нужны ни детектор имён, ни таблица замен. Чем меньше исходных сведений попадает в текст, тем меньше приходится искать и скрывать.

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

Где обрабатывать оригинал и проверять отправку

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

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

1. Локально выбрать нужные поля и подготовить текст. Если исходник — файл, извлечь нужные разделы либо проверить очистку всего файла.
2. Найти оставшиеся идентификаторы и заменить их. Если значения потребуется восстановить, хранить соответствия отдельно, с доступом только в пределах нужного обращения.
3. Проверить собранный запрос: инструкции, историю, вложения, аргументы и результаты инструментов. Разрешить отправку только через этот путь.
4. Получить ответ, проверить метки и восстановить значения локально. Неизвестную метку или метку другого обращения считать ошибкой; черновик ответа клиенту показать сотруднику.

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

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

Проверяйте передачу ещё до обращения к LLM. Если облачное распознавание речи уже получило запись встречи, очистка транскрипта не защищает эту передачу. Внешний сервис, который строит численные представления текста для поиска — embeddings, — тоже получает исходный текст; очистка нужна до вызова этого сервиса.

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

Сложный пример: сохранить, кто кому что обещал

Пусть из переписки нужно извлечь обязательства двух участников:

Исходный текст:
Иван Примеров написал Марии Образцовой: «Верну вам аванс в пятницу».
Позже И. Примеров попросил Марию прислать акт.

Неудачная замена:
PERSON написал PERSON: «Верну вам аванс в пятницу».
Позже PERSON попросил PERSON прислать акт.

Ожидаемая подготовка:
PERSON_1 написал PERSON_2: «Верну вам аванс в пятницу».
Позже PERSON_1 попросил PERSON_2 прислать акт.

При одинаковой метке для всех людей связь потеряна. При разных метках для «Иван Примеров» и «И. Примеров» один участник превратится в двух. Требуется не только найти имена, но и правильно связать упоминания.

Повтор одинаковой строки, приведение имени к начальной форме и связывание полного имени с инициалами — разные задачи. Например, образец замены в Presidio повторно использует метку для той же строки; связывание разных форм нужно реализовать отдельно. В первом пилоте соответствия проверяет человек. Автоматизировать этот шаг стоит после отдельного испытания на ваших текстах; неоднозначные инициалы оставляйте на ручную проверку.

Полезный ответ на подготовленный текст: «PERSON_1 обещал вернуть аванс PERSON_2 в пятницу; PERSON_2 попросили прислать акт». Проверять нужно обе части: оригинальные имена не ушли наружу, обязательства не перепутаны. Это ожидаемое поведение учебного примера, а не результат испытания конкретной модели.

Есть и другая ошибка. В предложении «PERSON_1 — единственный детский кардиолог в посёлке N» человек может остаться узнаваемым без имени. Если должность и место не нужны для задачи, их следует убрать или обобщить. Если без этих сведений задача теряет смысл, нужно пересмотреть место обработки.

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

В локальной пробе pii-mask 0.1.0, закреплённая версия результат был таким:

Вход:
Иван Петров: поручите Ивану Петрову отчёт.
Мария Соколова: ответила Марии Соколовой.

После замены:
{{PERSON_1}}: поручите {{PERSON_1}} отчёт.
{{PERSON_2}}: ответила {{PERSON_2}}.

После восстановления:
Иван Петров: поручите Иван Петров отчёт.
Мария Соколова: ответила Мария Соколова.

Падежные варианты этих двух имён получили общие метки, но окончания при восстановлении потерялись. Мы применили замену и обратную подстановку к тому же тексту, без вызова LLM. Эта проба не проверяла ни инициалы, ни восстановление свободного ответа модели.

Какие инструменты взять в пилот

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

Для собственного текстового приложения я бы сравнил pii-guard и Presidio с русской моделью и правилами под документы заказчика на одинаковых примерах. Первый интересен ориентацией на русский текст, второй — возможностью менять модель и правила. Если команда не готова поддерживать обработку файлов и правила, разумнее начать с пилота коммерческого контейнера на том же наборе.

До запуска зафиксируйте версию кода, модель, правила и настройки. Уточните требования к памяти и процессору или видеокарте для выбранной сборки. Проверьте отдельно лицензии кода и весов модели, возможность коммерческого использования и условия обновления. Иначе сравнение нельзя повторить, а выбранный компонент может не подойти по эксплуатации.

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

Как проверить пилот

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

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

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

Сначала проверяйте очистку и отправку на вымышленных данных. Затем на допущенных к передаче подготовленных примерах испытайте реальную модель: сможет ли она выполнить задачу и вернуть пригодные метки. Успех очистки ещё не означает пригодность всего помощника.

Локальные пробы исследования дают три полезных случая для проверки:

• В закреплённой версии docs_masked контрольные значения остались в колонтитуле, комментарии и авторе DOCX. Если наружу уходит файл, нужно проверять его целиком, включая метаданные и изображения.
• В одном обработчике LiteLLM значения сохранялись в аргументах инструментов и верхнеуровневых инструкциях. Детектор был заменён заглушкой: проверялся обход полей, не весь шлюз.
• У проверенной версии pii-mask сбой аудита отдельного фрагмента давал предупреждение вместо остановки. Предварительная проверка доступности аудитора не закрывает этот случай.

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

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

Какие требования РФ учесть

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

Локализация и трансграничная передача — разные проверки. База в России сама по себе не разрешает передачу иностранной модели; российский поставщик тоже требует проверки условий и субподрядчиков. Настройка «не использовать для обучения» не заменяет эти проверки. Текст 152-ФЗ.

Выберите один процесс, например подготовку ответа клиенту, и двух кандидатов. На размеченных примерах сравните фактически отправленные запросы и качество ответов. Это покажет, что нужно доработать перед запуском.

Термины

• LLM — большая языковая модель, обрабатывающая запрос и составляющая ответ.
• API — программный интерфейс обмена запросами между приложениями.
• Детектор — компонент, который ищет чувствительные фрагменты; он может пропускать данные или ошибочно отмечать обычный текст.
• Метка — заменяющее значение вроде PERSON_1; связь с оригиналом при необходимости хранится отдельно.
• Оператор персональных данных — лицо или организация, определяющие цели, состав и действия обработки.
• Обезличивание — по 152-ФЗ, преобразование, после которого без дополнительной информации нельзя определить принадлежность данных человеку.
• Embeddings — численные представления текста, например для поиска похожих фрагментов.

Источники

Технические источники и пробы — на 18 октября 2026 года, нормативная сверка — на 19 октября.

• 152-ФЗ, текст с изменениями, текст на сайте Минтруда: определения и обязанности оператора; для проекта нужна проверка применимых норм, включая специальные категории данных.
• Официальная публикация приказа № 140, текст приложений: требования к процедуре и методы обезличивания; нормативная сверка выполнена 19 октября.
• Постановление № 1154: область специального порядка.
• Документация инструментов и закреплённые версии кода приведены рядом с кандидатами и пробами. Короткий список отобран из исследования 26 решений; изучение документации, локальные пробы и испытание всей интеграции в таблице разделены. Коммерческие контейнеры не развёртывались, готовность продуктов к конкретному процессу не подтверждена.

Автор: Данил Письменный · Дата: 26 октября 2026