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