ОТЛИЧНЫЙ гайд по Human-on-the-Loop: что это, 3 схемы, 6 ситуаций для вмешательства человека и 5 правил HOTL-workflow

Human-on-the-Loop (HOTL) — это подход, при котором человек больше не нажимает каждую кнопку за искусственный интеллект, но и не исчезает из процесса совсем. Он задаёт правила, устанавливает границы, следит за исключениями и вмешивается тогда, когда ситуация становится рискованной, дорогой или непонятной.

«В эпоху AI-агентов человек перестаёт быть оператором корпоративной системы. Его новая роль — управлять уровнем автономности машины»

Звучит немного так, будто руководителю выдали не сотрудника, а очень быстрого, умного и слегка самоуверенного робота. Он может обработать тысячи заявок, проверить документы, оформить заказ или запустить бизнес-процесс. Но если робот внезапно решил купить компании 500 ноутбуков вместо пяти, кто-то всё-таки должен сказать: «Стоп, железный человек, давай сначала сверим бюджет».

Что такое HOTL

Human-on-the-Loop, или HOTL, — это модель взаимодействия человека и искусственного интеллекта, при которой AI-агент работает автономно в заранее определённых рамках, а человек осуществляет надзор, контролирует риски и подключается при необходимости.

Главная идея HOTL — человек контролирует не каждое действие, а правила, границы и последствия работы AI-агента.

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

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

Предыстория

Первые корпоративные системы в основном работали по принципу «если произошло A, сделай B». Человек заранее описывал все варианты, программа строго следовала алгоритму, а неожиденная ситуация обычно заканчивалась сообщением об ошибке. Система не спорила, не фантазировала и не пыталась «проявить инициативу».

С развитием машинного обучения системы научились распознавать изображения, тексты, голоса и закономерности в данных. Затем появились большие языковые модели, способные понимать запросы и формировать осмысленные ответы. Следующим шагом стали AI-агенты — системы, которые не просто отвечают на вопросы, а выполняют задачи.

Агент может получить цель «обработать просроченные счета», найти нужные данные в CRM, определить приоритеты, составить письма клиентам, отправить их и внести результаты в учётную систему. Человеку уже не нужно вручную руководить каждым шагом. Но возникает новая проблема: если агент сам выполняет много действий, как не дать ему случайно перейти границу?

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

Расшифровка и перевод

Английское выражение Human-on-the-Loop можно перевести как «человек в контуре управления» или «человек над контуром». Второй вариант точнее передаёт смысл: человек находится не внутри каждого отдельного шага, а над всей системой, наблюдая за тем, как она работает.

Термин	Перевод	Роль человека
Human-in-the-Loop	Человек в контуре	Подтверждает или выполняет отдельные действия
Human-on-the-Loop	Человек над контуром	Наблюдает, задаёт правила и вмешивается при отклонениях
Human-out-of-the-Loop	Человек вне контура	Не участвует в принятии решений во время работы системы

Важно не путать HOTL с полным отсутствием контроля. Если человек не нажимает кнопку «подтвердить» для каждой операции, это ещё не значит, что система работает без него. Контроль может быть реализован через лимиты, роли, политики, журналы, уведомления, автоматическую остановку и обязательную эскалацию.

Суть подхода

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

Хороший HOTL-процесс отвечает не на вопрос «можно ли доверить всё AI?», а на вопрос «какую часть работы можно безопасно передать AI именно сейчас?».

Для этого в системе заранее определяются несколько уровней автономности:

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

Например, AI-агент может самостоятельно вернуть клиенту товар стоимостью до 10 000 рублей, но при возврате дорогого оборудования обязан запросить подтверждение руководителя. Это не недоверие к искусственному интеллекту, а нормальная финансовая гигиена.

От HITL к HOTL

