Как маскировать персональные данные перед отправкой в нейросеть и соблюдать 152-ФЗ

Кратко. Перед отправкой промпта в нейросеть чувствительные данные можно заменить безопасными заглушками, а после ответа — восстановить автоматически. API Guard от kosareva.cloud работает как шлюз между приложением и моделью: распознаёт данные в запросе, маскирует их и возвращает исходные значения в ответе. Это помогает снизить риск раскрытия персональных данных и встроить работу с нейросетями в контур мер по соблюдению 152-ФЗ, но само по себе не заменяет полноценную правовую и организационно-техническую оценку.

Что такое маскирование персональных данных

Маскирование персональных данных — это автоматическая замена реальных идентификаторов безопасными маркерами до передачи текста во внешнюю нейросеть. Например, petrov@acme.ru превращается в [[EMAIL_1]], а ИНН — в [[INN_1]]. Модель видит маркеры, а не настоящие значения; после генерации ответа шлюз подставляет исходные данные обратно.

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

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

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

Почему нельзя отправлять данные в нейросеть как есть

Промпт — это тоже передаваемый текст. Если в нём есть имя клиента, телефон, адрес электронной почты, ИНН или номер документа, эти сведения покидают ваш исходный контур и попадают к поставщику модели.

Риски зависят от конкретной архитектуры и условий сервиса:

1. запрос может попасть в технические логи;
2. текст может использоваться для диагностики инцидентов;
3. к данным могут получить доступ сотрудники или подрядчики провайдера;
4. передача может оказаться трансграничной;
5. чувствительные сведения могут случайно попасть в историю диалогов или аналитические системы.

Даже если нейросеть нужна только для подготовки ответа клиенту, ей редко требуется знать реальный email или ИНН. Для задачи «составь вежливое письмо» достаточно маркера [[EMAIL_1]] и контекста о типе обращения.

Как маскирование связано с 152-ФЗ

152-ФЗ относит к обработке любое действие с персональными данными, включая передачу, предоставление доступа и обезличивание. Оператор обязан принимать правовые, организационные и технические меры для защиты данных от неправомерного или случайного доступа, копирования, распространения и других неправомерных действий.

Поэтому маскирование перед обращением к нейросети — не «галочка о соответствии», а одна из технических мер снижения риска. Оно помогает:

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

Если модель находится за пределами России, нужно отдельно оценить трансграничную передачу. Статья 12 152-ФЗ предусматривает уведомление уполномоченного органа до начала такой деятельности и устанавливает требования к правовым основаниям, целям, категориям данных и иностранным государствам. Маскирование может помочь не передавать персональные данные в конкретном запросе, но оператору всё равно нужно проверить всю цепочку обработки и свои обязанности.

Важно: API Guard не делает компанию автоматически соответствующей 152-ФЗ. Для соответствия нужны также законные основания обработки, политика, регламенты доступа, оценка угроз, договоры с обработчиками, контроль хранения и другие меры, которые зависят от вашей информационной системы и бизнес-процесса.

Как работает API Guard

API Guard — шлюз между вашим кодом и моделью. Вы отправляете запрос на специальный OpenAI-совместимый адрес, а шлюз выполняет три операции:

1. Находит чувствительные значения. Сервис распознаёт email, телефоны, ИНН, СНИЛС, паспорта и номера банковских карт. Для форматов, которые можно проверить контрольной суммой или строгой структурой, выполняется дополнительная проверка, чтобы не принять номер заказа за ИНН.
2. Заменяет значения на заглушки. Один и тот же идентификатор получает одну и ту же заглушку в рамках запроса. Поэтому модель понимает, что [[EMAIL_1]] в разных местах — это один и тот же адрес.
3. Восстанавливает значения в ответе. Когда модель возвращает текст, шлюз разворачивает поставленные им заглушки обратно. В том числе поддерживается потоковая выдача: система удерживает незакрытую часть маркера до получения следующего фрагмента.

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

