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

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

Что такое контроль ИИ человеком?

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

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

Что означает human-in-the-loop

Human-in-the-loop, или сокращённо HITL, означает участие людей в работе системы ИИ через обратную связь, вмешательство или принятие решений. Это широкое понятие, которое не сводится к кнопке «Одобрить». В работающем бизнесе за ним должна стоять конкретная обязанность: кто-то согласует предлагаемое действие, проверяет выполненную работу или разбирает исключение. Определение Stanford HAI.

Термин также охватывает разметку обучающих данных, исправление ответов модели и участие человека в обучении. Всё это правомерные значения, но согласованный сегодня возврат денег не переобучает автоматически завтрашнюю модель. Проверки в ходе работы дают материал для анализа; улучшение модели или процесса требует отдельных целенаправленных усилий. Объяснение Google Cloud.

Как человек участвует в работе ИИ-агента

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

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

Три точки, в которых нужен человек

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

До действия: согласование

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

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

После действия: выборочная проверка

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

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

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

При эскалации: передача человеку

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

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

Что означает human over the loop

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

По той же причине различайте согласование in the loop и наблюдение on the loop. Панель мониторинга может быстро показать проблему, но сама по себе не приостановит следующее действие — такую паузу нужно реализовать отдельно.

Оценивайте цену ошибки и возможность отменить действие

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

Оцените действие по следующим критериям:

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

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

Выборочная проверка подходит, когда действие чётко ограничено, данные надёжны, а остаточный ущерб приемлем. Предварительное согласование нужно, если последствия существенны или восстановление затруднено. Если не хватает обязательного факта или правила, передавайте случай человеку. Запрещённое действие следует блокировать: очередь согласований не должна становиться способом обойти правила.

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

ИИ с участием человека: пример агента поддержки

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

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

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

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

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

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

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

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

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

Пропускная способность ограничена. В условной очереди 24 запроса в час × 3 минуты на проверку = 72 минуты работы проверяющего в час. У одного человека есть лишь 60 минут, ещё до учёта остальных обязанностей. Такая очередь растёт, даже если все решения верны. Прежде чем обещать время ответа, сократите лишние согласования, сузьте полномочия агента или выделите больше сотрудников на проверки.

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

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

Как современные инструменты ставят ИИ-агента на паузу

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

OpenAI Agents SDK: согласование ожидающего вызова инструмента

OpenAI Agents SDK — библиотека для разработки агентов в коде приложения. Она поддерживает согласование вызовов инструментов через needs_approval=True в Python или needsApproval: true в JavaScript. Вызов, требующий одобрения, возвращает прерывание и состояние, из которого можно продолжить выполнение. Приложение одобряет или отклоняет ожидающий запрос, затем возобновляет тот же запуск; для отложенного решения состояние можно сериализовать. Документация OpenAI по согласованиям.

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

LangGraph: прерывание и возобновление сохранённого процесса

LangGraph — библиотека для построения процессов с агентами, в которых сохраняется состояние. Для ожидания внешнего ввода она использует interrupt(). Настройте checkpointer с долговременным хранением — компонент, сохраняющий состояние выполнения, — и постоянный thread_id. Возобновляйте работу через Command(resume=...), используя тот же идентификатор потока. Документация LangGraph по прерываниям.

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

n8n: проверка человеком для выбранных инструментов

n8n — платформа визуальной автоматизации процессов. В ней можно подключить проверку человеком к выбранным инструментам узла AI Agent. Согласно документации, процесс приостанавливается, показывает предлагаемый инструмент и параметры, затем при одобрении выполняет вызов с входными данными, заданными ИИ, а при отказе отменяет действие. Руководство n8n по проверке человеком.

Откройте коннектор Tools у агента, выберите канал в разделе Human review и подключите к этому шагу инструменты, требующие проверки. Среди каналов руководство описывает n8n Chat и Slack, а для составления сообщения проверяющему — переменные $tool.name и $tool.parameters.

Используйте это сообщение, чтобы показать человеку, что именно он одобряет. Руководство описывает одобрение и отказ; не стоит предполагать, что в нём предусмотрена и редактируемая форма возврата денег. Если проверяющий требует изменений, отправьте предложение на доработку и новое согласование.

Anthropic Claude Code: разрешения управляют доступом к инструментам

У агента для программирования Claude Code от Anthropic описаны режимы разрешений для инструментов. Режим default, обозначенный как Manual, запрашивает разрешения, делая исключения для разрешённых операций и правил. Режим acceptEdits автоматически разрешает правки файлов и некоторые команды файловой системы в допустимых рабочих каталогах. Режим plan изучает проект без изменения исходных файлов. Документация Claude Code по разрешениям.

Режим auto использует фоновый классификатор для таких действий, как команды оболочки и сетевые запросы. Это автоматическое решение по результатам проверки. Режим bypassPermissions пропускает запросы разрешений, кроме документированных действий, которые ни один режим не одобряет автоматически. Ни один из этих режимов не подтверждает, что каждое действие проверил человек.

Эти настройки управляют разрешениями самого Claude Code во время работы. Сервису поддержки клиентов по-прежнему нужны собственные правила возвратов, выбора получателей и доступа к данным. Отдельное руководство по Claude dangerously skip permissions объясняет границы применения этого режима.

Что записывать в журнал

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

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

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

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

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

Сокращайте проверки отдельно для каждого типа действий

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

1. 1

   Начните с предложений

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

2. 2

   Разрешайте выполнение в ограниченных рамках

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

3. 3

   Переводите подходящие действия на выборочную проверку

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

4. 4

   Возвращайте согласование при изменении условий

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

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

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

Какие обещания звучат убедительнее, чем работают

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

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

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

С чего начать в понедельник

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

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

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

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

Частые вопросы о контроле ИИ человеком

Что такое human-in-the-loop в ИИ?

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

Что на практике означает участие человека в процессе?

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

Human-in-the-loop и агентный ИИ — одно и то же?

Нет, хотя они могут использоваться вместе. Агент выбирает шаги и работает с инструментами; human-in-the-loop описывает, где люди влияют на эту работу или дают разрешение на неё.

Как сохранить участие человека в работе ИИ?

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

Почему ИИ зацикливается?

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

Чтобы получать практические руководства по внедрению ИИ в бизнес-процессы, подпишитесь на рассылку.