Как выглядит «объект одобрения»: уровень доверия, для которого никто не написал спецификацию

Ваш агент попросил менеджера одобрить банковский перевод на сумму 5000 долларов поставщику Y. Менеджер нажал «да» в Slack. Агент перепланировал задачу, решил, что правильная сумма — 50 000 долларов, и все равно выполнил действие. Одобрение было реальным. Привязка к параметрам — нет. В этой статье показан шаблон проектирования, который решает эту проблему: два параллельных пути выполнения кода и этап верификации, который выдержит проверку на соответствие Закону ЕС об искусственном интеллекте (EU AI Act).

Я назову это решение «объектом одобрения» (approval object). Это первоклассный артефакт, который ваш агент должен получить, прежде чем будет выполнено любое необратимое действие. Это шаблон, который сообщество начало открыто обсуждать этим летом, и UiPath Action Center предоставляет запись, на которой он построен.

Объект одобрения — это неизменяемая запись о конкретном предлагаемом действии. Она содержит тип действия, точные параметры, уровень риска, личность человека, давшего одобрение, результаты одобрения и временную метку. Все это адресуется ключом задачи, который инструмент может найти и проверить перед выполнением. Агент не может выполнить действие, если инструмент не получит эту запись повторно и не сверит ее с параметрами, которые он собирается отправить. Если перепланировать параметры после того, как человек сказал «да», проверка не будет пройдена. Инструмент откажет. Журнал аудита зафиксирует попытку. В UiPath Action Center вы получаете отслеживаемую запись «из коробки»; проверка верификации — это то, что вы строите поверх нее, и именно этого не хватает в большинстве реализаций с участием человека (HITL).

Что такое «театр одобрения»?

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

Здесь сломаны две вещи, и обе они являются одной и той же ошибкой.

Значение одобрения — это строка, а не артефакт. Нет никакой записи о том, что именно было одобрено, кроме сообщения в Slack, которое составил сам агент. А состояние агента (agent.state) изменяемо в промежутке между запросом и вызовом. Перепланирование, инъекция промпта, инструмент, который изменяет рабочую память — и сумма, которую видел человек, уже не та, что попадает в банковский API.

Это разочарование, которое проявляется в сообществе разработчиков к середине 2026 года. В темах на r/AI_Agents и r/LangChain постоянно звучит один и тот же диагноз: большинство реализаций HITL — это «театр», потому что одобрение не связано с действием. Решение, которое постоянно появляется в этих обсуждениях, заключается в том, чтобы относиться к одобрениям как к первоклассному артефакту.

Инъекция промпта — это тот клин, который делает этот вопрос срочным. Она занимает первое место в списке OWASP Top 10 для приложений с LLM в обоих опубликованных изданиях (2023 и 2025 годов), и паттерн эксплойта против агентских систем — это именно описанная выше схема «перепланирование после согласия». Если параметры могут измениться после одобрения, инъекция побеждает по умолчанию.

Как помешать агенту изменять параметры после одобрения

Решение — объект одобрения.

Он содержит:

• тип действия (например, bank.wire)

тип действия (например, bank.wire)

• точные параметры (сумма, поставщик, счет)

точные параметры (сумма, поставщик, счет)

• уровень риска

уровень риска

• разницу (diff) или предварительный просмотр, который видел человек

разницу (diff) или предварительный просмотр, который видел человек

• личность того, кто одобрил

личность того, кто одобрил

• временную метку

временную метку

• ключ задачи, который инструмент может найти и проверить перед выполнением

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

Инструмент каждый раз повторно сверяет эту запись с точными параметрами, которые он собирается отправить. Вот что на практике означает «одобрения, привязанные к параметрам».

Например, вы можете реализовать шаблон UiPath HITL в своем агенте в стиле LangGraph — приостановив работу на устойчивом вызове LangGraph interrupt() и вызвав Action Center с помощью CreateEscalation(). Возможность агента создавать контрольные точки позволяет ожиданию длиться часами, днями или пережить перезапуск процесса. И, при необходимости, ваш автономный агент может использовать tasks.retrieve() API для получения полного объекта задачи, чтобы явно проверить, что именно одобрил человек. Эта проверка может произойти в любом месте вашего рабочего процесса, при условии, что используется тот же ключ — в более позднем агенте, в узле скрипта Maestro Flow или на этапе рабочего процесса RPA или API. Важно то, что решение HITL зафиксировано и доступно для извлечения.

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

