Что можно поручить ИИ-агенту внутри корпоративной системы?

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

От поиска сведений до готовой заявки

Возьмем подготовку закупки, для которой нужны остатки из 1С, реквизиты поставщика из CRM и условия действующего договора. Агенту можно поручить собрать эти сведения, заполнить черновик заявки и подготовить служебную записку. Языковая модель будет выбирать инструменты и разбирать полученные ответы, а программные компоненты, проверяя ее запросы, будут выполнять операции через API корпоративных сервисов.

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

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

Доступ определяет последствия ошибки

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

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

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

Что происходит после нажатия «Подтвердить»

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

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

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

Когда появляется экономия

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

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