Сотрудничество человека и агента выходит за рамки простого «участия человека в процессе». Оно определяет границы автономности агента, а также потребности и механизмы обратной связи для человеческого контроля.

ИИ-агент — это программное обеспечение, способное использовать модель LLM для выбора действий и продвижения к поставленной цели. В бизнес-контексте агент может извлекать данные или вызывать инструменты, а затем предлагать изменения в определенном рабочем процессе. Сотрудничество человека и агента определяет, как люди участвуют в этой работе и где заканчиваются полномочия агента.

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

Определение границ взаимодействия

Фраза «человек в контуре» (human in the loop) относится к системе, в которой сохраняется определенный уровень участия человека. Она не обязательно объясняет, за что именно отвечает этот человек и когда он может вмешаться. Пользователь, одобряющий возврат средств до его осуществления, выполняет иную роль, чем операционный руководитель, еженедельно проверяющий выборку уже выполненных возвратов.

Стандарт NIST AI Risk Management Framework рекомендует четко формулировать и разграничивать роли при настройке и контроле систем взаимодействия человека и ИИ. Для агента это означает определение того, кто ставит цели и кто обладает полномочиями одобрять важные действия. Это также включает определение того, кто отвечает за мониторинг действий агента в рабочей среде и за обработку эскалаций.

Эти обязанности формируют границы взаимодействия. Агент получает достаточно полномочий для выполнения полезной работы внутри этих границ, в то время как приложение предотвращает его выход за их пределы без участия человека.

Выбор паттерна делегирования

Модель делегирования описывает, как распределяется ответственность во время выполнения задачи. Нам не нужна единая модель для всего приложения, поскольку подходящий уровень делегирования может меняться от одного действия к другому.

Следующие паттерны служат практической отправной точкой:

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

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

Выбор между предварительным одобрением и последующим просмотром

Предварительное одобрение (approval) происходит до выполнения действия и приостанавливает его до вмешательства уполномоченного лица. Последующий просмотр (review) подразумевает анализ уже выполненного действия и выявляет ошибки без приостановки успешных процессов.

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

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

Сделать выбор между этими двумя подходами можно на основе следующих критериев:

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

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

Проектирование процесса эскалации

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

Там, где это применимо, полезно встраивать триггеры эскалации в правила приложения (то есть заранее определенные условия, когда агент должен остановиться или передать задачу). Агент может эскалировать задачу, если она выходит за рамки его зоны контроля или превышает заданный финансовый лимит.

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

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

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

Закрепление доверия и контроля на программном уровне

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

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

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

Модель может подготовить запрос на возврат средств, но она не определяет собственные полномочия. Код приложения проверяет запрос и применяет лимиты, которые бизнес может регулировать. Затем слой исполнения записывает результат и уведомляет инженера поддержки в случае сбоя действия.

Утверждение также должно оставаться привязанным к состоянию, которое видел проверяющий, поэтому приложение должно аннулировать его, если аргументы запроса или соответствующая запись изменяются во время ожидания действия. Изменение политики перед выполнением должно вызывать те же проверки, поскольку валидное решение не должно санкционировать действие, которое проверяющий никогда не видел.

NIST AI RMF Playbook рекомендует вести историю и журналы аудита для контроля. В нем также указывается на переопределения и эскалации как на доказательство работы этих механизмов. Для приложения это означает отслеживание того, как часто люди одобряют или отклоняют предложение и как часто агент достигает границы.

Выбор правильного паттерна

Цель состоит не в том, чтобы дать агенту полную автономность. Напротив, нам нужен наименее ограничительный паттерн, который позволит удерживать действия в пределах допустимого риска организации.

Чтобы выбрать этот паттерн, можно ответить на несколько вопросов:

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

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

Граница может меняться по мере сбора доказательств командой. Задача может начинаться с утверждения каждого действия и переходить к выборочной проверке после того, как система продемонстрирует надежное поведение. Рост числа переопределений или исключений из правил может оправдать повторное сужение делегирования.

Заключение

Взаимодействие человека и агента — это отдельная парадигма, отличающаяся от общих стратегий «участия человека в процессе» (human-in-the-loop). В ней подробно описывается степень автономности агента, а также необходимость человеческого контроля и механизм обратной связи для агента. Хороший паттерн проектирования также предоставляет агенту четко определенный процесс эскалации для действий, выходящих за рамки его назначенной области.

Для разработчиков эти решения относятся к границам приложения. Разрешения и валидация ограничивают агента перед выполнением, в то время как записи аудита делают его поведение доступным для анализа. Когда делегирование соответствует последствиям каждого действия, агент может помогать продвигать бизнес-задачи вперед, не лишая человека контроля.

Чтобы узнать больше о создании приложений и агентов на базе ИИ с помощью Progress, ознакомьтесь со следующими ресурсами: