Коротко
ИИ-проект не окупается, когда компания автоматизирует красивую демонстрацию, а не рабочий процесс. Бот отвечает гладко, но менеджеры всё равно ведут клиентов в личном WhatsApp. CRM остаётся грязной. 1C живёт отдельно. База знаний устаревает. Пользователи не понимают, где агент помогает, а где ему нельзя верить.
Обычно проблема не в том, что «модель плохая». Чаще нет владельца процесса, нет реальных примеров, нет evals, нет прав на действие, нет baseline-метрики и нет человека, который после запуска отвечает за качество.
Ниже - разбор десяти ошибок. Его можно использовать как диагностику уже запущенного пилота или как чеклист перед новым проектом.
1. Автоматизировали не ту боль
ИИ легко показать на текстах: написать письмо, резюме звонка, ответ клиенту. Это удобно. Но не всегда это деньги.
Если менеджер тратил две минуты на ответ, а потом всё равно вручную создаёт сделку, ищет оплату, уточняет склад и согласует скидку, экономия слабая. Лучше искать место, где AI меняет операционный шаг: создаёт черновик карточки, проверяет документ, находит забытый follow-up, сортирует кандидатов, готовит задачу, подсказывает оператору правильный регламент.
Вопрос не «где ИИ выглядит умно», а где ручная рутина уже стоит денег.
2. Нет владельца процесса
Проект без владельца всегда выглядит ничьим.
IT может подключить интеграции. Подрядчик может собрать агента. Но кто решает, что ответ правильный? Кто говорит, какие ошибки опасны? Кто обновляет базу знаний? Кто принимает пилот? Кто защищает изменение процесса перед командой?
Если такого человека нет, ИИ становится игрушкой. Все рады, никто не отвечает.
3. Пилот сделали на идеальных вопросах
На идеальных вопросах любой агент хорош.
В жизни клиент пишет без приветствия, с ошибками, голосовым сообщением, на русском с казахскими словами, со скриншотом, с раздражением. Сотрудник спрашивает внутренний регламент не официальным названием, а «тот документ по возвратам, который Асель отправляла». Кандидат пишет «ночная смена бар ма, район какой?».
Если такие примеры не попали в тесты, первый настоящий тест начнётся после запуска. Это дорогой способ учиться.
4. Агент не видит систему, где принимается решение
Многие проекты остаются на уровне текста. Агент написал красивый ответ, а человек потом сам идёт в amoCRM, Bitrix24, 1C, Excel или почту.
Иногда это нормально: на первом этапе агент может быть помощником. Но если вся ценность в действии, а агент не может хотя бы подготовить это действие, окупаемость будет слабой.
Поэтому важно различать AI-агента, чат-бота и workflow. Чат-бот отвечает. Workflow двигает данные. Агент читает контекст, пользуется инструментами и останавливается там, где нужен человек.
5. CRM и документы никто не чистит
ИИ не лечит хаос в источниках. Он его ускоряет.
Если в CRM дубли, старые статусы и пустые поля, агент будет ошибаться. Если в базе знаний три версии одного регламента, он выберет не ту. Если инструкции лежат в личных папках, система не поймёт, что считать актуальным.
Нужна карта источников: где правда, кто владелец, как часто обновляется, что нельзя использовать, какие документы устарели. Это не самая приятная работа. Зато без неё AI-проект быстро начинает врать уверенным голосом.
6. Нет evals
Без evals команда спорит о вкусе.
Один говорит: «стало лучше». Второй: «мне не нравится тон». Третий: «модель ошиблась на моём кейсе». После каждой правки промпта никто не знает, что сломалось в старых сценариях.
Evals для AI-проектов нужны, чтобы сравнивать версии. Берёте реальные кейсы, ожидаемое поведение, категории ошибок и прогоняете систему после изменений. Это не бюрократия. Это приборная панель.
7. Scope распух до запуска
Начинали с поддержки. Потом добавили продажи. Потом HR. Потом документы. Потом «давайте ещё на казахском и для всех филиалов». Через месяц никто не понимает, что именно должно заработать.
Широкий scope скрывает проблемы. Узкий scope их показывает.
Поэтому пилот ИИ за 30 дней лучше строить вокруг одного процесса. Если он сработал, подход можно переносить дальше. Если нет, вы потеряли месяц, а не полгода.
8. Пользователям не объяснили границы
Сотрудники должны понимать, как работать с агентом.
Если агент пишет черновик, что нужно проверять? Если он ищет регламент, как понять, что источник правильный? Если он вытаскивает поля из документа, какие поля всегда смотрит человек? Если он предлагает следующий шаг по сделке, кто может его изменить?
Без этих правил пользователи либо слепо доверяют, либо полностью игнорируют систему. Оба варианта плохие.
9. Риски вспомнили в конце
Риски надо проектировать сразу.
Скидки, деньги, юридические обещания, персональные данные, медицинские вопросы, найм, увольнение, доступ к зарплатам, изменение статусов в 1C - это не зона для свободной автоматизации. Здесь нужны подтверждения, роли, логи, отказы и передача человеку.
Если риск-политика появляется только перед запуском, проект либо блокируется, либо выходит опасным.
10. Экономику посчитали после демо
Это классика. Сначала сделали демо, потом начали придумывать ROI.
Надо наоборот. До разработки определите единицу пользы: минут меньше на тикет, меньше пропущенных лидов, быстрее обработка кандидата, меньше ручной проверки документов, меньше ошибок в CRM, меньше эскалаций.
Метрика может измениться после пилота. Но если её нет вообще, окупаемость будет рассказываться словами, а не цифрами.
Как спасать проект
Не начинайте с замены модели.
Сначала сузьте процесс. Найдите владельца. Соберите реальные примеры. Разделите черновик, рекомендацию и действие. Опишите, где человек подтверждает. Сделайте тест-набор. Посмотрите, какие источники надо привести в порядок.
Иногда честный ответ - закрыть. Если объём маленький, процесс неважный, данных нет, риска много и владелец не готов участвовать, проект не надо спасать.
Но часто неудачный широкий проект можно перезапустить как узкий. Например, не «ИИ для отдела продаж», а контроль забытых follow-up в amoCRM. Не «ИИ для финансов», а проверка актов одного типа. Не «ИИ для HR», а первичная обработка кандидатов на одну массовую роль.
Как выглядит нормальная окупаемость
Она обычно не выглядит как революция. Оператор быстрее находит регламент. Рекрутер меньше времени тратит на однотипные вопросы. Руководитель продаж видит сделки без следующего шага. Финансист быстрее проверяет акт. Администратор клиники не пишет один и тот же ответ десятый раз.
Это маленькие изменения, но в большом потоке они дают деньги.
Если вы только готовитесь к внедрению, начните с чеклиста что подготовить перед внедрением ИИ. Если уже выбираете исполнителя, пригодится материал как выбрать подрядчика по внедрению ИИ.
FAQ
Главная причина провала - плохая модель?
Редко. Чаще виноваты слабая постановка задачи, отсутствие владельца, плохие источники, нет evals и слишком широкий scope.
Когда проект надо закрывать?
Когда нет измеримой боли, владелец не участвует, данные недоступны, риск слишком высокий или никто не может назвать действие, которое агент должен улучшить.
Можно ли спасти плохой пилот?
Да, если остались реальные примеры и понятны ошибки. Сузьте сценарий, соберите evals, ограничьте права агента и перезапустите на одном процессе.
Что делать, если пользователи не приняли агента?
Смотреть не только на модель. Возможно, агент слишком длинно отвечает, не показывает источник, мешает привычному процессу или требует лишние клики. Adoption - часть продукта.