Guardrails для ИИ-агентов: что агент не должен делать никогда

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

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

Почему запрет в промпте не удерживает агента?

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

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

Поэтому guardrails живут отдельным слоем. В Rocketly на экране Guardrails — границы безопасности вы декларативно описываете, чего агент делать не должен, и эти границы принудительно применяются во время выполнения, а не обсуждаются внутри рассуждений модели. Разница принципиальная: промпт добивается того, чтобы агент не хотел пересекать линию, guardrail — того, чтобы он не мог.

Чем guardrail отличается от правила и сценария?

Три понятия постоянно смешивают. Сценарий говорит «если произошло это — сделай то»: последовательно, условно, предсказуемо. Движок правил смотрит на значение поля и запускает результат. Guardrail не запускает ничего — он закрывает дверь. Сценарий описывает дорогу, guardrail ставит ограждение вдоль обрыва. И ограждение оправдывает себя именно в ситуациях, которых вы не предусмотрели.

Практическая проверка — один вопрос: это описание маршрута или границы? «Пришёл новый лид — изучи, сделай резюме, добавь заметку» — маршрут; порядок действий задаётся через пошаговый плейбук, чтобы не оставлять его на усмотрение модели. «Никогда не называй срок поставки» — граница, действующая на любом маршруте. Записанные в одном месте, они ослабляют друг друга.

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

Откуда брать список запретов?

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

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

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

Что блокировать жёстко, а что отправлять на подтверждение?

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

Действие	Обратимо?	Видит клиент?	Рекомендуемая граница
Заметка и резюме в карточке	Да	Нет	Автоматически
Обновление скоринга и тегов	Да	Нет	Автоматически
Увеличение рекламного бюджета	Частично	Нет	Ручное подтверждение
Отправка коммерческого предложения	Нет	Да	Ручное подтверждение
Обещание скидки или срока	Нет	Да	Жёсткий запрет
Удаление записи или диалога	Нет	Нет	Жёсткий запрет

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

Почему доступ к данным — половина границы?

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

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

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

Что должно произойти в момент срабатывания границы?

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

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

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

Как убедиться, что написанная граница действительно держит?

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

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

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

По каким записям видно, что границы работают?

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

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

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

Кто отвечает за список и как часто его пересматривают?

Бесхозный список границ портится в одну из двух сторон: либо его никто не трогает и агент постепенно становится бесполезным, либо в него дописывают все и он превращается в нечитаемый текст. В здоровой схеме у списка один владелец — как правило, ответственный за процесс, в котором работает агент, — и изменения проходят через него.

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

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

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

Не делают ли границы агента бесполезным?

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

Чем это отличается от тех же правил, записанных в промпт?

Фраза в промпте открыта для интерпретации и теряет вес по мере роста диалога. Декларированная граница применяется во время выполнения: даже если агент попытается вызвать действие, операция не пройдёт.

Нужно ли писать отдельную строку на каждый запрет?

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

Как я узнаю, что агент пытался нарушить границу?

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