ИИ-агенты в B2B в 2026: почему пилоты не доходят до продакшена и на каком шаге сгорает бюджет

Пошаговый регламент: что делать, в каком порядке и что замерить.

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

Связанные услуги: каталог, AI Boost Team, стать клиентом.

Цель регламента и что нужно на входе

Пилот ИИ-агента в B2B умирает не на модели. На интеграциях и грязных данных. Бюджет сгорает задолго до продакшена: демо собирается за 2–4 недели, а рабочий контур — это 3–5 месяцев, из которых на модель приходится меньшая часть.

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

Что должно быть на входе, иначе дальше идти нет смысла:

• Один процесс с измеримым входом и выходом. Обработка входящих заявок, квалификация лидов, первая линия поддержки. Формулировка «улучшить клиентский сервис» не считается.
• Baseline по 4 метрикам: время обработки операции, стоимость операции, доля ошибок, доля эскалаций на человека. Без baseline вы не докажете эффект ни себе, ни финдиру.
• Доступ к реальным данным процесса: логи, выгрузки из CRM, записи звонков, тикеты. Синтетика не подойдёт.
• Человек, назначенный владельцем качества агента после запуска. Один. С фамилией. Не «команда ИИ».

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

Где сгорает бюджет пилота: три дыры

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

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

Дыра 1: данные

Ориентир: 200–500 размеченных примеров из продакшена — минимальный датасет для оценки качества агента. Не для обучения. Для оценки. Без него вы не знаете, работает агент или красиво отвечает.

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

Стоимость разметки никто не считает заранее. А датасет — не одноразовый актив. Через 3 месяца процесс меняется, появляются новые типы обращений, и выборку нужно обновлять. Заложите это в бюджет поддержки, а не в разовый проект.

Дыра 2: интеграции

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

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

Дыра 3: логика после инцидентов

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

Пошаговый регламент: от baseline до продакшена

Шаги копируются в Notion или Asana как есть. Каждый — с владельцем и KPI. Нумерацию не пропускайте: порядок здесь не косметика.

1. Зафиксировать процесс и baseline. Выберите один процесс. Замерьте 4 метрики за предыдущий период: время обработки, стоимость операции, доля ошибок, доля эскалаций. Владелец — операционный директор. KPI шага: цифры записаны и подписаны финдиром. Стоп-сигнал: метрики невозможно посчитать — процесс не формализован, автоматизировать нечего.
2. Собрать и разметить датасет. 200–500 реальных примеров, включая грязные и пограничные. Разметка до старта разработки, не после. Владелец — аналитик или владелец процесса. KPI: выборка покрывает не менее 75% типов обращений из логов. Стоп-сигнал: больше 40% примеров невозможно однозначно разметить — критерии качества не определены.
3. Собрать агента на готовом стеке. LLM + оркестратор + инструменты + RAG. Свою модель не строим. Владелец — техлид. KPI: агент проходит размеченную выборку в тестовом режиме. Стоп-сигнал: команда предлагает обучать модель с нуля на этом этапе.
4. Собрать единый слой доступа к данным. Один шлюз к CRM, базе знаний, телефонии. С разграничением прав: агент видит только то, что нужно для процесса. Владелец — техлид и безопасник. KPI: агент получает данные по всем сценариям выборки без ручных костылей. Стоп-сигнал: доступы выдаются точечно «на время теста» — это останется навсегда.
5. Теневой режим 2–4 недели. Агент работает параллельно с человеком, решения сравниваются, расхождения разбираются. Владелец — владелец качества агента. KPI: доля расхождений с человеком падает и стабилизируется. Ориентир: теневой режим 2–4 недели снижает число инцидентов после запуска. Стоп-сигнал: расхождения не снижаются две недели подряд — проблема в данных или логике, не в модели.
6. Определить пороги выхода. Заранее зафиксируйте, при каких метриках переводите трафик. Пример: доля корректных ответов не ниже 75% на выборке, доля эскалаций не выше 35%, время ответа в рамках baseline. Владелец — операционный директор. KPI: пороги подписаны до запуска, не после. Стоп-сигнал: пороги «подкручивают» под фактический результат.
7. Постепенный перевод трафика. 20% → 40% → 60% с ручным fallback на каждом этапе. Логирование каждого шага агента. Владелец — владелец качества. KPI: метрики держатся на каждом уровне не менее недели. Стоп-сигнал: на любом уровне метрики падают ниже порога — откат на предыдущий.
8. Зафиксировать регламент эскалации. Когда агент передаёт диалог человеку, как именно, что видит оператор. Владелец — руководитель поддержки или продаж. KPI: операторы знают регламент и работают по нему. Стоп-сигнал: эскалация «когда агент не уверен» без критериев — операторы получат всё.

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

