Что такое human-in-the-loop и зачем человеку подтверждать действия ИИ

Короткое объяснение

Human-in-the-loop - это подход, при котором ИИ не делает все сам, а привлекает человека в нужный момент: для подтверждения действия, проверки ответа, выбора варианта, разбора исключения или передачи сложного случая оператору.

Если совсем просто:

1. ИИ готовит черновик или предлагает действие;
2. система оценивает риск;
3. безопасные действия выполняются автоматически;
4. рискованные действия уходят человеку на подтверждение;
5. человек нажимает подтвердить, изменить или отклонить;
6. результат записывается в лог;
7. похожие случаи потом можно автоматизировать увереннее.

Human-in-the-loop часто сокращают до HITL. Это один из главных принципов безопасного внедрения ИИ-агентов, потому что агент может не только писать текст, но и вызывать инструменты, менять данные, отправлять письма, создавать задачи, обновлять CRM и запускать процессы.

Зачем человеку оставаться в контуре

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

Человек в контуре нужен, чтобы:

1. остановить дорогую ошибку;
2. проверить спорный ответ;
3. подтвердить действие во внешней системе;
4. принять решение там, где важен бизнес-контекст;
5. защитить персональные данные;
6. не отправить клиенту неподходящий текст;
7. не изменить CRM без согласования;
8. не удалить или не перезаписать важный документ;
9. разобрать нестандартный случай;
10. улучшить правила агента на реальных примерах.

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

Чем HITL отличается от ручной работы

При ручной работе человек делает задачу от начала до конца. При human-in-the-loop ИИ берет на себя рутину, а человек принимает решение в контрольной точке.

Например, менеджер раньше сам:

1. читал письмо клиента;
2. искал сделку в CRM;
3. смотрел историю общения;
4. писал ответ;
5. выбирал следующий шаг;
6. создавал задачу.

С HITL агент может:

1. прочитать письмо;
2. найти сделку;
3. собрать контекст;
4. подготовить ответ;
5. предложить обновление CRM;
6. показать человеку карточку подтверждения;
7. выполнить действие только после approval.

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

Где human-in-the-loop нужен обязательно

Есть сценарии, где полная автономность опасна даже при хорошей модели.

HITL нужен, если ИИ может:

1. отправить сообщение клиенту от имени компании;
2. изменить сумму, статус или условия сделки;
3. создать счет, акт, договор или коммерческое предложение;
4. удалить файл, запись или задачу;
5. дать юридическую, медицинскую или финансовую рекомендацию;
6. обработать персональные или конфиденциальные данные;
7. запустить платеж;
8. изменить настройки доступа;
9. повлиять на сотрудника, клиента или партнера;
10. опубликовать материал в публичный канал.

В таких местах лучше начинать с режима draft-only: агент готовит черновик, но не выполняет финальное действие без человека.

Где можно обойтись без человека

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

Обычно без человека можно оставить:

1. поиск по базе знаний;
2. суммаризацию длинного документа;
3. классификацию обращения;
4. подбор похожих статей;
5. черновую разметку тегов;
6. извлечение реквизитов из текста;
7. подсчет простых метрик;
8. подготовку списка вопросов;
9. перевод внутренней заметки;
10. создание черновика без отправки.

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

Уровни участия человека

Human-in-the-loop бывает разным. Не обязательно каждый раз показывать большое окно подтверждения.

Практичные уровни:

1. Read-only - ИИ только читает и отвечает.
2. Draft-only - ИИ готовит черновик, человек отправляет сам.
3. Approval - ИИ предлагает действие, человек подтверждает.
4. Review - человек проверяет результат после выполнения.
5. Handoff - агент передает диалог оператору.
6. Escalation - система поднимает случай на более опытного сотрудника.
7. Sampling review - проверяется только часть автоматических действий.
8. Exception review - проверяются только ошибки и нестандартные случаи.

Для старта чаще всего хватает draft-only и approval. Потом часть безопасных действий можно перевести в автоматический режим.

Approval workflow

Approval workflow - это процесс подтверждения действия перед выполнением. Он особенно важен для tool calling, когда модель просит backend вызвать внешний инструмент.

