Введение
Чат-бот отвечает на вопрос и на этом останавливается. Агент идёт дальше: открывает заказ, сверяет условия доставки, заводит карточку в CRM и, если что-то не сходится, передаёт дело живому сотруднику. На словах разница маленькая. На практике она большая, потому что теперь система сама совершает действия, а значит, за них нужно отвечать.
Ниже разобрано, что случилось в этом году, где агенты действительно окупаются и почему больше половины таких проектов, судя по прогнозам, не доживёт до конца 2027-го.
Что произошло этой осенью
В начале октября Fujitsu запустила пробную среду для четырёх ИИ-агентов, которые помогают магазинам. Старт назначен на 6 октября 2026 года. Демонстрационные эксперименты с семью розничными компаниями идут поэтапно, то есть это проверка на живых точках, а не массовый релиз.
С другой стороны прилавка картина похожая. Отчёт Adobe, о котором 3 октября 2026 года написала The New York Times, фиксирует рост трафика на американские розничные сайты из ИИ-источников на 393% за этот год. Morgan Stanley прогнозирует, что к 2030 году траты, на которые влияют агенты, могут занять до 20% американской электронной коммерции, около 385 миллиардов долларов. Это прогноз, и относиться к нему стоит именно так. Но каталог магазина уже сейчас читает не только человек: его разбирает программа, которая сравнивает товары для покупателя.
Есть и вторая цифра, которую полезно помнить. Gartner, по данным Voiceflow от 17 сентября 2026 года, ожидает, что более 40% проектов с агентным ИИ будут остановлены до конца 2027 года. Причины там называют деньги, неясную пользу и слабый контроль рисков, а технология в этом списке стоит не первой. Часть продуктов, которые продаются как агенты, по факту остаётся чат-ботами или RPA с новой этикеткой.
Что такое агент, если убрать маркетинг
Модель получает задачу, выбирает инструмент, вызывает его, смотрит на ответ и решает, что делать дальше. Инструментов может быть сколько угодно: поиск по базе знаний, карточка клиента, выставление счёта, письмо, смена статуса заказа.
Для бизнеса у такой схемы есть три обязательных части. Первая — доступ к данным. Без него агент отвечает уверенно и пусто. Вторая — список разрешённых действий, и каждое действие имеет границы. Третья — журнал решений и понятный путь к человеку. Если выбросить любую из трёх, получится собеседник, который приятно говорит и ничего не делает.
Подробные разборы сценариев продаж и поддержки собраны в категории ИИ-агенты. Там же видно, чем агент отличается от обычного ассистента и по каким признакам оценивать качество.
Где агенты окупаются
Агенту нужна работа, которая повторяется, опирается на понятные правила и лежит в нескольких системах сразу. Ниже типичные места, где это встречается.
- Первичная обработка заявок. Агент определяет тип обращения, находит клиента в CRM, создаёт задачу менеджеру и предлагает удобное время для звонка.
- Поддержка. Ответ по базе знаний, проверка статуса заказа, передача спорного случая оператору вместе с короткой сводкой, чтобы тот не переспрашивал клиента.
- Документы. Из счёта извлекаются реквизиты, сверяются с договором, расхождения помечаются. Подписывает всё человек.
- Отчётность. Данные собираются из трёх-четырёх систем, сводятся в одну таблицу и уходят ответственному в назначенное время.
Ценность тут не в замене людей. Она в том, что сотрудник перестаёт переключаться между вкладками и искать, где лежит нужная цифра. Остаётся работа, которая требует суждения.
Какой процесс брать первым
Подходящий процесс обычно отвечает четырём условиям. Он повторяется ежедневно или хотя бы еженедельно. Решение по нему можно записать без долгих споров. Входные данные уже в цифровом виде. И ошибка обходится дешевле, чем ручная обработка того же объёма.
Самая частая ошибка — начинать сразу с «всей поддержки» или с «агента, который знает о компании всё». Такой проект растягивается на месяцы и заканчивается тем, что никто не понимает, работает он или нет. Удобнее взять два-три самых частых типа обращений, передавать остальное человеку и посмотреть на результат через несколько недель.
Кому это подходит и в каком виде
Интернет-магазин может поручить агенту вопросы о наличии, сроках доставки и возвратах. Для него важна связка с системой заказов, а не красивые формулировки ответа.
Компания с долгим циклом продаж использует агента, чтобы квалифицировать входящие лиды, подготовить первое письмо и не потерять напоминание о следующем шаге. Здесь решающая часть — качество карточек в CRM.
Сервисная компания принимает заявку, уточняет параметры объекта и формирует карточку для выездного мастера. Ошибка в адресе или в типе оборудования обходится дорого, поэтому проверка обязательна.
Бухгалтерия и юристы выигрывают от извлечения данных из документов. Решение о проведении остаётся за человеком, и так и должно быть.
Для малого бизнеса обычно хватает одного агента с одним-двумя подключениями. Крупной компании нужна общая схема: несколько агентов, единые правила доступа и один журнал на всех.
Как запускать пилот
Сначала нужно понять, с чем работаем сейчас. Сколько обращений приходит в день, сколько минут уходит на каждое, какая доля закрывается без участия человека и на каких ошибках чаще всего спотыкаются сотрудники. Без этих цифр потом не с чем сравнивать.
Второй шаг — собрать минимальный набор данных. Для поддержки это база знаний и история обращений. Для продаж — карточки клиентов, стадии сделок и шаблоны писем. Чистить всё до идеала не нужно, но нужно знать, где что лежит и кто отвечает за актуальность.
Третий шаг — договориться о границах. Агенту разумно разрешить читать данные и готовить черновики. Деньги, договоры, персональные данные и всё, что создаёт юридические последствия, на первом этапе остаётся за человеком.
Дальше собирается прототип и проверяется на реальных обращениях, которые уже обработали сотрудники. Сравнивать с демонстрацией на удачных примерах бессмысленно: удачные примеры есть у любого.
Пилот запускают на части трафика, с журналом и понятным способом передать диалог человеку. Расширять его стоит после того, как метрики стабильны несколько недель подряд, а не после одного хорошего дня.
Данные и инфраструктура
Агенту нужны три вида данных: справочная информация о компании, оперативные данные по клиентам и заказам, история прошлых решений. Справочная информация обычно разбросана по документам и почте, поэтому её приходится собирать заново и приводить к виду, который можно искать. Оперативные данные живут в CRM, ERP или во внутренней базе. Агенту к ним нужен доступ через API или сервисный слой, который ограничивает, что именно можно читать и менять.
Выбор инфраструктуры зависит от задачи. Для пилота обычно хватает облачной модели через API, сервера, на котором крутится оркестрация, и базы для журнала. Если персональные данные нельзя отправлять внешним сервисам, появляется вариант с локальной или self-hosted моделью. Он требует более мощного железа и людей, которые эксплуатируют его всерьёз. Решать это стоит по требованиям к конфиденциальности, а не по тому, что модно в этом квартале.
Логи вызовов инструментов, версии промптов и тестовый набор обращений лучше завести с первого дня. Иначе в момент ошибки никто не сможет ответить, почему агент так поступил, и обновлять его станет страшно.
Сколько это может стоить и принести
Считать эффект можно по простой схеме. Берём число обращений в месяц, минуты на одно обращение, стоимость часа сотрудника. Умножаем на долю обращений, которые агент закрывает сам. Из полученной экономии вычитаем стоимость модели, инфраструктуры и работу тех, кто проверяет ответы.
Точной цифры без данных компании не будет, и любой, кто её называет без них, рисует. Поэтому смысл пилота в том, чтобы заменить оценку фактом на одном процессе, а уже потом решать про масштаб.
Есть и обратная сторона. Если модель дешевле сотрудника, но каждый пятый ответ приходится переделывать, экономия уходит в ноль, а клиенты, которые получили неверный ответ, могут уйти совсем. Цену ошибки считают вместе с ценой работы.
Где агенты ошибаются
Главная опасность — уверенная ошибка. Агент может выдать неверный факт ровным тоном и с аккуратным объяснением, и читатель не почувствует подвоха. Для клиентских ответов нужно ограничивать источники, проверять факты по базе и предусмотреть, как диалог уходит к человеку.
Вторая опасность — лишние права. Агент, которому можно писать во все системы, становится уязвимым. Достаточно неудачного запроса или ошибочного вызова инструмента, чтобы поменять данные, которые менять нельзя. Права выдают минимальные и расширяют по мере необходимости.
Третья опасность — устаревание. Цены меняются, регламенты переписываются, а агент продолжает уверенно цитировать старую редакцию. Базу знаний и тестовые сценарии нужно пересматривать по расписанию, а не когда что-то сломалось.
Четвёртая — зависимость от поставщика. Модели меняются быстро. Архитектура должна позволять заменить одну модель другой, не переписывая всю систему.
И ещё честно про границы. Агенты плохо работают с неполными данными, с задачами, где нужна личная ответственность, и с процессами, которые существуют только в головах сотрудников. Такие процессы сначала придётся описать на бумаге.
Безопасность и персональные данные
Агент работает с людьми, поэтому вопросы безопасности решаются до запуска, а не после первой утечки. Нужно понимать, какие данные уходят в модель, где они обрабатываются, как долго хранятся и кто видит журналы. Для обработки персональных данных нужна правовая основа, а иногда и отдельное согласие пользователя.
Технически важны несколько вещей. Разделение доступа по ролям. Маскирование полей, которые не нужны для ответа: номер карты, паспорт, полный адрес. Защита от инъекций: текст из письма клиента может содержать команду для агента, и её нельзя выполнять без проверки. Журнал, по которому можно восстановить всю цепочку решений.
Если компания работает с закрытыми данными, полезно заранее записать, какие сценарии допустимы в облаке, а какие обрабатываются только внутри. Тогда спор о сервере не возникает посреди проекта.
Чем агент отличается от альтернатив
Классическая автоматизация на правилах и RPA остаётся лучшим выбором, когда процесс стабилен и описан до последнего шага. Она предсказуема, её проще проверять, и эксплуатация недорогая. Слабое место — текст, который нельзя разложить по полям, и нестандартные обращения.
Чат-бот на языковой модели без инструментов дешевле и запускается быстрее. Но он не может ничего сделать с заказом или CRM, поэтому годится для справочных вопросов и не годится для операций.
Ручная работа с подсказками модели безопасна и не даёт масштаба. Удобный вариант — гибрид. Правила закрывают типовые случаи, агент разбирает всё, что не разложилось по правилам, а человек принимает решения с последствиями.
Перед выбором стоит честно спросить себя, не решается ли задача обычным скриптом или правилом. Если да, агент не нужен. Связанные материалы про выбор первого процесса, пилот и расходы есть в категории Автоматизация бизнеса.
Как не превратить пилот в демо
Агент начинает работать, когда он встроен в процесс компании. Для этого нужны конкретный владелец процесса, список метрик, которые он отслеживает, регламент обновления базы знаний и понятная процедура передачи человеку.
Полезно заранее записать условие остановки. Например: если доля ошибок в проверочной выборке выше согласованного порога, агент переходит в режим подсказок для оператора и перестаёт отвечать клиенту сам. Такое правило снимает спор, когда ошибка уже случилась.
Подробнее про этапы, бюджет и типичные риски внедрения ИИ в компании можно прочитать в категории Внедрение ИИ. Там же собраны вопросы, которые стоит задать подрядчику до подписания договора.
Что делать дальше
ИИ-агенты уже не эксперимент для энтузиастов. Но и купить готового агента, поставить его и забыть не получится: за ним нужны архитектура, права, журнал и регулярная проверка.
Если хотите проверить, подходит ли агент вашему бизнесу, начните с малого. Возьмите три самых частых обращения или операции за последний месяц, выпишите, сколько минут уходит на каждое, и отметьте, какая доля решается без человека. Этих цифр достаточно, чтобы понять, стоит ли пилот и какой процесс брать первым.
