Почему большинство ИИ-пилотов не доживают до продакшена
Почему большинство ИИ-пилотов не доживают до продакшена
Есть фраза, которую я слышу почти дословно от разных людей: «На демо было вау, а через пару месяцев — тишина». Запустили, показали совету директоров, все покивали, выделили бюджет. А потом проект просто перестал двигаться. Никто его официально не закрывал — он умер сам, тихо, между другими приоритетами.
Это не редкий сбой. По исследованию MIT NANDA «The GenAI Divide» подавляющее большинство корпоративных ИИ-проектов не доходят до измеримого ROI — и авторы прямо указывают, что дело не в моделях, а в том, как их встраивают. Вопрос «почему ИИ не приживается в компании» почти всегда упирается не в технологию, а в управление. Это статья про анатомию такой смерти: почему она происходит, как распознать её ещё до запуска, и что делать, если ваш проект уже завис.
Анатомия мёртвого пилота: вау на демо, тишина через считанные месяцы
Давайте проследим типичную траекторию, в которой многие узнают свой проект.
Сначала — демо. Кто-то (внутренний энтузиаст или внешний подрядчик) показывает, как модель отвечает на вопросы по вашим документам, или собирает отчёт, или обрабатывает заявки. На демо всё работает блестяще, потому что демо специально собрано так, чтобы работать: чистые данные, удобные примеры, отрепетированный сценарий. Зал говорит «вау». Выделяется бюджет.
Дальше внедрение выходит из тепличных условий в реальность — и начинается расхождение. Реальные данные грязные. Пользователи задают вопросы не так, как в демо. У сотрудников, которые должны были встроить инструмент в работу, есть свои KPI, и новый инструмент в них не входит. Через две-три недели энтузиазм гаснет, через пару месяцев проектом никто не занимается.
Вот неочевидное наблюдение: «вау» на демо — это не предвестник успеха, а чаще предвестник смерти. Чем ярче демо, тем сильнее разрыв между ожиданием и тем, что выдержит продакшен — и тем сильнее усыплена бдительность тех, кто должен был задать неудобные вопросы про данные, метрику и процесс. Здоровые внедрения часто стартуют со скучного, неэффектного запуска, который зато выживает.
Почему ИИ не приживается: дело почти никогда не в технологии
Смерть проекта почти никогда не про качество модели. Дальше — три причины, по которым внедрения умирают на самом деле. Они управленческие, не технические.
Красный флаг №1: нет владельца со стороны бизнеса
Первый и самый частый — у проекта нет хозяина со стороны бизнеса. Есть исполнитель (ИТ-отдел, подрядчик, дата-команда), но нет человека из бизнеса, для которого успех — это его личная победа, а провал — его личная проблема.
Признак этого флага легко заметить уже на старте: спросите, кто именно отвечает за результат. Если в ответ называют отдел, а не фамилию, — это плохой знак. Если называют ИТ-директора — тоже тревожно: ИТ отвечает за то, чтобы инструмент работал технически, а не за то, чтобы он менял бизнес-показатель. Это две разные ответственности, и их регулярно путают.
Без владельца со стороны бизнеса некому продавливать изменения. Сотрудники не обязаны менять привычки, у подрядчика нет рычага, чтобы заставить процесс перестроиться, а у дата-команды нет полномочий трогать чужие регламенты. Проект повисает в воздухе: технически живой, организационно — никому не нужный. Именно такие инициативы тихо умирают первыми, потому что их некому защищать, когда приходит следующий квартальный аврал.
Красный флаг №2: успех не привязан к метрике
Второй флаг — отсутствие заранее определённой метрики успеха. Спросите про любой буксующий проект: «Как мы поймём, что он сработал?» — и в большинстве случаев услышите что-то размытое. «Повысим эффективность». «Ускорим обработку». «Сотрудникам станет удобнее».
Это не метрики. Метрика — это число, которое было до запуска, и которое мы хотим увидеть после. Среднее время обработки заявки: было 40 минут, цель — 15. Доля обращений, закрытых без эскалации: было 60%, цель — 80%. Если такого числа нет на старте, то у проекта нет критерия смерти — а значит, нет и критерия жизни. Он не может ни провалиться, ни победить, он может только бесконечно «продолжаться», пока про него не забудут.
Здесь есть ловушка, в которую попадают аккуратные команды: метрику определяют, но после запуска, подгоняя её под то, что уже получилось. Это самообман. Метрика, выбранная задним числом, всегда показывает успех — и именно поэтому ничего не значит. Здоровая практика — зафиксировать критерий успеха письменно до первого спринта, а не дорисовать его к финальной презентации. Эту же мысль я подробнее разбираю в тексте про правду о ROI ИИ-внедрений — без честной метрики разговор про окупаемость превращается в гадание.
Красный флаг №3: внедряли технологию, а не меняли процесс
Третий флаг — самый глубокий. Команда внедрила инструмент, но не тронула процесс, в который он должен встроиться. Модель работает, но люди вокруг неё работают по-старому — и инструмент остаётся сбоку, как красивая, но необязательная игрушка.
Классический пример схемы: внедрили ИИ-помощника для подготовки ответов клиентам. Технически он отвечает отлично. Но регламент не изменили — оператор всё так же обязан написать ответ сам, а потом ещё и сверить с тем, что предложила модель. В итоге работы стало больше, а не меньше. Через месяц операторы перестают открывать инструмент, и проект мёртв — не потому что плохая модель, а потому что процесс остался прежним, а в прежний процесс инструмент не помещался.
ИИ почти никогда не даёт ценности, если просто «положить его рядом» с существующей работой. Ценность появляется, когда меняют сам кусок процесса: убирают шаги, которые теперь закрывает модель, освобождают людей под более сложную работу, переписывают регламент. Модель при этом ложится слоем поверх обновлённого процесса, а не процесс перестраивается вокруг модели. Это и есть настоящая работа внедрения — и она управленческая, а не техническая. Поэтому проект, который ведёт только ИТ-команда без полномочий менять бизнес-процессы, обречён почти по определению. Про сопротивление команды этим изменениям — отдельный разговор в материале как внедрять ИИ без саботажа.
Почему «проект ради отчёта» умирает первым
Отдельная категория мёртвых проектов — те, что запускались не ради задачи, а ради факта запуска. «Совет директоров спрашивает, что мы делаем с ИИ» — и компания делает пилот, чтобы было что показать. Цель инициативы — не бизнес-результат, а отчёт о наличии активности.
Такие проекты умирают быстрее всех: как только отчёт сделан и галочка поставлена, у инициативы исчезает смысл существования. Она держалась не на ценности, а на потребности отчитаться, — а эта потребность закрывается одним слайдом.
Здесь важно не перепутать. Желание понять технологию на реальной задаче — здоровая мотивация, и с неё нормально начинать. Проблема не в том, что проект маленький или экспериментальный, а в том, что у него нет адресата ценности — конкретного человека или функции, которым станет лучше, если он сработает. Проект для обучения команды живёт: у него есть адресат — сама команда и её новый навык. Проект для слайда умирает, потому что адресата нет, есть только аудитория презентации.
Как выглядит здоровое внедрение с первого дня
Если перевернуть три флага, получается рамка здорового внедрения. Не гарантия — управляемых способов гарантировать результат во внедрении не существует, — но заметное смещение шансов в свою сторону.
| Мёртвый пилот | Живой пилот |
|---|---|
| Отвечает «отдел» / ИТ-директор | Отвечает конкретный человек из бизнеса |
| Метрика размытая или придумана потом | Число зафиксировано письменно до старта |
| Инструмент положили рядом с процессом | Изменили сам кусок процесса: убрали шаги, освободили людей |
| Цель — показать активность | Цель — конкретный адресат ценности |
| Яркое демо, тепличные данные | Скучный старт на реальных, грязных данных |
| Запуск сразу «по-крупному» | Узкий участок, который видно целиком |
Здоровое внедрение начинается не с выбора модели и не с подрядчика, а с трёх вопросов: кто хозяин, какое число мы двигаем, какой кусок процесса меняем. Если на все три есть конкретный ответ — проект, скорее всего, выживет, даже если технология средняя. Если хотя бы на один ответа нет — даже лучшая модель не спасёт. Кстати, выбор участка для первого шага — это отдельное решение, и ему посвящён материал про то, куда внедрять ИИ первым.
Предсказание на ближайшие 12 месяцев: маятник качнётся от «давайте запустим пилот» к «зачем нам ещё один пилот». Слишком многие компании накопили кладбище мёртвых проектов, и аппетит к новым экспериментам ради экспериментов падает. По прогнозу Gartner, значительная доля агентных ИИ-проектов будет свёрнута к 2027 году из-за неясной бизнес-ценности и роста издержек. Выиграют не те, кто запустит больше экспериментов, а те, кто научится доводить немногие до продакшена и честно закрывать тупиковые. Дисциплина «довести или закрыть» станет ценнее, чем сам факт наличия ИИ-инициатив.
Чек-лист: оживить или закрыть честно
Если у вас уже есть проект, который буксует, не нужно сразу его хоронить — но и тащить мёртвую инициативу через бюджет тоже не нужно. Пройдите его по пунктам и примите честное решение.
Проверка на «можно оживить»:
- [ ] Есть конкретный человек из бизнеса, готовый стать владельцем (не «отдел»)?
- [ ] Можно сформулировать метрику успеха числом — и оно реально достижимо?
- [ ] Есть участок процесса, который вы готовы реально изменить — убрать шаги, переписать регламент под новую работу?
- [ ] Есть адресат ценности — кому именно станет лучше?
- [ ] Технология на демо работала на ваших данных, а не на показательных?
Если на большинство пунктов «да» — проект, скорее всего, не мёртв, а просто запущен без управленческого слоя. Его чинят не заменой модели, а тремя решениями: назначить хозяина, зафиксировать число, изменить кусок процесса. Это и есть точечная диагностика — разобрать конкретный кейс и понять, что именно встало.
Признаки, что честнее закрыть:
- Никто из бизнеса не хочет брать ответственность за результат.
- Метрику невозможно сформулировать, или она недостижима в реальных условиях.
- Процесс менять нельзя по объективным причинам (регуляторика, контракты, риски).
- Запуск был ради отчёта, и эта задача уже закрыта.
Закрыть забуксовавший проект — это не поражение, а управленческая зрелость. Хуже всего — третий вариант, который выбирают чаще всего: не оживлять и не закрывать, а оставить инициативу тлеть, отъедая бюджет и внимание. Именно так выглядит большинство мёртвых проектов — формально живые, фактически — нет.
Если у вас есть пилот, который завис — давайте посмотрим вместе
Самый простой вход — короткий разговор на 30 минут: вы описываете, что запускали и где встало, я задаю несколько вопросов и говорю честно, что вижу. Дальше уже понятно — проект стоит оживить точечной диагностикой, или честнее закрыть и не тащить мёртвую инициативу через бюджет. Без обязательств с обеих сторон. Я не продаю «ещё один пилот» — я помогаю понять, нужен ли он вам вообще.
Не обязательно сразу программу. Достаточно часового разговора, чтобы понять, какая из дверей сейчас ваша — или что пока ни одна из них не нужна.
FAQ
Если на демо всё работало отлично — это же хороший знак?
Скорее наоборот. Демо специально собирают на чистых данных и удобных сценариях, поэтому оно почти всегда выглядит впечатляюще. Разрыв между демо и продакшеном — это и есть зона, где умирают такие проекты. Здоровее относиться к яркому демо с осторожностью и спрашивать: на ваших ли реальных, грязных данных это проверяли, или на показательных.
Кто должен отвечать за ИИ-пилот — ИТ или бизнес?
Технически — ИТ, за результат — бизнес. ИТ-отдел отвечает за то, чтобы инструмент работал, но не за то, чтобы он двигал бизнес-показатель. Нужен конкретный человек из бизнеса, для которого успех — личная задача. Если за результат отвечает только ИТ-директор, у проекта нет рычага, чтобы менять процессы вокруг себя, — и это частая причина тихой смерти.
У нас нет метрики, но интуитивно стало лучше. Это провал?
Не обязательно провал, но это сигнал к тому, чтобы метрику всё-таки зафиксировать — и желательно не задним числом. Метрика, придуманная после запуска под уже полученный результат, всегда показывает успех и поэтому ничего не значит. Возьмите число, которое было до запуска, и проверьте, изменилось ли оно. Если изменить нельзя — стоит честно разобраться, есть ли вообще измеримая ценность.
Можно ли оживить пилот, который уже два месяца стоит?
Часто можно — если проблема была управленческой, а не технической. Обычно у застрявшего проекта не хватает не модели, а хозяина, метрики или изменения процесса — и чинят его именно тремя решениями, а не заменой технологии. Но если адресата ценности нет в принципе — честнее закрыть. Точечная диагностика как раз помогает понять, какой это случай.
Сколько ИИ-проектов реально доходят до продакшена?
По отраслевым обзорам — меньшинство; до измеримой пользы добирается небольшая доля, а остальные останавливаются после стадии proof of concept. Gartner прогнозировал, что заметная часть генеративных ИИ-проектов будет заброшена уже после proof of concept. Конкретная цифра зависит от отрасли и зрелости компании, но картина устойчивая: проблема почти всегда не в технологии, а в трёх управленческих узлах.
