Как создать ИИ-агента для бизнеса: 4 пути и во что упирается каждый

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

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

Что такое ИИ-агент и чем он отличается от чат-бота?

Коротко: агент имеет инструменты и меняет состояние внешних систем, бот — разговаривает по сценарию.

Формулировка Anthropic разводит два понятия прямо:

«Workflows are systems where LLMs and tools are orchestrated through predefined code paths. Agents are systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks» — инженерный блог Anthropic.

То есть в сценарии («workflow») маршрут задан кодом заранее, а агент выбирает маршрут сам. У OpenAI определение практичнее: агенты — это «приложения, которые планируют, вызывают инструменты, передают работу узким помощникам и удерживают достаточно состояния, чтобы завершить многошаговую работу» (руководство по агентам).

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

Зачем бизнесу свой агент, если есть готовые ассистенты?

Коротко: готовый ассистент помогает сотруднику, свой агент работает внутри вашего процесса и с вашими данными.

Спрос в России уже не гипотетический. По исследованию «СберАналитики» и «Сбер Бизнес Софт», опубликованному 22 января 2026 года (опрос ноября 2025-го, 559 респондентов), инструменты автоматизации распределились так:

Чаще всего автоматизируют документооборот и обработку заявок (70%), бухгалтерию и финансовый учёт (55%), HR-процессы и стратегическое планирование (по 34%), поддержку клиентов (30%).

«Автоматизация перестала быть прерогативой крупных игроков и столичных регионов» — Анатолий Попов, зампредседателя правления Сбербанка, ComNews.

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

Какие есть четыре пути создать ИИ-агента?

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

Читать таблицу сверху вниз бесполезно. Отталкиваться нужно от задачи, и Anthropic формулирует это жёстко:

«Success in the LLM space isn't about building the most sophisticated system. It's about building the right system for your needs» — Building effective agents.

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

Путь 1: конструктор без кода

Коротко: лучший способ за неделю понять, полезна ли идея, и худший — строить на нём рабочий контур.

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

Потолок обнаруживается на трёх вопросах, и всегда в одном и том же порядке:

1. Есть ли в списке интеграций ваша учётная система? 1С в типовой конфигурации, самописная база, отраслевой софт — этого в готовых списках чаще нет.
2. Как ограничить, что агент может делать? В конструкторах права обычно грубые: доступ есть или его нет.
3. Где физически лежат данные разговоров? Для персональных данных здесь начинается требование закона — разбор в статье про нейросети без утечки данных и 152-ФЗ.

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

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

Путь 2: платформа облачного вендора

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

Крупные облака собрали агентные платформы, где готовы кирпичи — оркестрация, память, инструменты, журналирование вызовов. Управляемые сервисы снимают заметную часть инфраструктурной работы: например, 21 августа 2026 года AWS вывел поиск по вебу в Amazon Bedrock AgentCore в общую доступность — агент получает живые данные с цитированием, не выходя за пределы аккаунта клиента. Google Cloud свёл свои агентные продукты в единую корпоративную платформу.

Что вы получаете: скорость, journaling из коробки, масштабирование без своей команды эксплуатации.

Что вы принимаете вместе с этим:

• Привязку к вендору. Логика агента ложится на его примитивы, переезд стоит переписывания.
• Стоимость на объёме. Она линейна по обращениям и на росте перестаёт быть незаметной.
• Юрисдикцию данных. Для российской компании это первый вопрос, а не третий: где обрабатываются персональные данные и что написано в договоре.

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

Путь 3: свой фреймворк силами штатных разработчиков

Коротко: даёт максимум контроля и требует людей, которых на рынке мало.

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

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

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

Путь 4: заказная разработка под процесс

Коротко: имеет смысл, когда агент должен жить внутри вашего контура и работать с вашими данными, а не рядом с ними.

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

Как это выглядит на практике, видно на двух наших кейсах.

У застройщика (кейс) поток входящих состоял из людей, которые хотят «сначала разобраться», и менеджеры тонули в первичных обращениях. Бот ведёт первую линию — объясняет, отвечает, прогревает, — а квалифицированные обращения автоматически попадают в CRM, где сделку уже ведёт человек. Метрика простая: первую линию закрывает бот, менеджеры работают только с тёплыми.

В сети сервисных филиалов (кейс) AI-администратор в Telegram и WhatsApp записывает и переносит визиты круглосуточно, а умное расписание исключает двойные записи. Здесь агент уже пишет в рабочий контур, и вопрос прав доступа перестаёт быть теоретическим.

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

С чего начать: шесть шагов до первого рабочего агента

Коротко: начинайте с процесса и владельца, а не с выбора модели.

1. Выберите одну задачу. Повторяющаяся, с понятным результатом и измеримым объёмом: «первая линия входящих», «запись на визит», «разбор входящих накладных». Задача вида «внедрить ИИ» не является задачей.
2. Опишите, как её делает человек. По шагам, включая исключения: что он смотрит, куда записывает, когда зовёт коллегу. Это будущее техническое задание и одновременно ответ на вопрос, где агенту понадобятся права.
3. Назначьте владельца. Живого сотрудника, который отвечает за результат агента и разбирает его ошибки. Без этого пункта проект возвращается через полгода в виде инцидента.
4. Соберите прототип за неделю. На конструкторе, без интеграций, на выгрузке данных. Цель — проверить, что польза считается, а не что технология работает.
5. Задайте критерии приёмки заранее. Какую долю обращений агент закрывает сам, что считается ошибкой, при каком сигнале он передаёт человеку. Без описанного ожидаемого поведения невозможно собрать тесты — и это одна из типовых причин, по которым проекты застревают в пилоте.
6. Только теперь выбирайте путь из четырёх. С прототипом, метрикой и списком нужных интеграций разговор с подрядчиком или своей командой становится предметным.

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

