Human-in-the-loop ИИ-агенты: согласование, эскалация и контроль

Прямой ответ

Human-in-the-loop ИИ-агент автоматизирует рутинные шаги, но останавливается перед решением, которое принадлежит человеку, или перед действием с высоким риском. Человек может согласовать, отклонить или изменить предложенное действие, имея факты, нужные для оценки. Затем агент выполняет разрешённое действие и фиксирует результат.

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

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

Runtime HITL и training-time HITL

В общем смысле human-in-the-loop значит, что люди участвуют в работе, надзоре или принятии решений автоматизированных систем (IBM). В обучении машинного обучения это часто работа на этапе обучения: разметка данных, обратная связь по предпочтениям (RLHF) или active learning. Для production ИИ-агентов runtime HITL другой: агент предлагает действие инструмента, workflow останавливается, и человек решает до реального побочного эффекта. Этот материал про runtime-контрольные ворота, а не про циклы обучения модели.

Где человек находится в архитектуре

Запрос
   |
   v
План агента -> read-only tools -> пакет доказательств
   |                              |
   | безопасно, обратимо          | риск, внешний эффект, неясность
   v                              v
Автовыполнение               Очередь ручной проверки
   |                         | согласовать | изменить | отклонить
   |                         v            v         v
   +--------------------> Контролируемое действие  Эскалация
                                  |
                                  v
                         Аудит-лог + метрики исхода

Рисунок: поток контрольных ворот для ручного согласования в системе ИИ-агента. Безопасную обратимую работу можно выполнять автоматически; рискованная или неясная работа попадает в очередь проверки до побочных эффектов.

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

Практичное разделение - propose, затем commit: агент возвращает структурированный intent и параметры; человек (или политика) может их изменить; только после этого приложение выполняет вызов инструмента. Платформенные продукты выражают ту же идею как user confirmation перед критическими tools или return of control, когда приложение выполняет действие после ввода человека (AWS Bedrock Agents user confirmation; return of control). Используйте это как язык паттернов, а не как требование внедрить конкретный cloud-продукт.

Какие действия обычно требуют ворот

• Внешние отправки: email, ответы в чатах, счета, уведомления и массовые рассылки.
• Деньги: платежи, возвраты, кредиты на счёт, изменение цен и заказы на закупку.
• Доступ: смена ролей, выдача credentials, блокировка аккаунта и production-деплои.
• Системы учёта: стадии CRM, закрытие тикетов, обновление остатков и разрушающие записи в базе.
• Публичный или регулируемый контент: публикации, юридические формулировки, медицинские или финансовые утверждения и чувствительные ответы клиентам.
• Необратимые операции: удаления, отмены, принятие договора или действие, у которого откат медленный или неполный.

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

Согласование или эскалация: таблица решений

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

Минимальный дизайн ворот согласования

1. Назовите точное действие и максимальный радиус поражения.
2. Опишите политику наблюдаемыми условиями, а не размытой инструкцией «использовать здравый смысл».
3. Назначьте согласующего по роли и правам, а не по тому, кто сейчас онлайн.
4. Соберите пакет доказательств: входы, предполагаемые побочные эффекты, источники, результаты проверки и превью того, что произойдёт при согласовании.
5. Дайте пути «согласовать», «отклонить» и «изменить» с фиксацией причины каждого решения.
6. Задайте SLA и путь для устаревших элементов, чтобы очередь не исчезала молча (напомнить, переназначить, закрыть вручную или безопасно отменить; никогда не выполнять автоматически только из-за истечения срока).
7. Залогируйте предложение, проверяющего, решение, финальный вызов инструмента и результат под одним correlation ID.
8. Измеряйте долю переопределений, время в очереди, инциденты и успешное завершение до ослабления ворот.

Тот же паттерн - один из ключевых контролей вокруг production ИИ-агента. Его нужно проектировать вместе с правами инструментов, evals, observability и аварийным стопом.

Оркестрационные стеки с durable pause и resume упрощают это в коде (например, human-approval workflows с signals и timers в Temporal HITL cookbook). Выбор продукта вторичен относительно политики: именованный владелец, пакет доказательств, SLA и отсутствие автовыполнения только потому, что время вышло.

Паттерны зрелости за пределами одних ворот

Когда базовые ворота работают, можно наращивать контроль без переписывания всего агента:

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

Контекст надзора (не юридическая консультация)

Человеческий надзор в публичных фреймворках управления рисками - цель проектирования, а не галочка соответствия «в один клик». В EU AI Act Article 14 говорит о human oversight для high-risk AI systems, чтобы физические лица могли контролировать работу и вмешиваться при необходимости (текст Article 14; опциональный институциональный контекст: EC AI Act service desk по Article 14). В США NIST AI Risk Management Framework - добровольный подход к картированию, измерению и управлению рисками ИИ, включая human oversight как часть надёжной эксплуатации (NIST AI RMF hub; AI RMF 1.0 PDF).

Эта статья не определяет, является ли система читателя high-risk по EU AI Act и является ли дизайн ворот «соответствующим» требованиям. Относитесь к регулированию и фреймворкам как к контексту; применимость определяет юридический советник. Для production-агентов инженерный перевод конкретен: пауза до воздействия, дать компетентному проверяющему пригодные доказательства, залогировать решение и сохранить путь аварийной остановки.

Частые режимы сбоев

Ворота на всём подряд

Если каждый внутренний черновик требует согласования, агент становится медленным chat-интерфейсом, а проверяющие начинают нажимать «согласовать» не читая. Риск формальной штамповки без чтения - известное ограничение слишком широких HITL-дизайнов (Databricks on HITL limitations). Перенесите ворота к первому значимому побочному эффекту.

Нет ворот вообще

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

Эскалация как отказ

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

Нет именованного владельца

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

Слабые пакеты доказательств

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

Нет аудиторского следа

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

Чеклист внедрения

• Составьте перечень всех действий инструментов и отметьте, является ли действие внешним, финансовым, разрушающим, регулируемым или трудно обратимым.
• Определите классы: разрешено, запрещено, требует согласования и только через эскалацию.
• Настройте ролевой доступ для согласующих и отделите согласование от администрирования системы.
• Спроектируйте карточку проверки с достаточными доказательствами и превью точного побочного эффекта.
• Добавьте idempotency keys, чтобы двойное согласование не создавало двойное действие (см. также идемпотентность, повторы и очереди).
• Задайте лимиты повторов и направляйте повторные сбои в очередь исключений с человеческим владельцем.
• Фиксируйте решения и правки как размеченные данные для evals, а не как неструктурированную историю чата.
• Протестируйте пути согласования, отклонения, правки, истечения срока, двойного клика, недоступного инструмента и неавторизованного проверяющего.
• Запускайте shadow mode, затем canary для пути выполнения с воротами.
• Еженедельно смотрите время в очереди, долю переопределений, долю инцидентов и ложные эскалации.
• Документируйте аварийный стоп и процесс ужесточения ворот во время инцидента.
• Включайте автосогласование для класса действий только после того, как измеренный риск внутри согласованного порога; для dual-control или sampling maturity зафиксируйте стадию и критерии выхода до ослабления базовых ворот.

Как Northstar использует HITL

Northstar картирует workflow и его исключения до размещения ворот. Мы оставляем рутинные обратимые шаги в движении и ставим человеческий контроль там, где бизнес уже отвечает за значимое решение. Смотрите решения про аудит production-path и модель внедрения.