HITL — Human-in-the-Loop — означает, что человек включён прямо в каждый значимый шаг процесса. Агент формирует рекомендацию, затем ждёт подтверждения. Человек проверяет, нажимает кнопку, и только после этого система продолжает работу.

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

Переход от HITL к HOTL — это переход от поштучного согласования действий к управлению правилами и исключениями.

Упрощённо разницу можно представить так:

HITL — человек участвует в каждом шаге

ЗАДАЧА
  │
  ▼
AI-АГЕНТ предлагает действие
  │
  ▼
ЧЕЛОВЕК проверяет
  │
  ├── подтвердить ──► агент выполняет
  └── изменить/отклонить ──► агент ждёт новых указаний


HOTL — человек контролирует поток и исключения

ЗАДАЧА
  │
  ▼
AI-АГЕНТ анализирует и действует
  │
  ├── стандартная операция ──► выполнить автоматически
  ├── операция в лимите ─────► выполнить и записать в журнал
  ├── высокий риск ──────────► запросить человека
  └── нарушение политики ───► остановить и заблокировать

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

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

Критерий	HITL	HOTL
Участие человека	В каждом или почти каждом шаге	При исключениях и рискованных операциях
Скорость	Зависит от доступности сотрудников	Высокая для типовых операций
Масштабирование	Ограничено числом операторов	Лучше масштабируется
Основной риск	Человеческая усталость и задержки	Ошибки правил и чрезмерная автономность
Главная задача человека	Проверить конкретную операцию	Настроить, наблюдать и корректировать систему

Простыми словами

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

Вот это и есть HOTL. AI работает сам, пока ситуация обычная. Человек появляется, когда ситуация перестаёт быть обычной.

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

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

HOTL + AI Gateway + MCP. Схема

HOTL становится особенно мощным, когда объединяется с AI Gateway и MCP. В таком сочетании AI-агент получает единый контролируемый доступ к корпоративным инструментам, а человек и политики безопасности остаются над агентом.

AI Gateway — это контрольная точка между моделью и внешними системами, а MCP — стандартизированный способ дать агенту доступ к инструментам и данным.

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

MCP, или Model Context Protocol, — протокол, который помогает подключать AI-модели к инструментам, источникам данных и функциям по более унифицированным правилам. Благодаря этому агент может обращаться не к хаотичному набору самописных интеграций, а к описанным инструментам с понятными параметрами и ограничениями.

Пользователь или бизнес-событие
              │
              ▼
        AI-АГЕНТ
              │
              ▼
      AI GATEWAY
      ├── проверка личности и роли
      ├── проверка политики
      ├── оценка риска
      ├── лимиты и бюджет
      ├── маскирование данных
      └── журналирование
              │
              ▼
           MCP
      ├── CRM
      ├── ERP
      ├── база знаний
      ├── почта
      ├── платёжная система
      └── внутренние инструменты
              │
              ▼
        ДЕЙСТВИЕ АГЕНТА
              │
      ┌───────┴────────┐
      ▼                ▼
  разрешено        исключение
      │                │
      ▼                ▼
  выполнить       ЧЕЛОВЕК

В этой схеме агент не получает «магический ключ от всей компании». Он обращается к конкретному инструменту, а запрос проходит через несколько проверок. Например, агент может иметь право читать карточки клиентов, но не может удалить клиента из CRM. Может подготовить платёж, но не отправить его без подтверждения финансового директора.

Практическая ценность связки состоит в разделении ответственности:

• AI-агент понимает задачу и выбирает последовательность действий;
• MCP предоставляет стандартизированные инструменты;
• AI Gateway проверяет и ограничивает обращения;
• HOTL-механизм решает, когда нужен человек;
• BPM-система управляет маршрутом, сроками и эскалациями;
• журнал аудита фиксирует, кто, что и почему сделал.

