ИИ-агенты для бизнеса: чем отличаются от чат-бота и какие задачи им поручать

«Нам нужен ИИ-агент, чтобы он сам работал с клиентами». С такого пожелания трудно начать проект. Что значит «работал»: объяснял условия, находил заказ, готовил ответ или менял данные в CRM? У этих действий разные требования к информации и разные последствия ошибки.

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

Что делает агент в рабочем процессе

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

Названия «бот», «ассистент» и «агент» у разных продуктов пересекаются. Чат-бот тоже может быть подключён к рабочим системам. Поэтому я бы смотрел на фактические возможности и права, а не выбирал решение по слову на обложке презентации.

Представим условное обращение оптового покупателя: «Нужна повторная поставка. Проверьте прошлый заказ и напомните менеджеру связаться со мной». Вот три разных уровня обработки такого сообщения.

Фраза «задача создана» сама по себе не подтверждает выполнение. Нужно проверить запись в рабочей системе. И наоборот: агент может правильно выполнить допустимое действие, даже если его итоговое объяснение получилось неидеальным. Качество текста и качество операции оценивают отдельно.

Чем агент отличается от обычной автоматизации

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

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

Какие сценарии подходят для проверки

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

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

Опишите пилот одной рабочей карточкой:

• Событие: поступило обращение по выбранному каналу.
• Доступные сведения: текст обращения и конкретные разрешённые записи.
• Результат: черновик ответа или задача с определёнными полями.
• Граница: агент не назначает скидку и не меняет условия заказа.
• Исключение: при неоднозначности передаёт вводные сотруднику.

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

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

Как подключение к системам меняет задачу

У диалога появляется связь с реальными записями. Поэтому в проекте нужно согласовать, как определяется клиент, какие сведения можно прочитать и куда должен попасть результат. Например, поиск по номеру телефона может вернуть несколько записей. Это повод уточнить выбор, а не молча взять первую.

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

Дальше разберите сбои. Что произойдёт, если CRM не ответила? Если задача записалась, но подтверждение не дошло? Если клиент отправил одно обращение дважды? В последнем случае повторная обработка не должна автоматически создавать несколько одинаковых задач. Способ предотвращения дублей входит в проект интеграции.

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

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

Как ограничить выполнение действий

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

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

Подтверждение должно быть предметным

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

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

Как оценить пилот ИИ-агента

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

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

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

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

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

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