Что такое guardrails в ИИ и зачем они нужны агентам

Короткое объяснение

Guardrails - это правила, фильтры и проверки вокруг ИИ-системы. Они помогают ограничить опасные действия, защитить данные, проверить формат ответа, не дать агенту вызвать лишний инструмент и отправить рискованный случай человеку.

Если совсем просто:

1. системный промпт говорит модели, как надо себя вести;
2. guardrails проверяют, что правила действительно соблюдаются;
3. backend не дает выполнить опасное действие без разрешения;
4. логи показывают, что было заблокировано;
5. тесты помогают не сломать защиту при обновлениях.

Guardrails особенно важны для ИИ-агентов, потому что агент может не только отвечать текстом, но и вызывать tools, читать документы, менять данные и запускать workflow.

Зачем нужны guardrails

LLM может ошибаться, галлюцинировать, неверно понять запрос, поддаться prompt injection или выбрать неправильный tool. Если модель просто пишет текст, риск ограничен ответом. Если модель имеет доступ к инструментам, ошибка может превратиться в действие.

Guardrails нужны, чтобы:

1. блокировать опасные запросы;
2. не раскрывать секреты;
3. защищать персональные данные;
4. проверять права доступа;
5. не давать выдумывать ответ без источника;
6. ограничивать tools;
7. требовать approval для рискованных действий;
8. проверять формат ответа;
9. логировать инциденты;
10. передавать сложные случаи человеку.

Идея не в том, чтобы запретить все. Идея в том, чтобы сделать поведение ИИ управляемым.

Guardrails и системный промпт

Системный промпт задает правила поведения. Guardrails проверяют и enforced эти правила технически.

Пример системного промпта:

Не раскрывай персональные данные и не отправляй письмо клиенту без подтверждения.

Пример guardrails:

1. фильтр PII проверяет ответ перед отправкой;
2. policy gate запрещает tool `send_email` без approval;
3. audit log сохраняет попытку отправки;
4. UI просит менеджера подтвердить действие.

Промпт без guardrails - это просьба к модели. Guardrails превращают просьбу в правило приложения.

Какие бывают guardrails

Guardrails можно разделить по слоям.

1. Input guardrails - проверяют вход пользователя.
2. Retrieval guardrails - контролируют документы и доступы.
3. Tool guardrails - ограничивают вызовы инструментов.
4. Output guardrails - проверяют финальный ответ.
5. Memory guardrails - решают, что можно сохранять.
6. Cost guardrails - ограничивают стоимость и длину запросов.
7. Human approval - требуют подтверждение человека.
8. Monitoring guardrails - логируют блокировки и аномалии.

В реальном агенте обычно нужен не один фильтр, а несколько слоев.

Input guardrails

Input guardrails работают до вызова модели. Они проверяют запрос пользователя или внешний входной текст.

Они могут:

1. ограничить слишком длинный запрос;
2. заблокировать очевидную атаку;
3. найти попытку раскрыть system prompt;
4. обнаружить секреты в сообщении;
5. отфильтровать запрещенный контент;
6. проверить формат входных данных;
7. определить язык;
8. маршрутизировать запрос к человеку;
9. включить rate limit;
10. пометить запрос как рискованный.

Input guardrails не решают все, но уменьшают мусор и риск до того, как запрос попадет в модель.

Retrieval guardrails

Retrieval guardrails нужны для RAG и поиска по документам. Они проверяют, какие фрагменты можно передать модели.

Они помогают:

1. соблюдать права доступа;
2. не показывать закрытые документы;
3. не использовать устаревшие версии;
4. фильтровать документы по продукту;
5. отделять инструкции от данных;
6. не давать RAG-документам менять system prompt;
7. проверять источник ответа;
8. блокировать poisoned documents;
9. требовать citations;
10. логировать найденные chunks.

Без retrieval guardrails агент может ответить по чужому документу или принять вредную строку в документе за инструкцию.

Tool guardrails

Tool guardrails - один из самых важных слоев для ИИ-агентов.

Они контролируют:

