Сопротивление AI показывает, какая часть системы работы ещё не собрана: цель, роль, навык, среда, ответственность или поток.

Этот справочник начинается там, где заканчивается диагностика. Если зона горит красным, откройте нужный раздел и выберите 1–2 действия на ближайший спринт.

Позиции людей — не тип личности. Один и тот же человек может быть сторонником в одном сценарии, продуктивным скептиком в другом и избегающим участником в третьем. Источник сопротивления показывает, что чинить. Позиция человека показывает, как действовать.

Оглавление

Перед работой можно пройти интерактивную диагностику, открыть карту сопротивления и свериться с чеклистом внедрения AI.

1. Цель и метрики

Когда использовать

Команда по-разному отвечает на вопрос «зачем нам AI». В отчётах растёт активность: логины, промпты, демо, включённые лицензии. Рабочий результат при этом не меняется: доставка не ускорилась, качество не стало стабильнее, поддержка не разгрузилась, бизнес-гипотезы не проверяются быстрее.

Что собрать быстро

[краткосрочно] Outcome contract на пилот

Действие: перед пилотом зафиксировать одну рабочую проблему и ожидаемый эффект.

Как сделать: на одной странице написать:

  • какой сценарий пробуем;
  • какая боль есть сейчас;
  • какой результат ждём;
  • какая метрика покажет эффект;
  • какая защитная метрика не должна ухудшиться;
  • когда останавливаем, меняем или масштабируем.

Результат: команда перестаёт обсуждать «использовали AI или нет» и начинает обсуждать изменение работы.

Источники: Prosci ADKAR, DORA metrics, SPACE framework.

[краткосрочно] Развести активность и эффект

Действие: явно разделить метрики внедрения и метрики результата.

Как сделать: использовать активность только как ранний сигнал: кто попробовал, где появились первые сценарии, где нужна помощь. Целью пилота сделать рабочий outcome: Lead Time, время ревью, доля переделок, стоимость операции, SLA, нагрузка на поддержку, скорость проверки гипотезы.

Результат: исчезает ритуальное использование ради отчёта.

Источники: DORA metrics, SPACE framework, BCG AI at Work.

[краткосрочно] Выбрать 1–2 стартовых сценария

Действие: сузить внедрение до конкретных задач.

Как сделать: выбрать сценарии, где есть понятный вход, критерии качества и быстрый цикл проверки: тесты, документация, анализ логов, генерация boilerplate, подготовка PR-описания, поиск edge cases.

Результат: команда получает первый проверяемый артефакт, а не общий лозунг «используйте AI».

Источники: Google PAIR Guidebook, Microsoft Human-AI Guidelines.

Что собрать за 1–2 месяца

[среднесрочно] Карта AI fit / no-fit

Действие: разделить задачи, где AI помогает, и задачи, где он ухудшает результат.

Как сделать: после каждой пробы фиксировать:

  • задача была внутри понятного сценария или нет;
  • какие данные и контекст нужны;
  • где AI ошибся;
  • как человек проверил результат;
  • стоит ли повторять сценарий.

Результат: снижается и слепая вера в AI, и преждевременный вывод «AI не работает».

Источники: Jagged Technological Frontier, Google PAIR Guidebook.

[среднесрочно] Value review каждые 2–4 недели

Действие: регулярно смотреть, что изменилось в работе.

Как сделать: на короткой встрече пройти 4 вопроса:

  • где AI реально помог;
  • где создал шум;
  • какая метрика сдвинулась;
  • что меняем в следующем цикле.

Результат: пилот не превращается в вечный эксперимент без решения.

Источники: Kotter 8-Step Change Model, DORA metrics.

Что строить на квартал+

[долгосрочно] Слой метрик от привычки до бизнеса

Действие: собрать метрики в цепочку: активность → доставка → качество/ограничения → бизнес-эффект.

Как сделать: для каждого сценария указать:

  • ранний сигнал: люди попробовали и повторяют;
  • delivery-сигнал: задача проходит быстрее или ровнее;
  • guardrail: качество, безопасность, стоимость, нагрузка на ревью не ухудшились;
  • business-сигнал: SLA, поддержка, конверсия, time-to-market, стоимость операции или скорость гипотез изменились.

Результат: AI перестаёт быть отдельной инициативой и становится частью операционной системы.

Источники: SPACE framework, DORA metrics, McKinsey State of AI.