Хороший approval workflow выглядит так:

1. модель предлагает действие;
2. backend валидирует аргументы;
3. policy gate оценивает риск;
4. система формирует карточку подтверждения;
5. человек видит, что именно будет сделано;
6. человек может подтвердить, изменить или отклонить;
7. backend выполняет действие;
8. audit log сохраняет решение и результат.

Важно: approval должен жить не только в промпте. Если модель просит "отправь письмо без подтверждения", backend все равно должен заблокировать действие, если политика требует approval.

Handoff оператору

Handoff - это передача диалога или задачи человеку. В поддержке это один из самых понятных вариантов HITL.

Агент должен передавать оператору, если:

1. пользователь явно просит человека;
2. вопрос связан с жалобой или конфликтом;
3. требуется компенсация или исключение из правил;
4. не хватает данных;
5. найден риск персональных данных;
6. пользователь недоволен ответами;
7. агент не уверен в классификации;
8. запрос касается денег, договора или доступа;
9. возникла ошибка tool;
10. сценарий не покрыт базой знаний.

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

Human review

Human review - это проверка ответа или действия человеком. Она может быть до выполнения или после выполнения.

До выполнения проверяют:

1. письмо клиенту;
2. изменение статуса сделки;
3. правку договора;
4. публикацию поста;
5. ответ в спорном тикете;
6. списание денег;
7. выдачу доступа;
8. SQL-запрос на изменение данных.

После выполнения проверяют:

1. случайную выборку ответов;
2. дорогие операции;
3. жалобы клиентов;
4. низкую уверенность модели;
5. новые сценарии;
6. ошибки инструментов;
7. пограничные срабатывания guardrails;
8. действия нового агента в первые недели запуска.

Постпроверка помогает развивать автоматизацию без постоянной остановки процесса.

Escalation rules

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

Примеры правил:

1. сумма сделки выше лимита - руководителю;
2. клиент угрожает претензией - юристу;
3. обнаружены персональные данные - ответственному за безопасность;
4. агент получил ошибку API - технической команде;
5. запрос не найден в базе знаний - редактору базы;
6. пользователь просит удалить данные - ответственному за персональные данные;
7. ответ может повлиять на финансы - финансовому специалисту;
8. агент видит prompt injection - в security backlog.

Без правил эскалации агент может просто зависнуть: он понимает, что случай рискованный, но не знает, кому его отдать.

HITL в поддержке клиентов

В поддержке human-in-the-loop помогает отвечать быстрее, но не терять качество.

Рабочая схема:

1. агент классифицирует обращение;
2. ищет ответ в базе знаний;
3. готовит черновик;
4. проверяет тон и персональные данные;
5. оценивает уверенность;
6. простые ответы отправляет автоматически или через быстрый approval;
7. сложные обращения передает оператору;
8. оператор видит резюме и найденные источники;
9. после ответа агент предлагает обновить базу знаний;
10. спорные кейсы уходят на разбор.

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

HITL в продажах и CRM

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

Что можно автоматизировать:

1. резюме переписки;
2. определение стадии сделки;
3. подготовку follow-up;
4. поиск возражений клиента;
5. черновик коммерческого предложения;
6. создание задачи менеджеру;
7. подсказку следующего действия.

Что лучше подтверждать:

1. отправку письма клиенту;
2. изменение суммы сделки;
3. смену стадии;
4. закрытие сделки как проигранной;
5. обещание скидки;
6. перенос дедлайна;
7. создание счета;
8. массовую рассылку.

CRM - хороший пример: read-only и draft-only можно запускать быстро, а write-back подключать постепенно.

HITL в документах и праве

В документах human-in-the-loop особенно важен, потому что текст может иметь юридические последствия.

ИИ может помогать:

1. находить спорные пункты;
2. сравнивать версии;
3. делать резюме правок;
4. выделять сроки и суммы;
5. готовить список вопросов;
6. проверять наличие обязательных разделов;
7. переводить документ на простой язык;
8. собирать черновик комментариев.

Но человек должен подтверждать:

