AI-агент в ERP: где проходит граница допустимого делегирования решений

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

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

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

Делегировать задачу или полномочие

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

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

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

Как определить предел автономии в ERP

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

Для каждого действия задайте пять вопросов:

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

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

3. Какова цена ошибки и насколько она обратима? Исправить черновик проще, чем вернуть платёж или устранить последствия ошибочного кадрового решения.

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

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

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

Контроль человека должен быть действенным

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

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

Независимо от правовой классификации при проектировании ERP-процесса полезно проверять, не стал ли надзор декоративным. Если человек обычно утверждает предложения пачкой, не видит первичных данных или не может отменить действие, пометка «с участием человека» не описывает действительный уровень контроля.

Архитектура допустимого делегирования

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

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

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

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

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

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

Три ситуации, в которых граница видна особенно хорошо

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

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

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

Кадровый процесс. Агент может проверять комплектность документов, сопоставлять сведения и готовить структурированный анализ для уполномоченного сотрудника. В предлагаемой консервативной модели управления окончательный выбор по вопросам, существенно влияющим на права или занятость, остаётся за человеком; агент не определяет исход самостоятельно. Это рекомендация, а не универсальное требование AI Act о ручном утверждении каждого решения: обязательность участия человека зависит от применимого права, классификации системы и конкретного использования. Приложение III, пункт 4, относит к высокорисковым определённые системы для найма и отбора, решений об условиях труда, продвижении или прекращении отношений, распределения задач по индивидуальным характеристикам, а также мониторинга и оценки работников; статья 6(3) допускает узкое исключение, но системы, выполняющие профилирование физических лиц, остаются высокорисковыми. Значит, не вся HR-автоматизация автоматически high-risk, а правовая классификация и объём полномочий агента — два разных решения. Приложение III AI Act.

Что закрепить до запуска

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

Итоговый режим и его основание фиксируйте вместе с владельцем процесса и условиями следующего пересмотра.

Правовая рамка

Требования AI Act зависят от назначения и классификации конкретной системы. Для высокорисковых систем предусмотрен человеческий надзор, но это не означает обязательного ручного подтверждения каждой операции. Поэтому описанные в статье границы делегирования — инженерные рекомендации, а не универсальное толкование закона. Перед внедрением нужно проверить применимость регламента к конкретному сценарию и актуальную редакцию AI Act.