Одобрения без очереди ради очереди: как провести границу риска

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

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

Начните с карты побочных эффектов

Возьмите реальный процесс и выпишите все действия, которые меняют внешний мир. Полезно разделить их на чтение, подготовку, обратимое изменение, коммуникацию наружу и необратимую операцию. Для каждой строки укажите владельца риска, максимально допустимые параметры и признаки, по которым проверяющий поймёт смысл действия. Формулировка «вызвать почтовый инструмент» недостаточна; в карточке нужны адресат, тема, ключевой смысл и ожидаемое последствие.

Моделируемый сценарий: агент поддержки читает статус заказа и готовит ответ автоматически. Отправка ответа клиенту требует проверки только при возврате денег или изменении адреса. Сам возврат всегда ждёт сотрудника, который видит заказ, сумму, способ оплаты и причину. Это не готовая политика AiHummer: каналы, инструменты, права и правила эскалации организация настраивает под свой процесс.

Разведите право запустить и право подтвердить

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

Очередь одобрений тоже требует владельца. Кто проверяет запрос вечером? Что происходит, если ответственный отсутствует? Через какое время запрос теряет смысл? Можно ли передать его другому сотруднику? Если процесс не отвечает на эти вопросы, пауза превращается в скрытый дедлайн. Для срочных случаев лучше заранее определить безопасный резервный маршрут, чем разрешать обход гейта вручную.

Покажите человеку решение, а не сырой JSON

Аргументы должны быть достаточными для осмысленного решения. Проверяющему важны получатель, сумма, источник данных, причина и необратимые последствия. Секреты при этом не должны попадать в карточку или журнал. Если интерфейс показывает только технические поля, добавьте понятное описание инструмента и сократите его контракт: узкая операция «создать черновик возврата» безопаснее универсального HTTP-вызова с произвольным адресом.

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

Ограничения, которые стоит проговорить

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

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

Чек-лист перед пилотом

Выберите один процесс и перечислите все его побочные эффекты.
Для каждого действия зафиксируйте цену ошибки и возможность отката.
Поместите под гейт конкретные инструменты, а не абстрактную категорию.
Назначьте проверяющих и отделите их права от прав инициатора.
Покажите в карточке бизнес-аргументы, скрыв секреты.
Проверьте одобрение, отказ, истечение и неоднозначный сетевой ответ.
Запишите путь эскалации, если проверяющий недоступен.
Через месяц разберите журнал и скорректируйте политику без автоматического снятия защиты.

Как избежать «усталости от подтверждений»

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

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

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

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

Четыре вопроса владельцу процесса

Что именно изменится во внешней системе? Может ли это изменение быть отменено? Какие данные нужны человеку для решения? Как система докажет, что после неопределённого ответа действие произошло ровно один раз? Если хотя бы один ответ отсутствует, не расширяйте автономность: сначала сузьте инструмент или дополните наблюдаемость.

Механика описана в документации по одобрениям и на странице ролей, модерации и аудита. Сопоставьте её со своей картой риска и попробуйте один ограниченный сценарий на тестовом контуре.