Human-in-the-loop: как добавить подтверждения в работу ИИ-агента

Где нужен человек, а где нет

Human-in-the-loop (HITL) — это схема, в которой ИИ-агент готовит действие, а выполняется оно только после одобрения человеком. Подтверждать всё подряд не нужно: это убивает смысл автоматизации. Подтверждение нужно там, где ошибка дорогая или её нельзя отменить.

Простое правило: агент сам читает, ищет, считает и готовит черновики. Человек одобряет то, что меняет мир за пределами системы: деньги, сообщения клиентам, удаление и массовое изменение данных.

Как классифицировать действия агента

Составьте список всех инструментов (tools), которые доступны агенту, и оцените каждый по трём вопросам:

• Обратимо ли действие? Черновик письма — да, отправленное письмо — нет.
• Сколько стоит ошибка? Деньги, репутация, юридические последствия.
• Кто увидит результат? Внутренний пользователь или клиент, партнёр, госорган.

На основе ответов получится три уровня:

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

Как устроить очередь согласований

Очередь — это таблица заявок, где каждая запись содержит всё, чтобы принять решение за несколько секунд:

• что именно агент хочет сделать (инструмент и параметры, в читаемом виде);
• почему: исходный запрос, контекст, краткое обоснование от модели;
• какой объект затрагивается: клиент, заказ, сумма;
• кнопки «Одобрить», «Отклонить», «Изменить и одобрить».

Заявки удобно показывать там, где люди и так работают: в CRM, в Telegram-боте для сотрудников, во внутренней админке. Получил уведомление — нажал кнопку — агент продолжил.

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

Журнал аудита

Каждое действие агента — и автоматическое, и подтверждённое — пишется в журнал:

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

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

Как не замедлить всё

Подтверждения быстро становятся узким местом, если их слишком много. Что помогает:

• Пороги. Возврат до определённой суммы — автоматически, выше — через человека. Порог задаёт бизнес, а не модель.
• Пакетное одобрение. Двадцать однотипных писем можно просмотреть списком и одобрить разом.
• Таймауты и эскалация. Если заявку не разобрали за отведённое время, она уходит другому сотруднику или отменяется — но никогда не выполняется молча.
• Постепенное расширение доверия. Если какой-то тип действий долго одобряется без правок, его можно перевести в автоматический режим с выборочной проверкой.
• Понятные карточки. Чем лучше оформлена заявка, тем быстрее решение. Сырой JSON вместо описания — частая причина задержек.

Частые ошибки

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