Создание ИИ-агента: путь от задачи до работающего агента

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

ИИ-агент — это модель, которой дали инструменты, знания и правила

ИИ-агент — это программа на основе языковой модели, которая получает задачу, сама решает, какие шаги для неё нужны, выполняет их через подключённые системы и возвращает результат или передаёт работу человеку. Ключевое слово здесь — «выполняет». Нейросеть в чате отвечает на вопрос и останавливается. Агент может найти заказ в учётной системе, проверить правило в регламенте, заполнить карточку в CRM, поставить задачу менеджеру и только потом написать клиенту ответ.

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

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

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

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

1. Задача и метрика. Одна операция, которую агент будет выполнять, и три цифры, снятые до начала работ. Этому посвящены два следующих раздела, потому что именно здесь решается, окупится ли всё остальное.

2. Задание на агента. Описание поведения, а не список функций: цель в деньгах, границы, примеры правильных ответов, критерий приёмки, одинаково понятный обеим сторонам. Как его составить, подробно — в статье «Как написать ТЗ на AI-агента».

3. Знания и доступы. Документы, на которые агент опирается, и системы, к которым ему дают доступ. Что класть в базу знаний и чего класть нельзя, разобрано в материале «База знаний для AI-агента»; если агентов несколько и знания нужны общие — в статье о базе знаний компании для ИИ.

4. Сборка. Модель, инструменты, память, правила и порядок передачи человеку. Это техническая часть, и ниже я разбираю её простыми словами, без кода.

5. Проверка до запуска. Прогон агента на наборе реальных обращений, причём проверяет не тот, кто настраивал. Методика — в статье «Тестирование ИИ-агента перед запуском».

6. Пилот и наблюдение. Живой поток на ограниченном участке, сплошное чтение диалогов в первые недели, сравнение метрики с цифрами «до». Что смотреть и где агент ломается тихо, описано в материале «Мониторинг ИИ-агента после запуска: что смотреть, чтобы поймать тихий сбой».

7. Расширение. Новые темы, каналы и часы работы добавляются по одному, каждый раз как маленький пилот. Подробно — в статье «Как масштабировать агента после пилота».

Шаги 2, 3, 5, 6 и 7 у нас разобраны отдельно, поэтому здесь я на них не останавливаюсь. Дальше — то, что между ними: какую задачу брать первой, как считать эффект, из чего агент состоит, каким способом его собирать, что готовит сама компания, сколько это занимает и где проекты чаще всего спотыкаются.

Первая работа для агента: как отличить хорошую задачу от красивой

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

Задача подходит агенту, если у неё пять признаков.

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

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

Отдельный вопрос — какой процесс в компании вообще брать под ИИ первым, если кандидатов несколько. Он не про агентов, а про внедрение в целом, и подробно разобран в статье «Внедрение ИИ в процессы: с какого начинать и какой отложить». Для агента к тем критериям добавляется один: у задачи должен быть понятный момент, когда работа закончена. «Заявка разобрана и задача поставлена» — есть. «Клиент доволен» — нет.

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

Показатель, который агент должен сдвинуть, снимают до сборки

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

Главная метрика — в деньгах или во времени. Доля заявок, на которые ответили в первые пятнадцать минут; часы сотрудников на операцию в неделю; доля обращений, закрытых без участия человека; доля лидов, дошедших до встречи. Одна цифра, привязанная к деньгам бизнеса, а не к работе агента.

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

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

Снимают эти цифры вручную, за одну-две недели, на текущем процессе. Этого достаточно, чтобы потом сравнивать не с воспоминаниями, а с замером. Там же записывают условие остановки: при каком результате пилота проект сворачивают. Звучит пессимистично, но именно это условие делает пилот честным — у него появляется право провалиться.

Пример расчёта: в поддержку приходит 1 200 обращений в месяц, на каждое сотрудник тратит в среднем 7 минут — это 140 часов. Допустим, агент закрывает сам 40% обращений (480), а на остальные 720 готовит черновик, и сотрудник тратит на них 3 минуты вместо 7. Экономия — 56 часов на закрытых агентом и 48 часов на черновиках, минус несколько часов на выборочное чтение. Примерно сто часов в месяц. Умножьте на стоимость часа сотрудника с налогами — получится потолок того, что агент может вернуть. Если создание и содержание агента на горизонте года стоят больше, проект не окупится, как бы хорошо агент ни отвечал. Как считать эффект строже, с контрольной группой, — в статье «Как измерить эффект от внедрения AI».

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

Пять деталей, из которых собран любой агент

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

Модель — решает, что делать