Как работать с позициями людей

  • Сторонник: дать роль проводника рабочих сценариев. Просить показывать не только удачи, но и ограничения, проверки, стоимость ошибки.
  • Продуктивный скептик: дать право сформулировать критерии успеха, риски и условия остановки пилота.
  • Избегающий участник: дать маленькую задачу с личной пользой и понятным результатом. Без публичного давления.
  • Ритуальный пользователь: перестать спрашивать «использовал AI?». Спрашивать, какой рабочий артефакт появился и как проверено качество.
  • Активный блокер: зафиксировать ожидание: спорить через факты, риски и проверяемые гипотезы. После понятного безопасного пути недобросовестный срыв — управленческая граница.

Ошибки

  • Делать KPI из количества промптов или логинов.
  • Запускать «AI для всех задач» без стартовых сценариев.
  • Считать демо доказательством изменения работы.
  • Масштабировать пилот до решения «масштабировать / изменить / остановить».

2. Страх за роль и рост

Когда использовать

Люди спорят, как AI меняет обучение младших, статус экспертов, роль senior/lead и профессиональное суждение. Часть команды боится выглядеть слабее. Часть экспертов защищает старую модель роста. Хорошая проверка качества может ошибочно выглядеть как сопротивление.

Что собрать быстро

[краткосрочно] Role redesign canvas

Действие: проговорить, что меняется в роли человека.

Как сделать: для каждой роли заполнить 4 блока:

  • что человек делегирует AI;
  • что обязан проверять сам;
  • какие навыки нельзя терять;
  • как теперь выглядит рост.

Результат: тревога про замену переводится в конкретные ожидания.

Источники: Prosci ADKAR, MIT Sloan / BCG Responsible AI.

[краткосрочно] Безопасный первый опыт

Действие: дать первый опыт без публичного экзамена.

Как сделать: выбрать реальную задачу, посадить участника рядом с наставником, оставить человека «за рулём». AI предлагает, человек принимает решение и объясняет проверку.

Результат: человек получает опыт контроля, а не ощущение, что его сравнивают с машиной.

Источники: Edmondson psychological safety, Baldwin & Ford transfer of training.

[краткосрочно] Договор «AI не снижает планку ответственности»

Действие: отдельно сказать, что AI не отменяет профессиональное суждение.

Как сделать: зафиксировать простое правило: человек может использовать AI, обязан понимать результат и отвечает за итог. Если не может объяснить решение, оно не готово.

Результат: качество-minded скепсис становится нормой, а не признаком нелояльности.

Источники: Microsoft Human-AI Guidelines, NIST AI RMF.

Что собрать за 1–2 месяца

[среднесрочно] Growth ladder с AI

Действие: обновить ожидания по уровням.

Как сделать: описать, что junior, middle, senior и lead должны уметь делать с AI. Например: junior использует AI как объясняющий инструмент и учится проверять; middle ускоряет типовые задачи; senior проектирует проверки и границы применимости; lead меняет поток работы и правила команды.

Результат: AI становится частью роста, а не угрозой росту.

Источники: Prosci AI adoption, Training transfer workplace factors.

[среднесрочно] Listening sessions по ролям

Действие: собрать тревоги не общим опросом, а по группам ролей.

Как сделать: отдельно поговорить с junior, middle, senior, lead, QA, аналитиками, менеджерами. Фиксировать не жалобы, а изменения в ответственности, статусе, обучении и принятии решений.

Результат: появляются конкретные изменения в правилах, обучении и ожиданиях.

Источники: Oreg resistance to change, O’Donovan & McAuliffe review.

Что строить на квартал+

[долгосрочно] Обновлённая модель компетенций

Действие: включить AI-навыки в развитие роли.

Как сделать: добавить в competency model:

  • постановку задачи AI;
  • проверку результата;
  • понимание ограничений;
  • способность объяснить решение;
  • умение улучшать командные сценарии;
  • наставничество других.

Результат: AI перестаёт быть факультативным трюком и становится частью профессионального стандарта.

Источники: MIT Sloan / BCG Responsible AI, NIST AI RMF Core.

