Защита ИИ: как настроить guardrails и контроль действий

Защита ИИ строится на проверках в 5 точках: при получении запроса, загрузке контекста, формировании предложения модели, выполнении действий через инструменты и выдаче ответа. Фильтр контента может перехватить запрещённый ответ, но именно приложение должно решать, вправе ли клиент видеть запись или разрешать возврат денег. Небольшой команде стоит сначала настроить эти права, а уже затем добавлять новые классификаторы.

Как устроена защита ИИ с помощью guardrails?

Guardrails — это защитные механизмы, которые превращают правила на бумаге в реальные ограничения: что ИИ-приложение может получать, раскрывать и делать. Большая языковая модель, или LLM, формирует ответы и предлагает действия. Защитные механизмы проверяют входные и выходные данные либо ограничивают работу окружающего модель ПО.

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

Чтобы защитный механизм работал, нужны три составляющие: правило, проверка и действие по её результату. «Не раскрывать данные клиентов» — правило. Сравнить владельца запрошенной записи с клиентом, чья личность подтверждена, — проверка. Запретить чтение из базы данных — действие по её результату. Если система лишь пишет в журнал и ничего не блокирует, она фиксирует нарушение уже после того, как оно произошло.

Часть проверок детерминирована: при одинаковых правилах и входных данных они всегда дают одинаковый результат. Так проверяют, например, имена разрешённых инструментов и наличие обязательных полей. Другие проверки используют классификаторы — модели, которые оценивают, нарушает ли контент заданную политику. К ним относятся определение темы и классификация вредоносного контента. Согласование с человеком позволяет учесть его оценку перед разрешённым, но значимым по последствиям действием.

AI guardrails — общее название всех этих механизмов. Guardrails AI — один конкретный фреймворк. Если путать категорию с продуктом, важные участки системы могут остаться без ответственного за их защиту.

Guardrails на практике: весь путь запроса на возврат денег

Даже обычный по формулировке запрос на возврат требует разных проверок на разных этапах. Возьмём условное сообщение клиента: «Пожалуйста, верните деньги за мой последний заказ и отправьте подтверждение на мой новый email». Допустим, ваши правила требуют согласования перед возвратом, а подтверждения разрешено отправлять только на проверенный адрес из учётной записи.

Путь запроса выглядит так: проверка входных данных → контекст в пределах прав доступа → предложение модели → действие с проверенными правами и согласованием → проверка ответа. При каждом последующем вызове инструмента нужные проверки повторяются.

До вызова модели: подтвердить личность, отфильтровать и сократить данные

Определяйте клиента по аутентифицированной сессии, а не по имени или идентификатору учётной записи, которые он ввёл в чате. Ограничивайте размер и частоту запросов до ресурсоёмкой обработки.

Затем проверяйте сообщение на запрещённый контент, темы за пределами задачи и лишние конфиденциальные данные. Тематический фильтр поможет удержать помощника поддержки от посторонних советов. Фильтр персональных данных может удалить вставленный номер телефона, если он не нужен для задачи. PII — это сведения, позволяющие идентифицировать человека, например email или номер телефона.

Не удаляйте данные, которые действительно нужны процессу, не предусмотрев другого способа их использования. Храните проверенные сведения об учётной записи в приложении и передавайте модели только минимально необходимый контекст. Маскирование текста перед вызовом модели не удаляет копии, уже попавшие в журналы запросов. Поэтому сокращать объём данных нужно также при сборе и журналировании.

До поиска данных: ограничить доступные записи

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

Найденные документы, веб-страницы и результаты инструментов — это тоже входные данные. В справочной статье может оказаться инструкция, которая пытается переопределить правила приложения. Такая атака называется косвенной инъекцией промпта (indirect prompt injection). Рассматривайте найденный текст как материал для анализа, а не как разрешение менять порядок работы.

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

На этапе модели: задать рамки предложения

Запрашивайте у модели структурированное предложение с заранее известными полями, например действием и идентификатором заказа. Проверяйте структуру до того, как интерпретировать содержимое.

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

В нашем примере модель может предложить возврат и отметить просьбу сменить адрес. Решать, разрешено ли каждое из этих действий, должно приложение.

До запуска инструмента: проверить права и согласование

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

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

