Почему ИИ-пилоты на заводе умирают между демо и цехом
Пилот показали на совете директоров, все похлопали, выделили бюджет на «масштабирование». Через полгода система компьютерного зрения, которая на демо ловила 98% дефектов, ловит хорошо если половину, контролёры ОТК перестали ей доверять, а проект тихо переехал в раздел «отложенных инициатив». Это не редкий сбой и не вина конкретного интегратора. По данным RAND, так заканчивается больше 80% корпоративных ИИ-проектов – и почти всегда по причинам, которые видно было ещё до старта.
Самое неприятное в этой статистике – не сам процент провалов, а то, что виновата в них почти никогда не технология. Корпорация RAND в исследовании 2024 года опросила 65 дата-сайентистов и инженеров с опытом от 5 до 30 лет и разобрала причины, по которым ИИ-проекты не доходят до продакшена. Вывод звучит почти обидно: самая частая причина провала – в том, что руководители и технические специалисты по-разному поняли, какую задачу вообще нужно решить. Не данные, не модель, не GPU. Постановка задачи.
Для производственного руководителя это хорошая новость. Если бы дело было в технологии, оставалось бы только ждать следующего поколения моделей. Но раз дело в управленческих решениях – значит, на исход можно влиять. Ниже – семь признаков, что пилот обречён, собранные из RAND, McKinsey и разборов провалов в автопроме. Каждый признак – это вопрос, который стоит задать команде до того, как вы подпишете бюджет на масштабирование.
Сначала о масштабе: почему «пилот удался» ничего не значит
Завести пилот сегодня несложно. Сложно довести его до состояния, когда им ежедневно пользуются на трёх сменах и он влияет на цифры в P&L. Разрыв между этими двумя точками – главная ловушка.
McKinsey в отчёте 2025 года о масштабировании ИИ в производстве приводит цифру, которая отрезвляет: только 2% производителей считают, что ИИ полностью встроен в их операции. Около двух третей застряли на стадии исследования и точечных внедрений – то есть на бесконечных пилотах. Похожую картину рисует отчёт MIT, о котором мы писали отдельно: у 95% компаний генеративный ИИ не дал измеримого эффекта на прибыль.
В автопроме это видно в чистом виде. По разборам отраслевого издания Automotive Manufacturing Solutions, большинство проектов компьютерного зрения для контроля качества так и не выходят за пределы тестовой ячейки – не потому, что плохо распознают дефекты на демо, а потому, что демо и реальный цех – это две разные среды.
Дальше – по признакам.
Признак 1. Никто не может назвать цену проблемы в рублях
RAND ставит непонимание задачи на первое место среди причин провала, и в производстве оно проявляется специфически. Пилот запускают, потому что «надо внедрять ИИ» или потому что конкурент похвастался на конференции. Сформулировать, какую именно потерю в деньгах закрывает проект, никто не может.
McKinsey фиксирует ту же болезнь количественно: у большинства производителей нет привязки ИИ-инициатив к конкретным целевым показателям ценности. Проект без цены проблемы невозможно ни приоритизировать, ни закрыть, ни признать успешным – у него просто нет критерия. Как строить такой бизнес-кейс с реальными данными, мы разбирали отдельно.
До старта пилота попробуйте заполнить одну строку: «эта задача стоит нам N рублей в месяц, потому что …». Если N посчитать не получается – это не значит, что задача плохая. Это значит, что вы пока не понимаете её достаточно, чтобы тратить на неё ИИ-бюджет. Возьмите ту, где N очевиден: простой линии, переделка брака, штраф за срыв поставки.
Цену проблемы считать сложнее, чем кажется. Попробуйте ИИ на 9 реальных задачах руководителя – от анализа данных до претензии поставщику – бесплатно и без регистрации.
Доступ сразу после регистрации
Признак 2. Данных для задачи на самом деле нет
Вторая по частоте причина в списке RAND – у организации нет нужных данных. На заводе это звучит особенно знакомо. Данные вроде бы есть: SCADA пишет телеметрию, MES хранит наряды, ОТК ведёт журналы. Но когда доходит до обучения или промптинга модели, выясняется, что половина журналов на бумаге, в SCADA нет истории отказов с разметкой, а описания дефектов каждый контролёр пишет своими словами.
Это та самая фрагментация данных, на которую жалуются в автопроме: данные есть, но они разбросаны по системам, не размечены и не сведены к единому формату. Модель, обученная на чистой выборке для демо, в продакшене встречает реальность – и проседает.
Прежде чем заказывать пилот, стоит провести честную ревизию: где лежат данные по задаче, в каком они формате, кто их вносит и насколько единообразно. Если на этом этапе становится неуютно – лучше сначала навести порядок в данных, а уже потом запускать ИИ. Бумажный слой, с которого мы советовали начинать, хорош именно тем, что не требует чистой исторической выборки – модель работает с тем, что вы даёте ей прямо сейчас.
Признак 3. Команда влюблена в технологию, а не в проблему
Третья причина у RAND сформулирована прямо: проект больше увлечён применением самой свежей технологии, чем решением реальной проблемы. На производстве это выглядит как стремление сразу строить компьютерное зрение с дообучением нейросети там, где задачу решал бы простой текстовый ассистент за неделю.
MIT в своём отчёте отмечает смежный перекос: больше половины бюджетов на генеративный ИИ уходит в эффектные витрины – продажи и маркетинг, – тогда как наибольшую отдачу даёт скучный бэк-офис. На заводе аналог витрины – «умный цех» для экскурсий инвесторов; аналог бэк-офиса – автоматизация сменной отчётности и претензионной работы, которая никого не впечатлит на совете директоров, но реально экономит часы.
Один проверочный вопрос инициатору пилота: «Если бы этой технологии не существовало, как бы мы решали эту проблему?» Если внятного ответа нет – решение придумали раньше проблемы. Разворачивайте разговор от модели к задаче.
Признак 4. Задача в принципе не по зубам нынешнему ИИ
Пятая причина в списке RAND – ИИ применяют к задачам, которые слишком сложны для него. Это не приговор технологии, а вопрос границ. ИИ хорошо структурирует текст, распознаёт типовые дефекты, подбирает аналоги деталей. Он плохо справляется там, где нужны редкие события без истории, физические рассуждения о незнакомом оборудовании или решения с ценой ошибки в человеческую жизнь без страхующего контура.
Полезно разделить задачи на три корзины: «ИИ делает сам», «ИИ готовит черновик, человек утверждает», «ИИ пока не трогаем». Большинство производственных задач честно попадают в среднюю корзину – и это нормально. Проблемы начинаются, когда задачу из третьей корзины пытаются затащить в первую под давлением сроков.
Где ИИ помогает, а где незаметно ошибается – видно только на практике. В открытом модуле 9 задач менеджера с разбором типичных ошибок, бесплатно.
Доступ сразу после регистрации
Признак 5. Дрейф, о котором забывают через полгода
Это специфически производственная ловушка, которую офисные внедрения почти не знают. Модель компьютерного зрения, отлично работавшая на запуске, через несколько месяцев начинает ошибаться – и не потому, что её сломали. Изменилось освещение в цехе, поставщик сменил марку стали с чуть другим отблеском, износилась камера, сезон поменял влажность. Модель осталась прежней, а мир вокруг неё уехал.
Разбор этого эффекта в автопроме показывает закономерность: инспекционные системы деградируют не сразу, а спустя месяцы после успешного пилота, когда команду внедрения уже распустили, а про переобучение модели никто не подумал. Пилот, у которого нет плана на жизнь после запуска, обречён независимо от качества старта.
В проект стоит заложить не только запуск, но и эксплуатацию: кто и как часто проверяет точность, по какому порогу запускается переобучение, кто за это отвечает. Если ответ – «команда внедрения уйдёт, а дальше посмотрим», вы оплачиваете пилот, который умрёт по расписанию.
Признак 6. Всё держится на двух-трёх специалистах
Четвёртая причина у RAND – нехватка инфраструктуры для управления данными и развёртывания моделей. На практике это часто маскируется под кадровую зависимость: пилот работает, потому что его на коленке держат два энтузиаста-инженера. Они ушли в отпуск, сменили работу или переключились на другой проект – и система встала, потому что инфраструктуры, которая жила бы без них, нет.
Проверьте, переживёт ли проект уход любого одного человека. Если ответ «нет» – у вас не внедрённая система, а демо, которое случайно дожило до продакшена. До масштабирования нужна минимальная инфраструктура: документированный процесс, доступы, мониторинг, регламент обновления.
Признак 7. У проекта нет владельца со стороны бизнеса
Это сквозная причина, которая связывает все предыдущие. RAND и BCG сходятся в одном: у успешных проектов есть владелец продукта со стороны бизнеса – человек, который отвечает за результат в деньгах, а не за то, что «модель обучилась». Для IT- и продуктовых менеджеров, которые строят такой же процесс внутри команды, закономерность та же. Когда пилот целиком на ИТ или на внешнем интеграторе, некому ни поставить задачу в терминах цеха, ни принять решение об остановке, ни добиться, чтобы цехом реально пользовались.
BCG описывает рабочую пропорцию усилий внедрения как 70/20/10: семьдесят процентов сил уходит на людей, процессы и изменение того, как работает цех, двадцать – на технологии и данные, и лишь десять – на алгоритмы. Если в вашем проекте всё наоборот и 90% бюджета – это лицензии и интеграция, перекос виден сразу.
Владельца со стороны производства нужно назначать до старта, а не после. У него должны быть полномочия остановить проект – и мотивация довести его до ежедневного использования.
Как это собрать в один чек-лист
Перед тем как подписать бюджет на масштабирование пилота, пройдите по семи вопросам. Каждое «нет» – это не повод отказаться от ИИ, а место, где проект сломается, если не починить заранее.
- Можем ли мы назвать цену проблемы в рублях?
- Есть ли у нас данные для этой задачи в пригодном виде?
- Решаем ли мы проблему, а не любуемся технологией?
- По силам ли эта задача нынешнему ИИ?
- Есть ли план на жизнь системы после запуска, с учётом дрейфа?
- Переживёт ли проект уход любого одного человека?
- Есть ли владелец со стороны бизнеса с правом остановить проект?
Закономерность RAND читается между строк этого списка: шесть из семи вопросов – про управление, и только один – про технологию. Завод, который умеет отвечать «да» на управленческие вопросы, доведёт до цеха даже скромную модель. Завод, который надеется, что всё вытянет технология, провалит и самую сильную.
И вот что обнадёживает на фоне мрачной статистики. Навык формулировать задачу, считать её цену и отделять «по силам ИИ» от «не по силам» – это не врождённый талант и не редкое умение дорогого консультанта. Это тренируемая управленческая дисциплина. Проще всего она ставится не на дорогом провальном пилоте, а на безопасных учебных задачах, где ошибку видно сразу и она ничего не стоит.
От чек-листа к системному навыку
Открытый модуль mysummit.school: 9 практических задач, на которых видно, где ИИ реально помогает, а где незаметно ошибается. Фундамент курса даёт навыки формулирования задач, оценки результата и управления рисками ИИ – то, что отделяет удачный пилот от вечно отложенного. Бесплатно, без регистрации.
Часто задаваемые вопросы
Почему большинство ИИ-пилотов не выходят за пределы тестовой ячейки?
Что такое дрейф модели и почему он убивает ИИ-внедрения на производстве?
Как понять, что ИИ-задача по силам нынешним моделям?
Почему BCG рекомендует тратить 70% усилий ИИ-проекта на людей, а не на технологию?
Кто должен быть владельцем ИИ-проекта на производстве?
Stanislav Belyaev
Engineering Leader в Microsoft18 лет в управлении инженерными командами. Основатель mysummit.school. 700+ выпускников в Яндекс Практикуме и Стратоплане.