Как работать с позициями людей

  • Сторонник: сделать примером практики, не героем «я всех заменил». Просить показывать ход мысли, проверки и ошибки.
  • Продуктивный скептик: перевести тревогу за профессию в learning policy: какие навыки сохраняем, что проверяем, где AI нельзя использовать как костыль.
  • Избегающий участник: дать приватную или парную практику. Разрешить сказать «я не понял ответ AI» без санкции.
  • Ритуальный пользователь: спрашивать, чему научился, что проверил сам, где AI ошибся. Не принимать «я использовал AI» как результат роста.
  • Активный блокер: если человек высмеивает новичков или блокирует обучение других, зафиксировать ожидание от роли: развивать команду, а не удерживать знание как власть.

Ошибки

  • Продавать AI как «теперь junior не нужны».
  • Называть любую тревогу ретроградством.
  • Давать обучение без изменения ожиданий по ролям.
  • Делать публичные соревнования «кто лучше промптит».

3. Умение и инструмент

Когда использовать

Команда попробовала AI, получила слабый результат и решила «AI не работает». Причина не разобрана: не хватило навыка, сценарий не подходил, инструмент не видел контекст, правила мешали дать данные, задача была за пределами применимости.

Что собрать быстро

[краткосрочно] Разбор skill / tool / task после слабой пробы

Действие: каждый слабый результат разбирать на три причины.

Как сделать: после неудачной пробы спросить:

  • человек умел поставить задачу и проверить ответ;
  • инструмент имел нужный контекст;
  • сама задача подходит для AI.

Результат: команда не делает общий вывод из одного плохого опыта.

Источники: Jagged Technological Frontier, Algorithm aversion.

[краткосрочно] Hands-on lab: участник за рулём

Действие: заменить вебинар рабочей сессией.

Как сделать: участник сам решает свою задачу с AI, наставник рядом. Наставник не забирает клавиатуру, а помогает формулировать запрос, добавлять контекст и проверять результат.

Результат: знание переносится в работу.

Источники: Baldwin & Ford transfer of training, Training transfer workplace factors.

[краткосрочно] Failure examples

Действие: показать не только удачные промпты, но и ошибки.

Как сделать: собрать 5–10 примеров, где AI уверенно ошибся, потерял контекст, придумал API, сломал тесты или предложил небезопасное решение. Для каждого указать, как человек обнаружил ошибку.

Результат: доверие становится калиброванным: без слепой веры и без полного отказа.

Источники: Microsoft Human-AI Guidelines, Google PAIR Guidebook.

Что собрать за 1–2 месяца

[среднесрочно] Библиотека сценариев на реальных задачах

Действие: упаковать повторяемые способы работы.

Как сделать: для каждого сценария описать:

  • когда применять;
  • входные данные;
  • пример запроса;
  • критерии качества;
  • типичные ошибки;
  • как проверять результат.

Результат: опыт сторонников перестаёт жить у них в голове.

Источники: Google PAIR Guidebook, Prosci AI adoption.

[среднесрочно] Backlog улучшений AI-среды

Действие: фиксировать, что мешает инструменту работать хорошо.

Как сделать: собирать проблемы: нет доступа к репозиторию, IDE, CI, внутренним документам, логам, безопасному контексту, быстрым моделям, approved tools. Разделить: что чинит команда, что платформа, что security, что закупки.

Результат: «люди не умеют» не маскирует слабый инструмент и плохую среду.

Источники: NIST AI RMF, IBM AI adoption challenges.

Что строить на квартал+

[долгосрочно] Evaluation harness для повторяемых сценариев

Действие: проверять качество AI-результата не только глазами энтузиаста.

Как сделать: для важных сценариев собрать набор тестовых задач, эталонные ответы, критерии качества и регулярный прогон при смене модели/инструмента.

Результат: команда видит, где инструмент реально стал лучше или хуже.

Источники: Google PAIR Guidebook, NIST AI RMF Core.

Как работать с позициями людей

  • Сторонник: просить превращать удачные сценарии в воспроизводимые playbooks с failure modes. Не делать его единственным AI wizard.
  • Продуктивный скептик: дать роль проверяющего: критерии качества, failure cases, пороги применимости.
  • Избегающий участник: дать маленький safe-сценарий, шаблон и наставника рядом. Цель — первый рабочий артефакт.
  • Ритуальный пользователь: требовать проверенный артефакт, а не скриншот чата с AI.
  • Активный блокер: просить факты: задача, результат, критерии, повторяемость. Если инструмент слаб — чинить. Если факты искажаются после ясного запроса — управленческая граница.