Языковая модель читает входящее, понимает смысл и выбирает следующий шаг. Это самая обсуждаемая деталь и при этом самая заменяемая. Модели выходят каждые несколько месяцев, и хорошо собранный агент переезжает на новую без переписывания всего остального. Выбор модели определяют требования к данным (можно ли отправлять их в зарубежный облачный сервис), стоимость и качество на ваших задачах. Как выбирать между российскими моделями, разобрано в статье «Российские LLM: GigaChat, YandexGPT или своя», а между облаком и моделью на своём сервере — в материале «Открытая модель или облачный API».

Одна модель на всё — не обязательное условие. В опубликованном кейсе «Заря» на каждое сообщение покупателя работает связка из шести моделей: одна пишет черновик ответа, вторая проверяет его по 11 правилам редактуры, третья раскладывает диалог на 16 полей карточки клиента, четвёртая сжимает разговор в резюме, пятая расшифровывает голосовые, шестая описывает фото. Сильная модель там отвечает только за черновик, а на вспомогательных ролях экономят. Это нормальная инженерная логика: деньги тратят там, где ошибка видна клиенту.

Инструменты — то, чем агент действует

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

Главное правило здесь — минимальные права. Чтение и запись — разные инструменты. Действия, которые нельзя отменить (списать деньги, отправить договор, удалить запись), идут через подтверждение человека. Почему это не перестраховка, а нормальная архитектура, объясняет статья «Human-in-the-loop: почему ИИ не решает сам». На практике именно инструменты и интеграции съедают большую часть работы: модель подключается за день, а аккуратный доступ к трём системам заказчика — за недели.

Память — что агент помнит о разговоре и клиенте

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

У памяти две обратные стороны. Первая — это персональные данные, и храниться они должны так же аккуратно, как в CRM. Вторая — память может закрепить ошибку: неверно записанный факт агент будет повторять уверенно и долго. Как устроено обучение агента на диалогах и как его безопасно разучивать, разобрано в материале «Как ИИ-агент учится на диалогах компании».

База знаний — откуда берутся факты

Модель ничего не знает о вашей компании: ни цен, ни условий доставки, ни того, чем тариф «Стандарт» отличается от «Про». Всё фактическое агент берёт из базы знаний. Устроено это обычно так: документы режут на фрагменты, при каждом вопросе агент ищет самые подходящие фрагменты и отвечает, опираясь на них. В технических текстах это называют RAG — генерация с поиском по источникам. Для заказчика важно одно: агент отвечает не «по памяти модели», а по вашим документам, и качество ответов ограничено качеством этих документов.

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

Правила и передача человеку — где агент останавливается

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

Передача человеку — отдельная часть правил, и её проектируют так же тщательно, как ответы. Поводы (агент не уверен, клиент злится, вопрос вне компетенции, нужна подпись), что передаётся вместе с разговором, куда уходит обращение ночью — всё это решается до запуска. Разбор этих решений — в статье «Эскалация на оператора: когда AI зовёт человека». Когда задач у агента становится несколько, правила удобно раскладывать по навыкам — отдельным сценариям со своим условием включения; как это устроено, описано в материале «Библиотека навыков».

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

Один запрос под капотом: что агент делает между вопросом и ответом

Чтобы пять деталей не остались абстракцией, посмотрим, как они работают на одном обращении. Возьмём типичное сообщение в поддержку интернет-магазина: «Где мой заказ 4812? И хочу вернуть одну позицию из него».

Шаг первый — контекст. Агент получает сообщение вместе с историей переписки и карточкой клиента из памяти. Он видит, что клиент писал неделю назад о сроках доставки и что заказ оформлен на его телефон.

Шаг второй — план. Модель понимает, что в сообщении два вопроса: статус и возврат. Она решает начать со статуса, потому что от него зависит второй ответ: вернуть можно только полученный заказ.

Шаг третий — инструмент. Агент вызывает «статус заказа» с номером 4812. Учётная система отвечает: доставлен три дня назад, в заказе три позиции.

Шаг четвёртый — знания. Агент ищет в базе знаний правила возврата магазина и находит фрагмент: возврат в течение 14 дней, товар без следов использования, для отдельных категорий — ограничения.

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

Шаг шестой — действие в пределах прав. Агент создаёт заявку на возврат — это действие обратимо, и оно ему разрешено. Возврат денег он не проводит: это необратимое действие, и по правилам его подтверждает сотрудник. Клиенту уходит ответ со статусом, условиями и следующим шагом.

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

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

Конструктор, готовый продукт или агент под заказ: на чём создавать ИИ-агента

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

