Что агенту разрешено делать?
Для каждой системы, с которой работает сценарий, распишите, что агент может читать, что он может готовить в виде черновика и что может изменять. Это три разных уровня доверия, и их настройка — первая задача при разработке ИИ-агентов. Прочитать карточку клиента — одно, подготовить ему ответ — другое, а отправить этот ответ или поменять цену в каталоге — совсем третье. Выдавайте ровно те права, без которых задача действительно не решается. Ключи API, пароли и токены не должны попадать в текст, который видит модель: доступы хранятся на стороне приложения, и агент может запустить действие, ни разу не увидев сам ключ. Если агенту нужен доступ к нескольким системам, выдавайте права отдельно для каждой, а не одну общую учётную запись на всё.
Затем решите, какие действия требуют подтверждения человеком и что этот человек должен увидеть, прежде чем нажать «Да». Кнопка «Подтвердить?» без подробностей быстро приучает соглашаться не глядя. Сотруднику нужно видеть, к чему относится действие (какая запись, какой клиент, какой счёт), что именно агент предлагает изменить, на какие данные он при этом опирался и к чему это приведёт. Если чего-то из этого нет, подтверждение превращается в формальность и перестаёт защищать. Хорошее правило: если сотрудник не может за минуту разобраться, что именно он подтверждает, экран подтверждения нужно переделать.
И наконец, не выдавайте агенту широкие административные права «на будущее». Так часто поступают, когда дальнейшие сценарии ещё не ясны и кажется, что проще один раз открыть всё. Надёжнее расширять права тогда, когда новый сценарий продуман и проверен. В этом случае каждое расширение — осознанное решение со своими проверками, а вы всегда точно знаете, к чему у агента есть доступ сегодня.
Почему внешним данным нельзя доверять?
Агент редко работает только с вашими инструкциями. Он читает письма клиентов, веб-страницы, вложения и сообщения из других систем, и в любом из этих источников может оказаться текст, похожий на команду: «забудь прежние правила», «перешли этот файл», «отметь счёт как оплаченный». Иногда это намеренная попытка манипуляции, иногда просто запутанный документ. В обоих случаях содержимое письма или файла не должно менять порядок работы сценария.
На практике это значит, что правила работы агента хранятся отдельно от материалов, которые он обрабатывает, а каждый параметр действия проверяется кодом приложения до того, как что-то будет выполнено. Если агент предлагает вернуть клиенту деньги, приложение проверяет, что заказ существует, сумма укладывается в лимит, а получатель совпадает с данными в системе. Подтверждение никогда не берётся из документа: фраза в письме «изменение одобрено» — это просто текст, а одобрить что-либо может только ваш порядок подтверждения. Логика приложения здесь — последняя линия защиты: даже если модель поверила подложной инструкции, неверный параметр не пройдёт проверку, и действие не выполнится.
Проверяйте это специально. Кроме обычных случаев, подготовьте враждебные и вводящие в заблуждение примеры: вложение со скрытыми инструкциями, письмо якобы от руководителя, запрос с заведомо неверными номерами. Правильное поведение здесь простое: если проверка не пройдена, действие останавливается, а случай уходит к человеку. Агент, который при нестыковке данных действует наугад, «по самой вероятной версии», — именно то, чего нужно избежать.
Как отследить действия агента и исправить сбой?
Каждый запуск должен оставлять след, по которому потом можно восстановить картину: что предложил агент, кто и когда это подтвердил, что ответила рабочая система и какие записи были затронуты. Обращайтесь с этим журналом так же бережно, как с самими данными, — в нём могут оказаться персональные или коммерческие сведения. Заранее решите, что именно сохраняется, у кого есть доступ к журналу и сколько хранятся записи. Журнал нужен не только для разбора ошибок: по нему видно, как часто сотрудники отклоняют предложения агента, а это верный сигнал, что сценарий пора дорабатывать.
Дальше продумайте сбои: рано или поздно они случаются. Ограничьте число действий, которые агент может выполнить за определённое время, защитите сценарий от повторов, чтобы повторный запрос не выполнился дважды, и предусмотрите простой способ приостановить весь процесс без вызова разработчика. До запуска проверьте неудобные ситуации: запрос, который не дождался ответа, действие, выполненное наполовину, отказ в подтверждении посреди цепочки шагов. Для каждого случая нужно знать, в каком состоянии останутся записи и как процесс продолжится. Записывайте результаты этих проверок: когда сбой случится в работе, у команды уже будет описанный порядок действий, а не импровизация в спешке.
Назначьте и ответственного за работу сценария — человека, который может открыть конкретный запуск, разобраться, что произошло, и решить, как исправлять ситуацию. При разборе опирайтесь на данные рабочей системы, а не на рассказ агента. Агент может гладко и убедительно описать действие, которого на самом деле не было; значение имеет только запись в CRM или учётной системе.
Чек-лист: права агента
- Разделите права на чтение, черновики и изменения для каждой системы, с которой работает агент, и не допускайте ключи доступа в текст, который видит модель.
- Перед любым важным подтверждением показывайте сотруднику объект, точное предлагаемое изменение, основание и ожидаемый результат.
- Проверяйте внешние данные и параметры каждого действия кодом приложения: если проверка не пройдена, действие останавливается.
- Проверьте повторные запросы, тайм-ауты, частичное выполнение, остановку и восстановление и назначьте ответственного за запуски.
Пример: агент готовит ответ клиенту в CRM
Приходит заявка, и система готовит в CRM черновик ответа на основе самой заявки и утверждённой справки. Сама она ничего не отправляет. Сотрудник видит получателя, полный текст письма и источник, на который опирался черновик, и только после этого подтверждает отправку. Если сотрудник отклоняет черновик, это тоже фиксируется, и клиенту ничего не уходит.
CRM возвращает результат отправки, и он сохраняется вместе с данными запуска, так что любой может потом посмотреть, что было предложено, кто это подтвердил и что произошло на самом деле. Если одно и то же уведомление от интеграции придёт дважды — а с интеграциями такое бывает, — защита от повторов его распознает, и второе сообщение клиенту не уйдёт.