Компонент	Что делает	Пример контроля
AI-агент	Планирует и выполняет задачу	Обрабатывает заявку клиента
AI Gateway	Проверяет запросы, политики и доступ	Не разрешает отправить платёж выше лимита
MCP-сервер	Предоставляет инструменты и данные	Даёт агенту функцию поиска заказа
HOTL-модуль	Определяет необходимость вмешательства	Передаёт необычную операцию руководителю
BPM-система	Маршрутизирует процесс и эскалации	Назначает задачу ответственному сотруднику

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

Почему без HOTL агенты плохо масштабируются

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

Без HOTL рост числа AI-агентов часто увеличивает не производительность, а количество неконтролируемых исключений.

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

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

Третий риск — конфликт целей. Например, агенту поручили сократить время обработки обращений. Он может начать закрывать сложные заявки шаблонными ответами, потому что статистика скорости улучшилась. Формально цель достигнута, а клиенты почему-то стали недовольны. Машина не вредничает — она просто оптимизирует то, что ей измерили.

Четвёртый риск — непрозрачность. Если в системе не сохраняются входные данные, решения, вызовы инструментов и причины эскалации, после инцидента будет трудно понять, что произошло. Все будут смотреть друг на друга, а агент — молчаливо генерировать очередной отчёт.

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

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

Человек превращается из оператора в надзор

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

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

Это изменение затрагивает сразу несколько ролей.

Старая роль	Новая роль в HOTL	Что меняется
Оператор	Надзорный специалист	Контролирует исключения, а не каждую операцию
Руководитель	Владелец политики	Задаёт лимиты, правила и уровни автономности
Аналитик	Куратор качества решений	Проверяет метрики, ошибки и системные перекосы
ИТ-администратор	Архитектор доступа	Ограничивает инструменты и права AI-агентов
Комплаенс-специалист	Проектировщик ограничений	Определяет запрещённые действия и обязательные проверки

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

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

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

Когда человек должен вмешиваться

Человек должен вмешиваться не потому, что «AI всё равно ничего не понимает», а потому, что некоторые решения требуют ответственности, контекста, ценностей или полномочий, которые нельзя надёжно свести к одной вероятности в модели.

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

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

Ситуация	Действие агента	Уровень контроля
Сумма заказа < 10 000 ₽	Выполнить самостоятельно	Автономно
Сумма 10 000–100 000 ₽	Выполнить и записать в журнал	Автономно с аудитом
Сумма > 100 000 ₽	Запросить человека	Обязательное подтверждение
Необычная операция	Остановиться и эскалировать	Ручная проверка
Нарушение политики	Заблокировать	Запрет
Низкая уверенность	Передать человеку	Эскалация

Финансовая операция выше лимита

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

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

Необычная операция

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

В таких случаях опасно заставлять агента «сделать как-нибудь». Необычная ситуация — это сигнал для дополнительной проверки. Человек должен понять, действительно ли перед ним новый нормальный сценарий или попытка обойти ограничения.

Низкая уверенность или конфликт данных

Модель может быть неуверенной в классификации документа, личности клиента, смысле запроса или выборе следующего действия. Ещё сложнее ситуация, когда разные источники противоречат друг другу: CRM показывает один адрес, договор — другой, а письмо клиента содержит третий.

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

Юридически или репутационно значимое решение

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

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

Нарушение политики безопасности

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

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

Главное ограничение — доверие

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

Доверие к AI нельзя приказать. Его можно только заработать прозрачностью, ограничениями и стабильным качеством.

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

Полезно вводить режим постепенного запуска:

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

Human-on-the-Loop как новая роль руководителя

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

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

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

Второе изменение — необходимо назначать владельцев AI-процессов. У каждого агента должен быть человек или подразделение, ответственное за его качество, права доступа, обновление правил и анализ инцидентов.