Что получает модель

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

Как подключить маскирование к API

Меняется только адрес API. Ключ, модель, лимиты и схема вызова остаются привычными для OpenAI-совместимого клиента.

Python

from openai import OpenAI

client = OpenAI(
    api_key="ВАШ_КЛЮЧ",
    base_url="https://api.kosareva.cloud/guard/v1",
)

response = client.chat.completions.create(
    model="gpt-4o",
    messages=[
        {
            "role": "user",
            "content": (
                "Составь ответ клиенту. "
                "Email: petrov@acme.ru. "
                "ИНН: 7707083893."
            ),
        }
    ],
)

print(response.choices[0].message.content)

В модель уйдёт текст с маркерами вроде [[EMAIL_1]] и [[INN_1]], а в результате приложение получит готовый ответ с исходными значениями.

cURL

curl https://api.kosareva.cloud/guard/v1/chat/completions \
  -H "Authorization: Bearer ВАШ_КЛЮЧ" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-4o",
    "messages": [
      {
        "role": "user",
        "content": "Подготовь письмо клиенту petrov@acme.ru"
      }
    ]
  }'

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

Как внедрить маскирование без нарушения бизнес-процесса

1. Опишите потоки данных

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

2. Определите категории, которые нельзя передавать

Минимальный список для проверки — email, телефон, ИНН, СНИЛС, паспортные данные, номера карт, адреса и сведения о клиентах. Для ФИО и нестандартных идентификаторов добавьте собственные правила очистки.

3. Подключите шлюз на границе приложения

Маскирование эффективнее ставить до формирования внешнего HTTP-запроса: тогда разработчик не должен помнить о ручной очистке каждого промпта. На этом же уровне удобно вести технический аудит: какой сервис отправил запрос, какие типы были заменены и какой маршрут использован.

4. Проверьте качество ответов

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

5. Зафиксируйте правила в документах

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

Что маскирование не решает

Маскирование не отменяет необходимость:

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

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

Частые вопросы

Можно ли с помощью маскирования соблюдать 152-ФЗ?

Маскирование помогает выполнить часть технических мер по снижению риска, но не гарантирует соответствие 152-ФЗ. Оператору также нужны законные основания, регламенты, контроль доступа, оценка угроз, правила хранения и проверка трансграничной передачи.

Какие данные API Guard заменяет автоматически?

API Guard распознаёт email, телефоны, ИНН, СНИЛС, паспортные данные и номера банковских карт. ФИО пока не распознаются автоматически, поэтому для них нужно отдельное правило обработки.

Увидит ли нейросеть настоящие значения?

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

Меняется ли код интеграции?

Обычно достаточно заменить базовый URL OpenAI-совместимого клиента на адрес API Guard. Формат запроса, ключ и вызов chat completions остаются привычными.

Заменяет ли API Guard DLP-систему?

Нет. API Guard защищает маршрут запросов к нейросети от передачи распознанных идентификаторов. DLP, управление доступами, классификация документов, аудит и другие корпоративные меры выполняют более широкий набор задач.

Итог

Перед отправкой данных в нейросеть безопаснее передавать не реальные идентификаторы, а устойчивые заглушки. Такой слой сохраняет полезность модели, уменьшает объём персональных данных во внешнем запросе и помогает встроить использование AI API в систему мер по защите данных.

API Guard от kosareva.cloud ставится между приложением и моделью, автоматически маскирует поддерживаемые типы данных и восстанавливает их в ответе. Для бизнеса это практичный способ начать контролируемую работу с нейросетями, а затем дополнить техническое решение юридическими, организационными и инфраструктурными мерами, необходимыми для применения 152-ФЗ.

Источники

• API Guard — обезличивание персональных данных перед отправкой в нейросеть
• 152-ФЗ, статья 3 — основные понятия
• 152-ФЗ, статья 19 — меры по обеспечению безопасности персональных данных
• 152-ФЗ, статья 12 — трансграничная передача персональных данных