Маскирование ПДн перед нейросетью: почему запрета в запросе недостаточно
Как находить и заменять ПДн до вызова иностранной нейросети, зачем нужна повторная проверка и почему инструкция модели не является границей безопасности.
- Category: privacy-ai
- Published: 2026-10-04T09:06:05.455854
- Canonical: https://gitsell.ru/blog/maskirovanie-pdn-pered-neirosetyu-pochemu-zapreta-v-zaprose
Article
Фраза «не отправляй персональные данные» в системной инструкции не защищает канал передачи. Инструкцию исполняет уже выбранная модель, а значит текст сначала должен попасть к её поставщику. Если в нём были телефон, паспорт или ФИО, передача произошла до того, как модель прочитала запрет.
Надёжная граница ставится раньше: между приложением и внешней нейросетью. На этой границе сервис должен определить чувствительные фрагменты, выбрать допустимое действие и только затем открыть соединение с поставщиком модели.
Из чего состоит детектор
Одного регулярного выражения недостаточно. Телефон и электронная почта хорошо находятся по формату, для СНИЛС, ИНН физлица и банковской карты полезна проверка контрольной суммы. Адрес требует контекста, а имя человека может выглядеть как обычные слова.
В gitsell.ru используются два слоя:
- точные правила для телефонов, электронной почты, адресов, паспорта, СНИЛС, ИНН физлица, карт, счетов, дат рождения и учётных данных;
- локальная модель распознавания именованных сущностей для ФИО. Организация сама по себе автоматически не считается ПДн, а географическое название не превращается в адрес без контекста.
Результат — не «документ безопасен», а набор найденных фрагментов с категориями и позициями в тексте.
Маска должна сохранять смысл
Значения заменяются стабильными метками внутри одного запроса:
Иван Петров → <PERSON_1>
+7 999 123-45-67 → <PHONE_1>
Модель по-прежнему понимает, что речь идёт о человеке и его телефоне, но не получает исходное значение. После ответа приложение может восстановить метки там, где это безопасно и действительно требуется. Таблица соответствий не должна попадать к модели или в журнал вызовов.
Зачем проверять второй раз
Замена одного фрагмента может оставить часть значения, если границы были определены неверно. В тексте встречаются дубли, нестандартные разделители и данные внутри JSON. Поэтому очищенный запрос нужно прогнать через детектор повторно. Если остаток всё ещё похож на ПДн, внешний вызов блокируется.
В контуре защиты персональных данных Gitsell действует принцип безопасного отказа: недоступность детектора или локальной модели распознавания имён не разрешает запрос «по умолчанию».
Где маскирование неприменимо
В потоковом ответе трудно безопасно восстановить метку, разрезанную между частями сообщения. При векторизации исходное значение превращается в набор чисел, а при генерации изображения — в изображение; обратная подстановка уже не определена. Поэтому при найденных ПДн такие операции разумнее отклонить или направить в заранее выбранный российский контур, а не имитировать универсальную очистку.
Автоматический детектор уменьшает риск, но не доказывает отсутствие всех персональных данных в произвольном тексте. Его нужно сочетать с минимизацией контекста, ограничением прав агента и организационными мерами, предусмотренными 152-ФЗ.
Статьи по теме
- ИИ-агенты и персональные данные в России: карта рисков перед запуском: Практическая карта рисков при запуске ИИ-агента в российской компании: цели обработки, контекст 1С, внешние модели, документы, журналы и контроль действий.
- 1C AI Autofill: описания и реквизиты товаров без ручной рутины: Как 1C AI Autofill генерирует описания номенклатуры и заполняет характеристики в УНФ, Рознице, УТ, КА и ERP через ИИ-прокси.
- ИИ-прокси Gitsell: первый запрос через OpenAI SDK и curl: Первое подключение к ИИ-прокси Gitsell: единый OpenAI-совместимый endpoint, API-ключ, список моделей, curl и Python SDK.