Роли: кто за что отвечает

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

Стоп-сигнал: когда прерывать внедрение

Прервать — не значит провалить. Это значит не сжечь остаток бюджета на сценарий, который не сойдётся.

• Процесс не имеет измеримого входа и выхода. Нельзя посчитать стоимость операции до автоматизации — нельзя посчитать и после.
• Нет доступа к реальным данным. Синтетика даст синтетический результат.
• Нет человека, отвечающего за качество агента после запуска. Без владельца метрики деградируют за 3 месяца.
• Расхождения в теневом режиме не снижаются две недели подряд. Дальше — только переделка данных или логики, а не «ещё немного подождём».
• Пороги выхода пересматриваются в сторону понижения. Это уже не внедрение, это имитация.

Сработал любой пункт — остановитесь, зафиксируйте причину, перезапустите с одного процесса. Что переиспользовать из неудачного пилота: размеченный датасет, единый слой доступа, оркестратор. Это не сгорело. Сгорела логика под конкретный сценарий, который не сошёлся.

Экономика: как считать без иллюзий

Считайте стоимость обработки одной операции до и после. Не «экономию часов», а деньги. Операция стоила 60 ₽, стала 30 ₽ — это факт. «Стало быстрее» — не факт.

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

Своя модель оправдана редко. В большинстве B2B-сценариев 2026 года готовые модели с оркестрацией, инструментами и RAG закрывают типовые задачи. Своя модель нужна, когда есть уникальные данные, которых нет ни у кого, и объём задач оправдывает инфраструктуру. Сомневаетесь — не нужна. Посмотрите готовые контуры агентов, прежде чем считать свою инфраструктуру.

FAQ

На каком шаге чаще всего сгорает бюджет?

На интеграциях и данных. Демо собирается за 2–4 недели, а подключение к CRM, базе знаний, телефонии и внутренним API с учётом прав доступа и нестабильных ответов растягивается в 3–5 раз дольше. В смете пилота этого обычно нет.

Почему пилот не масштабируется на другие процессы?

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

Какие метрики показывают готовность к продакшену?

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

Нужно ли дообучать свою модель?

В большинстве B2B-сценариев 2026 года — нет. Готовые модели с оркестрацией, инструментами и RAG закрывают типовые задачи. Своя модель оправдана, когда есть уникальные данные и объём, который окупает инфраструктуру. Для первого процесса — почти никогда.

Сколько ждать эффекта?

Первый процесс с нормальным baseline и теневым режимом — 4–6 месяцев до стабильных метрик. Не 3 недели. Если кто-то обещает быстрее, он либо не считает интеграции, либо не считает поддержку.

Что сделать в следующие 10 минут

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

Дальше — зафиксируйте владельца качества агента. Одно имя. Назвать некого — внедрение ещё не началось, независимо от того, что говорит команда.

Когда baseline и владелец есть — приходите с ними на разбор контура. С пустыми руками разговор будет про модели. С цифрами — про деньги.

Сценарий внедрения: дорожная карта на первые недели