Зона ответственности	Вопрос руководителя	Результат
Цель	Какую бизнес-задачу решает агент?	Понятный ожидаемый результат
Границы	Что агенту запрещено делать?	Политики и ограничения
Лимиты	Какие суммы, объёмы и частота допустимы?	Пороговые значения
Эскалация	Когда и кому передавать проблему?	Маршруты согласования
Метрики	Как понять, что агент работает хорошо?	KPI, SLA и показатели качества
Ответственность	Кто разбирает ошибку?	Назначенный владелец процесса

Третье изменение — руководитель должен следить не только за результатом, но и за поведением системы. Например, агент может обрабатывать заявки быстрее, но при этом чаще передавать сложные случаи людям. Или наоборот: почти не эскалировать задачи, потому что предпочитает уверенно угадывать.

Хороший набор метрик может включать:

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

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

HOTL workflow для обработки проблем

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

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

В хорошем HOTL workflow заранее определено:

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

Всё это проще всего реализуется в BPM-системах. BPM, или Business Process Management, позволяет описать маршрут задачи, условия перехода, роли, сроки, уведомления, точки согласования и правила повторной обработки.

ЗАДАЧА
   │
   ▼
AI-АГЕНТ
   │
   ├── действие ──► результат
   ├── действие ──► результат
   ├── действие ──► результат
   │
   └── проблема / исключение
             │
             ▼
        ЧЕЛОВЕК
             │
       ┌─────┴─────┐
       ▼           ▼
   продолжить    остановить
       │
       ▼
  изменить параметры,
  выбрать другой маршрут
  или вернуть агенту задачу

Рассмотрим workflow по шагам. Сначала поступает задача: заявка клиента, документ, платёж, обращение сотрудника или бизнес-событие. Агент классифицирует её, собирает контекст и строит план действий.

Затем каждое действие проходит проверку политики. Если операция разрешена и находится в пределах лимитов, агент выполняет её. Результат записывается в журнал. Если операция требует согласования, BPM-система создаёт задачу для конкретной роли, например финансового директора или специалиста по безопасности.

Человек получает не просто кнопку «одобрить». Ему должны быть доступны:

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

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

Что агент может делать самостоятельно

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

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

Какие действия требуют вмешательства

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

Правило должно быть конкретным. Формулировка «в сложных случаях спрашивать человека» слишком расплывчата. Лучше написать: «Если сумма выше 100 000 рублей, получатель новый, а договор не найден, операция блокируется и передаётся финансовому директору».

При каких условиях происходит эскалация

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

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

Что человек может разрешить, изменить или остановить

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

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

Какие действия журналируются

Журнал должен содержать не только финальный результат, но и важные промежуточные события:

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

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

Практические примеры HOTL

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

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

Пример 1. Возврат товара в интернет-магазине

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

ЗАПРОС: возврат товара
│
├── заказ найден? ................ да
├── срок возврата соблюдён? ...... да
├── сумма: 7 500 ₽
├── категория: стандартная
└── конфликт данных? ............. нет

РЕШЕНИЕ: выполнить автоматически
Действия:
- создать заявку на возврат;
- отправить клиенту инструкцию;
- записать событие в журнал.

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

Пример 2. Закупка оборудования

Агент анализирует заявку подразделения, проверяет бюджет и сравнивает предложения поставщиков. Закупку на небольшую сумму он может оформить самостоятельно, если поставщик уже находится в белом списке.

ЗАЯВКА: 25 мониторов
│
├── бюджет подтверждён? .......... да
├── поставщик в реестре? .......... да
├── сумма: 86 000 ₽
├── отклонение от типовой цены? ... нет
└── нужен договор? ................ нет

РЕШЕНИЕ: выполнить и записать в журнал

ЗАЯВКА: серверное оборудование
│
├── сумма: 640 000 ₽
├── новый поставщик
└── требуется договор

РЕШЕНИЕ: остановить и запросить финансового директора

Человеку показываются предложения, сравнение цен, сведения о поставщике, бюджет и объяснение, почему сработала эскалация. Руководитель может разрешить закупку, запросить дополнительные предложения или отклонить её.

