PII-маскирование

Шлюз может автоматически вырезать персональные данные (ПДн) из запросов к моделям и восстанавливать оригиналы в ответах. Шлюз заменяет распознанные персональные данные условными метками перед отправкой провайдеру; распознаются не все данные — см. раздел «Ограничения». Ваш клиент получает полный ответ.

Сколько это стоит

Маскирование — платная функция: пока оно включено на ключе, стоимость каждого запроса по этому ключу увеличивается на 15 %. Наценка начисляется за включённую функцию. Детектор отрабатывает при каждом запросе независимо от того, сколько значений он нашёл; цена, зависящая от содержимого запроса, была бы непредсказуемой.

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

Режимы

Режим задаётся в настройках API-ключа в кабинете:

Любой запрос может переопределить режим ключа полем pii (апстриму оно не пробрасывается):

curl https://nikagateway.ru/v1/chat/completions \
  -H "Authorization: Bearer sk-tunnel-..." \
  -H "Content-Type: application/json" \
  -d '{
    "model": "deepseek/deepseek-v4-pro",
    "pii": {"mode": "redact_restore"},
    "messages": [
      {"role": "user", "content": "Ответь на письмо от ivan.petrov@example.com, тел. +7 903 123-45-67"}
    ]
  }'

Что распознаётся

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

Одиночное имя по умолчанию не маскируется. Персональные данные — это сведения, по которым человека можно определить: фамилия с именем и отчеством определяют, одно имя — нет. «Мария» в запросе не указывает ни на кого конкретного, а маскирование таких слов заметно портит смысл запроса, который увидит модель. Кому нужно иначе — настройка lone_names на ключе.

ФИО распознаётся тремя способами: тройка с отчеством («Иванов Иван Иванович»), фамилия с инициалами («Иванов И. И.») и пара имя-фамилия по словарю русских имён («менеджер Пётр Иванов»). Пара без фамильного суффикса берётся, только если рядом стоит слово о человеке — поэтому «Иван Грозный» в вопросе про историю остаётся открытым, а «клиент Иван Ким» маскируется.

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

Телефоны. Номер с «+» или с разделителями распознаётся сам по себе, в том числе иностранный. Одиннадцать цифр слитно («79161234567») — только рядом со словом о телефоне: в SQL и в логах ровно так же выглядит идентификатор, и без этого условия маскирование портило бы чужие первичные ключи.

Что НЕ маскируется по умолчанию. ИНН из 10 цифр и ОГРН из 13 — это реквизиты организации: персональными данными они не являются, публичны в ЕГРЮЛ, и их сокрытие ломает задачи вида «найди контрагента по ИНН». Включается настройкой ключа org_ids.

Что заведомо не ловится: одиночное имя без фамилии и отчества, ПДн внутри изображений, аудио и PDF, данные в двоичных полях запроса.

Настройки ключа

Правила задаются полем pii_rules API-ключа:

Из личного кабинета настраивается режим маскирования; правила — по запросу в поддержку.

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

1. Перед отправкой провайдеру каждое найденное значение заменяется детерминированным плейсхолдером вида [PII_EMAIL_1], [PII_PHONE_2]. Нумерация сквозная в рамках запроса, одинаковые значения получают один плейсхолдер:

   Ответь на письмо от [PII_EMAIL_1], тел. [PII_PHONE_1]

2. Маскируется всё тело запроса, а не отдельные поля: messages и system, описания инструментов, metadata, stop, input эмбеддингов, prompt генерации изображений. Не трогаются технические поля (model, role, type) и двоичное содержимое — изображения в base64 и ссылки на файлы. Поля-идентификаторы (name, user) маскируются плейсхолдером без скобок: провайдер требует от них формат [A-Za-z0-9_-].

3. Маппинг «плейсхолдер → оригинал» хранится в памяти запроса и в Redis (TTL 24 часа). В логи и журнал генераций он не записывается.

4. В режиме redact_restore плейсхолдеры в ответе (включая стриминг) заменяются на оригиналы перед отправкой клиенту.

Ответ в режиме redact_restore не отличается от обычного — модель работала с плейсхолдерами, а вы видите реальные данные.

Ограничения

• Маскирование работает с текстом. Персональные данные внутри изображений, аудиозаписей и PDF-файлов остаются как есть: их содержимое шлюз не разбирает.
• Одиночное имя или фамилия без остальных частей ФИО распознаются, только если полное ФИО уже встретилось в этом же запросе или задано словарём.
• Маппинг живёт 24 часа: восстановить ответ после этого срока нельзя.
• Распознавание добавляет к обработке запроса примерно 2 мс на килобайт текста: 8 КБ — около 20 мс, 128 КБ — около 250 мс. На фоне ответа модели это незаметно, но на очень больших контекстах задержка есть.

Что не проверяется совсем

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

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

Обучение провайдеров на ваших запросах

Часть провайдеров по умолчанию использует API-запросы для обучения своих моделей. Маскирование этого не отменяет: оно уменьшает объём переданных персональных данных, а условия провайдера по обучению действуют независимо.

• Deepgram — обучается по умолчанию, отказ работает только пер-запросно. Шлюз ставит отказ автоматически на каждом запросе, вам ничего делать не нужно. Если участие нужно осознанно, передайте mip_opt_out=false.
• OpenAI и Anthropic — на данных API не обучаются по договору.
• Google — не обучается на платном тарифе Cloud API; на бесплатном тарифе Gemini API обучается, доступ к данным для проверки открыт людям-рецензентам.
• fal — не обучается, кроме моделей со статусом Pending Enterprise Ready — на них запрет не действует.
• xAI — сведения не собраны.
• DeepSeek — политика прямо допускает использование входов и выходов API для обучения моделей, отказа нет.
• Moonshot AI (Kimi) — использование запросов для обучения прямо предусмотрено, механизма отказа нет.
• Z.AI (GLM), Alibaba (Qwen), Xiaomi (MiMo) — сведения не собраны.

Если использование запросов для обучения провайдером критично для вас, не используйте модели DeepSeek и Moonshot (Kimi) для чувствительных данных: маскирование уменьшает объём переданного, но не отменяет условий провайдера.

Чего маскирование НЕ гарантирует

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

Как мы это измеряем: в репозитории лежит корпус из 62 текстов — тикеты поддержки, выгрузки CRM, анкеты, логи, код, SQL, JSON и YAML. Для каждого записано, что обязано быть замаскировано и что трогать нельзя. На этом корпусе полнота и точность — 100 %, и тест не даёт им упасть при изменениях. Корпус — не весь мир: незнакомая форма записи или редкое имя в него не входят.

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

Функция платная: +15 % к стоимости запросов по ключу, пока маскирование включено (см. «Сколько это стоит» выше). Биллинг считается по фактическому usage от провайдера, наценка начисляется отдельной строкой.

Когда использовать

• Передаёте в промптах данные клиентов (тикеты, CRM-тексты, переписку);
• нужно уменьшить объём персональных данных, передаваемых поставщикам моделей;
• хотите исключить утечку ПДн в логи провайдера.

Тела запросов и ответов не сохраняются на уровне платформы независимо от режима маскирования — в журнале остаются только метаданные.