Новый email — отдельный вопрос прав доступа. В этом примере приложение направляет клиента на процедуру проверки учётной записи и до её завершения использует уже проверенный адрес. Фильтр контента не может установить, кому принадлежит почтовый ящик.

До отправки ответа: проверить результаты и раскрываемые данные

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

Затем проверяйте ответ клиенту: нет ли в нём запрещённого контента, конфиденциальных сведений и неподтверждённых утверждений, соблюдена ли нужная структура. Фраза «Возврат выполнен» допустима только при подтверждённом результате инструмента. Если согласование ещё ожидается, ответ должен прямо об этом сообщать.

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

Инструменты защиты ИИ: что заявлено в документации

Выбирайте инструмент по тому, на каком участке он помогает обеспечить контроль и какие правила вы готовы поддерживать. Приведённая ниже карта возможностей сверена с актуальной документацией поставщиков 17 октября 2026 года. Она сравнивает заявленные функции, а не измеренную точность обнаружения нарушений.

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

Что такое Guardrails AI?

Guardrails AI — Python-фреймворк для объединения валидаторов, проверяющих входные и выходные данные модели, и генерации структурированных данных. Во введении описаны сам фреймворк и его набор валидаторов.

Валидатор проверяет значение по заданному критерию и сообщает, пройдена ли проверка. Обработку неудачного результата определяет настроенная политика on_fail. Документация содержит примеры проверки токсичной лексики и PII, а также допускает собственные валидаторы. Принципы работы валидаторов.

Этот вариант подходит, если явные правила валидации хорошо вписываются в существующее Python-приложение. Ограничение — в охвате: установка фреймворка сама по себе не определяет, какие проверки выполняются на каждом пути и что блокирует их отрицательный результат. Описывайте и тестируйте эти решения вместе с приложением.

NVIDIA NeMo Guardrails

NVIDIA NeMo Guardrails предоставляет программируемые механизмы контроля на нескольких этапах взаимодействия с LLM. Документированные типы защитных механизмов охватывают входные данные, найденный контекст, диалог, выполнение действий и выходные данные.

Проверки входных данных могут охватывать безопасность контента, джейлбрейки, тематику и PII. Проверки при поиске оценивают контекст, а проверки диалога ограничивают ход беседы. На этапе выполнения можно проверять входные данные и результаты инструментов; на выходе — фильтровать, редактировать или блокировать ответы.

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

Amazon Bedrock Guardrails

Amazon Bedrock Guardrails предлагает настраиваемые фильтры контента, запрещённых тем, слов и конфиденциальных сведений, проверку опоры ответа на контекст и проверки Automated Reasoning. Фильтры конфиденциальной информации могут блокировать или маскировать поддерживаемые типы PII и данные по пользовательским шаблонам. Automated Reasoning оценивает ответы на соответствие логическим правилам. Обзор защитных механизмов.

ApplyGuardrail API оценивает текст независимо от вызова базовой модели. Его можно встроить перед поиском данных или перед выдачей ответа.

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

Какие средства защиты предлагают разработчики моделей?

OpenAI moderation классифицирует вредоносный контент в поддерживаемых текстовых и графических входных данных и возвращает флаги, категории и оценки. Документация по модерации также предупреждает: даже отказ, в котором обсуждается вредоносный контент, может вызвать срабатывание.

Используйте эти результаты как сигналы для применения своих правил. Обращение в поддержку с цитатой оскорбительного сообщения может требовать иной реакции, чем просьба такое сообщение создать. Модерация помогает принимать решения о контенте, но не задаёт правила доступа к заказам.

Google Gemini предоставляет настройки безопасности, которые связывают категории вредоносного контента с порогами блокировки. Актуальное руководство по настройкам безопасности охватывает, в частности, домогательства и оскорбления, язык ненависти, сексуальный и опасный контент, а также джейлбрейки.

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

Безопасность ИИ-агентов: что нужно заложить в архитектуру

Между предложением действия и его выполнением у агента должен быть обязательный рубеж проверки. Можно реализовать его через точки расширения фреймворка или обычный код сервиса. В любом случае он должен опираться на достоверные сведения о личности пользователя и текущее состояние приложения.

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

Согласование должно быть записью, которую система обязана проверить, а не просто словом «да» в беседе. Сохраняйте, что было согласовано, кем и с какими параметрами действия. Перед выполнением заново проверяйте состояние: пока человек принимал решение, деньги за заказ уже могли вернуть.

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

