Модуль p.4 · Урок 6
Урок 6: Risk register и change management — почему 95% AI-пилотов умирают и что делают те, кто дожил
Чему вы научитесь
- Отличать «технический риск модели» от настоящих причин, из-за которых промышленный AI-пилот не доходит до цеха и P&L
- Вести risk register по-взрослому: фиксировать риск, вероятность, импакт, владельца меры и момент, когда проект надо останавливать
- Разводить три разных провала: плохие данные, плохая интеграция и плохое принятие людьми
- Планировать change management для операторов и мастеров так, чтобы AI не воспринимался как внешний контроль или угроза увольнения
- Проверять, живой ли проект на самом деле, ещё до масштабирования: по owner, данным, бюджету, команде и режиму ручного отката
Самый дорогой миф в промышленном AI звучит так: «Если модель работает на демо, пилот почти победил». На практике пилот умирает не в ноутбуке data scientist, а между PoC и производственным процессом — на данных, интеграции, ИБ, санкционном контуре, ролях и принятии людьми. Поэтому этот урок не про качество модели, а про управляемость проекта. Если ROI ещё не посчитан, сначала вернитесь к уроку 1 этого модуля. Если не ясен контур по КИИ и санкциям, вернитесь к уроку p.3/02 про КИИ, уроку p.3/05 про санкционный контур и уроку p.3/08 про команду проекта.
Что на самом деле говорят цифры о «смерти пилотов»
| Наблюдение | Что это значит для CDTO | Источник |
|---|---|---|
| К концу 2025 года после PoC должно было быть брошено не менее 30% GenAI-проектов | Уже на горизонте первого года видно, что переход из пилота в эксплуатацию — не автоматический этап, а отдельный управленческий барьер | Gartner, 29.07.2024 |
| В январе 2026 Gartner уже писал, что по итогам 2025 года после PoC были брошены как минимум 50% GenAI-проектов | Массовый провал связан не с «сырыми моделями», а с плохими данными, рисками, стоимостью и неясной ценностью | Gartner, 26.01.2026 |
| 63% организаций либо не имеют, либо не уверены, что имеют AI-ready data practices | Если data foundation не собран заранее, пилот почти наверняка уйдёт в ручную доочистку и спор «модель плохая или данные плохие» | Gartner, 26.02.2025 |
| Gartner прогнозирует, что до конца 2026 года будет брошено 60% AI-проектов, не обеспеченных AI-ready data | Грязные данные — не техническая мелочь, а одна из самых дорогих причин досрочного закрытия проекта | Gartner, 26.02.2025 |
| В I&O только 28% AI use cases полностью успешны и соответствуют ожиданиям по ROI, а 20% проваливаются outright | Даже в ИТ-инфраструктуре, где процессы цифровее цеха, успех не является нормой. Для промышленности планку надо ставить ещё жёстче | Gartner, 07.04.2026 |
| Почти 2/3 компаний ещё не начали масштабировать AI по предприятию, а только 39% сообщают о влиянии на EBIT | Красивый локальный PoC и влияние на финансовый результат — это разные этапы зрелости | McKinsey, 05.11.2025 |
| Только 5% компаний получают устойчивый P&L-эффект от AI, а около 60% видят мало или не видят материальной пользы | Проект умирает чаще из-за слабой трансформационной дисциплины, чем из-за «не той модели» | BCG, 26.03.2026 |
Громкая формула «95% AI-пилотов умирают» на рынке действительно ходит, но как строгий benchmark её надо помечать как нужна проверка: в открытом доступе чаще цитируются пересказы MIT/NANDA и вторичные ссылки, чем чистый первоисточник с методикой. Для управленческого решения вам достаточно и более консервативных цифр Gartner, McKinsey и BCG: даже они показывают, что провал после PoC — обычный сценарий, а не исключение.
Матрица рисков AI-проекта
Ниже — минимальный risk register, который должен лежать на столе до запуска пилота. Не после инцидента, не после закупки, а до первого реального датасета.
| Риск | Вероятность | Импакт | Что ломается | Мера |
|---|---|---|---|---|
| Данные грязные, разметка неустойчивая, историчность слабая | Высокая на первом пилоте | Высокий | Модель не переносится в цех, команда спорит о качестве алгоритма вместо качества данных | Сначала data audit, карта источников, frozen dataset и критерии качества данных; если AI-ready data не подтверждены, пилот не стартует (Gartner, 26.02.2025) |
| Change management провален: мастера и операторы саботируют систему или не доверяют ей | Высокая | Высокий | AI остаётся «чужой надстройкой», рекомендации игнорируются, ручной обход становится нормой | До запуска определить, что меняется в смене, кто обучает, как измеряется принятие и где сохраняется ручной режим; сильное change management делает проект в производстве до 7 раз вероятнее к достижению целей (Prosci Manufacturing Change Management) |
| Интеграция с legacy-системами затягивается | Высокая | Высокий | Пилот работает только на выгрузках, не попадает в рабочий контур, а экономический эффект не подтверждается | До PoC зафиксировать точки интеграции: SCADA, MES, ERP, historian, OPC UA; отдельный budget line на интеграцию, а не только на модель |
| Регуляторика и ИБ режут проект на поздней стадии | Средняя, но в КИИ — высокая | Очень высокий | Проект нельзя законно ввести в эксплуатацию, даже если качество модели хорошее | Ещё на этапе идеи проверить КИИ и санкционный контур по уроку p.3/02 и уроку p.3/05; собрать роли из урока p.3/08 |
| Нет команды сопровождения после пилота | Средняя | Высокий | Пилот завершён, но некому вести модель, инциденты, обновления и drift | До бюджета на пилот заложить владельца эксплуатации, DevOps/MLOps, бизнес-owner и ИБ-owner |
| Галлюцинации или неправильные рекомендации автоматизируют ошибку | Средняя | Очень высокий в цехе | Растёт риск аварии, брака, неверных переключений и ошибочных решений | Не пускать LLM в полный автомат на критичных действиях; human-in-the-loop, правила блокировки и safe override mode обязательны, особенно для CPS и OT-контуров (Gartner, 12.02.2026) |
| Нарушен санкционный или поставочный контур | Средняя | Высокий | Сервис блокируется, обновления недоступны, контрактная схема разваливается | Для промышленного production-контура выбирать только жизнеспособный контур поставки; не смешивать sandbox и боевую эксплуатацию, вернуться к уроку p.3/05 |
| Уходит ключевой архитектор или внешний интегратор | Средняя | Средний–высокий | Архитектурные решения остаются «в головах», масштабирование зависает | Документировать архитектуру, контур ответственности, runbook, схему отката и модель сопровождения; не держать проект на одном человеке |
После заполнения этой таблицы спросите себя: какие из этих рисков у вас уже закрыты артефактами, а какие пока закрыты только уверенными словами команды. Всё, что закрыто словами, надо считать открытым риском.
flowchart TD
A[Есть конкретный KPI цеха и owner] --> B{Данные AI-ready?}
B -->|Нет| X[Пилот останавливаем и чиним data foundation]
B -->|Да| C{Контур законен и эксплуатационно допустим?}
C -->|Нет| Y[Возврат к p.3: КИИ, санкции, команда]
C -->|Да| D{Есть бюджет не только на PoC,
но и на интеграцию, обучение, сопровождение?}
D -->|Нет| Z[Проект уйдёт в пилотную витрину]
D -->|Да| E{Операторы обучены и есть ручной режим?}
E -->|Нет| M[Высокий риск саботажа и аварийного отката]
E -->|Да| N[Можно запускать controlled pilot]Что делают те, кто дожил до масштаба
Живой проект отличается от мёртвого не качеством презентации, а порядком решений.
- Сначала собирают data foundation, потом покупают AI. Это подтверждает и Gartner: отсутствие AI-ready data practices уже само по себе ставит проект под риск отказа (Gartner, 26.02.2025).
- Назначают owner не по инновациям, а по деньгам. У проекта должен быть владелец с KPI, который реально связан с EBITDA завода: OEE, выход годного, внеплановые простои, энергозатраты. Иначе эффект не доходит до P&L, что BCG прямо называет типичным местом эрозии ценности (BCG, 26.03.2026).
- Сразу закладывают бюджет на scale-out. Если в смете есть только PoC, но нет интеграции, обучения, мониторинга, MLOps и промышленной поддержки, проект почти наверняка застрянет между демонстрацией и эксплуатацией.
- Обучают операторов до запуска, а не после конфликта. Change management в производстве — не HR-декорация. Prosci прямо пишет, что с сильным change management производственный проект до 7 раз вероятнее достигнет целей (Prosci Manufacturing Change Management).
- Меряют успех не по метрике модели, а по KPI цеха. Gartner по I&O отдельно подчёркивает: выживают проекты, где AI встроен в существующие workflow и поддержан бизнес-руководителями, а не просто «технически работает» (Gartner, 07.04.2026).
Change management в три этапа
Технически правильный пилот часто погибает потому, что люди видят в нём внешний контроль, автоматический аудит их работы или прямую угрозу сокращения. Поэтому change management надо проектировать так же строго, как архитектуру.
Объявление. Сначала объясняют, зачем проект нужен цеху: какой KPI он улучшает, что меняется в рутине мастера и оператора, где граница автоматизации и кто принимает финальное решение. Не обещайте «никого не сократят», если вы этим не управляете. Обещайте только то, что можете гарантировать: ручной режим, обучение, понятную эскалацию ошибок и честные критерии успеха.
Обучение и parallel run. До ввода в боевой режим нужен период параллельной работы старого и нового процесса. Для цехового пилота обычно закладывают 2–4 недели на обучение и совместный прогон — это типовой управленческий диапазон, нужна проверка для конкретного производства. Цель этапа — не «прочитать инструкцию», а показать, как система ошибается, где она полезна и как оператор должен действовать при спорном результате.
Переход с постепенным включением и ручным режимом. Запуск должен быть gradual: сначала advisory mode, затем ограниченный production scope, затем full scope только после стабильных KPI. На всём критичном контуре сохраняйте safe override и понятный ручной откат. Для киберфизических систем это уже не опция, а базовое требование здравого смысла; Gartner отдельно подчёркивает необходимость ultimate human control и safe override mode (Gartner, 12.02.2026).
Чек-лист «Проект живой»
Проверьте, можете ли вы на каждый пункт ответить «да» без натяжки.
- Есть конкретный KPI цеха, а не общий тезис «повысим цифровизацию».
- Назначен owner, чей бонус или управленческий результат связан с этим KPI.
- Данные проверены на пригодность: источники, история, пропуски, разметка, дрейф.
- Посчитан не только PoC-бюджет, но и путь до эксплуатации: интеграция, MLOps, сопровождение, обучение.
- Юридический и ИБ-контур проверены до закупки сервиса или железа.
- Для КИИ и санкционного контура проект прошёл развилку из урока p.3/02 и урока p.3/05.
- Команда собрана заранее: бизнес-owner, ИТ, ИБ, владелец данных, эксплуатация; роли подробно разобраны в уроке p.3/08.
- Есть план инцидентов: кто останавливает систему, кто переводит на ручной режим, кто расследует ошибку.
- Операторы и мастера понимают, что именно меняется в их смене и как измеряется принятие решения системой.
- Пилот идёт в parallel run, а не сразу в blind automation.
- У проекта есть критерий kill decision: при каком результате его надо честно остановить, а не «дотягивать ещё квартал».
- Под пилот уже предусмотрен следующий шаг: либо scale-out, либо закрытие с извлечением уроков. Подробный модуль по операционному управлению и переходу от пилота к программе будет позже, но минимальная дисциплина должна быть уже сейчас.