Три месяца назад ко мне обратилась компания из сектора розничной торговли. Они потратили 11 месяцев и около 4 миллионов рублей на пилот по автоматизации прогнозирования спроса с помощью ML-модели. Результат: проект свёрнут, команда распущена, директор по цифровой трансформации уволился сам. История настолько типичная, что я перестал удивляться — я начал считать. По моей практике и данным от коллег-архитекторов, не менее 85–90% пилотных ИИ-проектов в России либо не выходят в продакшн, либо тихо умирают в течение полугода после запуска. Это не российская специфика страха перед технологиями. Это системная проблема, у которой есть конкретные причины и конкретные решения.
Почему пилоты умирают ещё до рождения: проблема постановки задачи
Самая распространённая причина провала — задача сформулирована как технологическая, а не бизнесовая. Звучит это примерно так: «Хотим внедрить GPT в клиентский сервис» или «Нужна нейросеть для анализа документов». Это не задача — это желание купить молоток в надежде, что он сам найдёт гвоздь.
В 2023 году я работал с производственным холдингом, где IT-директор пришёл с запросом «внедрить компьютерное зрение на конвейере». Когда мы начали разбирать, выяснилось: реальная боль — это брак на финальном этапе сборки, который обходится в 18 млн рублей в квартал. Компьютерное зрение — лишь один из возможных инструментов. В итоге мы переформулировали задачу: снизить процент брака с 3,2% до 1,5% за 6 месяцев с измеримым ROI. Именно эта переформулировка спасла проект — потому что теперь у него был критерий успеха.
Правило первое: перед запуском пилота запишите одно предложение: «Мы считаем пилот успешным, если [конкретный показатель] изменится с [X] до [Y] за [срок]». Если не можете написать это предложение — пилот не готов к старту.
Ловушка «идеальных данных»: как дата-стратегия топит проекты
Второй убийца пилотов — иллюзия о готовности данных. Компания начинает пилот, через месяц обнаруживает, что данные разбросаны по трём несвязанным системам, часть из них в Excel-файлах на рабочих столах менеджеров, а исторические данные за 2020 год «немного кривые, потому что тогда была реструктуризация».
По моим наблюдениям, в 70% случаев реальная стоимость подготовки данных превышает изначальную оценку в 3–5 раз. При бюджете пилота в 2 млн рублей это означает, что вся сумма уходит на ETL и очистку — и к моменту, когда данные готовы, деньги заканчиваются.
Что делать: проводить Data Readiness Assessment ещё до старта пилота. Это 2–3 недели работы аналитика, который отвечает на четыре вопроса: где данные физически хранятся, кто является их владельцем внутри компании, какова их полнота и достоверность, насколько сложно их извлечь и объединить. Стоимость такого аудита — 200–400 тысяч рублей. Экономия на провальном пилоте — в 10 раз больше.
Отдельная история — GDPR-подобные ограничения по персональным данным. Российские компании часто обнаруживают уже в середине пилота, что обучать модель на клиентских данных нельзя без дополнительного юридического оформления. Юристов нужно подключать на этапе дизайна, не запуска.
Организационный иммунитет: почему люди саботируют ИИ-внедрения
Технари любят думать, что главное — написать хороший код. Это ошибка, которая стоит проектам жизни. Организационное сопротивление убивает больше пилотов, чем технические проблемы.
Механизм выглядит так: менеджер среднего звена понимает, что ИИ-система будет делать то, что раньше делал его отдел. Он не саботирует открыто — он просто не предоставляет данные вовремя, не участвует в приёмке, находит причины отложить интеграцию. Через полгода проект тихо умирает «из-за технических сложностей».
Я наблюдал этот паттерн в банке, где пилот по автоматизации кредитного скоринга был заблокирован руководителем отдела андеррайтинга. Формально — «модель недостаточно объяснима для регулятора». Реально — отдел из 40 человек оказывался под угрозой сокращения вдвое.
Решение не техническое — оно политическое. Перед запуском пилота необходимо:
- Идентифицировать всех стейкхолдеров, на чьи KPI повлияет проект
- Провести индивидуальные встречи и честно обсудить последствия
- Включить «пострадавших» менеджеров в команду пилота с реальными полномочиями
- Переформулировать нарратив: не «ИИ заменит людей», а «ИИ возьмёт рутину, люди займутся задачами с большей ценностью»
Последний пункт — не манипуляция. Это правда, которую нужно реализовать на практике: если после пилота вы просто увольняете людей, следующий проект встретит ещё большее сопротивление.
Проблема масштабирования: от пилота к продакшну — пропасть шириной в год
Допустим, технически пилот сработал. Модель показывает точность 87%, стейкхолдеры довольны, руководство аплодирует на демо-дне. А потом начинается масштабирование — и проект умирает именно здесь.
Пилот и продакшн — это принципиально разные инженерные задачи. Пилот можно запустить на ноутбуке дата-сайентиста с данными за три месяца. Продакшн требует: отказоустойчивой инфраструктуры, мониторинга дрейфа модели, CI/CD-пайплайнов для переобучения, интеграции с legacy-системами, которым по 15 лет, документации для службы поддержки и соответствия требованиям ИБ.
В российских реалиях добавляется специфика: импортозамещение инфраструктуры. Пилот запустили на AWS или GCP, а в продакшн нужно переносить на Yandex Cloud или отечественные решения. Это не просто смена хостинга — это иногда переписывание значительной части кода.
Мой совет: проектируйте с учётом продакшна с первого дня. Это значит:
- Используйте инфраструктуру, близкую к целевой, уже в пилоте
- Выделите 30–40% бюджета пилота на MLOps, а не только на модель
- Определите команду поддержки ещё до запуска пилота — не после
- Заложите в роадмап минимум 3 месяца на «долину смерти» между пилотом и продакшном
Как строить пилоты, которые выживают: практический фреймворк
За три года работы с российскими компаниями разного масштаба я выработал подход, который повышает шанс выживания пилота примерно втрое. Он состоит из пяти элементов.
Первый: горизонт 90 дней. Пилот должен дать первый измеримый результат за три месяца. Не финальный — первый. Если за 90 дней нет ничего конкретного, проект теряет поддержку руководства вне зависимости от реального прогресса.
Второй: executive sponsor с личным KPI. Кто-то из топ-менеджмента должен лично отвечать за результат пилота. Не «курировать» и «поддерживать» — а иметь этот пилот в своих целях на год. Без этого при первом кризисе проект окажется без защиты.
Третий: минимальный жизнеспособный продукт, а не proof of concept. PoC доказывает, что технология работает. MVP доказывает, что пользователи готовы её использовать. Разница критическая: я видел десятки блестящих PoC, которые никто не захотел применять в работе.
Четвёртый: петля обратной связи с конечными пользователями каждые две недели. Не с руководством — с теми, кто будет работать с системой ежедневно. Их обратная связь на раннем этапе стоит дешевле, чем переделка после запуска.
Пятый: явный критерий остановки. Заранее договоритесь: при каких условиях вы останавливаете пилот. Это звучит пессимистично, но на практике снижает потери. Компании, у которых нет критерия остановки, продолжают вливать деньги в умирающий проект ещё 6–9 месяцев из-за психологии невозвратных затрат.
Вывод
90% провалов — это не приговор технологии. Это диагноз управленческой зрелости. ИИ-пилоты умирают не потому, что нейросети не работают, а потому что их запускают без чёткой бизнес-задачи, без готовых данных, без учёта человеческого фактора и без плана на жизнь после пилота.
Хорошая новость: все эти проблемы решаемы. Они решаются не дополнительным бюджетом и не более умными алгоритмами — они решаются правильной архитектурой решения ещё до написания первой строки кода.
Компания, которая научится строить пилоты, выживающие в продакшне, получит не просто одну работающую систему. Она получит компетенцию, которая в следующие пять лет станет одним из главных конкурентных преимуществ на российском рынке.
Разбираю реальные кейсы внедрения ИИ, архитектурные решения и управленческие ошибки в своём Telegram-канале. Если вы проходите через пилот прямо сейчас или только планируете — подписывайтесь, там есть чеклисты и шаблоны, которые я использую в работе.