Ошибки

  • После первой слабой пробы объявить «AI не работает».
  • Учить промптам без реальных задач.
  • Показывать только красивые демо.
  • Считать проблему навыком, когда официальный инструмент не видит контекст.

4. Среда и правила

Когда использовать

Официальный путь работы с AI неудобен или неясен. Люди обходят его, боятся пользоваться инструментом или используют запрещённые сервисы. Правила есть в презентации, реальный путь медленный, непонятный и не встроен в работу.

Что собрать быстро

[краткосрочно] One-page AI use policy

Действие: сделать правила короткими и применимыми.

Как сделать: на одной странице описать:

  • что можно;
  • что нельзя;
  • что требует согласования;
  • какие сервисы разрешены;
  • какие данные можно передавать;
  • куда идти с нестандартным случаем.

Результат: люди перестают гадать и придумывать свои правила.

Источники: NIST AI RMF, MIT Sloan / responsible AI.

[краткосрочно] Официальный путь должен быть проще обходного

Действие: проверить путь пользователя от идеи до первого результата.

Как сделать: пройти руками: получить доступ, открыть инструмент, подключить рабочий контекст, понять правила данных, получить помощь. Засечь время и точки ожидания.

Результат: видно, почему люди обходят правила.

Источники: Sociotechnical systems, IBM AI adoption challenges.

[краткосрочно] Exception lane

Действие: дать путь для спорных случаев.

Как сделать: вместо «нельзя» добавить короткую эскалацию: кто отвечает, какие данные нужны, за сколько дней дадут ответ, как фиксируется решение.

Результат: люди не прячут сложные сценарии и не уходят в shadow AI.

Источники: NIST AI RMF Core, MIT CISR / AI governance.

Что собрать за 1–2 месяца

[среднесрочно] Safe context packaging

Действие: научить команду безопасно давать AI контекст.

Как сделать: подготовить шаблоны: как обезличивать данные, как давать фрагмент кода, как описывать ограничения, как ссылаться на внутреннюю документацию без утечки.

Результат: качество AI растёт без нарушения правил данных.

Источники: Google PAIR Guidebook, NIST AI RMF.

[среднесрочно] RACI по AI-решениям

Действие: определить, кто принимает решения по инструментам, данным, исключениям и рискам.

Как сделать: прописать роли: команда, платформа, security, legal, procurement, engineering leadership. Для каждого типа решения указать owner и срок ответа.

Результат: правила перестают быть абстрактными и начинают работать.

Источники: NIST AI RMF Core, Deloitte State of AI.

Что строить на квартал+

[долгосрочно] Amnesty / discovery для shadow AI

Действие: сначала понять реальное использование, затем строить последствия.

Как сделать: провести безопасный сбор фактов: какие сервисы используют, почему официальный путь не подходит, какие данные уходят, какие задачи решают. Не охотиться на виноватых в первом проходе. После появления удобного безопасного пути зафиксировать последствия за обход.

Результат: организация получает реальную картину риска и шанс сделать официальный путь рабочим.

Источники: Oreg resistance to change, NIST AI RMF.

Как работать с позициями людей

  • Сторонник: сделать проводником безопасного официального пути. Ограничить speed hacking.
  • Продуктивный скептик: дать роль threat model reviewer. Пусть собирает спорные случаи и помогает перевести правила на язык команды.
  • Избегающий участник: провести через официальный путь в паре. Дать памятку «можно / нельзя / спросить».
  • Ритуальный пользователь: проверить, не вызван ли ритуал страхом нарушить правила. Дать approved-сценарий с реальной пользой.
  • Активный блокер: если человек использует правила как оружие «ничего нельзя», требовать конкретный риск и путь решения. Если обходит безопасный официальный путь после его появления — управленческие последствия.

Ошибки

  • Написать длинную политику и не проверить путь пользователя.
  • Запретить всё и получить shadow AI.
  • Отдать правила только security без участия команд.
  • Наказывать за обход до появления рабочего официального пути.

5. Ответственность

Когда использовать

В команде неясно, кто отвечает за результат, если участвовал AI. Автор говорит «это написал AI». Ревьюер не понимает, что проверять. Менеджер хочет скорость, инженер боится отвечать за чужой output.

Что собрать быстро

[краткосрочно] Правило владения результатом человеком

Действие: зафиксировать простое правило ответственности.

