Почему AI-пилоты не дают эффекта: провал заложен в конструкции
У пилота есть свойство, о котором редко говорят вслух: он по определению не обязан ничего менять. У него нет владельца процесса, нет интеграции с системой записи и нет даты, после которой старый способ работы закрывается. Он обязан только показать, что технология работает.
Технология при этом почти всегда работает. Именно поэтому обсуждение раз за разом уходит в сторону моделей и вендоров, хотя разница между удачным и неудачным исходом создаётся не там. Провал большинства пилотов заложен в их формате, а не в их содержании.
Пилот проверяет технологию, а решение о внедрении требует ответа на три других вопроса: кто владелец процесса после запуска, куда попадает результат и когда закрывается старый маршрут. Ни на один из них пилот не отвечает и не должен. Формат исправляется просто: пилот ставится не на демонстрацию возможностей, а на измерение одной величины — доли результатов, которые придётся исправлять.
Три вопроса, на которые пилот не отвечает
Разберём, что именно проверяет пилот и что остаётся непроверенным. Список короткий, и каждый пункт в нём определяет судьбу внедрения сильнее, чем качество ответов модели.
Кто владелец процесса после запуска. В пилоте владельцем является проектная команда, и она распускается по его окончании. Дальше выясняется, что у процесса нет человека, который отвечает за долю ошибок, принимает решение об остановке сценария и утверждает изменения правил. Без него сценарий живёт до первого серьёзного сбоя.
Куда попадает результат. В пилоте результат смотрят участники — этого достаточно для оценки качества. В эксплуатации результат должен попасть в систему, где для компании живёт истина о факте, иначе его не увидит тот, кто не участвовал в запросе. Интеграция в пилот обычно не входит, потому что она дороже самого пилота.
Когда закрывается старый маршрут. Пилот идёт параллельно существующей работе — это его нормальное свойство. Но параллельная работа не заканчивается сама: пока прежний способ доступен и ничего не стоит, часть работы будет идти по нему, и разделить эффект станет невозможно.
| Вопрос | Что проверяет пилот | Что остаётся непроверенным |
|---|---|---|
| Качество результата | Проверяет полностью | — |
| Владелец процесса | Не проверяет | Кто отвечает за долю ошибок и остановку |
| Попадание в систему записи | Не проверяет | Увидит ли результат тот, кто не участвовал |
| Закрытие старого маршрута | Не проверяет | Перейдёт ли работа целиком |
| Стоимость эксплуатации | Проверяет частично | Сопровождение, обновления, разбор ошибок |
Обратите внимание: пилот безупречно выполняет ровно ту задачу, которую перед ним ставят. Проблема не в нём, а в том, что его результат интерпретируют как ответ на вопрос о внедрении.
Данные о том, что решения не назначены
Отсутствие владельца — не абстракция, а измеренный факт, причём измеренный на большой выборке руководителей.
35% опрошенных руководителей сообщили, что до сих пор неясно, у кого есть полномочия оспорить или отменить рекомендацию AI, а 34% не имеют устойчивого механизма разрешения конфликта между решением человека и выводом модели. Только 15% организаций одновременно достигли зрелости и в применении AI, и в управлении изменениями.
Это заказное исследование консалтингового подразделения, цель которого — продать редизайн операционной модели; данные корреляционные, а не причинные. Ограничение существенное. Но сама цифра касается факта, а не оценки: треть руководителей не может назвать, у кого есть право отменить решение системы. Это ровно тот вопрос, который пилот не задаёт.
Почему успешный пилот откатывается назад
Есть класс работ, объясняющий механизм отката улучшений, полученных разовым усилием, — и он старше нынешней волны технологий.
Улучшения, достигнутые за счёт разового усиленного внимания без встраивания в постоянный процесс, систематически откатываются: как только показатели выправляются, людей снимают с этой работы, и проблемы возвращаются. Авторы называют это ловушкой способностей.
Работа не про AI и написана четверть века назад — это аналогия, а не прямое доказательство, и я использую её именно так. Механизм, однако, описан точно и узнаётся в любом пилоте: усиленное внимание команды в течение трёх месяцев даёт результат, который приписывается технологии, а не вниманию, и исчезает вместе с ним.
У этого механизма есть и вторая сторона — систематическое завышение результатов самим фактом наблюдения.
Повторный анализ восстановленных оригинальных данных знаменитых экспериментов с освещением показал, что хрестоматийная картина резкого роста производительности от самого факта наблюдения не подтверждается: «имеющиеся описания якобы примечательных паттернов данных оказываются полностью вымышленными», хотя слабые признаки эффекта наблюдения присутствуют.
Полный текст закрыт, и я работал с аннотацией и описанием находок — это ограничение. Вывод для практики двойной и потому полезный: ссылаться на «эффект наблюдения» как на объяснение любых успехов пилота нельзя, он слабее, чем принято думать. Но и переносить результаты пилота на эксплуатацию без поправки на внимание команды тоже нельзя — просто поправка меньше, чем говорит фольклор.
Отсев — это нормально, а вот отсутствие критерия — нет
Полезно снять и ложную рамку: то, что большинство экспериментов не доходит до эксплуатации, само по себе не является провалом.
Инженеры машинного обучения описывают путь от эксперимента к эксплуатации как процесс отбора: организации выгодно быстро прототипировать множество идей и отсеивать их, прежде чем лучшая дойдёт до промышленного использования. Широко цитируемая доля моделей, не доходящих до продакшена, отражает природу экспериментирования, а не неудачу.
Выборка мала — 18 человек — и нерепрезентативна статистически; авторы сами это отмечают. Но их наблюдение снимает ложную тревогу: проблема не в том, что девять пилотов из десяти закрываются, а в том, что критерий отсева не сформулирован заранее. Когда критерия нет, закрываются не худшие сценарии, а те, чей спонсор потерял интерес.
Как переделать формат пилота
Пилот не нужно отменять — нужно изменить вопрос, на который он отвечает. Вместо «работает ли технология» он должен отвечать на «какая доля результатов потребует исправления».
Ключевое здесь — второй узел. Порог, названный заранее, превращает пилот из демонстрации в проверку, а спор о результате — в сверку с числом. Без него итог обсуждается впечатлениями, и решение принимает тот, кто убедительнее говорит.
Третий узел не менее важен. Реальный поток отличается от подобранных примеров именно в тех случаях, ради которых внедрение и затевается: нестандартные формулировки, неполные данные, редкие ситуации. Демонстрация на подготовленных данных не даёт о них никакой информации. О том, как считать бизнес-эффект по этим же величинам, — отдельный разбор.
Четыре решения до начала пилота
Назовите владельца процесса, а не проекта
Человек, который останется после пилота и будет отвечать за долю ошибок. Если такого нет, пилот бессмыслен.
Назначьте порог до старта
Какая доля результатов, требующих исправления, считается приемлемой. Число называется заранее и записывается.
Проверяйте на реальном потоке
Без предварительного отбора примеров. Именно нестандартные случаи определяют пригодность сценария.
Назовите дату закрытия старого маршрута
Не в пилоте, а в плане внедрения — но назвать её нужно до пилота, иначе внедрение не завершится.
Пилот без заранее названного порога — это не проверка гипотезы, а поиск аргументов для решения, которое уже принято.
Вопросы, которые задают чаще всего
Почему AI-пилоты не переходят в промышленную эксплуатацию?
Потому что пилот проверяет качество технологии, а переход в эксплуатацию требует ответов на три других вопроса: кто владелец процесса, куда попадает результат и когда закрывается прежний способ работы. Ни один из них в формат пилота не входит. Пилот заканчивается успешно и упирается в решения, которые никто не готовил.
Как правильно поставить пилот AI-сценария?
Свести его к измерению одной величины — доли результатов, которые придётся исправлять, — и назначить порог приемлемости до старта. Замер делается на реальном потоке без предварительного отбора примеров. На выходе получается число, а не впечатление, и решение принимается сравнением с порогом, а не в споре.
Нужно ли закрывать пилот, если результат неоднозначный?
Да, и заранее назначенный критерий закрытия — единственный способ сделать это без конфликта. Отсев большинства экспериментов нормален: это свойство экспериментирования, а не признак неудачи. Ненормально, когда закрываются не худшие сценарии, а те, чей спонсор потерял интерес, — так организация теряет способность учиться на собственных попытках.
Насколько результаты пилота переносятся на эксплуатацию?
С поправкой на усиленное внимание команды, которая в эксплуатации исчезает. Величина этой поправки меньше, чем говорит популярная версия эффекта наблюдения, — повторный анализ классических экспериментов показал, что она невелика. Но не нулевая: пилот, который держится на ежедневном участии инициатора, в эксплуатации даст заметно худший результат.
Перечень трёх вопросов, на которые не отвечает пилот, и формат пилота с заранее назначенным порогом — авторское обобщение практики оценки технологических проектов в портфеле Китайско-Российского инвестиционного фонда и практики внедрений в Alego.Digital. Числовых внутренних метрик в статье не приводится: все цифры — из внешних источников с указанными методами. Формализованного описания этого формата в документах компаний нет; в статье он изложен впервые.
- IBM Institute for Business Value, Oxford Economics. The AI-Human Operating Model, июнь 2026 (опрос 1 000 руководителей в 14 странах). ibm.com
- Repenning N. P., Sterman J. D. Nobody Ever Gets Credit for Fixing Problems that Never Happened. California Management Review, 2001. web.mit.edu
- Levitt S. D., List J. A. Was There Really a Hawthorne Effect at the Hawthorne Plant? NBER Working Paper 15016, 2009. nber.org
- Shankar S., Garcia R., Hellerstein J. M., Parameswaran A. G. Operationalizing Machine Learning: An Interview Study. arXiv:2209.09125, 2022. arxiv.org