По оценке Gartner, не менее 30% проектов на основе генеративного AI будут закрыты после стадии proof of concept к концу 2025 года — из-за плохого качества данных, недостаточного риск-контроля, растущих затрат или неясной бизнес-ценности. Параллельно MIT Sloan Management Review и BCG из года в год показывают, что менее 10% компаний извлекают значимую финансовую выгоду из AI, несмотря на почти всеобщие инвестиции. Удивляет не уровень неудач. Удивляет то, насколько последовательно компании проваливаются по одной и той же причине.
Большинство корпоративных AI-пилотов проваливаются не из-за технических проблем, а потому что их проектируют как технологический эксперимент, а не как бизнес-трансформацию — разрыв между пилотом и production носит организационный характер, а не алгоритмический.
Типичный корпоративный AI-пилот формируется тем, что выглядит убедительно на управляющем комитете — узким изолированным кейсом с чистым датасетом и наглядным результатом. Чат-бот, отвечающий на пять отобранных вопросов. Модель компьютерного зрения, классифицирующая десять товарных изображений. Прогноз, обученный на трёх годах аккуратной исторической выборки.
Такие пилоты спроектированы так, чтобы выигрывать в демо-среде. Они почти не касаются систем, где реально происходит работа — ERP, CRM, очереди обращений, платформы контакт-центра, legacy-мейнфрейма. Когда руководство одобряет переход в production, команда обнаруживает, что интеграция с этими системами никогда не планировалась. Аутентификация, аудит-логи, обработка ошибок, эскалация на человека, локализация, compliance-проверка — ничего из этого не заложено. Пилот «проходит», проект умирает. Вывод, который делает большинство компаний, неверный: «технология ещё не готова». Верный вывод другой: это был не пилот. Это было демо.
Спросите корпоративную AI-команду, как она измеряет успех пилота, и услышите метрики уровня модели: accuracy, F1, BLEU, latency, стоимость токена. Эти цифры полезны для инженерных решений, но это не тот язык, на котором говорят CFO или владелец бизнес-процесса.
Пилот, достигающий 92% accuracy, но не сберегающий ни одного часа работы сотрудников, не снимающий ни одного тикета поддержки и не двигающий конверсию — с бизнес-точки зрения провал, независимо от рейтинга в leaderboard. Исследования State of AI от McKinsey раз за разом показывают: компании, получающие реальный EBIT-эффект от AI, — это те, кто привязывает каждый пилот к конкретной строке P&L ещё до того, как обучена первая модель. Остальные строят модели, технически отличные и коммерчески невидимые. В корпоративной среде вопрос не в том, «работает ли это». Вопрос в том, «что меняется в отчёте о прибылях и убытках, когда это работает». Пилоты, которые не могут ответить на этот вопрос, не переживают бюджетный цикл.
Пилоты строят инновационные команды, data science-подразделения, внешние консультанты или proof-of-concept команды вендоров. Production принадлежит IT-операциям, платформенным инженерам, бизнес-подразделению, которое использует инструмент, а в регулируемых индустриях — риску, комплаенсу и безопасности. Это разные люди, с разными бюджетами, разной мотивацией и разным определением «готово».
Исследования IDC и Forrester неизменно указывают на этот переход как на главный источник застрявших AI-инвестиций. Инновационная команда празднует пилот и переходит к следующей идее. Операционная команда наследует незнакомый стек без runbook, SLA, on-call-ротации и выделенного бюджета. Через шесть недель пилот тихо выводят из эксплуатации. Компании, которые стабильно выпускают AI в production, относятся к этому переходу как к центральной инженерной задаче, а не административной. Они назначают ответственного за production ещё до старта пилота и оценивают пилотную команду по тому, принял ли владелец систему, а не по тому, впечатлило ли демо совет директоров.
Пилоты работают на отобранных датасетах. Production работает на том, что реально генерирует бизнес, — неполных записях, несогласованных схемах, нескольких источниках правды, нераспознанных дубликатах сущностей, задним числом внесённых корректировках, legacy free-text-полях на трёх языках и интеграционных пайплайнах, построенных под месячную отчётность, а не под real-time inference.
AI-система обнажает каждое слабое место нижележащего data-стека, потому что модель принимает решения с такой скоростью и объёмом, с какими люди никогда не работали. Банк в Казахстане, запускающий пилот кредитного скоринга на чистой выгрузке заявок, строит другую систему, чем тот, кто должен обращаться к core banking на масштабе, сверяться с Первым кредитным бюро и выдавать аудитабельное решение. Работы Gartner по data-and-analytics показывают: от 60 до 85% данных, используемых в AI-проектах, требуют доработки перед production. Большинство пилотных бюджетов закладывает ноль. Именно поэтому многие AI-дорожные карты тихо превращаются в data engineering-дорожные карты — и именно поэтому компании, отказывающиеся инвестировать в эту плоскость, видят, как пилот за пилотом буксует.
Даже самый технически успешный AI-пилот провалится, если люди, чью работу он меняет, не подготовлены, не переобучены и не мотивированы его использовать. Модель обработки документов, сокращающая время проверки на 70%, всё ещё требует, чтобы аналитики доверяли её выводам, перестраивали процесс вокруг неё и перенаправляли освободившиеся часы на более ценные задачи. Ничего из этого не происходит по умолчанию.
Исследования BCG по захвату ценности от 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 года. MIT Sloan и BCG уже несколько лет показывают, что менее 10% компаний извлекают значимую финансовую выгоду из AI-инвестиций. На практике в большинстве компаний, запускающих AI-пилоты, большая часть застревает между демо и живой production-системой.
Исследования BCG, McKinsey и IDC последовательно указывают на организационные факторы как на главный блокер на корпоративном масштабе — нечёткие бизнес-метрики, отсутствие владельца 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. Если у вас уже были пилоты, которые встали, или вы готовитесь запустить следующий, мы готовы поделиться тем, что видим изнутри.
Хотите работать вместе? Свяжитесь с нами