Как создают ИИ‑агента для бизнеса: 6 этапов, сроки и результат

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

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

Разработка ИИ-агента — это на 70% не программирование. Это выбор процесса, сбор фактуры, описание границ, проверка качества и настройка работы людей вокруг нового инструмента.

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

С чего всё начинается: выбор процесса

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

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

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

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

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

Шесть этапов работы

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

По срокам важно не путать одиночного агента и мультиагентную систему. Одиночного агента для одного процесса можно развернуть за недели. Сложные системы, где несколько агентов распределяют между собой задачи, корректно проектируются месяцами. В инженерных рекомендациях Anthropic подчёркивается, что мультиагентные архитектуры требуют осторожности и могут расходовать примерно в 10–15 раз больше токенов: building effective agents. Поэтому усложнение архитектуры должно быть оправдано бизнес-задачей, а не желанием сделать «как у больших».

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

Что делает аналитик, а что — разработчик

У заказчика часто возникает честный вопрос: за что платить, если модель уже создана OpenAI, Anthropic или другим поставщиком? Ответ в том, что модель — только двигатель. Чтобы автомобиль ездил по маршруту компании, нужны дорога, правила, навигация, ограничения скорости, журнал поездок и человек, который понимает, куда вообще ехать.

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

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

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

Для объяснения ценности хорошо работает правило 10/20/70, которое часто используют в управленческом контексте BCG: 10% ценности дают алгоритмы, 20% — данные, 70% — изменение того, как работают люди вокруг технологии. Подрядчик может сделать агента, собрать данные и помочь встроить новый порядок, но не может полностью заменить управленческое решение внутри компании. Поэтому разработка ИИ-агента под ключ всегда требует участия заказчика, даже если техническая часть берётся на себя.

Что бизнес получает на выходе

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

1. Описание процесса и границ: что агент делает, чего не делает, когда передаёт вопрос человеку.
2. Настроенный агент на платформе СофтРестЧат с подключёнными каналами.
3. База знаний: собранная, структурированная, с указанием источников и владельца актуализации.
4. Инструкции и сценарии в читаемом виде, которые заказчик может править сам.
5. Список инструментов и интеграций с описанием прав доступа.
6. Тестовый набор: 30–100 случаев с ожидаемым поведением агента.
7. Логи и трассировка: видно, что агент отвечал, какие инструменты вызывал, с какими аргументами и что вернулось.
8. Доступы и инструкция по эксплуатации: как поменять текст, как отключить агента, что делать при сбое.
9. Метрики и способ их снятия: чтобы эффект можно было проверить не на ощущениях, а на данных.

Самый важный пункт в этом списке — тестовый набор. Он превращает разговор о качестве из субъективного «мне не нравится ответ» в проверяемую процедуру. Если в базе есть 50 типовых случаев и ожидаемое поведение для каждого, любое изменение инструкции, базы знаний или интеграции можно прогнать повторно. Это особенно важно после запуска, когда бизнес начинает добавлять новые сценарии и документы.

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

Сроки: от чего они зависят

Базовая вилка для одного агента — 3–8 недель. Но календарный срок почти всегда зависит не только от разработки. Иногда техническая сборка занимает меньше времени, чем ожидание доступов, выгрузки примеров или согласования формулировок между отделами.

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

Число интеграций — второй фактор. Каждая внешняя система означает отдельный контур доступов, прав и проверки. CRM, 1С, телефония, HelpDesk, почта, мессенджеры — всё это можно подключать, но каждая интеграция должна иметь понятный сценарий использования. Агенту не нужны все ключи от офиса, если его задача — только проверить статус заявки и создать задачу менеджеру.

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

Что нужно от заказчика

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

• Владелец процесса с правом принимать решения по сценариям и ограничениям.
• 30–50 реальных примеров: обращений, документов, заявок, диалогов или записей.
• Доступ к тестовому контуру систем, а не к боевому окружению на старте.
• Ответ на вопрос «что нельзя никогда»: какие обещания, действия и формулировки запрещены агенту.
• 2–4 часа в неделю на приёмку во время проекта.

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

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

Почему проекты проваливаются: три причины из статистики

Статистика по ИИ-проектам выглядит жёстко, но она полезна: показывает, что главные риски находятся не в способности моделей писать текст, а в управлении, данных и контроле. Gartner прогнозирует, что более 40% agentic AI-проектов будут отменены к концу 2027 года из-за растущих затрат, неясной бизнес-ценности или недостаточных механизмов контроля рисков: прогноз Gartner. Важно заметить: возможности моделей в этом списке причин не главные. Все три причины управленческие.

В обсуждениях часто цитируют исследование MIT за август 2025 года: 95% генеративных пилотов не дали измеримого влияния на прибыль. Эту цифру стоит читать с оговорками: под «провалом» понималось отсутствие измеримого эффекта за шесть месяцев, выборка была ограниченной и собранной в том числе на конференциях, а сами авторы называли оценки ориентировочными. Но практический вывод всё равно важен: по тем же данным покупка готовых решений давала успех в 67% случаев, а внутренняя разработка — примерно втрое реже. Для бизнеса это аргумент в пользу платформенного подхода и узких пилотов вместо долгой разработки с нуля.

McKinsey в опросе 1 719 респондентов, проведённом в мае–июне 2026 года, отмечала: 37% компаний относят на счёт ИИ хоть какое-то влияние на EBIT, а доля «высоких исполнителей» остаётся небольшой — около 6%. При этом среди крупных компаний с выручкой свыше 1 млрд долларов доля тех, кто масштабирует агентов хотя бы в одной функции, выросла с 27% до 40% за год. Рынок движется, но выигрывают не те, кто громче говорит об ИИ, а те, кто умеет встраивать его в процессы.

Опрос Salesforce среди 2 025 руководителей в мае 2026 года выделял похожие признаки успешных проектов: чистые управляемые данные, узкий охват агента и заранее описанные пути эскалации к человеку. Метрики там самооценочные, но направление совпадает с практикой: удавшиеся внедрения держатся на порядке работы. Три главные причины провалов лечатся не новой моделью, а дисциплиной: узким процессом, данными, тестами, ограничениями и понятной ответственностью.

Сколько это стоит

Стоимость разработки ИИ-агента зависит от контура задачи, количества интеграций, готовности данных и требований к безопасности. Но для одного ограниченного процесса можно использовать понятную рамку: внедрение под ключ — 30 000 ₽ за одного агента. В эту сумму входит 20 000 ₽ за работу и 10 000 ₽ за лицензию платформы СофтРестЧат. Отдельно оплачивается работа моделей по фактическому потреблению.

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

Для сравнения: на рынке простой бот может стоить 50–200 тыс. ₽, рабочий агент с интеграциями — 300 тыс. – 1,5 млн ₽, корпоративная мультиагентная система — от 3 млн ₽. Поддержка часто оценивается в 30–50% стоимости разработки в год. Эти цифры не означают, что каждому бизнесу нужен дорогой проект. Чаще наоборот: начинать лучше с узкого агента, который решает одну проверяемую задачу и даёт материал для следующего решения.

Что делать дальше

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

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

Короткая формула старта: выбрать один процесс, собрать 30–50 реальных примеров, описать запреты и критерии успеха, запустить пилот, измерить результат. Именно так разработка ИИ-агента превращается из эксперимента в управляемый бизнес-проект.

Автор Антон Амосов

Поделиться Скопировано!