Фаза 2 · Этап 5 из 6
Назначить ответственного, выбрать степень доверия к ИИ на старте и запустить пилот с возможностью быстрого отката
Создать конкретный план внедрения делегирования: когда, как, кто, какие метрики, как откатить.
Цель шага: Создать конкретный план как внедрять делегирование. Когда? Как? Кто? Какие метрики успеха? Как откатить?
Снимает проблемы:
Как читать этот раздел
Методология определяет ЧТО делегировать и ЗАЧЕМ. Техкоманда определяет КАК — архитектуру, паттерны проектирования, инструменты, инфраструктуру.
Перед началом внедрения убедись, что пакет артефактов собран:
Проверь каждый пункт перед переходом к Внедрению.
Если менеджер и техкоманда — один человек, чек-лист работает как самопроверка: все артефакты готовы перед началом реализации?
Этот раздел — для технической команды или для самопроверки, если ты совмещаешь роль менеджера и разработчика. Если у тебя есть разработчик — передай ему Профиль исполнителя и Карточку делегирования, остальное он сделает сам.
При передаче технической команде руководитель отдаёт готовые документы — Профиль исполнителя и Карточку делегирования. Инженер собирает из их полей два объекта API-запроса. Ничего не пересоздаётся.
Системный промпт — задаётся один раз при настройке агента:
| Поле | Документ |
|---|---|
| Инструкции для ИИ, Компетенции, Ограничения роли | Профиль исполнителя |
| Контекст | Карточка делегирования |
| Критерии проверки: формат результата, критерии «принято» и «отклонено» | Карточка делегирования |
| При провале: действие, макс. итераций, действие после исчерпания | Карточка делегирования |
| Результат работы ИИ | Карточка делегирования |
| Ограничения, Безопасность | Карточка делегирования |
Пользовательский промпт — формируется при каждом вызове:
| Поле | Документ |
|---|---|
| Входные данные | Карточка делегирования |
Не передаётся в API — используется на других шагах методологии:
| Поле | Документ | Где используется |
|---|---|---|
| Кто валидирует, Время на валидацию | Карточка делегирования | Организация проверки — для человека |
| Тип взаимодействия | Карточка делегирования | Уровень автономности агента (шаг Внедрение) |
| Интерфейс, Инструмент, Триггер | Карточка делегирования | Как запускать агента (шаг Внедрение) |
| Исполнитель | Карточка делегирования | Ссылка на Профиль исполнителя |
| Тип исполнителя, Источник роли | Профиль исполнителя | Реестр исполнителей команды |
| Стоимость | Профиль исполнителя | ROI-расчёт (шаг Обоснование) |
| Онбординг для исполнителя-человека | Профиль исполнителя | Онбординг нового сотрудника |
Прежде чем писать план, учитывай четыре принципа (Bara, 2026):
1. Именованный владелец
Каждый результат ИИ имеет конкретного ответственного человека. Не «команда отвечает», а «Иванов проверяет».
2. Управляемое, обратимое делегирование
Делегирование — это операционное решение, а не бинарный выключатель. Можно повысить или понизить уровень автономности в любой момент.
3. Пропорциональная валидация
Бюджетируй время на проверку явно. Если не запланировал проверку — она не случится, и ошибки накапливаются.
4. Поддержание компетенций
Периодически делай задачи руками (без ИИ). Не как наказание, а как калибровку. Если не делать — через 3–6 месяцев не сможешь проверить результаты.
Работа без ИИ — для каждого делегированного блока назначь конкретного человека и периодичность ручного выполнения. Если этот план не зафиксирован явно — он не выполняется.
Делегирование ИИ создаёт новую нагрузку — проверка результатов. На старте кажется, что проверять всё дороже, чем делать самому. Часто, так и есть. Уровни автономности снижают эту нагрузку со временем:
| Уровень | ИИ делает | Человек делает | Нагрузка | Когда | Делай сам |
|---|---|---|---|---|---|
| 1 — Ассистируемый | Помогает | Делает сам | ~100% | Старт | — |
| 2 — Контролируемый | Делает результат | Проверяет каждый | 30–60% | 3+ цикла | — |
| 2+ — Двойной контроль | Делает результат | Каждый проверяют двое | 50–80% | После 3+ циклов на уровне 2, если Оценка рисков сработала | — |
| 3 — Авто-мониторинг | Делает результат | Выборка 20% | 10–20% | 5+ циклов | 1 раз в квартал |
| 4 — Авто-ограниченный | Делает сам | Периодический аудит | < 5% | 8+ циклов | 1 раз в 2 месяца |
«Делай сам» — выполни блок без ИИ, чтобы сохранить способность ловить его ошибки. На уровнях 1–2 ты и так в процессе. На уровнях 3–4 это нужно планировать явно.
Логика: инвестируешь время на проверку в начале → накапливаешь доказательства → повышаешь уровень → проверок меньше → экономия растёт.
Типичная ошибка: Команды начинают с уровня 3, потому что «ИИ же умный». Уровень автономности — решение о доверии, не характеристика модели. Мощная модель начинает с уровня 1 и повышается с накопленными доказательствами (Feng, McDonald, Zhang, 2025).
Что такое цикл: одно полное выполнение блока с проверкой результата по чек-листу Карточки делегирования. Если блок выполняется реже 1 раза в месяц — используй временной критерий вместо количественного: 3 месяца без ошибок для повышения 1→2, 5 месяцев для 2→3, 8 месяцев для 3→4.
Зона (шаг Декомпозиция) — природа блока, не меняется. Уровень автономности (шаг Внедрение) — доверие к ИИ, растёт с опытом. Зона определяет потолок:
| Зона | Что это | Максимальный уровень | Почему |
|---|---|---|---|
| Автоматизация | ИИ делает, человек проверяет | До уровня 4 | Задача полностью формализуема |
| Усиление | ИИ — черновик, человек дорабатывает | До уровня 2–3 | Человеческая доработка всегда нужна |
| Коллаборация | Человек — автор, ИИ помогает | До уровня 1 | ИИ — ассистент: готовит данные по запросу человека |
| Человек | Человек делает | До уровня 0–1 | ИИ — собеседник: помогает рассуждать, готовит вводные |
Пример: Блок «Выгрузить задачи» — Автоматизация (EPOCH = 1). При первом запуске — уровень 1 (проверяешь каждый результат). Через 5 циклов без ошибок — уровень 2. Через 3 месяца — уровень 3 (выборочная проверка 20%). Зона не изменилась, уровень вырос, нагрузка снизилась в 5 раз.
Блоки с Оценкой рисков. Если Оценка рисков сработала (Вопрос 1 — ошибка необратима, или Вопрос 3 — грозит штраф, иск или вред здоровью), потолок уровня автономности — 2+, не 3. Выборочная валидация для таких блоков недопустима: пропущенная ошибка стоит дороже, чем сэкономленное на проверке время.
Стартовый уровень зависит от накопленных данных о надёжности ИИ в этом блоке (определяется на этапе пилота):
| Накопленный опыт | Стартовый уровень | Почему |
|---|---|---|
| Новый | Уровень 1 | Нет данных — максимальный контроль |
| Пробуем | Уровень 1–2 | Мало данных — контроль с допуском |
| Стабильный | Уровень 2–3 | Результат стабилен — можно ослабить |
| Доказанный | Уровень 3–4 | Доказанная надёжность |
Почему так: доверие зарабатывается долго, теряется за секунду. Это защищает от соблазна «давай сразу на автопилот».
Ты выявил делегируемый блок (Автоматизация или Усиление) и принял решение о внедрении. Вот что делать:
Шаг 1. Определи стартовый уровень.
Посмотри «Готовность ИИ-инструмента» из Декомпозиции → таблица выше (новый → уровень 1, пробуем → 1–2, стабильный → 2–3, доказанный → 3–4). Если сомневаешься — бери ниже.
Шаг 2. Запиши в реестр делегирования.
Заполни строку: блок, уровень, владелец, готовность ИИ-инструмента, дата старта.
Шаг 3. Работай по правилам уровня.
| Уровень | Что делаешь | Что записываешь |
|---|---|---|
| 1 | Делаешь задачу сам, ИИ помогает (подготовка данных, черновик) | Сколько времени сэкономил, были ли ошибки |
| 2 | ИИ делает результат, ты проверяешь КАЖДЫЙ по чек-листу ДО использования | Принял / отклонил, что исправил |
| 3 | ИИ делает, ты проверяешь каждый 5-й результат (20%) | Ошибки в выборке |
| 4 | ИИ работает сам, ты делаешь аудит раз в месяц | Результат аудита |
Шаг 4. После каждого цикла — обнови реестр.
Запиши дату последней проверки и количество ошибок.
Шаг 5. Повышение уровня.
N циклов без ошибок (3→5→8) → подними уровень на 1. Зафиксируй в реестре с датой и обоснованием.
Шаг 6. Понижение уровня.
Ошибка → мгновенно опусти на 1 уровень. Без согласований. Зафиксируй причину в реестре.
Пример: Блок «Сбор задач из писем». Старт: опыт «новый» → уровень 1. Неделя 1–3: делаешь сам, ИИ готовит черновик списка. Неделя 4: 3 цикла ОК → уровень 2, ИИ делает список, ты проверяешь каждый. Неделя 9: 5 циклов ОК → уровень 3, проверяешь каждый 5-й. Время на проверку: было 25 мин → стало 5 мин.
Гибридная команда — это не «человек + чат-бот». Это команда, где часть задач выполняют люди, часть — ИИ-агенты, а часть — совместно. Интерфейс определяет, как именно человек и ИИ работают вместе на каждом блоке.
Без явного выбора интерфейса происходит одно из двух:
Интерфейс — это мост между зоной делегирования (кто автор) и уровнем автономности (сколько доверия). Он отвечает на вопрос: «Через какой канал ИИ встроен в работу этого блока?»
| Стадия зрелости команды | Типичный паттерн | Что происходит |
|---|---|---|
| Старт (0–3 месяца) | Диалог для всех блоков | Команда учится формулировать задачи и проверять результаты. Накапливается доверие |
| Рост (3–6 месяцев) | Диалог (Коллаборация и Человек) + Агент (Автоматизация и Усиление) | Рутинные блоки переходят на агентов. Человек фокусируется на стратегических задачах |
| Зрелость (6+ месяцев) | Диалог (Коллаборация и Человек) + Агент (Усиление) + Пайплайн (Автоматизация) | Стабильные блоки автоматизированы полностью. Команда владеет процессом и может откатить любой блок |
Это не план «внедрить всё за полгода», а описание того, как команды естественно наращивают автоматизацию, если процесс управляем. Каждый переход от Диалога к Агенту или от Агента к Пайплайну — явное решение с критериями (уровень автономности, количество успешных циклов).
Три провала, на которых сработал бы шаг Внедрение
DPD, январь 2024 — обновили и не протестировали. Служба доставки обновила чатбот, не пересмотрев уровень автономности. Бот выругался матом на клиента, написал стихотворение про «худшую курьерскую службу в мире», пост собрал 1,3 млн просмотров. Принцип методологии: обновление модели = новый инструмент → уровень 1, тест, потом продакшн. Источник: Time.
Klarna, май 2025 — повысили уровень, понизить не смогли. В феврале 2024 финтех заявил: ИИ заменил 700 операторов, экономия 40 млн долларов. Через полтора года CEO Себастьян Семятковски публично признал: «зашёл слишком далеко». Качество упало, начали нанимать людей обратно. Принцип методологии: повышение уровня — медленное, понижение — мгновенное. Уволенных людей вернуть сложнее, чем переключить настройку. Источник: Fortune.
UnitedHealth, иск 2024 — валидация была, но для галочки. Алгоритм nH Predict отказывал пожилым пациентам в покрытии реабилитации. 90% отказов отменялись при апелляции — ошибка девять из десяти. Формально валидация существовала, фактически — никто не проверял. Принцип методологии: чем выше риск, тем глубже проверка. Для решений о здоровье — 100% человеком, не «автоотказ + право обжалования». Источник: CBS News.
Подход не привязан к конкретному ИИ. Разные блоки можно делегировать разным моделям — один для текста, другой для данных, третий для кода.
Связь с Профиль исполнителя (шаг Проектирование): Компетенции и инструкции исполнителя определены в Профиль исполнителя. Здесь выбирается конкретная модель на основе технических критериев. Профиль исполнителя отвечает «что должен уметь», критерии ниже — «какая модель подходит технически».
6 критериев выбора:
| Критерий | Вопрос | Пример |
|---|---|---|
| Точность | Насколько хорошо модель решает этот тип задач? | Генерация кода vs аналитика — разные модели лидируют |
| Стоимость | Сколько стоит 1 выполнение блока? | Дешёвая на 70% рутины, дорогая на 30% сложных |
| Скорость | Нужен результат за секунды или минуты? | Интерактивный → быстрая; пакетная → любая |
| Приватность | Чувствительные данные в блоке? | Внутренние данные → модель с локальным развёртыванием |
| Доступность | Нужна стабильность 24/7? | Критичный процесс → резервная модель |
| Сложность | Простая экстракция или глубокий анализ? | Экстракция → лёгкая модель; анализ → мощная |
Правило приватности: Если блок работает с персональными данными, коммерческой тайной или внутренними документами — используй модель с локальным развёртыванием или с гарантией несохранения данных провайдером. Не отправляй чувствительные данные в API третьей стороны.
Практика: Не выбирай модель один раз на весь процесс. Оценивай для каждого блока на этапе пилота. Дешёвая модель справляется с 70% блоков — это нормально и экономически правильно.
Делегирование не ограничивается схемой «человек → ИИ». Реальные процессы часто включают цепочки:
| Тип | Как работает | Пример |
|---|---|---|
| Человек → ИИ | Классика: человек ставит задачу, ИИ выполняет, человек проверяет | Руководитель → ИИ генерирует отчёт → руководитель проверяет |
| ИИ → ИИ | Один ИИ передаёт результат другому для следующего шага | Модель А собирает данные → Модель Б анализирует |
| Человек → ИИ → Человек → ИИ | Чередование: разные этапы — разные исполнители | ИИ собрал факты → аналитик проверил → ИИ написал отчёт → руководитель утвердил |
Правило ответственности: В любой цепочке у каждого звена есть именованный человек-владелец. ИИ не может быть конечным ответственным. Если никто не может проверить звено — звено нельзя делегировать.
Затухание полномочий. Работает как в обычной иерархии: менеджер не может дать сотруднику полномочий больше, чем есть у него самого. С ИИ — то же правило.
Если вы поручили ИИ подготовить материалы и открыли доступ к внутренней базе — ИИ не может «передать» этот доступ следующему инструменту в цепочке. Каждое следующее звено получает только часть прав предыдущего — никогда больше. Если на каком-то шаге цепочке не хватает доступа для задачи — это сигнал вернуться к Проектированию: пересмотреть Карточку делегирования и явно прописать, что и кому доступно.
Почему это важно на практике: когда один ИИ передаёт задачу другому, риск не в том, что ИИ «захочет» больше прав. Риск в том, что цепочка настроена небрежно — и данные уходят туда, куда вы не планировали. Каждое звено должно иметь явно прописанные ограничения в Карточке делегирования.
Рекомендация: Начинай с простых цепочек (человек → ИИ). После 3–6 месяцев опыта, когда уровень автономности стабилен на 3+, переходи к мультиагентным цепочкам (ИИ → ИИ) и масштабируй.
Кто отвечает. Владелец блока несёт ответственность за результат — независимо от того, кто допустил ошибку: ИИ сгенерировал некорректно или человек не заметил при проверке. Переложить ответственность на ИИ нельзя: компания отвечает за всё, что вышло от её имени, в том числе сгенерированное ИИ (Moffatt v. Air Canada, 2024). Формальная проверка без реального разбора результата не снимает ответственности (Mata v. Avianca, 2023).
Три шага после инцидента:
1. Откат. Признать ошибку клиенту, исправить результат.
2. Расследование. Зафиксировать: ИИ сгенерировал некорректно или человек не поймал при проверке. Это разные корни — разные решения.
3. Изменение. Устранить причину:
| Корень ошибки | Действие |
|---|---|
| ИИ стабильно ошибается на этом типе задач | Добавить антипример в критерии «отклонено» в карточке делегирования |
| Человек не успевает проверить | Снизить уровень автономности или уменьшить количество результатов в одном цикле проверки |
| Человек не знал, что проверять | Уточнить критерии «принято» в карточке делегирования |
Стоп-сигналы — немедленная реакция:
| Красный флаг | Порог | Действие |
|---|---|---|
| Частота ошибок ИИ | > 10% результатов | Понижение уровня, пересмотреть блок |
| Управление ИИ дороже задачи | Время на управление > исходного | Пересмотреть границы блока или отказаться |
| Нет экономии через неделю | 0% экономии времени | Проверить настройку; если ОК — пилот не оправдан |
| Жалобы клиентов/команды | Любые | Немедленная пауза, разбор |
Матрица решений по итогам пилота (неделя 4):
| Сигнал | ROI | Качество | Команда | Действие |
|---|---|---|---|---|
| Масштабировать | ≥ 40% экономии времени ИЛИ ≥ 25% снижение затрат | Стабильно / растёт | Принимает | Масштабируй |
| Скорректировать | 10–40% экономии | Смешанное | Нужна доработка | Скорректируй (ещё 2 нед.) |
| Отказаться | < 10% экономии ИЛИ отрицательный | Падает | Сопротивляется | Откажись от этого блока |
Пороги ≥ 40% / ≥ 25% совпадают с порогами из Обоснования. Одна шкала на всю методологию.
[Название процесса]: План внедрения
День 1–2: Настройка доступа
День 3–4: Написание кода/скрипта
День 5: Подготовка людей
Что делаем:
Метрики успеха:
Если не работает:
Что делаем:
Долгосрочные метрики:
| Блок | Уровень | Владелец | Готовность ИИ-инструмента | Последняя проверка | Ошибки за цикл |
|---|---|---|---|---|---|
| Н/П/С/Д |
Н — Новый, П — Пробуем, С — Стабильный, Д — Доказанный
| Задача | Зона | Периодичность | Кто выполняет |
|---|---|---|---|
| Автоматизация | 1 раз в 2 мес | ||
| Усиление | 1 раз в мес |
Зачем ротация. Когда задачу регулярно выполняет ИИ, человек постепенно теряет способность оценивать качество результата — даже если думает, что разбирается. Это называется «иллюзия понимания»: человек видит результат и принимает его, но самостоятельно воспроизвести или критически проверить уже не может. Для Коллаборации ротация не нужна: человек участвует в каждом цикле. (Fyfe et al., 2024)
Ориентир по частоте. Авиационная практика FAA устанавливает 90 дней как максимальный интервал между ручными упражнениями для когнитивных навыков высокой ставки. Когнитивные задачи с неопределённостью деградируют быстрее процедурных — в зоне Усиления интервал короче. (Arthur et al., 1998; FAA 14 CFR § 61.57)
Признаки деградации — наблюдаешь хотя бы один → запланируй ручное выполнение в ближайший раз:
Экспресс-тест (1 мин перед плановым циклом):
Задай себе вопрос: «Назову ли я три возможные ошибки ИИ в этой задаче?»
День 1–2: Настройка доступа
День 3–4: Настройка и тест
День 5: Подготовка команды
План ротации: Раз в 2 месяца (зона Автоматизации) руководитель собирает задачи самостоятельно, без скрипта. Экспресс-тест перед циклом: «Назову ли я три возможные ошибки скрипта?»
Проверь каждый пункт перед переходом к Мониторингу.
Время выполнения: 60–120 мин
Перед пилотом команда должна уметь работать с ИИ: ставить задачу, проверять результат, давать обратную связь. Курс «После промптов» закрывает эти навыки за шесть писем — до того, как начнётся внедрение.
Подробнее о курсе →