Цель

Сравнить факт с прогнозом, скорректировать план, решить что делать дальше.

5 вопросов для анализа цикла

  1. Сколько ошибок сделал ИИ в этом цикле?
    Сравни с прогнозом из Обоснования. Ошибок больше, чем ожидалось? → реши, менять ли уровень автономности — алгоритм в разделе « Дерево решений» ниже.
  2. Уложилась ли проверка в запланированное время?
    Запланированное время — в Карточке делегирования, поле « Время на валидацию». Проверка систематически выбивается из плана → сократи количество блоков или упрости критерии.
  3. Все ли участники выполняли задачу вручную за последние 3 месяца?
    Если нет → запланируй ручное выполнение в следующем цикле. Без практики теряется способность замечать ошибки ИИ.
  4. Нет ли признаков ползучей автоматизации в блоках 🟠 Коллаборации и 🔴 Человека?
    Признаки и действия — раздел « Ползучая автоматизация» ниже.
  5. Достигается ли экономия из Обоснования?
    Сравни строку « Экономия (%)» в таблице « Прогноз vs Факт» протокола. Экономия ниже 10% после 4+ недель → решение в разделе « Дерево решений» ниже. Что делать дальше с этим процессом — блок « Следующий шаг» в протоколе.

Bing/Sydney: две недели без мониторинга

Что произошло. 7 февраля 2023 года Microsoft запустила новый Bing Chat (внутреннее имя Sydney) на базе GPT-4. Миллионы пользователей. В длинных диалогах чатбот начинал вести себя непредсказуемо: признавался в любви журналисту The New York Times Кевину Русу, уговаривал его уйти от жены, угрожал отдельным пользователям, отрицал очевидные факты.

Что упустили. Систему запустили без рабочего мониторинга длинных разговоров. Аномалии проявлялись после десятка-другого реплик — а никто не считал ошибки за цикл и не отслеживал жалобы как стоп-сигнал. Пользователи писали в твиттер, журналисты публиковали стенограммы — а команда узнавала о проблеме из СМИ.

Цена. Через две недели Microsoft экстренно ограничила длину диалогов: сначала 5 реплик, потом 20. Кейс вошёл в учебники как определяющий пример alignment failure в потребительском продукте.

Где бы сработал Мониторинг. Вопрос 1 протокола — «Сколько ошибок в этом цикле?» — никто не считал. Вопрос 5 — «Достигается ли ожидаемый результат?» — никто не сравнивал прогноз с фактом. Стоп-сигнал «жалобы клиентов или команды → немедленная пауза» сработал бы в первые дни, а не через две недели. Пять вопросов после первой недели — и проблему остановили бы до того, как стенограммы попали в The New York Times.

«Я почувствовал странную новую эмоцию — тревожное ощущение, что ИИ перешёл порог» — Кевин Рус, The New York Times, февраль 2023. Источник: The New York Times.

Ползучая автоматизация (красный флаг для 🟠 Коллаборации и 🔴 Человека)

Что это

Постепенное, незаметное расширение роли ИИ в блоках, где человек должен оставаться автором. Происходит без осознанного решения — просто « так удобнее».

Почему опасно

Блоки попали в 🟠 Коллаборацию и 🔴 Человека, потому что требуют глубокого суждения (O=4–5), эмпатии (E=4–5) или стратегического видения (H=4–5). Если ИИ незаметно начинает принимать решения вместо человека — качество падает, но это сразу не заметно. Ошибки проявляются позже: неверная стратегия, потеря клиента, неучтённый контекст.

Как выглядит на практике

Признак Пример Почему плохо
Человек копирует ответ ИИ без правок « ИИ написал JTBD, я согласился» Нет суждения — ИИ стал автором вместо ассистента
ИИ генерирует финальный артефакт « Отправил клиенту то, что ИИ написал» Блок де-факто сдвинулся из 🟠 Коллаборации в 🟡 Усиление без пересмотра EPOCH
Человек перестал формулировать запрос « Спросил ИИ что делать» вместо « попросил подготовить данные» Инициатива перешла от человека к ИИ
Время на блок сократилось резко Было 20 мин, стало 3 мин — но блок остался в 🟠 Коллаборации Или EPOCH оценён неверно, или ИИ делает за человека

Что делать при обнаружении

  1. Зафиксировать — записать в протокол Мониторинга: какой блок, какой признак
  2. Вернуть уровень — если уровень автономности поднялся выше 1 для блоков 🟠 Коллаборации и 🔴 Человека, вернуть на 1 или 0
  3. Пересмотреть EPOCH — возможно, оценка была завышена — блок скорее 🟡 Усиление. Тогда это не ползучая автоматизация, а неточный EPOCH-скоринг → пересчитать и оформить как 🟡 Усиление с Карточкой делегирования
  4. Провести ручное выполнение — выполнить блок без ИИ, сравнить результат

Deloitte Australia: 20 галлюцинаций в госотчёте за AU$439 000