Как сделать: кто поручил задачу AI и принял результат, тот владеет итогом. AI не является автором, ревьюером или ответственным за качество.

Результат: исчезает серая зона «это не я, это AI».

Источники: NIST AI RMF Core, Microsoft Human-AI Guidelines.

[краткосрочно] AI-assisted PR template

Действие: добавить короткий шаблон для PR, где участвовал AI.

Как сделать: в описании PR указать:

  • где помог AI;
  • что человек проверил;
  • какие тесты прошли;
  • какие риски остались;
  • что ревьюеру смотреть внимательнее.

Результат: ревьюер получает контекст, а автор показывает владение результатом.

Источники: NIST AI RMF, AI-generated PR review evidence.

[краткосрочно] Право отказаться от AI-output

Действие: разрешить человеку не принимать результат AI.

Как сделать: правило: если человек не может объяснить результат, проверить его или безопасно встроить в работу, результат не используется.

Результат: снижается страх «меня заставят отвечать за непонятный код».

Источники: Google PAIR Guidebook, Microsoft Human-AI Guidelines.

Что собрать за 1–2 месяца

[среднесрочно] Risk-tiered review

Действие: разделить проверки по уровню риска.

Как сделать: низкорисковые изменения проверяются лёгким чеклистом. Высокорисковые изменения требуют дополнительных тестов, security/privacy review, парного ревью или решения архитектурного owner.

Результат: команда не тормозит всё одинаково и не пропускает рискованные изменения без внимания.

Источники: NIST AI RMF, DORA metrics.

[среднесрочно] Reviewer enablement

Действие: научить ревьюеров проверять AI-assisted work.

Как сделать: дать примеры типовых ошибок: hallucinated API, неучтённые edge cases, скрытая сложность, слабые тесты, несовместимость с архитектурой, security/privacy риск.

Результат: ревью перестаёт быть моральным спором и становится проверяемой практикой.

Источники: AI-generated PR review evidence, SPACE framework.

Что строить на квартал+

[долгосрочно] Incident learning loop

Действие: разбирать ошибки AI-assisted work без охоты на виноватых.

Как сделать: если AI-результат привёл к дефекту, разобрать:

  • где человек доверился без проверки;
  • какого контекста не хватило;
  • какой тест должен был поймать ошибку;
  • какое правило или шаблон нужно обновить.

Результат: ответственность усиливается через обучение, а не страх.

Источники: Edmondson psychological safety, NIST AI RMF.

[долгосрочно] Журнал решений для агентных процессов

Действие: для более автономных AI-процессов фиксировать ключевые решения.

Как сделать: логировать цель, входные ограничения, важные действия агента, человеческие точки контроля, принятое решение и владельца результата.

Результат: у команды есть traceability без требования хранить весь чат как юридический мусор.

Источники: NIST AI RMF Core, Microsoft Human-AI Guidelines.

Как работать с позициями людей

  • Сторонник: попросить сделать эталонный AI-assisted PR. Следить, чтобы скорость не обходила ревью.
  • Продуктивный скептик: дать владение risk checklist и review rubric. Перевести «я не буду отвечать» в список proofs, после которых отвечать разумно.
  • Избегающий участник: дать парную задачу и маленький чеклист проверки. Разрешить отказаться от AI-output, если не может объяснить.
  • Ритуальный пользователь: убрать галочку «AI used». На ревью спрашивать: что проверил, какие тесты прошли, какой риск остался.
  • Активный блокер: если требует невозможный уровень доказательств для низкорисковых изменений, договорить уровни риска. Если скрывает участие AI после ясного правила раскрытия — управленческие последствия.

Ошибки

  • Перекладывать ответственность на AI.
  • Требовать полный transcript вместо короткого evidence/context.
  • Проверять все изменения одинаково тяжело.
  • Считать disclosure заменой тестов и ревью.

6. Поток

Когда использовать

AI ускорил кодинг, но сквозная доставка не изменилась. Очередь переехала в ревью, QA, security, релиз, бизнес-валидацию или поддержку. Разработчики чувствуют скорость, система доставки показывает ожидание.

Что собрать быстро

[краткосрочно] Карта потока работы с AI

Действие: нарисовать путь задачи от идеи до результата.

Как сделать: отметить этапы: постановка задачи, разработка, ревью, тесты, security, релиз, бизнес-проверка. Для каждого этапа указать время работы, время ожидания, очередь и роль AI.

