Governor shift, или «сдвиг к управлению», описывает смену роли специалиста, который работает с искусственным интеллектом. Раньше цикл выглядел просто: построить систему, запустить, поддерживать. Теперь к этому добавляется слой решений о том, как система ведёт себя. Автор термина, руководитель AI-трансформации Lowe's, Fortune 100 ритейлера товаров для дома, формулирует это так: работа больше не ограничивается созданием AI-систем, она включает определение того, как они работают, какие решения принимают автономно, когда эскалируют человеку и какие действия остаются запрещёнными.
Сам переход он называет governor shift: от выполнения задач своими руками к установке намерения, принципов и границ внутри систем, которые выполняют их за вас.
Сдвиг касается тех, кто отвечает за результат: инженеров, продакт-менеджеров, аналитиков и бизнес-операторов, подписывающихся под работой, которую черновиком сделала машина. Пользователь, печатающий запросы в чат-бот, в эту категорию не попадает. Пример из колонки «6 Guidelines for Governing AI»: бизнес-оператор может не писать код, но именно он решает, какие ценовые исключения агент одобряет сам, а какие обязан эскалировать. Это и есть управление.
Термин прозвучал в контексте книги The Enterprise Brain, соавтором которой выступает автор. Там же используется понятие GenAI Divide, о котором ниже.
Почему старая модель «построил и забыл» больше не работает
Причина в ответственности. Система выдаёт результат, но подпись под ним ставит человек. Если виртуальный ассистент в ритейле советует покупателю, как починить протекающий кран, и ведёт его к нужному товару, кто-то должен заранее определить, в какой момент ассистент останавливается и передаёт разговор живому консультанту.
Эту границу нельзя вывести из кода автоматически. Её задаёт тот, кто отвечает за итог: за долю решённых обращений, за отсутствие ошибочных советов, за репутацию бренда. Поэтому роль специалиста смещается: меньше про написание кода, больше про описание поведения системы. Без этого слоя агент остаётся техдолгом, который рано или поздно выдаёт дорогую ошибку.
Обратная сторона: если границы не заданы, команда получает поток ручных проверок. Каждый ответ агента смотрят глазами, и автоматизация превращается в новую форму ручной работы. Об этом следующий раздел.
GenAI Divide: почему $30–40 млрд инвестиций дают только 5% эффекта
Отчёт MIT Media Lab Project NANDA 2025 года, о котором рассказывает автор колонки, оценил инвестиции в enterprise генеративный AI в $30–40 млрд. При таких вложениях подавляющее большинство организаций из датасета ещё не показали измеримого влияния на прибыль и убытки. Около 5% интегрированных пилотов генерировали существенную ценность. Исследователи назвали эту закономерность GenAI Divide, и автор колонки взял термин для своей книги.
Ключевой вывод в пересказе автора звучит так: компаниям редко не хватает технологий. Они используют те же модели, что и 5% победителей. Не хватает людей, которые умеют направлять системы и отвечать за результат.
Что на самом деле означает «5% пилотов»
Цифра 5% относится к интегрированным пилотам, которые дают существенную ценность, а не к доле компаний, что-то внедривших. Разница важна: большинство проектов доходят до стадии работающего прототипа, но не до измеримого вклада в P&L.
Причина обычно не в модели. Типовой сценарий: агент отвечает на вопросы клиентов, качество ответов приемлемое, но дальше начинается ручная работа. Кто-то проверяет ответы, кто-то вручную заводит заявку в CRM, кто-то сверяет цены в двух системах. Экономия от автоматизации съедается обслуживанием процесса вокруг неё.
Governor shift отвечает на этот разрыв прямо: путь из нижней части распределения в верхнюю лежит через управление, а не через замену модели на более сильную. Когда границы, принципы и контуры эскалации описаны, пилот перестаёт требовать постоянного человеческого надзора.
Оговорка по источникам: в доступном фрагменте колонки принципы только перечислены, часть из них не раскрыта прямыми цитатами. Ниже мы разбираем их как практическую интерпретацию, которая не противоречит источнику, а за точными формулировками стоит обратиться к первоисточнику.
Принцип 1: распознайте human middleware и administrator trap
В программной инженерии middleware называют код, который стоит между двумя системами и передаёт информацию туда-сюда. Многие специалисты стали его человеческой версией: вручную переносят данные, переформулируют запросы, копируют выводы агента из одного интерфейса в другой.
Автор называет это «human middleware» и отдельно вводит «administrator trap» - ловушку, которую создаёт архитектура, а не люди, в неё попавшие. Смысл в том, что сотрудник не выбирает роль передаточного звена, его в неё ставит отсутствие интеграции. Если агент не имеет доступа к нужной системе, кто-то обязан стать этим доступом.
Как отличить human middleware от полезной работы
Рабочий критерий простой. Опишите задачу как поток данных. Если смысл сводится к «взять из A и передать в B без изменений», это middleware. Если по дороге нужно решить, какие числа заслуживают внимания, какие риски реальны и какие компромиссы приемлемы, это суждение, и делегировать его агенту пока рискованно.
Автор прямо говорит: передача информации - то, с чем агенты справляются хорошо, а вот оценить значимость числа или реальность риска они не могут. Пример из ритейла: сверить цену конкурента и перенести её в систему - middleware. Решить, давать ли исключение из ценовой политики конкретному клиенту, - суждение.
В роли middleware легко застрять незаметно: работа выглядит нужной, задачи не заканчиваются, а ценность создаётся только за счёт вашего времени. Тест на выход из ловушки один - уберите себя из процесса и посмотрите, что сломается. Если ломается интеграция, чините архитектуру, а не терпение сотрудника.
Принцип 2: замените жёсткие правила принципами с приоритетами
Правила работают на человеческой скорости. Пока решения принимают люди, инструкция из сотни пунктов справляется. Как только систему ставят в контур, где она принимает тысячи решений, правила начинают ломаться: реальность подкидывает случаи, которых в списке нет.
Автор предлагает обратный ход: заменить правила принципами. Принцип описывает цель и способ разрулить конфликт целей, а не конкретный шаг. Сравните два подхода. Правило: «возврат товара дороже определённой суммы требует подписи руководства». Принцип: «решения о возврате принимаются в пользу клиента, если стоимость возврата ниже стоимости удержания; при неопределённости приоритет отдаётся марже».
Второй подход гибче, но требует работы. Принцип должен быть проверяемым и иметь явный порядок приоритетов. Формулировка вида «действовать в интересах компании» бесполезна: под неё можно подвести любое решение, и агенту, и проверяющему.
Практическая схема формулировки: цель, допустимые границы, метрика проверки, порядок разрешения конфликтов. Если принцип нельзя проверить на конкретном кейсе, он ещё не готов. Для команд, внедряющих автономных агентов, полезна готовая рамка из трёхуровневого Governance-стека: там инженерные политики отделены от рабочего процесса и метрик, и видно, как политики превращаются в проверяемые правила поведения.
Принцип 3: запишите культуру компании в код тремя слоями
Принципы нужно где-то хранить. Автор предлагает три слоя, которые переводят культуру компании в форму, понятную агентам: constitution, doctrine и playbook.
- Constitution (конституция) - фундаментальные запреты и обязательства, которые не обсуждаются и не имеют исключений.
- Doctrine (доктрина) - интерпретация принципов для типовых классов ситуаций: как компания обычно поступает и почему.
- Playbook (плейбук) - конкретные сценарии с последовательностью действий и точками эскалации.
Пример на данных клиента. Constitution: «персональные данные не раскрываются и не покидают контур». Doctrine: «при запросе данных клиента сначала подтверждаем личность». Playbook: «если клиент не может подтвердить личность, предлагаем альтернативный канал и не раскрываем детали заказа».
Слои решают конкретную задачу: поведение агента становится предсказуемым и объяснимым. Когда инцидент уже случился, вы можете сказать, какой слой сработал неверно, и починить именно его, а не переписывать всю систему промптов. Это не бюрократия ради бумаг, а способ отделить «нельзя никогда» от «обычно делаем так» и от «в этом сценарии делаем шаг за шагом».
Принцип 4: используйте термостат доверия вместо бинарного переключателя
Автономность часто настраивают как переключатель: агент либо всё делает сам, либо всё эскалирует. Обе крайности плохи. Первая приводит к дорогим ошибкам, вторая возвращает ручной труд.
Термостат доверия работает как порог уверенности. Агент оценивает свою уверенность в решении. Выше порога - действует сам, ниже - передаёт человеку. Порог не одинаков для всех задач и настраивается под риск.
| Тип решения | Пример | Порог уверенности |
|---|---|---|
| Информационный ответ | Есть ли товар на складе | Низкий: ошибка дешева |
| Изменение условий сделки | Скидка сверх регламента | Высокий: ошибка дорога |
| Действие с данными | Изменение записи клиента | Максимальный или запрет |
Ключевой момент: порог - управленческое решение, а не настройка по умолчанию. Его выставляет тот, кто отвечает за последствия, и меняет по мере накопления статистики. Похожая логика лежит в методологии Agent-Ops 0.4.0, где агент предлагает, человек утверждает, а детерминированный исполнитель применяет только допущенные действия: разделение ролей там задано явно, и это хороший ориентир для настройки контура.
Принцип 5: сначала выстройте контекст по циклу CCRAG
Управление по исключениям работает только на качественном контексте. CCRAG описывает цикл, который этот контекст выстраивает: Connections, Context, Reasoning, Actions, Governance.
- Connections - связи между данными и системами: к чему агент имеет доступ и как получает информацию.
- Context - рабочая обстановка: правила, история взаимодействий, состояние процесса.
- Reasoning - логика решения: как из контекста и данных получается вывод.
- Actions - действия, которые агент вправе совершить.
- Governance - контроль: кто и как проверяет результат и меняет поведение системы.
Это цикл, а не линейный чек-лист. Governance влияет на Connections и Context: обнаружили, что агент ошибается на определённом классе запросов, добавили данные и уточнили принцип. CCRAG здесь стоит отделять от классического RAG: RAG отвечает на вопрос «какие документы подложить в контекст», а CCRAG описывает управляющий слой целиком, включая доступы, действия и контроль.
Почему без CCRAG управление по исключениям превращается в хаос
Логика простая. Управление по исключениям экономит время только тогда, когда рутина обрабатывается корректно. Если у агента нет доступа к данным о запасах (Connections), он не сможет правильно ответить о наличии товара (Reasoning), и каждый второй ответ уйдёт человеку. Исключения перестают быть исключениями.
Поэтому порядок внедрения важен. Сначала связи и контекст, потом логика и действия, потом контроль. Попытка сразу перейти к управлению по исключениям без этого фундамента даёт поток эскалаций, который быстро съедает выгоду. В мультиагентных системах добавляется ещё один слой - координация между агентами; разбор стека для такой координации есть в материале про сеть AI-агентов как единую команду.
Принцип 6: переходите к управлению по исключениям
Управление по исключениям - финальная стадия governor shift. Человек вмешивается только тогда, когда агент сигнализирует о проблеме или ситуация вышла за рамки описанных принципов. Пример: агент сам одобряет скидку до 5%, всё, что выше, уходит на согласование.
Условие входа в эту стадию - предыдущие пять шагов. Без принципов с приоритетами агент не сможет разрешить конфликт целей. Без описанной культуры не поймёт границ. Без порога уверенности не отличит рутину от риска. Без контекста не обработает типовые случаи. Нарушение любого пункта означает, что исключений станет столько, что ручная работа вернётся целиком.
Практический показатель зрелости: доля решений, которые агент закрывает без человека, при стабильном или улучшающемся качестве. Если этот показатель растёт, а инциденты не учащаются, контур настроен. Если качество падает, порог эскалации стоит опустить, а не ужесточать надзор над каждым ответом.
Что это значит для вашей роли: суждение и вкус как дефицитный ресурс
Рутинное выполнение уходит агентам, а суждение остаётся за человеком. Инженер всё чаще не пишет код вручную, а определяет, какие решения агент принимает сам и что именно считается недопустимым. Продакт-менеджер формулирует принципы и приоритеты вместо подробного ТЗ на каждый экран.
Спрос смещается к редкому ресурсу: способности оценить, что здесь правильно, а что нет, когда формальные критерии не покрывают ситуацию. Это и есть вкус в рабочем смысле: выбор между несколькими допустимыми вариантами, за который вы готовы отвечать.
Для команд это означает перераспределение задач. Подробное описание исполнения переходит в инструкции для агентов, а человек занимается границами, приоритетами и разбором отклонений. Как это меняет структуру команд и роль руководителя, разбирается в материале про AI-native организацию.
Какие навыки стоит развивать уже сейчас
- Формулирование принципов и приоритетов так, чтобы их можно было проверить на конкретных кейсах.
- Проектирование контуров управления: где проходит порог эскалации и кто отвечает за исключение.
- Работа с неопределённостью: что делать, когда данных мало, а решение принимать нужно.
- Ответственность за решения агента: умение объяснить, почему система поступила именно так.
Это дополнение к техническим навыкам, а не их замена. Без понимания, как устроены модели, доступы и данные, вы не сможете поставить агенту корректную границу.
Ограничения и риски governor shift
- Не каждый процесс описывается принципами. Там, где решение зависит от уникального контекста, который не формализуется, принципы будут давать сбои.
- Настройка термостата доверия требует данных. Пока статистики мало, порог приходится ставить наугад, и первые недели дают либо лишние эскалации, либо пропущенные ошибки.
- Управление по исключениям ломается при резком изменении условий. Если правила рынка или процесса меняются, агент продолжает действовать по устаревшим принципам.
- Плейбуки устаревают. В быстро меняющемся процессе их не успевают обновлять, и разрыв между описанным и реальным поведением растёт.
- Сопротивление внутри команды реально. Часть специалистов видит в передаче задач агенту потерю статуса, и это тормозит переход сильнее технических проблем.
Отдельный класс рисков связан с runtime-контролем. Даже корректно описанные границы не спасают, если права агента на уровне интеграции шире, чем задумано. Показательный разбор такого сбоя есть в кейсе про read-only агента, который всё равно изменил запись в CRM: агент не имел прав в HubSpot, но downstream-узел всё равно выполнил PATCH. Урок: принципы и политики нужно дублировать техническими ограничениями на границе исполнения.
Governor shift - эволюционный переход, а не готовая кнопка. Компании, которые ждут универсального рецепта, рискуют остаться в нижней части распределения: технологии у всех одинаковые, разница создаётся там, где описаны границы и назначена ответственность.
Как применить governor shift в вашем проекте: с чего начать
- Найдите точки, где вы human middleware. Выпишите задачи за неделю и отметьте те, что сводятся к переносу данных между интерфейсами. Это первые кандидаты на интеграцию или автоматизацию.
- Сформулируйте 3-5 принципов с приоритетами. Для одного конкретного агента, не для всей компании. Каждый принцип проверьте на трёх реальных кейсах, включая спорный.
- Опишите constitution, doctrine и playbook. Начните с запретов: что агент не делает никогда. Затем опишите типовые ситуации и только потом конкретные сценарии.
- Настройте порог уверенности для эскалации. Разделите решения по цене ошибки и задайте разные пороги. Зафиксируйте, кто имеет право менять порог.
- Проверьте контекст по CCRAG. Пройдитесь по пяти элементам и найдите разрыв: нет доступа к данным, не описан контроль, не заданы допустимые действия.
- Начните с управления по исключениям в одном процессе. Один сценарий, одна метрика, неделя наблюдения. Расширяйте контур только после того, как доля решений без человека начнёт расти без падения качества.
Если проект небольшой, принципы остаются теми же, меняется масштаб. Для локальной LLM с RAG на одном сервере конституцией становится набор системных инструкций и ограничений доступа к файлам, доктриной - правила выбора источников, плейбуком - сценарии, где модель обязана ответить «не знаю» или передать вопрос человеку. Ресурсов на полный контур не хватит, поэтому начинайте с одного процесса и минимального набора принципов, а не с попытки описать всю организацию.
Первый шаг не требует бюджета: возьмите свой текущий сценарий с агентом и честно ответьте, сколько решений он закрывает без вас и что происходит, когда он ошибается. Эти два числа покажут, на каком месте распределения вы находитесь и какой принцип стоит вводить первым.