В этом материале
DLP в gateway строится вокруг конкретных данных и границ передачи. Проверяйте не только совпадение фильтра, но и фактический исходящий запрос, журналы и поведение при недоступной проверке.
DLP для AI gateway помогает контролировать передачу определённых данных в запросах к моделям. Полезная настройка начинается с ответа, какие сведения нельзя передавать и на какой границе их нужно остановить или изменить. Универсальной кнопки, которая распознаёт все секреты и исправляет любую цепочку приложения, нет.
Ниже описан технический пилот с искусственными примерами по официальной документации, проверенной 1 ноября 2026 года. Правила обработки реальных данных определяет их ответственный владелец.
Составьте карту исходящих полей
Модельный запрос содержит не только видимый текст пользователя. Там могут быть системная инструкция, история, результаты поиска, аргументы инструментов и вложения. Для каждого участка определите, какая проверка его видит и до какого внешнего сервиса она выполняется.
LiteLLM Guardrails Quick Start описывает этапы проверки вокруг вызова. Для предотвращения передачи входа нужен соответствующий pre-call контроль. Анализ журнала после запроса может помочь обнаружению, но не отменяет уже состоявшуюся отправку.
Начните с узкого класса данных
Выберите искусственный формат тестового секрета или внутреннего идентификатора. Опишите ожидаемое действие: блокировка, замена маркером либо разрешённое прохождение. В LiteLLM Content Filter предусмотрены шаблоны и действия, которые нужно сверять для выбранного режима.
Не оценивайте качество по одному успешному совпадению. Строка может быть разбита между полями, находиться во вложении или выглядеть как обычный номер. Требуется набор положительных и отрицательных примеров, соответствующий вашему приложению.
Сравните действия фильтра
| Режим | Полезный результат | Что остаётся проверить |
|---|---|---|
| Блокировка | Нежелательный запрос не выполняется по правилу | Понятный отказ и отсутствие лишних повторов |
| Маскирование | Внешний вход содержит заменённые поля | Сохранена ли полезность задачи |
| Наблюдение | Есть событие для анализа | Данные могли уже уйти наружу |
Условная система заменяет внутренний номер договора перед суммаризацией. Если итоговый текст после замены стал неоднозначным, это отдельная прикладная проблема. Техническое маскирование и полезность ответа проверяются вместе, но считаются разными свойствами.
Посмотрите фактический исходящий запрос
В изолированном тесте подтвердите, что нужное поле действительно изменилось до передачи. Для этого используйте синтетические данные и контролируемый приёмник либо предусмотренную диагностику. Не включайте запись всех рабочих запросов ради проверки, которая сама создаёт копии закрытого содержимого.
Отдельно проверьте свои журналы, трассировки и систему ошибок. Gateway может изменить внешний вход, а backend по-прежнему сохранять исходный текст в общую аналитику. Такая цепочка требует собственного решения, даже если модельный маршрут настроен правильно.
Испытайте отказ проверки
Определите поведение при тайм-ауте фильтра, неизвестном формате файла и превышении допустимого размера. Контроль не должен незаметно отключаться только потому, что его компонент оказался недоступен. Для каждого сценария сохраните ожидаемое действие и результат пилота.
Дальше полезны границы guardrails и политики данных роутеров. Требования к обработке данных обсуждаются вместе с назначением нагрузки и условиями эксплуатации конкретного узла.