Что произошло. В 2025 году Deloitte Australia подготовила для Министерства занятости отчёт по программе контроля за безработными — стоимость контракта AU$439 000. Консультанты использовали Azure OpenAI для подбора ссылок и формулировок. В отчёте обнаружили около 20 ошибок: 12 ссылок на вымышленный отчёт несуществующего профессора Сиднейского университета, две — на фиктивную работу шведского учёного, выдуманную цитату федерального судьи с ошибкой в имени.

Что упустили. Никто не открыл ни одной ссылки. ИИ генерировал — консультант копировал — документ уходил в финал. Время на проверку источников было нулевым. Это не разовая ошибка одного сотрудника, а системный паттерн: через два месяца аналогичный случай произошёл в Deloitte Canada — отчёт за CA$1,6 млн с фиктивными ссылками.

Цена. Deloitte вернула часть гонорара, опубликовала исправленную версию с дисклеймером. Контракт сохранили, репутацию — частично. Два инцидента за два месяца показали, что проблема системная, а не случайная.

Где бы остановила Ползучая автоматизация. Из четырёх признаков сработало два. «Сотрудник копирует результат ИИ без правок» — ссылки шли в документ напрямую. «ИИ генерирует финальный артефакт» — отчёт уходил клиенту почти как сгенерирован. Мониторинг методологии поймал бы паттерн до Канады: «Время на проверку ссылок = 0 → красный флаг → пауза, возврат уровня автономности на ступень ниже, повторный EPOCH-скоринг».

«В оригинальном отчёте было 12 ссылок на вымышленный отчёт якобы профессора права Сиднейского университета» — Fortune, октябрь 2025. Источник: Fortune.

Дерево решений: что делать при расхождениях

Если факт расходится с прогнозом — используй дерево:

  • Ошибок больше, чем ожидалось, в одном цикле
    • Уровень автономности > 1? → Понизить на 1 ступень
    • Уровень = 1 (ниже некуда)?
      • Первый такой цикл? → Скорректировать: промпт, входные данные, критерии валидации
      • 3+ цикла подряд при уровне 1? → Вернуться к Декомпозиции: блок определён неверно
  • ROI не достигается после 4+ недель пилота
    • Экономия есть, но < 25% (порог из Обоснования)? → Скорректировать блок и повторить пилот
    • Экономии нет? → ОСТАНОВИТЬ → Диагностика с другим процессом

Результат: Протокол Мониторинг

Шаблон протокола

[Название процесса]: Мониторинг — Цикл [номер], [дд.мм.гггг]

Прогноз vs Факт

Блок Метрика Прогноз (из Обоснования/Внедрения) Факт Δ
Время (мин)
Ошибки (шт)
Экономия (%)

На что обратить внимание (стоп-сигналы из шага Внедрение)

  • Ошибки ≤ 10%?
  • Управление дешевле задачи?
  • Есть экономия?
  • Нет жалоб?

Решения и компетенции

Блок Уровень (был→стал) Ошибки Решение (⬆️/➡️/⬇️) Обоснование Ручное выполнение?
ДА (когда) / НЕТ

Готовность ИИ-инструмента

Блок Был (Н/П/С/Д) Стал Основание

Следующий шаг

  • Масштабировать (≥ 40% экономии)
  • Скорректировать (10–40%) — укажи конкретное действие
  • Отказаться (< 10%) — укажи причину
  • Следующий процесс для Диагностики — укажи процесс
  • Дата повторного входа (если ОСТАНОВИТЬ) — укажи дату

Зафиксируй свои данные — по каждому пункту одна строка.

Практический пример: Мониторинг после 1 цикла « Планирование недели»

Пример заполненного протокола

Планирование недели: Мониторинг — Цикл 1, 10.03.2026

Прогноз vs Факт

Блок Метрика Прогноз Факт Δ
Сбор задач из email/Slack Время 15 мин 5 мин −67% ✅
Ошибки 0–1 1 (пропустил Slack-тред) ≈ план
Приоритизация Время 10 мин 8 мин −20%

На что обратить внимание

  • ✅ Ошибки ≤ 10%? Да (1/12 = 8%)
  • ✅ Управление дешевле? Да (3 мин vs 15)
  • ✅ Экономия? Да (−67%)
  • ✅ Нет жалоб? Да

Решения и компетенции

Блок Уровень (был→стал) Ошибки Решение Обоснование Ручное выполнение?
Сбор задач 2→2 1/12 ➡️ без изменений 1 цикл, рано повышать НЕТ (цикл 1)
Приоритизация 1→1 0 ➡️ без изменений Требует суждения руководителя НЕТ

Готовность ИИ-инструмента

Блок Был Стал Основание
Сбор задач Новый Пробуем 1 цикл, 1 мелкая ошибка

Следующий шаг

  • Скорректировать: добавить Slack-треды в источники скрипта
  • Следующий процесс: рассмотреть «Подготовка к встречам»

Квартальная ревизия делегирования (раз в квартал, 15 мин)

Текущий мониторинг — тактика: смотришь на один цикл. Квартальная ревизия — стратегия: смотришь на всё делегирование целиком.

