ИИ-агент и чат-бот: в чём разница для бизнеса

«ИИ-агент» стал одним из самых популярных терминов в разговорах об автоматизации — и одним из самых размытых. Под ним продают и чат-бот на сайте, и ассистента для сотрудников, и систему, которая самостоятельно обрабатывает заказы в 1С. Для руководителя разница принципиальная: от неё зависят стоимость внедрения, риски и, главное, экономический эффект.

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

Коротко: чат-бот отвечает, агент выполняет

Самое полезное различие для бизнеса — не в технологии, а в результате работы.

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

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

Как устроен чат-бот

Чат-боты бывают двух поколений.

Сценарный бот

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

Бот на языковой модели

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

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

Как устроен ИИ-агент

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

1. Языковая модель — понимает входящий запрос или документ и планирует шаги.
2. Инструменты — доступ к рабочим системам: поиск заказа в 1С, чтение карточки в CRM, проверка остатков, создание документа, отправка письма. Каждый инструмент — это конкретное разрешённое действие.
3. Правила процесса — регламент, по которому агент принимает решения: когда можно перенести доставку, какие документы требуют проверки, какие суммы — согласования.
4. Уровни полномочий — какие действия агент выполняет сам, какие только готовит, какие требуют подтверждения сотрудника.
5. Эскалация — когда агент не уверен или ситуация выходит за правила, он передаёт задачу человеку вместе со всем, что уже выяснил.
6. Журнал — каждое действие агента фиксируется: что сделал, на основании каких данных, кто подтвердил.

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

Сравнение

Один процесс — два подхода

Возьмём типичное обращение в интернет-магазин или дистрибьютору: «Где мой заказ? Можно ли перенести доставку на четверг?»

Как это обрабатывает чат-бот

1. Распознаёт вопрос о статусе заказа.
2. Просит номер заказа и показывает статус из базы.
3. На вопрос о переносе отвечает правилом: «Перенос доставки возможен не позднее чем за сутки. Для переноса свяжитесь с оператором».
4. Создаёт обращение для оператора.

Оператор затем открывает заказ в 1С, проверяет статус у транспортной компании, смотрит свободные слоты, пишет клиенту, получает подтверждение, переносит доставку и фиксирует изменение в CRM. Бот снял первую часть разговора, но основная работа осталась за человеком.

Как это обрабатывает агент

1. Определяет клиента по номеру телефона или e-mail, находит его активные заказы.
2. Проверяет статус заказа в 1С и статус отправления у транспортной компании.
3. Проверяет по правилам, можно ли перенести доставку: срок, тип доставки, регион.
4. Запрашивает свободные слоты на четверг и предлагает клиенту варианты.
5. После выбора клиента оформляет перенос, обновляет заказ и фиксирует изменение в CRM.
6. Если перенос невозможен или ситуация нестандартная — заказ уже отгружен, клиент недоволен, сумма выше порога — передаёт обращение оператору с подготовленной карточкой: что спросил клиент, что проверено, какие есть варианты.

Оператор подключается только к исключениям — и сразу видит всю картину, а не начинает разбор с нуля.

Экономика: где разница в деньгах

Модельный пример. Служба поддержки получает 2 000 обращений в месяц. Средняя обработка одного обращения оператором — 6 минут. Итого 200 часов в месяц. Стоимость часа оператора с налогами и накладными — 750 ₽, то есть 150 000 ₽ в месяц на обработку обращений.

Демонстрационный расчёт. Фактический эффект определяется после аудита процесса.

Дальше из этих сумм нужно вычесть стоимость владения, а затем сравнить со стоимостью внедрения: агент дороже в разработке, потому что требует интеграций с 1С, CRM и службой доставки, правил и пилота. Поэтому агент выигрывает не всегда. Если 80% обращений — справочные вопросы, хороший бот по базе знаний даст почти тот же эффект дешевле. Если значительная часть обращений требует действий в системах, бот упирается в потолок: он снимает разговор, но не работу.

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

Уровни полномочий агента

Главный вопрос, который задают руководители: «А если агент сделает что-то не то?». Ответ — в уровнях полномочий. Каждое действие агента относится к одному из трёх уровней.

Уровень определяется ценой ошибки, а не сложностью задачи. В финансах, юридических вопросах и HR финальное решение всегда остаётся за человеком: агент готовит, проверяет, подсвечивает риски, но не принимает решение сам.

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

Когда достаточно чат-бота

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

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

Когда нужен агент

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

Типичные процессы для агентов: приём заказов из почты и мессенджеров с созданием документов в 1С, обработка входящих счетов и УПД, диспетчерская обработка заявок на перевозку, первичная обработка лидов с квалификацией и заполнением CRM, сверка актов с контрагентами. Обратите внимание: в большинстве из них нет клиента в чате. Агенты чаще работают во внутренних процессах, чем на сайте.

Риски агентов и как их контролировать

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

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

Отдельный инструмент — «теневой режим» на пилоте. Первые 1–3 недели агент обрабатывает реальный поток, но ничего не меняет в системах: только записывает, что бы он сделал. Сотрудники работают как обычно, и результаты сравниваются. Так становится видна реальная точность до того, как агенту дают права на действия.

Как проходит пилот агента

Пилот агента длится 3–8 недель и состоит из трёх фаз.

1. Теневой режим, 1–3 недели. Агент обрабатывает реальный поток, но только записывает решения. Метрики: доля операций, которые агент обработал бы без эскалации, и доля совпадений с решениями сотрудников.
2. Режим подготовки, 1–3 недели. Агент готовит действия, сотрудник подтверждает их одним нажатием или исправляет. Метрики: доля подтверждённых без изменений, время сотрудника на операцию.
3. Рабочий режим для части операций, 1–2 недели. Действия с низкой ценой ошибки агент выполняет сам, остальные — по-прежнему с подтверждением. Метрики: часы ручной работы, точность по выборочной проверке, количество эскалаций.

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

Типичные ошибки при внедрении агентов

• Слишком широкая задача. «Агент, который ведёт клиента от заявки до оплаты» — это десятки процессов. Начинать стоит с одного узкого: «принять заказ из письма и создать его в 1С».
• Права «на всякий случай». Агенту дают полный доступ к CRM, потому что так проще настроить. Это создаёт риск без пользы. Права выдаются под конкретные действия процесса.
• Нет плана для исключений. Агент без понятной эскалации либо ошибается, либо останавливается. Сотрудник, который получает эскалации, должен быть назначен до запуска.
• Оценка по демонстрации. На десяти подобранных примерах агент работает идеально. На реальном потоке из тысячи операций появляются форматы и ситуации, которых на демонстрации не было. Поэтому решения принимаются по результатам теневого режима, а не презентации.
• Агент там, где хватило бы правила. Если процесс полностью описывается условием «если поле X равно Y, сделай Z», ему не нужна языковая модель — достаточно обычной автоматизации в 1С или CRM. ИИ нужен там, где вход неструктурирован: письма, документы, свободный текст.

Пять вопросов для выбора

1. Что происходит после того, как человек получил ответ? Если ничего — достаточно бота. Если серия действий — смотрите на агента.
2. Сколько раз в день выполняется процесс? При небольшом объёме сложная интеграция агента может не окупиться.
3. Можно ли описать правила и исключения? Если каждый случай уникален, агент будет постоянно эскалировать.
4. Какова цена ошибки? От неё зависит уровень полномочий и, соответственно, реальная экономия.
5. Есть ли интеграция с системами? Без доступа к 1С, CRM или почте агент не сможет выполнять действия.

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

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