директор и машина · операционное управление · запись № 041 · 22 августа 2026 · Давид Герштейн

Риски внедрения ИИ: почему проект умирает уже после запуска

Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные.

Если ваш пилот с ИИ заглох — вы в большинстве. Разбираю пять причин, по которым внедрения умирают, хотя технически всё работало. Четыре из пяти я прошёл лично.

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

Все ошибки ниже — мои собственные. Каждая стоила недель работы, и каждую можно было предвидеть.

Ошибка 1. Вы считаете это технической задачей

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

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

Мой самый поучительный провал выглядит так. Система оценки качества звонков: слушает все разговоры менеджеров, оценивает по чек-листу, показывает провалы. Технически — образцовая: за период эксплуатации она оценила 7139 разговоров, порядка 177 в день, себестоимость эксплуатации — около 25 000 ₽ в месяц. Ни один отдел контроля качества не даст такой охват за такие деньги.

А теперь цифра, которая важнее: за весь период руководители оставили на эти оценки один отзыв. Один. Калибровка критериев оборвалась через месяц после запуска. Система продолжала оценивать — результаты никто не разбирал.

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

Ошибка 2. Робот, за которым приходится следить

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

Вторая история короче. Автоматический процесс публикации контента упёрся в ошибку и молча остановился. Утром я обнаружил, что ничего не вышло, запустил руками, разобрался. Через неделю — снова. Фраза, которую я тогда сказал своему же ИИ-ассистенту, стала для меня определением проблемы: «Если бы я не пошёл к тебе, ничего бы не произошло».

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

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

Ошибка 3. Доверие к данным, на которых всё стоит

ИИ-отчётность строится на данных CRM — а данные врут. Не метафорически: в один из месяцев я обнаружил, что у 12,9% лидов дата создания изменилась задним числом. Сдвиги накапливались, две выгрузки за один и тот же период давали разные числа.

Отчёты, построенные на этих данных, были красивыми, убедительными и неверными — подробно я разобрал это в статье про враньё данных в CRM.

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

Ошибка 4. Ваш пилот так и остаётся пилотом

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

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

На распознавании документов я прошёл этот путь целиком. На демо всё распознаётся прекрасно. В реальном потоке: сканы вверх ногами, один документ в пяти файлах, рукописные вставки, типы документов, которых нет в библиотеке. Точность извлечения ключевых полей у нас выросла с 59% до 85% — но не сменой модели, а месяцами калибровки под каждый из 79 типов документов и, главное, честным разделением потока на режимы: что обрабатывается автоматически, что — автоматически с проверкой человеком, что — только руками. Без этого разделения первая же ошибка на важном документе убивает доверие ко всей системе.

После разделения структура потока выглядела примерно так: около 70% документов проходят полностью автоматически, порядка 25% — автоматически, но с обязательной проверкой человека, и около 5% система сама отправляет в ручную обработку, не пытаясь угадать (оценка). Именно эти 5% и были демонстрационным провалом на этапе пилота — подрядчик показывал только первую категорию.

Ошибка 5. Считать эффект в технологиях, а не в деньгах

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

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

Как встроить ритуал без ручного контроля

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

Ниже — рабочая связка для CRM на Bitrix24, где оценки звонков уже пишутся в поля сделки. Вебхук раз в неделю собирает JSON с оценками, модель отбирает проблемные звонки и формирует повестку. Это ровно та часть, которой не хватило в моём кейсе из ошибки №1.

Ты — ассистент руководителя отдела продаж. На входе — JSON-массив оценок звонков за неделю, выгруженный вебхуком из Bitrix24 (поля сделки UF_CALL_SCORE и UF_CALL_FLAGS).

Формат входных данных:
{
  "period": "2026-08-15/2026-08-21",
  "calls": [
    {"call_id": "88213", "manager": "Иванов", "deal_id": "40521", "score": 62, "flags": ["не назвал цену", "не закрыл на след. шаг"]},
    {"call_id": "88214", "manager": "Петров", "deal_id": "40522", "score": 91, "flags": []},
    {"call_id": "88215", "manager": "Иванов", "deal_id": "40530", "score": 58, "flags": ["не назвал цену"]}
  ]
}

Задача:
1. Отбери до 3 звонков с наименьшим score, где flags не пустые.
2. Сгруппируй флаги по частоте среди звонков каждого менеджера.
3. Сформируй короткую повестку встречи руководителя с менеджером: что разобрать, что повторить на следующей неделе.

Верни ответ строго в JSON, без пояснений вне него.

Пример ответа модели на приведённых данных:

{
  "manager": "Иванов",
  "calls_to_review": ["88213", "88215"],
  "top_flag": "не называет цену",
  "flag_frequency": 2,
  "agenda": "Разобрать отработку возражения по цене на звонках 88213 и 88215",
  "repeat_next_week": "Проверить, называет ли Иванов цену в первых трёх звонках недели"
}

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

Экономика: во что обошлась ошибка №1

Настройка системы оценки звонков заняла ~20 часов, эксплуатация — ~25 000 ₽/мес. Потенциальный эффект при работающем ритуале разбора — если он всего на 2 сделки из 50 в месяц меняет исход — ≈ 360 000 ₽/мес (оценка). Мы получили не эту цифру, а ноль: ритуал не заработал, и все 25 000 ₽/мес ушли в эксплуатацию системы, которую никто не использовал по назначению.

Пример на цифрах отдела. Восемь менеджеров, оборот отдела ~9 млн ₽/мес, средний чек ~180 000 ₽ — это 50 сделок в месяц. Если оценка звонков стабильно выявляет и чинит один типовой сбой у одного менеджера — например, менеджер не проговаривает следующий шаг, и сделка «подвисает», — и это спасает 2 сделки в месяц, эффект составил бы 2 × 180 000 = 360 000 ₽/мес. Это оценка потенциала, а не измеренный факт: у нас ритуал так и не заработал, проверить цифру на практике не удалось.

Что мы не считаем эффектом: сам факт наличия 7139 оценок в системе. Оценки — это запас информации, а не поток денег. Пока их никто не разбирает с менеджером, они не конвертируются ни в одну сделку. За два месяца эксплуатации без ритуала расходы составили 25 000 × 2 = 50 000 ₽ чистых потерь — система работала, отдел продаж не изменился.

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

Сводка: где именно возникают риски внедрения ИИ

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

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

Чек-лист на понедельник

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

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

Что из этого следует

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

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

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

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

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

Как доводить до эксплуатации, а не до демо, — по шагам в бесплатном курсе для руководителей.

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

Частые вопросы

Почему ИИ-система работает технически, а результата нет?

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

Сколько стоит система оценки звонков для отдела продаж?

Настройка занимает около 20 часов, эксплуатация — порядка 25 000 ₽ в месяц. Это оценка для отдела из 8 менеджеров, без учёта времени руководителя на разбор результатов.

Как проверить, что автоматизация работает без постоянного надзора?

По трём признакам: автоматический перезапуск после сбоя, громкое оповещение, если перезапуск не помог, и статус «работает ли сейчас», который можно получить за 10 секунд.

Что делать, если подрядчик показал только пилот?

Спросить, что происходит с кейсом, который не подходит под стандартный сценарий. Ответ «такого не бывает» означает, что перед вами демо, а не продакшен.

#ии и нейросети #ошибки и провалы #деньги