Конструктор без кода. Визуальный сборщик — такие сервисы для создания ИИ-агентов ещё называют платформами: блоки «получить сообщение», «спросить модель», «вызвать сервис» соединяются стрелками. Из известных примеров — сценарии с ИИ-агентом в n8n или сборка агента в Yandex AI Studio. Плюсы — быстрый старт, небольшие деньги на входе, собрать первую версию может сам сотрудник-энтузиаст. Минусы проявляются позже: подключения ограничены каталогом конструктора, сложная логика превращается в клубок блоков, который через месяц никто не понимает, а данные хранятся там, где решил сервис, и это вопрос к 152-ФЗ. Конструктор хорош, чтобы за неделю проверить гипотезу на простой задаче, и плох как основа для процесса, от которого зависят деньги.

Готовый продукт под класс задач. Агент, у которого сценарии, инструменты и интеграции для определённой работы — поддержки, продаж, внутренних задач компании — уже собраны и проверены на других проектах. Плюсы — короче срок, понятнее стоимость, продукт поддерживают и развивают без вас. Минус — он работает в рамках своего класса задач, и под совсем нестандартный процесс придётся либо подстраиваться, либо дописывать. У 404ai так устроена Везория: двенадцать ИИ-агентов с координатором работают по общей базе знаний компании, мы внедряем их под задачу, и первые задачи агенты берут в работу от недели после сбора базы знаний.

Агент под заказ. Архитектуру, модели и интеграции проектируют под ваш процесс. Плюсы — любая логика, любые системы, данные там, где требует служба безопасности, включая модель на своих серверах. Минусы — дольше и дороже на старте, и нужен кто-то, кто будет поддерживать агента после запуска: менять правила, обновлять знания, чинить интеграции, когда поменяется API соседней системы. Кто и как это делает, разобрано в статье «Кто поддерживает AI после внедрения». Под такие задачи у нас есть разработка под задачу — с прототипом на данных заказчика за 2–6 недель.

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

Как проверить подрядчика до договора, какие вопросы задать и что должно насторожить на переговорах, описано в статье «Как выбрать подрядчика по внедрению AI».

Что нужно для создания ИИ-агента со стороны компании: данные, владелец, доступы и 152-ФЗ

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

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

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

Доступы. Служебная учётная запись в CRM и других системах с минимальными правами, ключи программного интерфейса, тестовая среда, если она есть. Доступы выдаёт ИТ или служба безопасности, и на это уходит больше времени, чем кажется, поэтому просить их лучше в первый же день. Как договориться с ИТ-отделом, чтобы внедрение не стояло в очереди, — в статье «Как договориться с ИТ-отделом о внедрении AI».

Персональные данные и 152-ФЗ. Если агент видит имена, телефоны, переписку клиентов или сотрудников, компания обрабатывает персональные данные, и на агента распространяются те же требования, что и на CRM. Практический вопрос здесь один: где работает модель и где хранятся данные. Передача персональных данных в зарубежный облачный сервис — это трансграничная передача, о которой оператор по 152-ФЗ заранее уведомляет Роскомнадзор, а для части данных она вовсе нежелательна. Варианты решения известны: российская облачная модель, модель на своём сервере или маскирование персональных данных до того, как текст уйдёт в модель. Выбирать между ними стоит до сборки, а не после первого вопроса службы безопасности. Правила работы сотрудников с ИИ полезно записать отдельно; что в них включить, описано в статье «Регламент работы с ИИ».

И пятое, о чём часто забывают: люди, чья работа меняется. Если сотрудники узнают об агенте из жалоб клиентов, они будут искать в нём ошибки, а не помогать их исправлять. Рассказать заранее, что агент берёт на себя и что остаётся людям, стоит дешевле, чем потом разбираться с саботажем; подробнее — в материале «Внедрили AI, а сотрудники им не пользуются».

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

Честный срок создания ИИ-агента до разбора задачи не назовёт никто, и это не уловка. Техническая сборка предсказуема, а вот подготовка знаний и доступов зависит от компании: у одной регламенты написаны и актуальны, у другой живут в головах трёх сотрудников, один из которых в отпуске. Общая логика сроков внедрения разобрана в статье «Сроки внедрения AI: от чего они зависят»; для агента ориентиры такие.

• Задача, метрика, задание — обычно дни, если владелец процесса доступен.
• Знания и доступы — самая непредсказуемая часть: от нескольких дней до нескольких недель, почти целиком на стороне компании.
• Сборка — зависит в первую очередь от числа интеграций, а не от сложности диалога. Каждая новая система — отдельная работа.
• Проверка до запуска — неделя-две, включая исправление найденного.
• Пилот — столько, сколько нужно, чтобы набрать поток для решения по метрике. В кейсе «Заря» пилот длился шесть недель: с 8 июля по 18 августа 2026 года бот обработал 576 сообщений.

Со сметой похожая история. Цифры по рынку разбросаны в разы, и сравнивать их без состава работ бессмысленно; общая картина — в статье «Стоимость внедрения ИИ: из чего складывается цена». Для агента смета складывается из шести частей, и полезно видеть каждую отдельно.