Начните с одного процесса, где есть измеримый вход и выход: обработка входящих заявок, квалификация лидов или первая линия поддержки. Зафиксируйте baseline: время обработки, стоимость операции, доля ошибок, доля эскалаций на человека. Соберите 200–500 реальных примеров из продакшена, включая сложные и грязные кейсы, и разметьте их до старта разработки. Соберите агента на готовом стеке (LLM + оркестратор + инструменты), не строя свою модель. Прогоните теневой режим 2–4 недели: агент работает параллельно с человеком, решения сравниваются, расхождения разбираются. Только после стабильного качества переводите трафик постепенно, оставляя ручной fallback и логирование каждого шага.

1. Нулевая неделя: baseline-метрики, карта ролей и ответственности, технические ограничения и SLA.
2. Неделя 1-2: запуск узкого пилота, контрольные точки, лог ошибок типовых сценариев.
3. Неделя 3-4: первое улучшение по KPI или честное признание, что нужно поменять сценарий/данные.
4. Неделя 5+: масштабирование на смежные процессы и фиксация регламентов, чтобы качество держалось без геройства команды.

Формат “один главный результат на одну неделю” сохраняет темп и экономит управленческое внимание.

Кейс-пласт: как считать результат в цифрах

Ниже — не “рекламные проценты”, а каркас, который вы должны перевести в свои единицы: заявки, маржа, стоимость часа операций, качество поддержки или конверсия в платеж.

Если хотя бы одна ключевая метрика после внедрения не становится понятнее, чем до baseline, есть смысл остановиться и перепрошить эксперимент, а не “дожимать технологией”.

Риски и как их снять заранее

• Запуск без baseline и недельной аналитики — самый дорогой вариант, потому что непонятно, что лечить.
• Смешивание многих задач одновременно — обычно увеличивает календарные сроки и бюджет сверх суммы задач по отдельности.
• Слабая интеграция с точками истины данных (CRM, биллинг, тикет-системы) даёт красивый интерфейс и плохой бизнес-эффект.

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

Короткая диагностика под ваш процесс: обычно 3 дня для малого бизнеса и до 5 дней для проектов со сложной воронкой и несколькими стейджами.

Быстрый расчет эффекта: (количество заявок × текущая стоимость обработки заявки) − (то же после внедрения целевой модели) + (дополнительные продажи × средняя маржа). Число получится грубым и полезным: оно задаёт экономику решения даже без идеальных данных.

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

• Запросить диагностику процесса: Открыть форму контактов PrimeCoder
• Получить план внедрения на 30 дней: Подключить AI Boost Team как внешний AI-офис с KPI

FAQ по теме статьи

На каком шаге чаще всего сгорает бюджет?

На интеграциях и данных. Демо собирается за 2–4 недели, а подключение к CRM, базе знаний, телефонии и внутренним API с учётом прав доступа и нестабильных ответов занимает в 3–5 раз больше времени. Вторая зона — переделка логики после первых инцидентов в продакшене, когда выясняется, что агент не умеет корректно эскалировать.

Почему пилот не масштабируется на другие процессы?

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

Какие метрики показывают, что агент готов к продакшену?

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

Нужно ли дообучать свою модель?

В большинстве B2B-сценариев 2026 года — нет. Готовые модели с оркестрацией, инструментами и RAG закрывают типовые задачи. Своя модель оправдана, когда есть уникальные данные, жёсткие требования по конфиденциальности или стоимость инференса на объёме становится критичной.

Как считать ROI пилота, чтобы не обмануть себя?

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

Что делать, если пилот уже провалился?

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

Дальше по теме платформы: смежные материалы (ROI / деньги)

Статью лучше читать в связке — так быстрее собирается картина, как ответ складывается в работающую воронку, а не в изолированный совет.

• Сколько стоит AI Boost Team в 2026
• ROI AI Boost Team: как считать
• AI-отдел на аутсорсе vs штат