# Guardrails LiteLLM: где проверять запрос и ответ модели

Guardrails LiteLLM: pre-call, post-call, проверка потока и logging-only, поведение фильтра при сбое, тестовые примеры и влияние на задержку AI gateway.

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

Guardrails в LiteLLM — механизмы проверки запросов и ответов вокруг модельного вызова. Чтобы понять их пользу, сначала определите, на каком этапе нужна проверка: до передачи данных, после генерации, во время потока или только для наблюдения.

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

## Выберите нужную границу

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

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

Конкретные имена режимов и возможности сверяйте для выбранной интеграции. Не копируйте настройку другой системы, предполагая совпадение всех событий жизненного цикла.

## Опишите одну проверяемую политику

Начните с узкого правила: например, обнаружить искусственный тестовый секрет перед внешним вызовом. Запишите ожидаемое действие — отклонить, замаскировать или только отметить событие. Без этого невозможно оценить, прошёл ли тест успешно.

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

## Проверьте обычный вход и ложное совпадение

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

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

## Назначьте поведение при сбое

Если внешний фильтр недоступен, система должна действовать по заранее выбранному правилу. Разрешать ли продолжение, отклонять ли задачу или переводить её в очередь — зависит от назначения проверки. Важно испытать это поведение, а не узнавать его в рабочем инциденте.

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

## Измерьте влияние на сервис

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

Далее пригодятся [DLP для AI gateway](/ru/journal/ai-gateway-dlp/) и [ошибки внутри потока](/ru/journal/openrouter-stream-errors/). Границы данных и ответственность за проверки определяются для конкретного пилота вместе с конфигурацией инфраструктуры.