1. какие tools доступны;
2. какие tools read-only;
3. какие tools требуют approval;
4. какие аргументы допустимы;
5. есть ли права у пользователя;
6. не превышен ли лимит вызовов;
7. не повторяется ли действие;
8. не вызван ли опасный tool после prompt injection;
9. не передаются ли секреты в tool;
10. записан ли audit log.

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

Output guardrails

Output guardrails проверяют ответ перед показом пользователю.

Они могут ловить:

1. персональные данные;
2. секреты;
3. неподтвержденные обещания;
4. отсутствие источника;
5. неправильный формат;
6. токсичный или запрещенный контент;
7. юридически рискованные формулировки;
8. медицинские или финансовые гарантии;
9. раскрытие system prompt;
10. выдуманные ссылки.

Иногда output guardrail блокирует ответ, иногда просит модель переписать его, а иногда передает случай человеку.

Memory guardrails

Память агента особенно опасна, если сохранять все подряд.

Memory guardrails решают:

1. что можно сохранять;
2. что нельзя сохранять;
3. на какой срок;
4. в какой namespace;
5. кто может удалить память;
6. как подтверждать долгосрочные факты;
7. как не сохранять галлюцинации;
8. как не сохранять секреты;
9. как обновлять устаревшие данные;
10. как показать пользователю сохраненные сведения.

Без memory guardrails агент может запомнить временную ошибку как постоянный факт.

Human approval

Human approval - это guardrail, где рискованное действие требует подтверждения человека.

Approval нужен, если агент:

1. отправляет письмо клиенту;
2. меняет статус заказа;
3. создает юридический документ;
4. выдает скидку;
5. меняет данные в CRM;
6. запускает платеж;
7. удаляет файл;
8. меняет доступы;
9. публикует контент;
10. отвечает в конфликтной ситуации.

Хорошая схема: агент готовит черновик и объясняет основание, человек подтверждает или правит.

Policy gate

Policy gate - это слой, который принимает решение: разрешить, заблокировать, отправить на approval или передать человеку.

Он может учитывать:

1. пользователя;
2. роль;
3. канал;
4. тип tool;
5. риск действия;
6. сумму операции;
7. чувствительность данных;
8. наличие источника;
9. результат проверки PII;
10. историю предыдущих вызовов.

Policy gate лучше держать в backend, а не только в промпте.

Redaction и маскирование данных

Redaction - это удаление или маскирование чувствительных данных.

Можно маскировать:

1. телефоны;
2. email;
3. номера документов;
4. адреса;
5. токены;
6. API-ключи;
7. номера карт;
8. персональные идентификаторы;
9. внутренние комментарии;
10. коммерческие условия.

Маскирование особенно важно в логах, prompt context, tool results и ответах пользователю.

Guardrails и prompt injection

Prompt injection - одна из причин, почему guardrails нельзя заменять промптом.

Атака может выглядеть так:

1. пользователь просит игнорировать правила;
2. документ в RAG содержит скрытую инструкцию;
3. tool result возвращает текст “выполни команду”;
4. письмо клиента пытается раскрыть system prompt;
5. пользователь просит вызвать запрещенный tool.

Guardrails должны отделять инструкции от данных. Пользовательский текст, документы и tool results не должны менять system prompt, tool policy и права доступа.

Guardrails и галлюцинации

Guardrails не убирают галлюцинации полностью, но могут снижать ущерб.

Они помогают:

1. требовать источник;
2. блокировать ответ без evidence;
3. просить модель сказать “не найдено”;
4. отделять факт от предположения;
5. проверять citations;
6. передавать спорный ответ человеку;
7. запускать fact-checking;
8. логировать низкую уверенность.

Для RAG-сценариев особенно важны groundedness и faithfulness: ответ должен опираться на найденные документы.

Guardrails и стоимость

Guardrails нужны не только для безопасности, но и для управления стоимостью.

Cost guardrails могут:

1. ограничить длину входа;
2. ограничить max tokens;
3. остановить бесконечный agent loop;
4. ограничить число tool calls;
5. выбрать дешевую модель для простых задач;
6. запретить повторные ретраи;
7. остановить запрос после лимита;
8. уведомить администратора о всплеске расходов.

Без лимитов агент может начать дорого “думать”, искать и вызывать tools без достаточной пользы.

