Почему 100% автономности ИИ-агента — плохая цель: где оставить человека

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

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

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

Второй автономно закрывает 75% обращений. Ещё 25% он передаёт специалистам — вместе с собранными данными, историей проверок и предложенным решением. Ошибок и повторной работы у второго меньше, а бизнес-результат можно подтвердить.

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

Одна из частых архитектурных ошибок — считать успешный вызов инструмента подтверждением бизнес-результата. Агент вызвал метод CRM и получил 200 OK. Это означает только то, что сервер обработал HTTP-запрос. Запись могла попасть в очередь, не пройти последующую проверку или быть отклонена другой системой.

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

Поэтому мы разделяем как минимум три уровня результата:

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

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

Агент может получить противоречивые сведения из CRM, ERP и переписки, не найти обязательный документ или встретить формулировку, для которой нет однозначного правила. Языковая модель почти всегда способна продолжить рассуждение, но правдоподобный ответ не создаёт основания для действия.

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

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

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

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

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

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

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

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

Тайм-аут не равен отказу. Запрос мог дойти до внешней системы, а ответ — потеряться. Если агент просто повторит команду, можно получить две операции вместо одной.

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

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

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

Плохо настроенное подтверждение просто переносит ответственность на сотрудника. На экране появляется вопрос «Разрешить действие?» без контекста, и специалист нажимает кнопку почти автоматически.

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

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

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

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

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

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

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