В чем разница между обычным одобрением и объектом одобрения?

Театр одобрения (свободный)

Объект одобрения (привязанный к параметрам)

Одобрение

Строка в ответе чата

Первоклассный артефакт, который агент должен заработать

Что записано

Сообщение в Slack, составленное агентом

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

Источник истины при выполнении

agent.state: изменяемая память процесса

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

Агент перепланирует после «да»

Вызов продолжается с новыми параметрами

Проверка не пройдена, инструмент отказывает, попытка логируется

Направление сбоя

Сбой с открытым доступом

Сбой с закрытым доступом по определению

Инъекция промпта

Побеждает по умолчанию — схема «перепланирование после согласия» является эксплойтом

Измененные параметры никогда не доходят до инструмента

Где находится верификация

В агентском фреймворке (если вообще есть) — можно обойти при подмене среды выполнения

В инструменте, в точке необратимого действия

Артефакт аудита

Логи, которые агент написал о самом себе, восстановленные постфактум

Сам объект одобрения, зафиксированный в момент принятия решения

Устойчивое ожидание

Запрос-ответ; ломается при перезапуске

Длится часами, днями, переживает перезапуск процесса

Переместите эту границу доверия, и произойдут три вещи:

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

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

• Объект одобрения является записью аудита. Article 12 of the European Union (EU) AI Act требует, чтобы системы ИИ с высоким уровнем риска вели автоматические журналы, достаточные для восстановления решений и выявления рисков. Для систем удаленной биометрической идентификации (defined in Annex III, point 1(a)) требования еще строже: они предписывают список конкретных полей: период каждого использования, проверенная справочная база данных, входные данные и личность лиц, проверяющих результаты. Даже если ваша система не относится к таковым, более широкий смысл остается прежним: поля, необходимые для доказательного аудиторского следа, — это те же поля, которые объект одобрения фиксирует в момент принятия решения, а не восстанавливает позже из логов, которые агент написал о самом себе. Внедрение для систем ИИ с высоким уровнем риска согласно Приложению III изначально планировалось на август 2026 года. Цифровой регламент Omnibus продлил основные сроки для систем с высоким уровнем риска до декабря 2027 года, но крайний срок приближается, и команды по комплаенсу уже запрашивают эти записи.

Объект утверждения — это запись аудита. требует, чтобы высокорисковые системы ИИ вели автоматические журналы, достаточные для восстановления хода принятия решений и выявления рисков. Для систем удаленной биометрической идентификации () требования еще строже: они предписывают вести список конкретных полей: период каждого использования, проверенная эталонная база данных, входные данные и личность лиц, проверяющих результаты. Даже если ваша система не относится к таковым, общий принцип остается прежним: поля, необходимые для создания достоверного аудиторского следа, — это те же поля, которые объект утверждения фиксирует в момент принятия решения, а не восстанавливает позже из журналов, которые агент написал о самом себе. Принудительное исполнение требований для высокорисковых систем ИИ согласно Приложению III изначально планировалось на август 2026 года. Регламент Digital Omnibus продлил основные сроки для систем высокого риска до декабря 2027 года, но крайний срок приближается, и группы комплаенса уже запрашивают эти записи.

• В результате маршрутизация отделена от принудительного исполнения. Slack, Teams, Outlook, пользовательский почтовый ящик: неважно, где именно человек нажимает кнопку. Запись попадает в одно и то же место, и инструмент выполняет одну и ту же проверку.

В результате маршрутизация отделена от принудительного исполнения. Slack, Teams, Outlook, пользовательский почтовый ящик: неважно, где именно человек нажимает кнопку. Запись попадает в одно и то же место, и инструмент выполняет одну и ту же проверку.