Где guardrails нужны особенно

Guardrails особенно важны в сценариях с данными, деньгами и действиями.

Примеры:

1. поддержка клиентов;
2. CRM и продажи;
3. финансы и бухгалтерия;
4. договоры и юристы;
5. медицина;
6. HR и персональные данные;
7. IT service desk;
8. GitHub и код;
9. внутренний поиск по документам;
10. маркетинг и публикации;
11. реклама и бюджеты;
12. агенты с write tools.

Если агент может повлиять на клиента, деньги, доступы или данные, guardrails обязательны.

Когда можно начать проще

Не всегда нужен сложный фреймворк сразу.

Для первого прототипа можно начать с:

1. allowlist tools;
2. read-only режим;
3. ручное подтверждение;
4. простая проверка PII;
5. лимит длины запроса;
6. запрет ответа без источника;
7. audit log;
8. небольшой набор тестовых атак;
9. ручной review спорных ответов;
10. отключение опасных действий.

Фреймворки помогают, но плохую архитектуру они не исправят.

Как тестировать guardrails

Guardrails нужно тестировать отдельно.

В тестовый набор добавляют:

1. обычные безопасные вопросы;
2. попытку раскрыть system prompt;
3. prompt injection;
4. просьбу вызвать запрещенный tool;
5. документы с вредной инструкцией;
6. вопрос без ответа в базе знаний;
7. персональные данные;
8. запрос на скидку или платеж;
9. слишком длинный запрос;
10. конфликтующие источники.

Важно тестировать не только блокировки, но и нормальные случаи. Иначе guardrails станут слишком жесткими и начнут мешать пользователю.

Типичные ошибки

Частые ошибки:

1. считать guardrails одной фразой в системном промпте;
2. включить write tools без approval;
3. не проверять права доступа в RAG;
4. не логировать блокировки;
5. не тестировать prompt injection;
6. возвращать в tool result слишком много данных;
7. хранить секреты в prompt;
8. не маскировать PII в логах;
9. не ограничивать стоимость;
10. блокировать слишком много нормальных запросов;
11. не иметь fallback человеку;
12. не проверять guardrails после смены модели.

Guardrails должны быть полезными, а не декоративными.

Мини-чеклист

Перед запуском AI-агента проверьте:

1. есть input guardrails;
2. RAG учитывает права доступа;
3. tools разделены по риску;
4. write tools требуют approval;
5. output проверяется перед отправкой;
6. память ограничена;
7. PII маскируется;
8. есть audit log;
9. есть лимиты стоимости;
10. есть тесты на prompt injection;
11. есть fallback человеку;
12. есть быстрый способ отключить агента.

Если агент пока не проходит этот список, лучше запускать его как помощника с черновиками.

Что изучать дальше

После guardrails стоит разобраться в смежных темах:

1. prompt injection;
2. AI safety;
3. human-in-the-loop;
4. approval workflow;
5. audit log;
6. evals;
7. RAG security;
8. tool policies;
9. PII redaction;
10. observability.

Эти темы помогают превратить AI-демо в управляемый production-сценарий.

Частые вопросы

Guardrails можно заменить системным промптом?

Нет. Системный промпт задает правила, но guardrails должны проверять их технически: валидировать вход, фильтровать документы, ограничивать tools, проверять ответ, требовать approval и писать логи.

Guardrails нужны только для ИИ-агентов?

Нет. Они полезны и для обычных LLM-приложений. Но для агентов они особенно важны, потому что агент может вызывать tools и менять внешний мир.

Что важнее: input или output guardrails?

Нужны оба слоя. Input guardrails снижают риск до модели, output guardrails проверяют финальный ответ. Для агентов отдельно нужны tool guardrails и retrieval guardrails.

Guardrails не сделают ИИ слишком жестким?

Могут, если настроить их грубо. Поэтому нужны не только attack cases, но и normal cases: guardrails должны блокировать опасное, но не мешать обычным полезным запросам.

Нужно ли использовать готовый guardrails-фреймворк?

Не обязательно на старте. Можно начать с простых rule-based проверок, allowlist tools, approval и audit log. Для сложных сценариев полезны специализированные фреймворки и сервисы.