Результат: команда видит, где AI ускорил работу и куда переехала пробка.

Источники: DORA metrics, Sociotechnical systems.

[краткосрочно] Защитное ограничение по ревью

Действие: не давать AI генерировать больше работы, чем система способна проверить.

Как сделать: ввести WIP-лимит на открытые PR, лимит размера PR или явную политику маленьких изменений. Отдельно смотреть очередь ревью.

Результат: локальное ускорение не превращается в перегруз соседнего этапа.

Источники: DORA metrics, AI-generated PR review evidence.

[краткосрочно] Доска наблюдения за потоком

Действие: смотреть не только скорость кодинга.

Как сделать: выбрать 4–6 сигналов: Lead Time, время ревью, размер PR, доля переделок, change failure, количество задач в очереди, время до бизнес-валидации.

Результат: обсуждение возвращается к прохождению задачи целиком.

Источники: DORA metrics, SPACE framework.

Что собрать за 1–2 месяца

[среднесрочно] Start with bottleneck role

Действие: внедрять AI там, где узкое место, а не только у разработчиков.

Как сделать: если очередь в аналитике — помогать аналитике. Если в QA — помогать тест-дизайну и автотестам. Если в ревью — улучшать PR size, описание, предварительные проверки.

Результат: AI начинает менять сквозной поток, а не только локальную занятость.

Источники: DORA metrics, McKinsey State of AI.

[среднесрочно] Уменьшение размера партий

Действие: использовать AI для меньших и чаще проверяемых изменений.

Как сделать: просить AI помогать дробить задачу, готовить маленькие PR, писать тесты, обновлять документацию и делать понятное описание изменения.

Результат: ревью и релиз становятся устойчивее.

Источники: DORA metrics, SPACE framework.

Что строить на квартал+

[долгосрочно] Пакет внедрения для следующей команды

Действие: масштабировать не лозунг, а рабочий пакет.

Как сделать: после пилота собрать:

  • сценарии, которые сработали;
  • ограничения;
  • метрики до/после;
  • правила ревью;
  • WIP-ограничения;
  • шаблоны;
  • ошибки;
  • условия, где повторять нельзя.

Результат: следующая команда получает готовый способ работы, а не вдохновляющую презентацию.

Источники: Kotter 8-Step Change Model, Prosci ADKAR.

Как работать с позициями людей

  • Сторонник: дать задачу показать системный эффект, не только личные wins. Ограничить роль «генератора PR».
  • Продуктивный скептик: попросить найти, куда переехала очередь, где выросли переделки и потери качества.
  • Избегающий участник: проверить перегруз. Снизить WIP, дать protected learning time и сценарий, который уменьшает боль на узком этапе.
  • Ритуальный пользователь: убрать отчёты активности. Смотреть движение работы: время этапа, очередь, качество, переделки.
  • Активный блокер: отделить честный сигнал перегруза от намеренной блокировки. Перегруз чинить через capacity и WIP. Недобросовестный срыв договорённостей после явной договорённости — управленческая граница.

Ошибки

  • Мерить скорость написания кода и игнорировать delivery.
  • Разгонять разработку при перегруженном ревью.
  • Масштабировать до устойчивого пилота.
  • Не включать QA, security, аналитику, DevOps и бизнес-валидацию.

Быстрый 30–60–90 план

Первые 30 дней

  • Пройти диагностику и выбрать одну красную зону.
  • Зафиксировать outcome contract на один пилот.
  • Выбрать 1–2 сценария на реальных задачах.
  • Провести hands-on сессию: участник за рулём.
  • Ввести правило: человек владеет результатом AI-assisted work.
  • Нарисовать текущий поток задачи и найти очередь.

31–60 дней

  • Собрать библиотеку сценариев и failure examples.
  • Обновить правила: можно / нельзя / спросить.
  • Добавить AI-assisted PR template.
  • Ввести risk-tiered review.
  • Провести value review и решить: масштабировать, изменить или остановить.
  • Развести активность AI и метрики результата.

61–90 дней

  • Обновить ожидания по ролям и росту.
  • Собрать backlog улучшений AI-среды.
  • Настроить доску наблюдения за потоком.
  • Упаковать пакет внедрения для следующей команды.
  • Пересмотреть governance: роли, исключения, ответственность, эскалация.
  • Принять решение по масштабированию только после проверки результата и защитных метрик.

Источники