Подтверждать действие ИИ до выполнения или проверять после: что выбрать
Когда ИИ-агент начинает действовать в почте, таблице или CRM, команда обычно обещает «оставить человека в контуре». Но это выражение скрывает два принципиально разных режима. В первом человек подтверждает конкретное действие до отправки запроса. Во втором агент действует сам, а сотрудник читает журнал и при необходимости исправляет последствия. Оба режима могут быть полезны. Они не взаимозаменяемы, потому что письмо нельзя «отослать обратно», а неверную внутреннюю метку иногда можно исправить за секунды.
Вопрос начинается с обратимости
Представьте агента, который читает обращение клиента, предлагает категорию, меняет статус заказа и пишет ответ. Поставить предварительную метку «проверить» в тестовой очереди — почти обратимое действие. Отправить клиенту отказ или изменить стоимость — действие с внешним эффектом. Чем меньше обратимость, тем раньше должен находиться контроль. Для внутренних, низкорисковых операций разумно допустить последующую выборочную проверку. Для внешних сообщений, финансовых решений и доступа к данным требуется предварительное утверждение конкретного проекта действия.
Это не выбор между «человек всё делает» и «машина работает одна». Агент может собрать факты, показать черновик, перечислить источник каждого поля и ждать на последнем шаге. Пока подтверждения нет, у него нет полномочия нажать отправку. Такой вариант экономит время на подготовке, но сохраняет границу ответственности. В гайде по ограничению действий агента важно именно перечисление разрешённых операций, а не общее пожелание «будь осторожен».
Предварительное подтверждение
Его плюс — возможность предотвратить ошибку до появления последствий. Хороший экран подтверждения показывает не только кнопки «да» и «нет», но и точный адресат, финальный текст, изменяемые поля, исходные данные и разницу с текущим состоянием. Если вместо этого показывается длинный пересказ модели, сотрудник может автоматически согласиться, не увидев существенного изменения. Для высокой нагрузки нужны группировка однотипных действий и приоритет спорных случаев, иначе очередь согласования станет узким местом.
Минус — задержка. Агент не завершит задачу ночью или в выходной, если уполномоченный человек недоступен. Кроме того, согласование не гарантирует верности: человек может принять ложный факт, если не видит источник. Поэтому предварительный контроль надо соединять с тестами полей и осмысленным журналом. Утверждение письма не должно автоматически подтверждать изменение баланса: это разные полномочия. В разборе предварительного просмотра правок CRM показано, почему полезно видеть diff до записи.
Последующая проверка
Она выигрывает в скорости и подходит там, где действие локально, дешёво и быстро откатывается. Например, агент предложил теги внутренним статьям, а редактор раз в день проверяет выборку и исправляет неточные. Чтобы режим был безопасным, нужны фиксируемый результат, понятный автор решения, возможность отмены и порог, после которого автоматизация останавливается. Проверка «когда-нибудь посмотрим логи» не является процессом контроля.
Основной риск — задержка обнаружения. Пока человек увидит ошибку, она могла попасть в отчёт, рекомендацию или следующую автоматизацию. Одной кнопки «откатить» может не хватить, если другие сервисы уже прочитали неверный статус. Поэтому для последующей проверки задайте срок реакции и список downstream-систем. Если статус читает платёжный модуль или клиентский кабинет, он перестаёт быть безобидной внутренней меткой.
Сравнение на пяти критериях
По скорости последующая проверка обычно выигрывает: действие не ждёт сотрудника. По предотвращению необратимой ошибки сильнее подтверждение до выполнения. По нагрузке на человека результат зависит от интерфейса: предварительный просмотр каждого мелкого шага утомляет, а редкая выборочная проверка может пропустить систематический сбой. По аудиту оба режима требуют журнала, но предварительный должен хранить версию показанного черновика и решение утверждающего; последующий — исходное состояние, действие, сигнал о проблеме и откат. По доверию клиента решает не название режима, а фактическая возможность исправить вред.
Есть и гибрид: низкорисковые шаги выполняются автоматически, а внешние или необычные — идут на подтверждение. Порог необычности нельзя брать только из самоуверенности модели. Добавьте объективные условия: нет номера заказа, сумма выше установленной границы, данные двух документов расходятся, адресат новый, операция затрагивает права человека. Набор проверок нужно прогнать на старых спорных случаях. В материале о журнале действий агента показано, какие записи помогают восстановить цепочку решений.
Как проверить выбранный режим до запуска
Возьмите не только типовой пример, но и письмо с неверной датой, пустой счёт, повторное событие и конфликт двух источников. Для каждого сценария запишите, какое действие агент предложил, какой экран увидел человек, что было сделано и можно ли вернуться к исходному состоянию. Разрешите автоматическое выполнение только для случаев, где цена ошибки заранее известна и укладывается в принятый риск. После запуска измеряйте не только долю одобрений, но и время обнаружения неверного действия. Высокая скорость без этого показателя вводит в заблуждение.
Вывод: подтверждать до выполнения стоит то, что внешне заметно, чувствительно или трудно отменить. Проверять после можно обратимые внутренние шаги при хорошем журнале и быстром откате. Большинство полезных сценариев находится между этими полюсами и требует маршрутизации по риску, а не одного переключателя на весь процесс.
Короткие ответы
Если человек нажал «одобрить», агент уже безопасен? Нет. Человек может не увидеть неверный исходный факт, поэтому нужны читаемый diff и ссылка на документ.
Можно ли проверять после отправки письма? Проверять необходимо, но это уже не предотвращает доставку. Для чувствительных писем лучше подтверждение до отправки.
Достаточно ли логов для отката? Логи объясняют событие, но не отменяют внешние последствия. Способ исправления следует проектировать отдельно.