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

1. у агента нет владельца

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

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

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

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

2. нет данных — или они врут

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

на таком фундаменте агент строит уверенные и неверные ответы — худшее сочетание из возможных.

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

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

3. автоматизировали хаос

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

симптом: на вопрос «как этот процесс работает сейчас» три сотрудника отвечают три разные вещи. это не процесс — это три привычки.

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

4. ждали магию

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

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

симптом: цель проекта сформулирована словами «повысить эффективность», «оптимизировать за счёт ии», «не отстать от рынка». ни в одной из формулировок нет процесса и цифры.

противоядие: цель вида «сократить время ответа на заявку с 4 часов до 15 минут» или «освободить 60 часов менеджеров в месяц». не формулируется такая цель — нет и проекта, есть мода.

5. замахнулись на всё сразу

вместо одного процесса — «цифровая трансформация»: и продажи, и поддержка, и документы, и hr, единой платформой, за один проект. на бумаге — синергия. в жизни — проект на год, в котором через три месяца ничего не работает целиком, бюджет наполовину съеден, а команда устала до первого результата.

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

симптом: в первом кп подрядчика больше трёх процессов и слово «платформа».

противоядие: один процесс, 2–4 недели, работающий результат в проде. дальше — следующий. скорость набирается итерациями, а не размахом.

6. не договорились, что такое «работает»

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

симптом: на вопрос «как поймём, что пилот удался» ответ — «ну, посмотрим по ощущениям».

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

7. забыли людей

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

симптом: команда узнала о внедрении из слухов. или на демо сидит молча и смотрит в стол.

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

что общего у всех семи

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

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