Урок 1: Как запустить AI-пилот за 90 дней — календарь, артефакты, чек-листы

Чему вы научитесь

• Разбивать первый AI-пилот на три фазы по 30 дней как управляемый runbook, а не как набор несвязанных активностей
• Проверять по неделям, какие артефакты должны быть готовы до запуска и без чего пилот нельзя считать жизнеспособным
• Проводить жёсткий go/no-go на неделе 8, чтобы не тащить в pilot run сырой scope и неподготовленные данные
• Отделять discovery от readiness: идея, которая понравилась руководству, ещё не означает готовность данных, команды и контура
• Запускать parallel run так, чтобы к концу 90 дней у вас были не «ощущения команды», а подтверждённые метрики для решения о scale-out

Первый пилот почти никогда не проваливается потому, что «модель выбрали не ту». Он проваливается раньше — на выборе use case, на качестве данных, на позднем разговоре с ИБ, на размытом owner и на том, что никто не договорился, как именно проект переходит из demo в цех. Поэтому здесь нужен не «ещё один brainstorm», а runbook.

У этого урока простая цель: дать вам календарь первых 90 дней. Если вы ещё не собрали рычаг ценности, вернитесь к уроку p.1/03 про четыре рычага. Если не определились с контуром, перечитайте модуль p.2, а для TCO — урок p.2/06. Если не посчитан базовый бизнес-кейс, сначала откройте урок p.4/01 про ROI и урок p.4/04 про one-pager. Если пока неясно, кто именно должен сидеть в steering committee, посмотрите p.3/08 про команду AI-проекта и p.4/05 про адресное обоснование для стейкхолдеров.

Кейс Aker BP полезен здесь не из-за модели, а из-за дисциплины запуска: компания показывает, как industrial AI сокращает root cause analysis с недель до часов, но это происходит уже на готовой data foundation и операционной архитектуре, а не в vacuum (Aker BP, 16.09.2025). Кейс Татнефти полезен по другой причине: 38 топ-менеджеров и 28 ML-специалистов за короткий цикл сгенерировали 150+ идей применения AI — то есть запуск программы начался не с кода, а с организованного процесса отбора и приоритизации (Napoleon IT, 09.02.2023).

Три фазы 90-дневного пилота

Эта схема — не рыночный стандарт и не ГОСТ. Это рабочая управленческая рамка AIStudy: она полезна тем, что заставляет принимать решения вовремя и не прятать неготовность за словами «ещё чуть-чуть допилим».

Календарь «90 дней на одной странице»

Артефакты, без которых пилот нельзя считать управляемым

Ниже — минимальный пакет документов и решений. Он выглядит скучно, но именно он отделяет программу от «инновационной активности».

Подробно про risk register и change management уже было в уроке p.4/06. Здесь важно другое: к неделе 8 это должен быть не черновик в голове AI-чемпиона, а согласованный пакет.

Чек-лист Data readiness: 10 пунктов до старта пилота

1. Есть owner данных. Не просто «данные лежат в historian», а конкретный владелец, который отвечает за доступ, описание и ограничения.

2. Есть минимум одна непрерывная история. Если вы видите только текущий снимок системы, это ещё не dataset.

3. Источник данных стабилен. Теги, поля, протоколы и выгрузки не меняются каждый вторник без уведомления.

4. Понятны пропуски и quality issues. Вы знаете, где датчики врут, где пропадают события и где есть ручной ввод.

5. Есть связка данных с бизнес-событием. Для CV — с решением оператора, для PdM — с фактом отказа, для LLM — с correct answer или workflow outcome.

6. Есть baseline. Вы можете показать текущую частоту брака, простоя, перерасхода или времени анализа до AI.

7. Понятен контур доступа. Какие данные можно выносить, какие — только on-prem, какие попадают под 152-ФЗ, КИИ или коммерческую тайну.

8. Есть минимальная карта интеграций. Откуда данные приходят и куда prediction должен вернуться: SCADA, MES, EAM, ERP, ticketing.

9. Есть окно на доразметку и валидацию. Если разметка нужна, у неё есть ответственные и SLA, а не обещание «потом interns сделают».

10. Есть механизм промышленного обновления. Даже для пилота вы понимаете, как dataset будет обновляться на 9–12 неделе, а не только как собрать frozen sample.

Если на 3+ пунктах ответ честный «нет», пилот технически можно начать, но управленчески он будет ложным стартом.

Go/no-go meeting agenda на неделе 8

На go/no-go нельзя собирать полуторачасовую презентацию «в целом всё неплохо». Нужна жёсткая повестка.

1. Открытие и цель. Sponsor подтверждает, какой KPI процесса пилот должен улучшить и в какой срок.

2. Business case review. Product Owner показывает baseline, ожидаемый эффект и консервативный ROI. Если цифры не держатся, meeting заканчивается раньше.

3. Data readiness review. Data lead показывает качество данных, историю, пропуски, разметку, доступ и частоту обновления.

4. Architecture and contour review. Архитектор и ИБ подтверждают контур, интеграции, допустимость сервисов, требования 152-ФЗ, КИИ и ФСТЭК — см. p.3/01, p.3/02, p.3/03.

5. Vendor / internal team review. Кто реально строит пилот, что уже закуплено, что ещё зависит от подрядчика и как выглядит exit plan. Шаблон вопросов к вендору — в p.10/05.

6. Change and operations review. Кто обучает операторов, где manual override, как фиксируются ложные сигналы, кто on-call в первые недели.

7. Decision. Только три варианта: go, conditional go с датой закрытия 1–2 блокеров, либо no-go с возвратом в readiness.

Красные флаги первого пилота

Что делать дальше после первых 90 дней

В конце 12 недели у вас должно быть не «ощущение, что стало лучше», а одно из трёх решений.

1. Scale — пилот дал эффект, data path устойчив, операторы приняли систему, есть бюджет на тиражирование.
2. Pivot — идея ценная, но нужен другой контур, другой класс модели или другая зона процесса.
3. Kill — пилот честно закрывается. Это не провал, если вы сохранили уроки и не закопали ещё полгода в мёртвый use case.

Если дошли до этой точки, следующий урок модуля — как выйти из PoC-ада и не умереть на масштабировании.