# DLP для AI gateway: как уменьшить утечки через запросы к LLM

DLP для AI gateway: какие поля проверять до отправки модели, как тестировать маскирование, обрабатывать вложения и логи, отличать наблюдение от блокирующего контроля.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/ai-gateway-dlp/
Language: ru

DLP для AI gateway помогает контролировать передачу определённых данных в запросах к моделям. Полезная настройка начинается с ответа, какие сведения нельзя передавать и на какой границе их нужно остановить или изменить. Универсальной кнопки, которая распознаёт все секреты и исправляет любую цепочку приложения, нет.

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

## Составьте карту исходящих полей

Модельный запрос содержит не только видимый текст пользователя. Там могут быть системная инструкция, история, результаты поиска, аргументы инструментов и вложения. Для каждого участка определите, какая проверка его видит и до какого внешнего сервиса она выполняется.

[LiteLLM Guardrails Quick Start](https://docs.litellm.ai/docs/proxy/guardrails/quick_start) описывает этапы проверки вокруг вызова. Для предотвращения передачи входа нужен соответствующий pre-call контроль. Анализ журнала после запроса может помочь обнаружению, но не отменяет уже состоявшуюся отправку.

## Начните с узкого класса данных

Выберите искусственный формат тестового секрета или внутреннего идентификатора. Опишите ожидаемое действие: блокировка, замена маркером либо разрешённое прохождение. В [LiteLLM Content Filter](https://docs.litellm.ai/docs/proxy/guardrails/litellm_content_filter) предусмотрены шаблоны и действия, которые нужно сверять для выбранного режима.

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

## Сравните действия фильтра

| Режим | Полезный результат | Что остаётся проверить |
| --- | --- | --- |
| Блокировка | Нежелательный запрос не выполняется по правилу | Понятный отказ и отсутствие лишних повторов |
| Маскирование | Внешний вход содержит заменённые поля | Сохранена ли полезность задачи |
| Наблюдение | Есть событие для анализа | Данные могли уже уйти наружу |

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

## Посмотрите фактический исходящий запрос

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

Отдельно проверьте свои журналы, трассировки и систему ошибок. Gateway может изменить внешний вход, а backend по-прежнему сохранять исходный текст в общую аналитику. Такая цепочка требует собственного решения, даже если модельный маршрут настроен правильно.

## Испытайте отказ проверки

Определите поведение при тайм-ауте фильтра, неизвестном формате файла и превышении допустимого размера. Контроль не должен незаметно отключаться только потому, что его компонент оказался недоступен. Для каждого сценария сохраните ожидаемое действие и результат пилота.

Дальше полезны [границы guardrails](/ru/journal/litellm-guardrails-boundary/) и [политики данных роутеров](/ru/journal/router-data-policy-comparison/). Требования к обработке данных обсуждаются вместе с назначением нагрузки и условиями эксплуатации конкретного узла.