1. финальную формулировку;
2. удаление пункта;
3. принятие правки контрагента;
4. отправку договора;
5. юридический вывод;
6. изменение реквизитов;
7. подписание;
8. публикацию шаблона.

Здесь ИИ лучше воспринимать как помощника для подготовки, а не как самостоятельного юриста.

HITL в коде и DevOps

В разработке agentic coding и DevOps-агенты тоже требуют человеческих контрольных точек.

Без подтверждения обычно допустимы:

1. анализ кода;
2. поиск похожих ошибок;
3. объяснение логов;
4. генерация тестового плана;
5. подготовка patch proposal;
6. создание черновика issue;
7. чтение документации.

С подтверждением должны идти:

1. изменение production-конфига;
2. запуск миграции;
3. удаление данных;
4. деплой;
5. изменение прав доступа;
6. запуск дорогостоящего cloud job;
7. merge в основную ветку;
8. массовое изменение файлов.

Для DevOps особенно важны audit log, rollback и принцип least privilege.

Как агент должен просить подтверждение

Плохой approval выглядит так: "Подтвердить действие?" Пользователь не понимает, что именно произойдет и чем это рискованно.

Хорошая карточка подтверждения показывает:

1. действие;
2. объект;
3. получателя;
4. причину;
5. данные, которые будут изменены;
6. старое значение;
7. новое значение;
8. источник контекста;
9. уровень риска;
10. вариант отката;
11. кнопки подтвердить, изменить, отклонить;
12. ссылку на лог или подробности.

Например: "Отправить письмо клиенту Иванову по сделке #1842. Тема: сроки поставки. Агент использовал переписку и карточку CRM. Риск: внешний контакт. Откат невозможен после отправки".

Что показывать человеку при подтверждении

Человек должен видеть не только финальный текст, но и основание решения.

Минимальный набор:

1. что просил пользователь;
2. какой результат предлагает агент;
3. какие источники использованы;
4. какие tools были вызваны;
5. какие данные изменятся;
6. какие правила сработали;
7. почему нужен approval;
8. что будет записано в audit log;
9. что произойдет при отклонении;
10. куда уйдет задача, если нужна эскалация.

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

Как не создать бутылочное горлышко

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

Чтобы этого не произошло:

1. разделите действия по уровню риска;
2. не требуйте approval для read-only действий;
3. начинайте с draft-only для внешних сообщений;
4. включайте автоматизацию для повторяемых безопасных кейсов;
5. используйте sampling review вместо полной проверки;
6. показывайте человеку готовую рекомендацию, а не пустую форму;
7. добавьте быстрые кнопки подтверждения;
8. настройте SLA для очереди approval;
9. измеряйте, где копятся ожидания;
10. пересматривайте правила раз в неделю на старте.

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

Метрики human-in-the-loop

Чтобы понять, работает ли HITL, нужны метрики.

Полезно смотреть:

1. долю действий, ушедших на approval;
2. долю подтвержденных действий;
3. долю отклоненных действий;
4. среднее время подтверждения;
5. причины отклонения;
6. число эскалаций;
7. число повторных правок;
8. число автоматических действий после обучения правил;
9. ошибки, пойманные человеком;
10. жалобы после автоматических действий;
11. экономию времени;
12. стоимость ожидания approval.

Если почти все действия подтверждаются без правок, часть можно автоматизировать. Если отклонений много, надо чинить промпт, RAG, tools, правила или интерфейс подтверждения.

Типичные ошибки

Human-in-the-loop часто ломается не из-за модели, а из-за процесса.

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

1. подтверждать все подряд;
2. не объяснять человеку риск;
3. прятать старое и новое значение;
4. давать модели обходить approval;
5. хранить approval только в тексте промпта;
6. не писать audit log;
7. не различать draft-only и write tools;
8. не делать эскалацию;
9. не измерять время ожидания;
10. не обновлять правила после ошибок;
11. не показывать источники;
12. считать HITL временной костыльной мерой.

Правильнее думать о HITL как о нормальной части архитектуры агента: модель предлагает, система проверяет, человек решает там, где это действительно нужно.