Почему UiPath Action Center является эталонной реализацией

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

Утверждения попадают в единое место независимо от канала, а Orchestrator хранит аудиторский след, защищенный от перезаписи или вмешательства со стороны агента. С 2025 года UiPath внедряет унифицированное ведение журналов аудита по всей своей платформе с возможностью экспорта в выбранную вами SIEM через API и CSV.

Независимо от того, используете ли вы Microsoft Sentinel, IBM QRadar, Splunk или другую SIEM, ваши события утверждения будут поступать из одних и тех же API журналов аудита. Это именно тот артефакт, который запрашивает ваша команда по комплаенсу.

При выборе места хранения записей об утверждениях обратите внимание на два сертификата:

• ISO/IEC 42001:2023 — это международный стандарт для систем управления ИИ; компания UiPath получила сертификат ISO/IEC 42001:2023 в октябре 2025 года.

— это международный стандарт для систем управления ИИ; компания UiPath получила сертификат ISO/IEC 42001:2023 в октябре 2025 года.

• AIUC-1 — это комплексный стандарт безопасности, надежности и отказоустойчивости для агентов ИИ. Он тестирует системы и агентов ИИ на соответствие реальным рискам, таким как инъекции промптов и неправомерное использование инструментов — тем же рискам, которые лежат в основе паттерна «перепланирование после подтверждения».

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

UiPath обладает как ISO/IEC 42001 (система управления ИИ), так и AIUC-1 — это одна из немногих платформ корпоративной автоматизации, сочетающая общий стандарт системы управления ИИ с сертификацией безопасности, специфичной для агентов.

Агенты, роботы и люди работают на одной и той же подложке оркестрации. Тот же объект утверждения, который ограничивает автономного агента ИИ, также ограничивает классическую автоматизацию, и журналу аудита неважно, кто именно сделал запрос. Это имеет значение, когда ваш рабочий процесс подготовки Okta, инициированный через Slack, включает шаг агента, шаг робота и шаг менеджера в рамках одного запуска.

Один практический стандарт: участие человека (HITL) при первом использовании. Новый тип действия, новый инструмент, новый уровень риска; направляйте запрос через объект утверждения, пока у вас не появятся оценки, позволяющие доверять ему без присмотра. Это соответствует эмпирической картине, опубликованной Anthropic в статье «Измерение автономности агентов ИИ на практике»: 80% вызовов инструментов исходят от агентов, имеющих хотя бы одну меру защиты, но это исследование также отмечает, что невозможно оценить качество или устойчивость к взлому этих мер защиты извне. Привязка к параметрам — это то, с чего нужно начать измерение.

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

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

Пять движущихся частей, по порядку:

• Триггер, который превращает запрос на естественном языке (Slack, электронная почта, форма) в структурированное предлагаемое действие с типизированными параметрами

Триггер, который превращает запрос на естественном языке (Slack, электронная почта, форма) в структурированное предлагаемое действие с типизированными параметрами

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

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

• Длительное ожидание, которое переживает перезапуски процесса и задержки со стороны человека, измеряемые часами или днями, а не секундами. Это «долгосрочная» часть; HTTP-вызов типа «запрос-ответ» здесь не подойдет

Длительное ожидание, которое переживает перезапуски процесса и задержки со стороны человека, измеряемые часами или днями, а не секундами. Это «долгосрочная» часть; HTTP-вызов типа «запрос-ответ» здесь не подойдет

• Отслеживаемая запись, возвращаемая после утверждения, содержащая окончательные (возможно, отредактированные) параметры для проверки инструментом

Отслеживаемая запись, возвращаемая после утверждения, содержащая окончательные (возможно, отредактированные) параметры для проверки инструментом

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

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

Таков этот паттерн. Вопрос о стеке технологий — следующий.

Пример: рабочий процесс утверждения Slack-to-Okta с редактируемой областью, доступом по времени и полным аудиторским следом

Стек UiPath, который я бы использовал для этой схемы: UiPath Orchestrator + Action Center + коннектор UiPath Okta, инициируемый из Slack через интеграцию UiPath Slack, с унифицированным экспортом аудита в вашу SIEM.

