Почему ИИ-агент не дошёл до продакшена: 6 причин и как их закрыть

Что значит «дошёл до продакшена»

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

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

Что говорят цифры

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

По данным S&P Global Market Intelligence, доля компаний, закрывших большинство ИИ-инициатив, выросла за год с 17% до 42%, а в среднем до продакшена не доходит 46% пилотов. Исследование MIT про GenAI Divide фиксирует ещё более резкую картину: около 95% организаций не получают измеримой отдачи от пилотов с генеративным ИИ — об этом писало Fortune со ссылкой на отчёт.

Оптимистичная часть картины тоже измерена: IDC ожидает 1,15 млрд активных агентов к 2029 году и отмечает, что уже больше 30% предприятий ввели формальные метрики ценности ИИ. Разбор IDC — в материале про агентное развёртывание. То есть проблема не в том, что агенты не работают вовсе: проблема в том, что до управляемого результата доходит меньшая часть проектов.

Причина 1. База знаний собрана из того, что было под рукой

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

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

Что делать вместо этого: до старта определить 5–7 групп документов, у каждой назначить владельца и договориться, кто и как часто обновляет их в базе. Сбор базы занимает 40–50% времени проекта, и попытка проскочить этот этап — самая дорогая экономия в проекте.

Причина 2. У пилота нет метрики успеха

Метрика пилота — это заранее выбранное число, по которому руководство решает, продолжаем мы или закрываем. Без него обсуждение скатывается в оценку «мне нравится, как он отвечает», а такая оценка меняется вместе с настроением.

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

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

Причина 3. Агент отвечает там, где нужен человек

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

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

Рабочая настройка — порог уверенности в диапазоне 0,7–0,75 и обязательная передача человеку по темам, где есть деньги: возвраты, списания, пересчёт, претензии. Оператор при этом получает не пустой тикет, а найденные документы и оценку уверенности, поэтому эскалация ускоряет ответ, а не тормозит его.

Причина 4. Интеграции отложили на потом

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

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

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

Причина 5. После запуска у агента нет владельца

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

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

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

Причина 6. Экономику посчитали в конце

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

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

У проектов с посчитанной экономикой есть и второе преимущество: известно, на какую нагрузку агент рассчитан. Без этого при росте обращений втрое бюджет растёт незаметно, а вместе с ним — и желание закрыть проект.

Что делать: пять условий запуска

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

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

Коротко

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