Как агента подключают к 1С, CRM и остальным системам?

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

Агенту нужны инструменты — то есть способы прочитать и записать данные там, где они живут. Здесь появляется стандарт, который за последние два года стал общим языком: MCP (Model Context Protocol), открытый протокол Anthropic, представленный в ноябре 2024 года. Его описывают как универсальный переходник наподобие USB-C: вместо самописной интеграции под каждую пару «модель — сервис» одна общая спецификация (анонс Anthropic).

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

Как это выглядит, когда сделано, видно на оптовом кейсе: двусторонняя интеграция с 1С, где номенклатура, остатки, отгрузки и оплаты синхронизируются сами, а заказ сразу видит реальные остатки и ставит резерв. Агенту есть чем оперировать именно потому, что этот контур существует. Подробнее про сам слой связок — в разборе как связать 1С, CRM, банк и Telegram в один контур.

Что ломается при переходе от демо к продакшену?

Коротко: демо проверяет идею на чистых данных, продакшен — на грязных, на правах доступа и на счёте за месяц.

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

• Данные оказываются несвежими. Хранилище обновляется по расписанию, агент отвечает по прошлому дню.
• Legacy-системы не отдают данные сами. Требуется интеграционный слой, которого в смете демо не было.
• Модель начинает решать вопросы доступа. Клиент запрашивает чужие сведения, и агент либо выполняет запрос, либо ошибается. Оба исхода плохие.
• Появляется риск цепочки поставок. Компрометация зависимости заносит чужой код внутрь контура.
• Нет сценариев и метрик. Без описанного поведения нельзя собрать тесты и критерии приёмки.
• Не хватает людей. Инженеров эксплуатации языковых моделей в России мало.

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

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

Какие права давать агенту, чтобы не поймать инцидент?

Коротко: минимально необходимые, и решение о доступе не должна принимать сама модель.

Здесь есть редкий случай, когда у меры безопасности есть измеренный эффект. Компания «Информзащита» 26 мая 2026 года опубликовала данные по инцидентам с ИИ-агентами:

• 42% организаций столкнулись с инцидентами безопасности из-за агентов в 2026 году — против 31% годом раньше;
• 53% сталкивались с тем, что агент превышал заданные полномочия;
• 58% говорят, что обнаружение и реагирование занимает больше пяти часов;
• у тех, кто применяет принцип минимально необходимого доступа, инциденты фиксируются в 17% случаев, у остальных — в 76%.

«В 2026 г. мы ожидаем, что число инцидентов будет расти прежде всего там, где агенты внедряются быстрее, чем появляются владельцы» — Анатолий Песковский, директор Департамента наступательной безопасности «Информзащиты», CNews.

Разница между 17% и 76% — это почти пятикратный разрыв, полученный организационной мерой, а не покупкой софта. Что из этого следует на практике:

1. Права выдаются под задачу, а не под сотрудника. Агенту первой линии не нужен доступ ко всей клиентской базе — ему нужно создавать обращение и читать публичный прайс.
2. Проверку прав делает система, а не модель. Агент запрашивает данные, а решает, можно ли их отдать, ваш контур доступа.
3. У агента есть владелец. Человек, который смотрит журнал действий и разбирает спорные случаи.

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

Как отличить настоящего агента от переклеенного ярлыка?

Коротко: спросите про инструменты, состояние и права — на трёх вопросах ярлык отваливается.

У явления есть имя. В пресс-релизе от 25 июня 2025 года Gartner ввёл термин agent washing — переклейку названия «агент» на уже существующие продукты: ассистентов, RPA и чат-ботов без реальных агентных возможностей. Из тысяч вендоров, заявляющих агентность, по оценке Gartner настоящую дают около 130.

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

«Most agentic AI projects right now are early-stage experiments or proof of concepts that are mostly driven by hype and are often misapplied» — Anushree Verma, старший директор-аналитик Gartner, пресс-релиз Gartner от 25.06.2025.

Там же Verma добавляет то, что стоит перечитать дважды перед стартом любого проекта:

«Many use cases positioned as agentic today don't require agentic implementations» — то есть значительной части задач, которые сегодня подают как агентные, агент попросту не нужен.

Чек-лист покупателя из трёх вопросов, которые полезно задать любому продавцу:

1. Какие инструменты вызывает система и что она меняет в моих системах? Если ответ «отвечает на вопросы» — это бот.
2. Как ограничиваются её права и кто принимает решение о доступе? Если «модель сама разберётся» — это будущий инцидент.
3. Что происходит, когда она ошибается? Должен быть ответ про передачу человеку, журнал действий и владельца.

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

Источники

• Anthropic. Building effective agents — определения агента и сценария, рекомендация не усложнять
• OpenAI. Agents guide — определение агента через планирование, инструменты и состояние
• Anthropic. Introducing the Model Context Protocol — стандарт подключения инструментов, ноябрь 2024
• Gartner. Предсказание по агентным проектам, 25.06.2025 — 40% закрытых проектов, agent washing, около 130 настоящих вендоров
• ComNews. Исследование «СберАналитики» и «Сбер Бизнес Софт», 22.01.2026 — 39% компаний используют ИИ-агентов, структура автоматизации
• CNews. «Информзащита» об инцидентах с ИИ-агентами, 26.05.2026 — 42% инцидентов, 17% против 76% при минимальных правах
• Хабр. ИИ-агент работает, пока ему не дали доступ к реальным данным — что ломается при переходе в продакшен, оценка «в 20 раз»