Когда AI-агентам нужно одобрение, а не только аудит
Аудит говорит вам, что произошло. Одобрение решает, должно ли это произойти вообще.
Это различие становится центральным по мере того, как AI-агенты переходят от черновиков и анализа к операционной работе. Read-only-ассистента можно проревьюить постфактум. Агент, который отправляет письмо, меняет запись клиента, оформляет возврат, обновляет инвентарь, модифицирует воркфлоу или вызывает продакшен-API, может создать последствие до того, как у кого-то будет время посмотреть в лог.
Для CTO вопрос не в том, нужен ли человек в петле для каждого действия. Это убило бы смысл автоматизации. Вопрос в том, какие действия могут идти на автопилоте, какие требуют gate и какие должны быть отказаны, пока система не докажет больше контекста.
Audit-only системы отвечают слишком поздно для работы с необратимым воздействием. Системы одобрения сдвигают точку контроля вперёд.
TL;DR
- Аудит — постфактум; одобрение — это решение до того, как действие коммитнется
- Классы действий — не отдельные экземпляры — задают правильный дефолт: allow, conditional, approve или deny
- Конверт одобрения (предлагаемое действие, класс, актор, доказательства, ручка обратимости, истечение) — это разница между информированным ревью и формальным штампом
- Автопилот не враг governance; неуправляемый автопилот — враг
- “Bad success” — технически успешное действие, нарушающее бизнес-границу — это то, что одобрение предотвращает, а аудит только диагностирует
Не каждое действие заслуживает того же трения
Первая ошибка — трактовать «AI-действие» как один класс риска.
Агент, читающий внутренний документ, — не то же самое, что агент, отправляющий контракт. Черновая рекомендация — не то же самое, что выполненное обновление базы данных. Обратимый внутренний тег — не то же самое, что необратимая платёжная инструкция. Сообщение клиенту — не то же самое, что приватная аналитическая заметка.
Дизайн одобрения начинается с классов действий. CTO должен знать, какие классы существуют в agent-стеке и какой дефолтный путь принимает каждый класс.
Низкорисковые обратимые действия часто могут идти на автопилоте. Им по-прежнему нужны audit-доказательства, но не нужен человек, одобряющий каждый экземпляр. Примеры: внутреннее суммирование, нечувствительное обогащение, создание черновиков, тегирование или маршрутизация очередей, где откат ясен и воздействие ограничено.
Среднерисковые действия могут требовать условного одобрения. Они могут запускаться автоматически, если действие остаётся внутри известных порогов, использует одобрённые источники данных и объявляет ручку обратимости. Если действие пересекает порог или использует незнакомый контекст, оно помещается в карантин.
Действия высокого воздействия или необратимые требуют approval gate. Внешние побочные эффекты, регулируемые решения, изменения аккаунтов, платёжные инструкции, уведомления клиентов, деструктивные операции и юридические или финансовые обязательства не должны опираться только на постфактум-аудит.
Эта работа классификации — не комплаенс-театр. Это то, как автоматизация сохраняет скорость, не притворяясь, что каждое действие безопасно.
Одобрение — это runtime-решение
Одобрение не должно жить только в заметке встречи, политике онбординга или чек-листе деплоя. Оно должно быть представлено во время выполнения.
Агент предлагает действие. Governance-слой классифицирует действие. Политика проверяет класс, актора, контекст, порог, доказательства и обратимость. Система возвращает вердикт. Если требуется одобрение, действие ждёт. Если одобрение дано, ledger записывает, кто одобрил, что они видели, какая версия политики применялась и какое действие выполнилось.
Это отличается от просьбы людей ревьюить случайные выходы. Хороший approval gate даёт ревьюеру компактный конверт решения: что агент хочет сделать, почему он хочет это сделать, какие доказательства использовал, каково может быть воздействие, какое правило применяется и что случится, если действие неправильное.
Без этого конверта одобрение становится гаданием. Человек присутствует, но не обязательно информирован. Многие системы «human in the loop» проваливаются именно здесь. Они добавляют человека, не давая этому человеку полномочий, контекста или структурированной записи. Юридический якорь того, что на самом деле означает полномочие интервенции в EU AI Act, см. в Статья 14: Расшифровка человеческого надзора.
Одобрение должно означать, что человек может сказать да, нет, модифицировать или эскалировать, и система записывает это решение как часть цепочки событий.
Это делает одобрение ревьюабельным. Если клиент позже спросит, почему действие произошло, ответ — не «кто-то нажал approve». Ответ — полная запись одобрения.
Граница автопилота
Автопилот не враг governance. Неуправляемый автопилот — враг.
Зрелый agent-стек должен позволять обратимой низкорисковой работе идти без человеческой задержки. Иначе команды будут обходить систему. Модель контроля должна быть строгой там, где воздействие высокое, и тихой там, где воздействие низкое.
Полезная граница — обратимость плюс масштаб воздействия.
Если действие обратимо, низкого воздействия, внутри известного класса и подкреплено достаточными доказательствами — автопилот обычно разумен. Он по-прежнему должен эмитировать строку audit ledger. Он по-прежнему должен сэмплироваться или ревьюиться политикой. Он по-прежнему должен ставиться на паузу, если поведение дрейфует. Но ему не нужен человеческий клик каждый раз.
Если действие сложно отменить, влияет на клиента, двигает деньги, меняет регулируемую запись или расширяется за пределы известного класса — одобрение должно становиться обязательным. Действие ждёт, пока человек с полномочиями проревьюит конверт.
| Форма действия | Дефолтный путь | Audit ledger | Человеческое одобрение |
|---|---|---|---|
| Read-only внутренний анализ | Allow | Требуется | Нет |
| Внутреннее обратимое изменение состояния (известный класс) | Allow при наличии ручки обратимости | Требуется | Нет |
| Коммуникация клиенту | Условное одобрение, если претензия, класс получателя или чувствительность пересекают порог | Требуется | Иногда |
| Внешний финансовый или юридический побочный эффект | Требуется одобрение | Требуется, подписано | Да |
| Деструктивная или необратимая продакшен-операция | Deny, если воркфлоу не объявляет одобрённый emergency-путь | Требуется, подписано, хранится 5–7 лет | Да, именованная роль |
Точные классы варьируются по компаниям. Паттерн — нет.
Одобрение предотвращает bad success
AI-инциденты не всегда очевидные провалы. Иногда агент делает ровно то, что его попросили, и в этом проблема.
Support-агент может оформить возврат, который щедрый, но вне политики. Sales-агент может отправить условие скидки, которое финансы никогда не одобряли. Operations-агент может обновить запись на основе устаревших данных. Workflow-агент может закрыть тикет, который должен был быть эскалирован. Модель не упала. API вернул успех. Логи выглядят чистыми.
Это bad success: технически успешное действие, нарушающее бизнес-границу.
Аудит помогает вам найти bad success постфактум. Одобрение помогает предотвратить это, когда класс действия заслуживает ревью.
В анонимизированном развёртывании в ритейл-операциях практический риск был не в драматическом AI-провале. Это было тихое накопление автоматизированных решений, влияющих на операционное состояние. Починка была — различать предложение, алерт, запись и запись вне границ. Предложения могли течь. Рутинные алерты могли течь. Последовательные записи проходили через governance gate. Записи вне границ помещались в карантин с причинами.
Результат — не более медленная операция. Это более ясная операция. Оператору больше не приходилось реконструировать каждое исключение по памяти. Система знала, какие действия нуждались во внимании, а какие могли запускаться.
Это цель approval-архитектуры: снизить нагрузку на человека, резервируя человеческое суждение для решений, где это имеет значение.
Конверт одобрения
Полезный запрос на одобрение должен быть достаточно коротким для быстрого ревью и достаточно полным для поддержки подотчётности позже.
Минимум, он должен включать:
- Предлагаемое действие
- Класс действия
- Идентичность актора или агента
- Целевую систему или запись
- Бизнес-воздействие
- Ссылки на доказательства
- Версию политики
- Причину, по которой требуется одобрение
- Ручку обратимости или причину отсутствия обратимости
- Поведение истечения или таймаута
Ревьюер не должен читать сырые трейсы модели, если что-то не необычно. Система должна суммировать релевантный контекст и сохранять более глубокие доказательства для аудита.
Это важно, потому что очереди одобрения могут стать узким местом. Если каждый элемент требует расследования, люди будут штамповать, откладывать или забрасывать воркфлоу. Конверт одобрения — это разница между информированным контролем и перформативным трением.
Это также важно для регулируемого ревью. Будущий ревьюер должен видеть то, что видел одобряющий. Если UI одобрения показывал отполированное резюме, но ledger хранил только таймстемп и user ID — доказательство неполное. Запись одобрения должна сохранять контекст решения, а не только клик.
Дизайн дефолта
Дефолтный путь — самый важный дизайн-выбор.
Некоторые команды по умолчанию allow, потому что хотят скорости. Это работает, пока не появится новый класс действия и не выполнится до того, как кто-то заметит. Другие команды по умолчанию ручной ревью, потому что хотят безопасности. Это работает, пока очередь ревью не станет настолько шумной, что люди перестанут ей доверять.
Лучший дефолт — class-aware:
Известные низкорисковые классы — allow с аудитом. Известные условные классы — allow, только когда пороги и доказательства удовлетворены. Неизвестные классы — карантин. Известные высоковоздействующие классы — требуют одобрения. Известные запрещённые классы — deny.
Неизвестное не должно означать разрешённое. Оно должно означать, что система нашла форму действия, которую конституция ещё не понимает. Карантин — правильный ответ, потому что он сохраняет безопасность, не блокируя постоянно эволюцию продукта. Ревьюер может классифицировать новое действие, добавить правило, и будущие экземпляры потекут правильно.
Так модель одобрения улучшается со временем. Она не зависит от того, чтобы каждый сценарий был предсказан во время изначального дизайна. Она зависит от того, что runtime отказывается тихо нормализовать новый риск.
Система становится более эффективной по мере зрелости классов действий. Раннее развёртывание может помещать в карантин больше. Позднее развёртывание может больше работать на автопилоте, потому что у команды есть доказательства, пороги и паттерны обратимости. Governance должен становиться быстрее со зрелостью, а не тяжелее.
Архитектурного двоюродного брата этого различия — слой подотчётности, владеющий gate, ledger и маршрутизацией эскалации — см. в Что такое слой подотчётности AI-агентов?.
Что CTO должны спросить в этом квартале
Если ваша компания катит агентов, попросите карту одобрений.
Какие действия запускаются автоматически? Какие требуют одобрения? Какие отказываются? Какие помещаются в карантин, потому что новые или неоднозначные? Кому позволено одобрять? Какие доказательства они видят? Где хранится одобрение? Как ведёт себя система, когда никто из одобряющих не отвечает? Что случается, когда политика меняется?
Если эти ответы живут в разбросанных комментариях Jira, системных промптах и племенных знаниях — approval-слой ещё не реален.
Немедленный шаг — выбрать первый воркфлоу с необратимым воздействием и реализовать полный паттерн там: классификация действий, runtime-вердикт, конверт одобрения, запись ledger, поведение таймаута и экспорт для ревью. Как только паттерн работает, примените его к следующему воркфлоу.
Не начинайте с одобрения всего. Начинайте с одобрения действий, где audit-only был бы слишком поздним.
FAQ
В: Является ли «одобрение» тем же, что «human in the loop»?
Частично. «Human in the loop» описывает присутствие человека; одобрение описывает структуру его решения. Человек может быть «в петле», ревьюя случайные выходы, но это не одобрение — это сэмплирование. Одобрение — это когда действие ждёт, пока именованная роль оценит структурированный конверт, и вердикт записывается как часть цепочки событий.
В: А что насчёт латентности? Не замедлят ли очереди одобрения агента?
Только для действий, нуждающихся в одобрении. Смысл маршрутизации по классу действий — в том, что низкорисковые обратимые действия никогда не попадают в очередь, они идут на автопилоте. Очередь зарезервирована для действий, чьё воздействие оправдывает ожидание. Если всё в очереди — классификация неправильная, а не очередь.
В: Как обращаться с поведением таймаута?
Явно. Каждый запрос на одобрение должен объявить, что произойдёт, если ни один одобряющий не ответит в течение таймаута: deny (безопасный дефолт для необратимых действий), эскалация на старшую роль или истечение до no-op с залогированной причиной. Тихие таймауты — это ожидающий случиться провал аудита.
В: Может ли агент быть своим собственным одобряющим, если это «supervisor model»?
Нет. Одобрение, выполненное другим AI в той же границе доверия — это не одобрение, это верификация. Одобрение требует именованной человеческой роли с полномочиями принять последствие. Supervisor-модель может пре-фильтровать, оценить или аннотировать запрос, чтобы помочь человеку-ревьюеру, но не может заменить человека в записи одобрения.
В: Как удержать одобряющих от штампования?
Три рычага. Первый — сузить очередь строгой маршрутизацией по классу действий, чтобы ревьюеры видели только запросы, реально нуждающиеся в суждении. Второй — спроектировать конверт так, чтобы ревьюер мог ответить на вопрос за менее 60 секунд. Третий — сэмпл-аудитить саму очередь одобрений: отслеживать, происходят ли отказы и модификации, и трактовать 100% коэффициент одобрения как сигнал, что очередь неправильно нацелена.
Никола Ковтун, основатель Infracortex AI Studio. Мы помогаем командам разделять автопилот и одобрение, чтобы низкорисковые действия двигались быстро, а последовательные останавливались на правильном gate. Cortex Governance Gate обрабатывает маршрутизацию по классу действий; Cortex Audit Ledger записывает полный конверт; поверхность эскалации связывает их вместе. Для вашего конкретного стека — запишитесь на discovery call или см. Security Gate engagement.
См. также: EU AI Act Статья 14: Человеческий надзор | Что такое слой подотчётности AI-агентов? | Кейс европейских ритейл-операций
Cortex build: 0.3.3-260518