Пример 3. Обработка входящей почты

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

ПИСЬМО: "Срочно изменить реквизиты оплаты"
│
├── отправитель новый? ............ да
├── вложение есть? ................ да
├── просьба изменить платёжные данные
├── совпадает с политикой? ........ нет
└── риск фишинга: высокий

ДЕЙСТВИЕ: заблокировать автоматическую обработку

Маршрут:
1. создать событие безопасности;
2. уведомить владельца договора;
3. передать письмо специалисту ИБ;
4. не менять реквизиты без проверки.

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

Пример 4. Поддержка корпоративных сотрудников

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

ЗАПРОС: выдать доступ к финансовому модулю
│
├── сотрудник идентифицирован? .... да
├── роль подтверждена? ............ частично
├── доступ критичный? ............. да
├── заявка руководителя? .......... нет

РЕШЕНИЕ: передать на согласование

ЧЕЛОВЕК МОЖЕТ:
- подтвердить доступ;
- запросить обоснование;
- ограничить срок действия;
- отклонить запрос.

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

Как внедрять HOTL в компании

Внедрение HOTL лучше начинать не с покупки модного AI-продукта, а с выбора конкретного процесса. Нужно понять, где есть большой объём повторяющихся операций, понятные правила и измеримый результат.

Лучший первый процесс для HOTL — не самый эффектный, а достаточно полезный, ограниченный и безопасный для эксперимента.

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

1. Описать процесс. Зафиксировать входы, шаги, результаты, исключения и ответственных.
2. Разделить действия по риску. Низкий риск — автономно, средний — с аудитом, высокий — с обязательным согласованием.
3. Определить политики. Записать лимиты, запреты, требования к данным и условия остановки.
4. Назначить владельца. Должен быть конкретный человек или команда, отвечающие за процесс.
5. Настроить журналирование. Сохранять действия агента, решения и эскалации.
6. Запустить пилот. Начать с ограниченного объёма и наблюдать за ошибками.
7. Проверить метрики. Оценить качество, скорость, стоимость и нагрузку на сотрудников.
8. Расширять автономность постепенно. Только после подтверждения стабильной работы.

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

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

Ошибки при построении HOTL

Самая распространённая ошибка — считать HOTL обычным согласованием. Если человек просто получает сотни уведомлений и механически нажимает «одобрить», никакого качественного надзора нет. Есть цифровой конвейер усталости.

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

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

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

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

Итог: автономность под контролем

Human-on-the-Loop — это не компромисс между ручной работой и полной автоматизацией, а отдельный способ проектирования процессов. Он позволяет AI-агентам работать быстро и масштабно, сохраняя человека там, где нужны ответственность, опыт, здравый смысл и право остановить систему.

Зрелая AI-автоматизация — это не когда человек исчезает из процесса, а когда он вмешивается редко, своевременно и осмысленно.

В HOTL человек не обязан проверять каждую строку и каждую транзакцию. Он задаёт правила, определяет уровни риска, управляет доступом, контролирует исключения и анализирует результаты. Агент выполняет рутинную работу, но не получает бесконтрольную власть.

Связка HOTL + AI Gateway + MCP + BPM создаёт практическую основу для корпоративных AI-агентов:

• AI-агент планирует и выполняет задачи;
• MCP предоставляет стандартизированные инструменты;
• AI Gateway проверяет доступ, политики и риски;
• BPM-система маршрутизирует согласования и исключения;
• человек принимает решения в критических точках;
• журнал фиксирует весь процесс для аудита и улучшения.

Главный вопрос при внедрении HOTL звучит не так: «Можно ли полностью заменить человека?» Гораздо полезнее спросить: «Какие решения машина может принимать сама, а где человеку обязательно нужно сохранить право вмешательства?»

Ответ на этот вопрос и становится основой безопасной, масштабируемой и по-настоящему полезной работы с AI-агентами.