1. Подготовка: разбор задачи, задание, база знаний, проверочный набор.
2. Интеграции: каждая подключаемая система считается отдельно.
3. Сборка и проверка: правила, инструменты, прогоны и исправления.
4. Расход модели: модели платят за объём обработанного текста. В многошаговом агенте на одно обращение приходится несколько вызовов модели, и расход растёт с длиной истории и числом шагов. Считать его удобно в рублях на одно закрытое обращение.
5. Сопровождение: разбор диалогов, обновление знаний, правки правил, реакция на изменения в соседних системах. Это ежемесячная статья, а не разовая.
6. Время ваших людей: владелец процесса, ИТ, сотрудники на пилоте. Эту часть не видно в счёте подрядчика, но она реальна.

Отдельно о запросе «создать ИИ-агента бесплатно». Бесплатно можно собрать прототип: у многих конструкторов есть бесплатный тариф, у моделей — пробный лимит. Этого хватает, чтобы за выходные проверить идею на десятке своих вопросов. Рабочий агент бесплатным не бывает: платить придётся как минимум за расход модели и за время человека, который читает диалоги и обновляет знания. Бесплатный прототип полезен как раз тем, что быстро показывает, стоит ли платить за остальное.

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

Ошибки, из-за которых агент не доживает до второго месяца

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

• Начали с выбора модели. Неделя уходит на сравнение нейросетей, а задача так и не сформулирована. Модель выбирается под задачу и данные, а не наоборот.
• Агент «на всё». Универсальный помощник, который должен и отвечать клиентам, и писать отчёты, и помогать юристу. Каждая задача у него получается наполовину, а проверить ни одну невозможно.
• Проверка на придуманных вопросах. Набор теста составил тот же человек, который настраивал агента, и из головы. На живом потоке агента встречают другие формулировки, и доверие теряется в первую неделю.
• У знаний нет хозяина. В день запуска база знаний верна, через месяц поменялись цены и условия, а обновить её некому. Агент продолжает уверенно называть старые цифры.
• Широкие права с первого дня. Агенту дали запись во все системы «чтобы не возиться». Первая же ошибка превращается из неточного ответа в испорченные данные.
• Нет журнала шагов. Агент ошибся, а понять, почему, нельзя. Правят наугад, и исправление одного ломает другое.
• Метрика без качества. Гонятся за долей обращений, закрытых без человека, и агент «учится» не отдавать сложное оператору. Цифра растёт, клиенты уходят.
• Тихий запуск. Сотрудники узнают об агенте постфактум и воспринимают его как угрозу, а не как помощь.

Общая черта у всех восьми ошибок одна: их дешевле предотвратить на бумаге до сборки, чем исправлять в работающем агенте. Шире — про ошибки внедрения ИИ в продажах — написано в статье «Ошибки внедрения AI в продажах».

Когда агент не нужен: таблица, скрипт или человек справятся дешевле

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

• Задача редкая. Если операция случается несколько раз в месяц, подготовка агента не окупится. Хорошая инструкция для сотрудника дешевле.
• Процесс жёсткий, формат не меняется. Перенести данные из одной системы в другую, собрать отчёт по одним и тем же полям — это работа для обычной интеграции или робота, который повторяет действия. Понимание смысла там не нужно, а нестабильность модели — лишняя. Как решать, где нужен агент, а где хватит роботизации, разобрано в статье «AI-агенты и RPA: что выбрать под процесс».
• Все ответы помещаются в меню. Если клиенты спрашивают пять типовых вещей, бот на кнопках справится надёжнее и дешевле.
• Процесса нет. Правила живут в головах, и каждый сотрудник делает по-своему. Агент в такой ситуации автоматизирует беспорядок. Сначала процесс описывают, потом автоматизируют.
• Ошибка дорогая и необратимая, а проверить её некому. Если цена одного неверного действия огромна и поставить человека на подтверждение нельзя, агент здесь рано.
• Результат нечем измерить. Нет данных «до» и нет способа снять их — значит, через три месяца никто не сможет сказать, работает ли агент.

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

С чего начать на этой неделе: три страницы вместо презентации

Первые шаги к агенту не требуют ни подрядчика, ни бюджета. Хватит трёх документов на одну страницу каждый.

Первая страница — задача в одну строку. Глагол, объект, результат и кто проверяет. Плюс список того, что агенту делать запрещено.

Вторая страница — три цифры «до». Главная метрика, метрика качества и то, что не должно ухудшиться. Снятые на текущем процессе за одну-две недели, с условием остановки пилота.

Третья страница — выгрузка примеров. Пятьдесят-сто реальных обращений или документов за последние месяцы с тем, как на них отреагировали. Без персональных данных, если выгрузка уходит наружу.

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

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