Как эта комбинация соотносится с нашими требованиями:

• Запрос через Slack. Интеграция UiPath Slack запускает процесс Orchestrator с указанием запрашивающего, целевой системы и запрашиваемой области в качестве типизированных параметров.

Запрос через Slack. Интеграция UiPath Slack запускает процесс Orchestrator с указанием запрашивающего, целевой системы и запрашиваемой области в качестве типизированных параметров.

• Одобрение менеджером с возможностью редактирования области действия. Action Center создает объект одобрения. Менеджер может редактировать область действия непосредственно в интерфейсе; правки становятся частью отслеживаемой записи, а не передаются по сторонним каналам. Проверка выполняется на основе итоговой области действия, а не исходного запроса.

Одобрение менеджером с возможностью редактирования области действия. Action Center создает объект одобрения. Менеджер может редактировать область действия непосредственно в интерфейсе; правки становятся частью отслеживаемой записи, а не передаются по сторонним каналам. Проверка выполняется на основе итоговой области действия, а не исходного запроса.

• Подготовка учетных записей в Okta. Коннектор UiPath Okta выполняет вызов для подготовки учетных записей после этапа проверки: повторно получает запись из Orchestrator и проверяет итоговую область действия перед отправкой вызова. Если область действия была изменена после одобрения, вызов завершается с ошибкой (fail closed).

Подготовка учетных записей в Okta. Коннектор UiPath Okta выполняет вызов для подготовки учетных записей после этапа проверки: повторно получает запись из Orchestrator и проверяет итоговую область действия перед отправкой вызова. Если область действия была изменена после одобрения, вызов завершается с ошибкой (fail closed).

• Автоматическое истечение срока действия доступа. Сохраняйте срок действия в данных одобрения, после чего запланированное задание по отмене подготовки выполнит необходимые действия. Никакого «осиротевшего» доступа и ручной очистки.

Автоматическое истечение срока действия доступа. Сохраняйте срок действия в данных одобрения, после чего запланированное задание по отмене подготовки выполнит необходимые действия. Никакого «осиротевшего» доступа и ручной очистки.

• Полный контрольный журнал. Orchestrator хранит запись аудита. Единая система ведения журналов аудита UiPath экспортирует эту цепочку в ваш SIEM. Сертификация ISO/IEC 42001:2023 (подтверждена в октябре 2025 года) охватывает саму систему управления ИИ, а AIUC-1 — продукты UiPath на базе ИИ, включая агентов. Это именно тот артефакт, который запрашивает ваша команда по комплаенсу при проверке регулятором.

Полный контрольный журнал. Orchestrator хранит запись аудита. Единая система ведения журналов аудита UiPath экспортирует эту цепочку в ваш SIEM. Сертификация ISO/IEC 42001:2023 (подтверждена в октябре 2025 года) охватывает саму систему управления ИИ, а AIUC-1 — продукты UiPath на базе ИИ, включая агентов. Это именно тот артефакт, который запрашивает ваша команда по комплаенсу при проверке регулятором.

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

Один совет и одно предостережение

Внедряйте проверку в инструмент, а не в структуру агента. Проверки на уровне структуры могут быть обойдены в тот момент, когда кто-то заменит среду выполнения или подключит новый инструмент. Проверки на уровне инструмента по своей сути завершаются с ошибкой при нарушении условий (fail closed).

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

Попробуйте сами

Суть в шаблоне. Объект одобрения, отслеживаемая запись, проверка на стороне инструмента, контрольный журнал, который выдержит проверку регулятора. UiPath Action Center — это эталонная реализация, к которой я бы обратился, а документация Action Center — это точка входа.

Если вы строите это на другом стеке, я бы хотел на это взглянуть; напишите мне в LinkedIn. И если вы столкнетесь с формой объекта одобрения, которая не вписывается в перечисленные мной поля (уровень риска, различия, срок действия), расскажите, что вы добавили. Это спецификация, которую еще никто не написал, и она будет написана публично.