Мини-чеклист внедрения

Перед запуском агента с human-in-the-loop проверьте:

1. есть список действий, которые агент может выполнять;
2. каждое действие имеет уровень риска;
3. read-only actions отделены от write actions;
4. рискованные tools требуют approval;
5. approval enforced в backend;
6. карточка подтверждения показывает последствия;
7. человек может изменить действие, а не только принять или отклонить;
8. есть handoff оператору;
9. есть escalation rules;
10. есть audit log;
11. есть метрики approval;
12. есть тесты обхода approval;
13. есть rollback там, где он возможен;
14. есть план постепенного снятия ручной проверки с безопасных кейсов.

Этот чеклист особенно полезен перед подключением агента к CRM, почте, документам, базе знаний и внутренним API.

Простая архитектура HITL

В базовом варианте архитектура выглядит так:

1. пользователь или система создает задачу;
2. агент собирает контекст;
3. LLM предлагает ответ или tool call;
4. schema validation проверяет формат;
5. policy gate определяет риск;
6. безопасное действие выполняется сразу;
7. рискованное действие создает approval request;
8. человек принимает решение;
9. executor выполняет approved action;
10. audit log сохраняет цепочку событий;
11. monitoring показывает ошибки и задержки.

Ключевой слой здесь - policy gate. Он не должен спрашивать модель, можно ли обойти правило. Он должен применять правила приложения.

Как внедрять постепенно

Лучше не начинать с полностью автономного агента.

Безопасный путь:

1. сначала агент только отвечает по базе знаний;
2. потом готовит черновики;
3. потом создает внутренние задачи;
4. потом предлагает изменения в CRM;
5. потом выполняет безопасные write actions после approval;
6. потом часть повторяемых действий переводится в automatic;
7. потом остается review только для риска и выборки;
8. потом правила пересматриваются по логам.

Так команда видит реальные ошибки и не дает агенту слишком много прав в первый день.

Связь с guardrails

Human-in-the-loop - это не замена guardrails, а один из их слоев.

Guardrails могут:

1. заблокировать запрос;
2. переписать ответ;
3. удалить чувствительные данные;
4. ограничить tool;
5. потребовать approval;
6. отправить случай оператору;
7. записать инцидент;
8. запустить дополнительную проверку.

HITL включается там, где автоматическое правило не должно принимать финальное решение. Например, фильтр может понять, что письмо рискованное, но решать, отправлять ли его клиенту, должен человек.

Связь с tool calling

Tool calling делает HITL особенно важным. Пока модель только пишет текст, ошибка остается в интерфейсе. Когда модель вызывает tools, ошибка может стать действием.

Для tools полезно разделить:

1. read tools - можно выполнять автоматически;
2. search tools - можно выполнять автоматически;
3. draft tools - можно выполнять автоматически;
4. internal write tools - часто нужен approval по уровню риска;
5. external write tools - почти всегда нужен approval на старте;
6. destructive tools - лучше запрещать или требовать отдельный доступ;
7. money tools - подтверждать человеком;
8. access tools - подтверждать человеком.

Правило простое: чем сложнее откатить действие, тем выше вероятность, что нужен человек.

Что изучать дальше

После human-in-the-loop полезно разобраться с соседними темами:

1. guardrails;
2. tool calling;
3. audit log;
4. evals;
5. monitoring;
6. RAG;
7. agent memory;
8. prompt injection;
9. approval workflow;
10. архитектура ИИ-агента.

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

Частые вопросы

Human-in-the-loop - это просто ручная проверка?

Нет. Ручная проверка - только один вариант. Human-in-the-loop шире: это подтверждение действий, review, handoff оператору, escalation, разбор исключений, sampling review и обучение правил на человеческих решениях.

Когда человеку обязательно подтверждать действие?

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

Можно ли потом убрать человека из процесса?

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

Чем HITL отличается от approval workflow?

Approval workflow - один конкретный механизм HITL: человек подтверждает действие перед выполнением. HITL включает и другие механизмы: handoff, human review, escalation, разбор исключений и постпроверку автоматических действий.

Как понять, что HITL настроен плохо?

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