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

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

И всё же в запросе на старте почти всегда звучит обратное: «давайте внедрим автономного агента, а лучше сразу мультиагентную систему». То есть начать с автономности и максимальной сложности. 

Как показывает практика, чем больше команда вкладывается в автономность на старте, тем меньше получает на выходе. Бюджет и внимание уходят на «ум» и оркестрацию, на то, чтобы агент «сам решал», а не на описание границ процесса. Агент без них действует на неподготовленных данных и в неясной зоне ответственности: его решения приходится перепроверять вручную, ошибочные действия откатывать, а контроль достраивать постфактум. Ручного труда в итоге не меньше, а больше, плюс счёт за самого агента. 

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

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

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

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

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

Масштаб здесь вполне реальный: например, ИИ-ассистент Klarna в первый месяц принял на себя две трети всех обращений в поддержку и сократил среднее время решения с 11 минут до двух. Но эта цифра обманчива. Дело не в скорости ответа, а том, что система правильно раскладывает поток по типам и заводит каждый случай в свой маршрут. Распознали тип плохо – и агент будет аккуратно и быстро работать не там, где нужен эффект.

Дальше агент собирает контекст. Это не «поиск в интернете всего подряд», а подъём релевантного: по обращению – история клиента, биллинг и политика возвратов; по заявке на кредит– кредитная история, скоринг и лимиты; по претензии – полис и история выплат; по закупке – договор, каталог поставщиков и бюджет. Плюс права доступа и ограничения ИБ. 

Именно здесь ломаются пилоты. Не на «уме» модели, а на доступе к данным и интеграции. Этот барьер компании называют главным. 

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

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

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

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

Почему это важно, видно по разрыву в данных: по данным BCG, измеримую бизнес-ценность от генеративного ИИ извлекли лишь 28% компаний. Остальные застряли на стадии «разговора», потому что большинству обращений нужно реальное решение проблемы, а не вежливая реплика. Красноречивый ассистент отвечает за формулировку. Агент отвечает за следующий шаг процесса, и поэтому обязан показать варианты и их последствия, а не один уверенный текст.

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

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

Пример из практики: у сервиса 1-800Accountant агент на платформе Agentforce в пик налогового сезона самостоятельно закрывает 70% чат-обращений против 50% на старте. Удерживать такую долю можно, только когда за действием стоит подготовленный набор решений, а не импровизация. 

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

Человек в контуре – это не случайная кнопка «согласовать», а спроектированная точка контроля. Заранее определяют: где человек обязан подтвердить, где достаточно уведомления, где агент действует сам, кто именно подтверждает, сколько можно ждать и что происходит при отказе. 

Работающая конструкция выглядит, например, так: возврат до 5 тыс. руб. по типовой причине агент проводит сам; от 5 до 50 тыс. готовит решение, а проводит оператор; выше или причина нетиповая – только человек, агент лишь собирает досье. Сами числа у каждого свои, важно, что они записаны до запуска и меняются решением владельца процесса, а не настроением смены. Та же логика порогов работает в кредитных лимитах, выплатах по претензиям и закупках.

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

Поэтому в регулируемом контуре точка подтверждения и журнал действий – не бюрократия для аудита, а условие, при котором автономное действие агента вообще допустимо.

После подтверждения (или в пределах разрешённой автономности) агент вызывает инструмент: биллинг, CRM, службу заявок, карточные системы банка, ERP и складские системы в цепочке снабжения, внутренние API. 

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

Здесь агентный ИИ встречается с реальной интеграцией, и поэтому его нельзя проектировать в отрыве от корпоративной архитектуры. Действие должно жить не в песочнице, а в реальных системах. По данным BCG, один европейский банк автоматизировал решения по автокредитам на 90%. Это пример возможного масштаба, когда границы описаны и интеграция собрана. Но на этом же шаге видно и обратное: собрать надёжную интеграцию даже к одному процессу трудно, а «коробочная» оркестрация нескольких агентов поверх легаси-систем – пока отдельная, ещё не решённая задача.

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

Это не бюрократия: именно журнал отличает управляемого агента от непрозрачного слоя. 

Лучшая иллюстрация – Nubank (банк с более чем 100 млн пользователей): в его промышленном фреймворке надёжность дают не удачные промпты, а инфраструктура оценки и журналирования. На проде это дало рост индекса лояльности по обращению (tNPS) на 37 п. п. в доставке карт и на 40 п. п. в управлении долгом – при качестве на уровне экспертов-людей. 

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

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

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

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

На практике чек-лист можно ужать до трёх вопросов:

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

Казалось бы, ответил на вопросы из чек-листа — и можно выдохнуть. Но на этом история не заканчивается.

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

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

Главное, что показывает процессная аналитика, – есть ли у процесса устойчивый скелет. Если каждый экземпляр процесса идёт своим маршрутом, описывать границы для агента рано: сначала процесс, потом агент.

Рабочий порядок действий:

Тогда эффект считается в тех же единицах, в которых процесс измеряли до агента, и разговор с финансовым директором становится коротким.

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

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

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

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

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

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

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