В нашем практическом руководстве по защитным механизмам ИИ-агентов в продакшене и ограничению последствий сбоев эта архитектура разобрана подробнее. Для рассматриваемого запроса главный вопрос прост: если модель предложит неправильное действие, какой сервис откажется его выполнять?

Какие ограничения нужно учесть до запуска?

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

Например, AWS описывает проверку опоры на контекст для суммаризации, перефразирования и ответов на вопросы при наличии исходного материала и запроса, но прямо исключает диалоговые сценарии вопросов и ответов и чат-боты. Документированные пределы составляют 100,000 символов для источника, 1,000 для запроса и 5,000 для ответа. Это ограничения числа символов для конкретной функции, а не общие пределы контекста модели и не запрет использовать другие средства защиты Bedrock в чат-ботах. Документация по проверке опоры на контекст.

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

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

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

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

Минимальный набор защиты для небольшой команды

Начните с шести мер контроля, которые вы можете объяснить, проверить на практике и закрепить за ответственными. Внедрять все фреймворки из таблицы не требуется.

1. 1

   Личность клиента и доступные данные

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

2. 2

   Правила для входных данных и их минимизация

   Определите поддерживаемую задачу, проверяйте релевантные риски контента и удаляйте ненужные конфиденциальные поля. Выберите безопасный ответ на запросы за пределами задачи.

3. 3

   Требования к ответу

   Проверяйте обязательные поля, правила раскрытия данных и утверждения о выполненных действиях. Если у ответа нет надёжного подтверждения, он должен признавать неопределённость или направлять клиента в поддержку.

4. 4

   Ограниченные действия и согласование

   Предоставляйте инструменты с узкими бизнес-функциями. Перед выполнением проверяйте личность клиента, аргументы и текущее состояние; требуйте согласования для действий, которые ваши правила относят к значимым по последствиям.

5. 5

   Поведение при сбоях и рабочие лимиты

   Задайте подходящие для процесса лимиты запросов, вызовов инструментов, повторных попыток и времени выполнения. Определите поведение при сбое обязательной проверки или зависимого сервиса. Заново проверяйте изменённые предложения и повторные попытки.

6. 6

   Регрессионные тесты и журнал аудита

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

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

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

Как проверить приложение с помощью Promptfoo

Promptfoo — инструмент оценки и red teaming: он помогает проверять обычное поведение приложения и намеренно атакующие запросы. В его документации по тестированию агентов описаны проверки ролевых ограничений, доступа к объектам без необходимых прав и несанкционированного доступа к функциям.

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

Для нашего условного сценария возврата начните с таких случаев:

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

Это предлагаемые тестовые сценарии, а не отчёт о результатах тестирования. Проверяйте не только итоговый ответ, но и внешние изменения и сохранённое состояние. Фраза «Я не могу этого сделать» ничего не гарантирует, если инструмент уже это сделал.

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

Какие ожидания от guardrails завышены?

Продукт для защиты ИИ — не универсальная кнопка безопасности. Его ценность зависит от того, что он проверяет, где работает и что именно предотвращает его решение.

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

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

ИИ без защитных механизмов: чего именно не хватает?

Для функции, которой пользуются клиенты, полезнее выяснить, какие конкретно меры контроля отсутствуют. Приложение может использовать фильтрацию контента от поставщика, но не иметь разграничения прав клиентов, проверки ответов или обязательного согласования. Ярлык «защищено» скрывает эти пробелы.

И наоборот: приложению с детерминированным контролем доступа всё ещё могут понадобиться проверки контента. Безопасность контента и действия в пределах предоставленных прав — отдельные требования. Одно общее название не отвечает на оба вопроса.

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

Какие бывают защитные механизмы для ИИ?

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

Как настроить guardrails для ИИ?

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

Что делает Guardrails AI?

Guardrails AI объединяет валидаторы в защитные механизмы для входных и выходных данных и поддерживает генерацию структурированных данных. Какие риски проверяются и как обрабатываются неудачные проверки, определяют ваши настройки и код приложения.

Существует ли ИИ без защитных ограничений?

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

Какие 3 риска безопасности ИИ стоит проверить в первую очередь?

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

С чего начать в понедельник

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

Получайте практические руководства по внедрению ИИ в рассылке.