Как распознать
- Метрики стабильны и хороши, но масштабирование откладывается месяц за месяцем без новой даты решения.
- Человек-валидатор стал постоянной ролью. Каждое решение AI проверяется вручную даже после фазы «Канарейка» — выкатки на узкий сегмент трафика. Человек-валидатор проверяет 100% выводов, и без него пилот не работает.
- У переходов между фазами двойного прогона нет численных критериев. Для «Тени» (AI работает параллельно с оператором, его решения не идут в дело) прописано «расхождения меньше 30%». Для перехода с «Канарейки» на «Градуальный» (плавное расширение доли трафика) не прописано ничего. Переход остаётся обсуждением, не триггером.
- Команда оптимизирует точность, а не покрытие. Обсуждения на еженедельном синхроне идут вокруг «довести точность с 93 до 95%», а не «выкатить на следующие 25% трафика».
- Пилот живёт на спецусловиях. Выделенные лучшие люди, очищенные от исключений данные, ручные обработки на сложных кейсах. На полном потоке этих условий нет.
- Финансирование как у эксперимента, а не как у продукта. Деньги идут из R&D или экспериментального бюджета. Перевод в opex требует отдельного согласования, которое откладывается.
- Никто не уполномочен сказать «всё, переходим». Решение зависит от консенсуса между владельцем процесса, AI-командой, региональным руководством и финансами. Консенсуса нет.
Почему случается
Размытые критерии выхода. Пилот стартует с целью «посмотреть, работает ли». Успех определяется неявно: «когда руководитель скажет, что готово». Это финиш без флажка. Команда накапливает свидетельства (расхождения меньше 20%, отмены меньше 10%, ни одной критической ошибки), но «готов к масштабированию» остаётся движущейся мишенью. У разных стейкхолдеров «готов» означает разное: техническая готовность для инженеров, готовность процесса для операций, готовность бюджета для финансов. Совпадения этих трёх «готов» не происходит само по себе.
Перфекционизм вместо адекватности. Фокус смещается с «достаточно ли хорошо для перехода» на «идеален ли результат». «93% точности мало для production, нужно 98%». При этом каждый шаг улучшения требует кратно больше данных и времени. Команда застревает в цикле совершенствования вместо цикла масштабирования. Это самый незаметный механизм: он выглядит как ответственность, а работает как избегание.
Замёрзший средний уровень тормозит транспортировку. Если масштабирование AI воспринимается средним менеджментом как угроза, торможение происходит мягко: дополнительные проверки, уточнения, валидация исключительных кейсов, ещё один раунд согласований с комплаенсом. Каждый аргумент звучит разумно. См. замёрзший средний уровень; он почти всегда участвует в пилотах, которые «успешны, но не масштабируются».
Пилот живёт на спецусловиях, которые не переносятся. Когда команда пробует выйти на 100% трафика, обнаруживается: исключений в реальности в 5–10 раз больше, чем в пилотной выборке; один человек физически не может проверить весь поток; данные на полном трафике загрязнены. Команда возвращается на «Канарейку» с формулировкой «масштабирование требует больших изменений в инфраструктуре». Реально требуется не инфраструктура, а отказ от спецусловий, и команда к этому не готова.
К чему приводит
Замораживается бюджет, замораживается команда. Пилот требует постоянного внимания: еженедельные разборы, ручные проверки, доучивание модели. Инженеры и владелец процесса не могут параллельно запускать следующий AI-кандидат, и портфель трансформации не растёт. По обобщению отчётов McKinsey, BCG, 2024, 40–50% AI-пилотов в крупных организациях не доходят до промышленной эксплуатации. Бо́льшая часть умирает не от технических проблем, а от организационного затягивания.
Через 18–24 месяца появляется второй симптом: вокруг застрявшего пилота возникает теневая инфраструктура. Часть пользователей внутри компании начинает обращаться к публичным AI-инструментам напрямую, потому что собственный пилот для них слишком медленный или закрыт. Безопасность данных становится заботой не AI-команды, а лотереи. Это уже не один паттерн, а каскад: пилот навсегда → теневая автономия → инцидент → откат всей инициативы.
Крупный финансовый институт запустил пилот AI-обработки счетов-фактур в одном региональном отделе. Через 6 месяцев расхождения 15%, ноль критических ошибок, потенциальная экономия по всей сети в несколько сотен миллионов рублей в год. Третий год пилот живёт в том же региональном отделе. Причина не техническая: KPI регионального вице-президента жёстко привязан к доле ручных одобрений как мере «контроля рисков», и масштабирование AI нарушает его метрику. Чтобы выйти из этого состояния, нужно менять KPI вице-президента, а не модель.
Как выходить
Подпишите численные пороги выхода до старта, не после. Для каждой фазы фиксируется четыре цифры: расхождения ≤ N%, отмены ≤ M%, ноль критических ошибок 2 недели подряд, бизнес-показатели не деградируют. Достижение порога становится автоматическим триггером перехода, а не поводом для совещания. См. двойной прогон, там описан полный протокол.
Назначьте одного владельца решения. Право сказать «переходим на следующую фазу» лежит на конкретном человеке (владелец процесса или продуктовый менеджер), не на комитете. Консенсус остаётся самой частой причиной застревания между «Канарейкой» и «Градуальным». Один человек принимает решение по подписанным порогам и несёт за него ответственность.
Переформулируйте спецусловия как риски, а не как требования. Не «нужен человек, который проверяет каждый результат», а «риск: без ручной проверки отмены вырастут выше 15%. План: за 4 недели собрать на решениях оператора обучающую выборку и снизить порог ручной проверки до 30% трафика, дальше до 10%». Спецусловия читаются как сигнал о пропущенной работе, а не постоянная часть процесса.
Запустите следующий пилот при достижении «Градуального». Не ждите полного потока. Когда первый процесс выходит на 25% трафика и устойчиво держится, владельцы и инженеры начинают параллельно запускать «Тень» для процесса B. Конвейер вместо линейной очереди отличает компанию с работающей трансформацией от компании с одним вечным пилотом.
Что путают с этим паттерном
Осторожная выкладка с подписанными порогами — здоровая практика, не паттерн отказа. Признак: у каждой фазы есть дата следующего решения и численный порог. У пилота без выхода нет ни даты, ни порога; вместо них обещание «скоро».
Регуляторная заморозка. В медицине, банке, при работе с персональными данными переход на полный поток может быть заблокирован регулятором или внутренним compliance. Это другой паттерн (compliance-paralysis), он лечится ранним вовлечением регулятора и юристов в дизайн процесса, не порогами фаз.
Стоящий маховик — техническая проблема: лог решений не превращается в обновления модели. Может сосуществовать с пилотом без выхода (часто именно так и происходит), но лечится другими инструментами. Если метрики пилота не растут несколько месяцев, и при этом лог решений не питает обучение, у вас два паттерна, и стоящий маховик нужно лечить первым.
Прототип, который правильно не масштабируется. Иногда пилот честно показывает: концепция не работает на полном трафике. Это валидный результат пилота, а не паттерн отказа. Признак: у команды есть письменный вывод «масштабирование нецелесообразно по таким-то причинам», и пилот закрыт. Если же команда не может ни масштабировать, ни закрыть, это пилот без выхода.
