Почему AI-пилоты в корпорациях не доходят до прода
Temirlan D.8 мин чтения
По оценке Gartner, не менее 30% проектов на основе генеративного AI будут закрыты после стадии proof of concept к концу 2025 года — из-за плохого качества данных, недостаточного риск-контроля, растущих затрат или неясной бизнес-ценности. McKinsey State of AI 2025 ставит масштаб этой проблемы в более чёткий контекст: только около 39% компаний фиксируют какой-либо EBIT-эффект от генеративного AI, а менее 20% называют этот эффект значимым. Удивляет не уровень неудач. Удивляет то, насколько последовательно компании проваливаются по одной и той же причине.
Большинство корпоративных AI-пилотов проваливаются не из-за технических проблем, а потому что их проектируют как технологический эксперимент, а не как бизнес-трансформацию — разрыв между пилотом и production носит организационный характер, а не алгоритмический.
Пилоты проектируют под демо, а не под production-процессы
Типичный корпоративный AI-пилот формируется тем, что выглядит убедительно на управляющем комитете — узким изолированным кейсом с чистым датасетом и наглядным результатом. Чат-бот, отвечающий на пять отобранных вопросов. Модель компьютерного зрения, классифицирующая десять товарных изображений. Прогноз, обученный на трёх годах аккуратной исторической выборки.
Такие пилоты спроектированы так, чтобы выигрывать в демо-среде. Они почти не касаются систем, где реально происходит работа — ERP, CRM, очереди обращений, платформы контакт-центра, legacy-мейнфрейма. Когда руководство одобряет переход в production, команда обнаруживает, что интеграция с этими системами никогда не планировалась. Аутентификация, аудит-логи, обработка ошибок, эскалация на человека, локализация, compliance-проверка — ничего из этого не заложено. Пилот «проходит», проект умирает. Вывод, который делает большинство компаний, неверный: «технология ещё не готова». Верный вывод другой: это был не пилот. Это было демо.
Метрики успеха — метрики тщеславия, а не бизнеса
Спросите корпоративную AI-команду, как она измеряет успех пилота, и услышите метрики уровня модели: accuracy, F1, BLEU, latency, стоимость токена. Эти цифры полезны для инженерных решений, но это не тот язык, на котором говорят CFO или владелец бизнес-процесса.
Пилот, достигающий 92% accuracy, но не сберегающий ни одного часа работы сотрудников, не снимающий ни одного тикета поддержки и не двигающий конверсию — с бизнес-точки зрения провал, независимо от рейтинга в leaderboard. Исследования State of AI от McKinsey раз за разом показывают: компании, получающие реальный EBIT-эффект от AI, — это те, кто привязывает каждый пилот к конкретной строке P&L ещё до того, как обучена первая модель. Остальные строят модели, технически отличные и коммерчески невидимые. В корпоративной среде вопрос не в том, «работает ли это». Вопрос в том, «что меняется в отчёте о прибылях и убытках, когда это работает». Пилоты, которые не могут ответить на этот вопрос, не переживают бюджетный цикл.
Никто не отвечает за переход от пилота к production
Пилоты строят инновационные команды, data science-подразделения, внешние консультанты или proof-of-concept команды вендоров. Production принадлежит IT-операциям, платформенным инженерам, бизнес-подразделению, которое использует инструмент, а в регулируемых индустриях — риску, комплаенсу и безопасности. Это разные люди, с разными бюджетами, разной мотивацией и разным определением «готово».
Инновационная команда празднует пилот и переходит к следующей идее. Операционная команда наследует незнакомый стек без runbook, SLA, on-call-ротации и выделенного бюджета. Через шесть недель пилот тихо выводят из эксплуатации. Компании, которые стабильно выпускают AI в production, относятся к этому переходу как к центральной инженерной задаче, а не административной. Они назначают ответственного за production ещё до старта пилота и оценивают пилотную команду по тому, принял ли владелец систему, а не по тому, впечатлило ли демо совет директоров.
Долг в инфраструктуре данных накапливается под AI-нагрузкой
Пилоты работают на отобранных датасетах. Production работает на том, что реально генерирует бизнес, — неполных записях, несогласованных схемах, нескольких источниках правды, нераспознанных дубликатах сущностей, задним числом внесённых корректировках, legacy free-text-полях на трёх языках и интеграционных пайплайнах, построенных под месячную отчётность, а не под real-time inference.
AI-система обнажает каждое слабое место нижележащего data-стека, потому что модель принимает решения с такой скоростью и объёмом, с какими люди никогда не работали. Банк в Казахстане, запускающий пилот кредитного скоринга на чистой выгрузке заявок, строит другую систему, чем тот, кто должен обращаться к core banking на масштабе, сверяться с Первым кредитным бюро и выдавать аудитабельное решение. По прогнозу Gartner, к 2026 году компании закроют 60% AI-проектов именно из-за отсутствия AI-готовых данных — это превышает все остальные категории причин отказа от AI-инициатив. Большинство пилотных бюджетов закладывает нулевые затраты на доработку данных. Именно поэтому многие AI-дорожные карты тихо превращаются в data engineering-дорожные карты — и именно поэтому компании, отказывающиеся инвестировать в эту плоскость, видят, как пилот за пилотом буксует.
Организационные изменения воспринимают как «потом разберёмся»
Даже самый технически успешный AI-пилот провалится, если люди, чью работу он меняет, не подготовлены, не переобучены и не мотивированы его использовать. Модель обработки документов, сокращающая время проверки на 70%, всё ещё требует, чтобы аналитики доверяли её выводам, перестраивали процесс вокруг неё и перенаправляли освободившиеся часы на более ценные задачи. Ничего из этого не происходит по умолчанию.
Исследование BCG 2025 года по захвату ценности от AI показывает: небольшая группа компаний, которую BCG называет «AI future-built» — те, кто полностью интегрирует AI с организационными изменениями, — достигает в пять раз большего прироста выручки и в три раза большего сокращения затрат по сравнению с остальными. Отличие не в технологии, а в том, перестраивает ли компания работу вокруг AI. На практике это означает раннее вовлечение владельцев процессов, честную коммуникацию об эволюции ролей, перепроектирование workflow до внедрения, обучение, встроенное в раскатку, и чёткие метрики adoption — не только performance модели. В условиях текущего Года AI в Казахстане, когда многие компании запускают свои первые серьёзные AI-инициативы, соблазн велик — отложить change management «на потом, когда технология заработает». «Потом» не наступает. К этому моменту пилот уже стал мёртвым активом.
Контраргумент
Стандартное возражение: пилоты проваливаются, потому что сама технология не готова — модели галлюцинируют, latency непредсказуема, стоимость волатильна, а корпоративный инструментарий отстаёт на год от того, что требует production.
Но готовность технологии редко является реальным блокером на корпоративном масштабе. Те же самые модели уже работают в production в банках, страховых, ретейле и логистике по всему миру. Когда две организации разворачивают одну и ту же модель на одной и той же задаче, и одна получает 30% прироста производительности, а другая — ноль, переменная не в модели. Переменная во всём, что вокруг: в данных, интеграции, владении, метриках, change management. Винить технологию удобно, потому что это проблема, которую должен решать кто-то другой. Организационные проблемы некомфортны, потому что они — собственность самой компании.
Что это значит
Практические выводы для руководителей конкретны. Во-первых, переопределите, что такое пилот: не демо, а узкое production-развёртывание с реальными пользователями, реальными данными и реальной бизнес-метрикой, привязанной с первого дня. Если команда не может сформулировать, какая строка P&L сдвинется и на сколько, — пилот ещё не готов стартовать. Во-вторых, назначьте поимённого владельца production — руководителя бизнес-подразделения или операций — до начала работ по модели, и сделайте приёмку системы его первичным критерием успеха. В-третьих, честно заложите бюджет на доработку данных и интеграцию, которая, как правило, потребует больше ресурсов, чем сама AI-работа. В-четвёртых, относитесь к организационным изменениям как к полноценному workstream со своим владельцем, сроками и метриками, а не как к коммуникационной задаче, прикрученной в конце.
Компании, которые захватят непропорционально большую ценность от AI в ближайшие три года, — это не те, у кого больше всего пилотов. Это те, у кого меньше всего пилотов доходят до production, и у кого хватает дисциплины рано закрывать остальные. Для CEO казахстанских холдингов и крупных компаний, которые сейчас формируют AI-стратегию, возможность в том, чтобы пропустить дорогую фазу «кладбища пилотов» целиком — проектируя каждую инициативу с первого эскиза как бизнес-трансформацию с AI-компонентом, а не как AI-эксперимент в поисках бизнес-применения.
Часто задаваемые вопросы
Независимые оценки расходятся, но общая картина согласована. Gartner прогнозирует, что не менее 30% проектов на генеративном AI будут закрыты после proof of concept к концу 2025 года. McKinsey State of AI 2025 фиксирует, что лишь около 39% компаний отмечают какой-либо EBIT-эффект от генеративного AI, а менее 20% называют этот эффект значимым. На практике в большинстве компаний, запускающих AI-пилоты, большая часть застревает между демо и живой production-системой.
Исследования McKinsey и BCG последовательно указывают на организационные факторы как на главный блокер на корпоративном масштабе — нечёткие бизнес-метрики, отсутствие владельца production, долг в инфраструктуре данных и недоинвестированный change management. Сами модели, как правило, достаточно зрелые. Разрыв — в том, как компания проектирует, владеет и впитывает работу.
Демо проектируется так, чтобы впечатлять в контролируемой среде на отобранных данных. Хороший пилот — это узкое production-развёртывание: реальные пользователи, реальные данные, реальные интеграции, поимённый владелец со стороны бизнеса и конкретная P&L-метрика, привязанная к успеху. Если пилот не отвечает на вопрос «что меняется в P&L, когда это работает», — это демо, как бы его ни называл вендор.
Метрики уровня модели — accuracy, latency и подобные — полезны для инженеров, но не должны быть заголовочной метрикой. Заголовочной метрикой должен быть бизнес-результат, который пилот призван сдвинуть: сэкономленные часы, захваченная выручка, предотвращённые издержки, сокращённый цикл или снижение ошибок в конкретном процессе. Это определяется до начала моделирования, а не обнаруживается задним числом.
Четыре вещи. Сузьте пилот до production-развёртывания с поимённым владельцем со стороны бизнеса. Привяжите успех к конкретной строке P&L до начала работ по модели. Честно заложите бюджет на доработку данных и системную интеграцию. Относитесь к организационным изменениям — переобучению, перепроектированию процессов, метрикам adoption — как к полноценному workstream со своим владельцем. Пилоты, входящие в эту дисциплину, проваливаются значительно реже.
В opengate мы работаем с компаниями именно над этой задачей — переводом AI-амбиции в AI, который доходит до production. Наши форматы Audit, Pilot и Scale выстроены вокруг production-готовности с первой недели — с поимённым владельцем бизнес-стороны и метриками успеха, привязанными к P&L. Если у вас уже были пилоты, которые встали, или вы готовитесь запустить следующий, мы готовы поделиться тем, что видим изнутри.