Guardrails для AI-агентов: input, output и защита действий

Пилот AI выглядит безопасным, потому что его тестирует сам разработчик доверенными запросами. В продакшене на вход попадают чужие данные, а на выходе агент может вызывать инструменты - и одной проверки “модель ответила разумно” уже недостаточно. Guardrails - это не одна проверка, а несколько независимых слоев защиты, каждый из которых ловит то, что пропустил предыдущий.

Три слоя guardrails

• Input guardrails - работают до вызова модели, на самом запросе.
• Output guardrails - работают после ответа модели, до того как результат уйдет пользователю.
• Action guardrails - работают на уровне вызова инструментов и реальных действий в системах.

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

Input guardrails: что проверять до модели

• Отделять инструкции от данных: контент, полученный извне (например, через web fetch), помечать как untrusted и не давать ему переопределять системный промпт - это главная защита от prompt injection.
• Маскировать или вырезать персональные данные перед отправкой в модель, если они не нужны для задачи.
• Ограничивать тему и scope запроса explicit allow-list того, что агент обслуживает.
• Rate limiting и лимит длины ввода на пользователя и сессию.

Output guardrails: что проверять после модели

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

Action guardrails: что проверять перед выполнением

• Явное разделение read-only и action-инструментов - основа для разных политик безопасности; как проектировать сами инструменты - в статье Tool calling: базовые и расширенные инструменты AI-агента.
• Allow/deny-политика на домены, операции и суммы для action-инструментов.
• Human-in-the-loop для операций с деньгами, юридическими последствиями или необратимыми действиями - когда именно он обязателен, разобрано в статье Human-in-the-loop: где агенту нужен человек.
• Post-check: подтверждение, что действие в целевой системе действительно выполнилось так, как задумано.

Defense-in-depth: где физически ставить guardrails

Лучше один общий шлюз (gateway/прокси) между агентом и моделью/инструментами, где guardrails применяются централизованно, чем отдельная реализация в каждом сервисе. Это дает единую точку правил вместо дублирования логики в каждом агенте, аудиторский след для разбора инцидентов и возможность обновить правило один раз, а не в N местах.

Мониторинг guardrails

Guardrails без метрик - это неизвестно работающая защита. Нужно считать:

• частоту срабатывания каждого правила (block rate),
• долю ложных срабатываний (false positive rate) - блокировки легитимных запросов,
• инциденты, которые guardrails пропустили и обнаружили постфактум.

Каждый пропущенный инцидент должен становиться новым regression-кейсом - процесс подробно описан в статье Evals и regression-тесты для AI-агентов в продакшене.

Готовые фреймворки vs свои правила

Для типовых задач - детекция PII, prompt injection, токсичность - разумнее взять готовый классификатор или фреймворк (например, NeMo Guardrails, AWS Bedrock Guardrails, LLM Guard), чем писать эвристики с нуля: они обучены на большом наборе атак и обновляются вместе с новыми техниками обхода. Свои правила имеет смысл писать только для бизнес-специфичных ограничений - какие суммы, домены и операции разрешены именно в вашем продукте.

Главное правило

Guardrails - это не разовая проверка, а слой между моделью и реальным миром, который работает на каждом запросе. Если он отсутствует хотя бы на одном из трех уровней - input, output или action - продакшен рано или поздно получит инцидент, который пилот никогда бы не показал.