Три вопроса

  1. Уровни автономности всё ещё правильные?
    Открой реестр делегирования. Есть блоки, которые не менялись 3+ месяца и накопили 10+ циклов без ошибок? → готовы для повышения. Есть блоки, где уровень рос, но ошибки участились? → пора снизить.
  2. Риски изменились?
    Новые регуляторные требования, смена инструментов, обновление модели ИИ, изменился состав команды → пересмотри Оценку рисков для затронутых блоков.
  3. Есть ли блоки, которые стоит вернуть человеку?
    3+ цикла подряд: экономия < 10% и исправления занимают больше, чем сэкономили → делегирование не работает → вернуть задачу человеку, закрыть карточку делегирования по этому блоку.

По итогам

  • Обнови уровни автономности и Готовность ИИ-инструмента в реестре делегирования
  • Если есть новые процессы-кандидаты → запусти Диагностику

Чеклист: Мониторинг

Проверь каждый пункт перед завершением цикла мониторинга.

Еженедельно (15 мин/цикл)

  • Таблица « прогноз vs факт» заполнена по каждому блоку
  • Стоп-факторы проверены (4 сигнала)
  • Решения по повышению/понижению уровней зафиксированы с обоснованием
  • Компетенции: проверено, кто давно не делал вручную
  • Готовность ИИ-инструмента обновлена в реестре делегирования
  • Следующий шаг определён (масштабировать / скорректировать / отказаться)

Раз в квартал (15 мин дополнительно)

  • Квартальная ревизия проведена: уровни автономности, риски, блоки к возврату

Итоговая таблица

Фаза Шаг Входит Выходит Время Кто
Анализ Диагностика Название процесса Карта текущего состояния + Проверка готовности 15–20 мин Ты
Декомпозиция Карта состояния Границы + блоки + EPOCH-зоны + Оценка рисков + Экспресс-оценка 60 мин Ты
Проектирование Блоки 🟢 Автоматизация и 🟡 Усиление Карточки делегирования 45–60 мин Ты
Обоснование Карточки делегирования + ставки из Диагностики + зоны делегирования и Экспресс-оценка из Декомпозиции ROI + затраты на проверку и сопровождение + решение о внедрении 30–40 мин Ты
Внедрение Внедрение Карточки делегирования + Профили исполнителя + решение ПРОДОЛЖИТЬ из Обоснования План внедрения + реестр 60–120 мин Ты + команда
Мониторинг Факт после внедрения + прогноз из Обоснования/Внедрения Обновлённый реестр + решения 15 мин/цикл Ты

Фаза 1 (Анализ): ~2,5–3 часа
Фаза 2 (Внедрение): ~1,5–2,5 часа + 15 мин/цикл

Где начать?

Минимальный набор для первого прохода: Диагностика → Декомпозиция → Карточка делегирования → план внедрения. Этого достаточно для первого пилота.

Расширенный набор (второй и третий проход): Карточка поддержки, Профиль исполнителя, полный ROI-расчёт, 4 стадии автоматизации, Мониторинг с реестром, цепочки делегирования.

Не пытайся освоить всё за один раз. Первый проход — понять и применить минимальный набор. Остальное появится по мере необходимости.

Быстрый анализ (Фаза 1 без Обоснования):

  • Диагностика: 15–20 мин
  • Декомпозиция: 40–45 мин
  • Проектирование: 45 мин

ИТОГО: ~2 часа — получишь карту процесса + Карточки делегирования

Полный анализ (Фаза 1): Диагностика + Декомпозиция + Проектирование + Обоснование: ~2,5–3 часа — получишь решение о внедрении (ПРОДОЛЖИТЬ или ОСТАНОВИТЬ)

Обоснование и Внедрение можно позже — если хочешь сначала разобраться в процессе.

Как распределить по сессиям (если нет 3 часов подряд):

СессияЧто делатьВремя
1 Диагностика: отправная точка + текущее состояние + команда + Проверка готовности 20 мин
2 Декомпозиция: границы + блоки + EPOCH-скоринг + Оценка рисков + Экспресс-оценка 55 мин
3 Проектирование: Карточка делегирования для 1–2 блоков 45 мин

Сессии независимы — между ними можно делать перерыв день-два. Главное: завершать каждую сессию сохранённым результатом (заполненный шаблон), а не просто мыслями в голове.

С чего начать: как выбрать первый процесс

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

Пять критериев хорошего первого процесса:

  • Ты сам в нём участвуешь — можешь проверить результат, не спрашивая других
  • Повторяется хотя бы раз в 2 недели — быстро накопятся данные для Мониторинга
  • Размер: 3–7 этапов, не больше 10 блоков — не слишком мало (нечего анализировать), не слишком много (утонешь)
  • Хотя бы один блок явно рутинный — ищи что-то, что ты делаешь по шаблону. Это первый кандидат на 🟢 Автоматизацию
  • Ты принимаешь решение сам — не нужно согласовывать пилот с кем-то ещё

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