Модуль p.11 · Урок 4
Урок 4: 12 антипаттернов AI-программы — провалы, которые вы не хотите повторить
Содержание
- Чему вы научитесь
- 12 антипаттернов, которые убивают AI-программу
- Бонус-антипаттерн: Cloud default для КИИ
- Три коротких сценария провала
- Сценарий 1. «Сильный ноутбук, нулевая интеграция»
- Сценарий 2. «Центральный AI-офис против цеха»
- Сценарий 3. «Мы купили платформу, значит программа уже запущена»
- Как лечить программу в первые 30 дней после диагностики
- Как провести экспресс-диагностику программы за одну встречу
- Как использовать этот список без бюрократии
Чему вы научитесь
- Узнавать по ранним сигналам антипаттерны, которые убивают AI-программу ещё до первой настоящей экономии
- Разводить технологические, управленческие, культурные и контурные причины провала, а не сваливать всё на «плохое принятие людьми»
- Исправлять антипаттерны по одному, не запуская новый пилот ради маскировки старых проблем
- Использовать RFP, TCO и ownership discipline как защиту от vendor lock-in, fabricated ROI и бесхозных моделей
- Быстро диагностировать, когда программу надо приостановить и пересобрать, а не «дотягивать до отчёта»
Если в p.4/06 мы разбирали, почему пилоты умирают, то здесь разбираем, как именно выглядят провалы в повседневной жизни программы. Антипаттерн — это не абстрактный риск. Это повторяющийся способ сломать проект руками самой организации.
Хорошая новость в том, что антипаттерны почти всегда видно заранее. Плохая — большинство команд их видит, но трактует как «временные неудобства».
flowchart LR
A[Слабая задача] --> B[Нет владельца]
B --> C[Нет данных]
C --> D[Пилот]
D --> E[Красивое демо]
E --> F[Не масштабируется]
F --> G[Отбрасывают]
G --> H[Руководство теряет веру]
H --> I[Следующий пилот с нуля]
I --> A
C -->|Разрыв цикла| J[Аудит данных и владелец]12 антипаттернов, которые убивают AI-программу
| Антипаттерн | Как выглядит | Почему возникает | Ранний сигнал | Как исправить |
|---|---|---|---|---|
| 1. Model-first вместо data-first | Сначала обсуждают модели и демо, потом выясняют, что данных нет | Команда хочет быстрый вау-эффект | На первой встрече больше разговоров про LLM, чем про dataset и baseline | Возвращайтесь к data audit и readiness; см. p.11/01 |
| 2. Moving target | Scope меняется каждые две недели | Sponsor не договорился, какой KPI главный | В backlog постоянно добавляются новые use cases без kill решения старых | Freeze scope на pilot window и введите change control |
| 3. Integration deferral | «Интегрируем после пилота» | Команда боится показать сложность legacy-контуров | В PoC нет SCADA/MES/EAM path, есть только CSV и ноутбук | Проектируйте integration architecture до запуска |
| 4. Vendor lock-in без exit clauses | Вендор обещает чудо, но не даёт export данных и моделей | Закупка смотрит на demo, а не на выход из контракта | В RFP нет ownership, portability, escrow и exit-процедур | Используйте шаблон из p.10/05 |
| 5. AI-чемпион без mandate | AI-чемпион делает слайды, но не может принять ни одно решение | Sponsor делегировал тему без полномочий | Любое решение уходит на три недели «согласований» | Зафиксируйте mandate, sponsor и steering committee |
| 6. ROI fabrication | В one-pager рисуют фантастическую экономию | Проект продают ради approval любой ценой | ROI не бьётся с baseline и TCO | Возвращайтесь к p.4/01 и считайте консервативно |
| 7. Ignore TCO | Бюджет посчитан только на PoC | Все влюбились в CapEx демо | В смете нет сопровождения, MLOps, интеграции, retraining | Считайте TCO на 3 года, а не только пилот |
| 8. No owner | Все формально «поддерживают», но никто не отвечает | Проект межфункциональный, поэтому ownership размыт | На вопрос «кто убьёт пилот, если он слабый?» тишина | Назначьте owner с KPI из EBITDA |
| 9. Operator-as-problem | Сопротивление людей трактуют как саботаж | Проект запустили сверху вниз, не изменив workflow | Операторы обходят систему и возвращаются к блокноту | Включите operator feedback в дизайн и внедрение |
| 10. Top-down без domain input | AI-решение проектируют без технологов | Центральная команда считает цех «чёрным ящиком» | Модель красиво выглядит, но не учитывает физику процесса | Встраивайте domain expert в core team с первой недели |
| 11. Скрытый AI | От пользователя скрывают, что совет даёт модель | Руководство боится вопросов и сопротивления | Люди узнают про AI из слухов и теряют доверие | Прямо объясните, где AI советует, а где человек решает |
| 12. Nothing-to-win для operator | От оператора требуют нового поведения, но бонус не меняется | Бизнес не продумал мотивацию и нагрузку | «Зачем мне это, если премия та же, а работы больше?» | Связывайте новый workflow с понятной выгодой и поддержкой |
Бонус-антипаттерн: Cloud default для КИИ
| Как выглядит | Почему возникает | Ранний сигнал | Как исправить |
|---|---|---|---|
| Команда по умолчанию запускает AI в внешнем облаке, хотя актив связан с КИИ или чувствительными данными | Удобнее и быстрее сделать demo, чем пройти контурные ограничения | На ранних встречах звучит Azure OpenAI, AWS Bedrock или внешний SaaS без разговора с ИБ | Сначала проходите фильтр p.3/02 и p.3/05, а уже потом выбираете стек |
Этот бонус-антипаттерн особенно опасен тем, что на первых неделях он выглядит как «мы очень быстро двигаемся», а потом внезапно превращается в стоп-кран от ИБ и регуляторики.
Три коротких сценария провала
Сценарий 1. «Сильный ноутбук, нулевая интеграция»
Команда делает отличный PoC на выгрузке, качество модели всех радует, sponsor доволен. Через месяц выясняется, что prediction некуда встроить: MES не готова, historian не даёт нужную частоту, сервис-деск не умеет принимать рекомендации. Это не проблема модели. Это чистый integration deferral.
Сценарий 2. «Центральный AI-офис против цеха»
В центральном офисе есть сильная ML-команда, но на проект почти не привлекают технологов и мастеров. Модель запускают сверху, операторы воспринимают её как внешний контроль и быстро находят обход. На бумаге change management есть, в жизни — operator-as-problem и top-down without domain input.
Сценарий 3. «Мы купили платформу, значит программа уже запущена»
Компания покупает дорогой vendor stack, но не фиксирует ownership данных, моделей и выхода из контракта. Через год оказывается, что всё работает только вместе с конкретным интегратором, а команды внутри не появилось. Это vendor lock-in плюс no owner.
Как лечить программу в первые 30 дней после диагностики
Распознавание антипаттерна ничего не даёт, если дальше команда снова уходит в обычный ритм. Поэтому после диагностики полезно не «запланировать transformation на полгода», а провести короткий реабилитационный цикл.
Неделя 1 — заморозьте новые инициативы. Не добавляйте новые use cases, пока не понятно, почему буксуют текущие. Это особенно важно при
Moving targetиAI-чемпион без mandate.Неделя 1 — перепроверьте owner и success criteria. У каждого живого use case должен быть один владелец, baseline и kill criteria. Если этого нет, use case временно выводится из активной фазы.
Неделя 2 — разберите data path и integration path. Схема «ноутбук → CSV → презентация» должна быть либо честно признана временной, либо закрыта реальной архитектурой. Иначе
Model-firstиIntegration deferralбудут повторяться бесконечно.Неделя 3 — пересоберите контрактный и санкционный контур. Если есть vendor lock-in, мутные права на данные или внешний cloud по умолчанию для чувствительного актива, это надо лечить до следующего rollout, а не после него.
Неделя 4 — проведите operator review без фильтра менеджмента. Поговорите с мастерами, инженерами смены и реальными пользователями. Именно здесь всплывают
Operator-as-problem,Скрытый AIиNothing-to-win.
Этот 30-дневный цикл не заменяет полноценную программу исправления. Он нужен, чтобы снять системное самообманное напряжение и вернуть управление проектом в реальные руки.
Как провести экспресс-диагностику программы за одну встречу
Назовите owner каждого живого use case. Если владелец размывается между тремя функциями, фиксируйте антипаттерн
No owner.Попросите показать baseline и TCO. Если команда показывает только accuracy и demo, фиксируйте
ROI fabricationилиIgnore TCO.Спросите, куда prediction встраивается в процесс. Если ответ «потом в MES», фиксируйте
Integration deferral.Поговорите с оператором, а не только с командой проекта. Если у него нет выгоды и нет доверия, вы увидите
Operator-as-problemиNothing-to-win.Проверьте контрактную и контурную сторону. Если нет exit clauses и ясного legal/security path, у вас одновременно
Vendor lock-inи, возможно,Cloud default для КИИ.
Как использовать этот список без бюрократии
Антипаттерны полезны не для того, чтобы составить длинный отчёт. Они полезны как язык early warning. Хороший AI-чемпион раз в месяц проходит по этому списку и задаёт четыре вопроса:
- Что у нас уже выглядит как системный паттерн?
- Что можно исправить внутри квартала?
- Что требует решения sponsor, а не project team?
- Какой use case надо остановить, чтобы не отравлять репутацию всей программы?
Если отвечать на эти вопросы честно, большинство провалов будет заметно ещё до того, как они попадут в board deck.