Approval boundaries: какие действия AI-агент не должен выполнять сам

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

Общий выбор исполнителя AI-проекта в Армении разобран на странице AI-специалиста. Здесь вопрос уже: где агент должен остановиться перед изменением внешней системы?

Исходная бизнес-задача

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

Граница согласования ставится непосредственно перед побочным эффектом. Одобрение общего плана не разрешает автоматически все будущие вызовы. Другой адресат, изменённый текст, истёкший срок или отзыв прав требуют новой проверки. Разбор tool calling показывает адаптер исполнения, а разбор state и memory объясняет, почему воспоминание модели об одобрении не является разрешением.

Какие варианты решения существуют

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

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

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

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

Авторское дерево решений APPROVAL-GATE-7

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

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

Контракт согласования и исполнения

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

async function route(proposal: Action, context: Context) {
  if (!policy.allows(context.actor, proposal.tool, proposal.target)) return "deny";
  const risk = classifyImpact(proposal);
  const snapshot = await destination.readVersion(proposal.target);
  if (snapshot.version !== proposal.expectedVersion) return "refresh";
  if (risk.requiresReview) {
    const approval = await approvals.findExact(digest(proposal), context.policyVersion);
    if (!approval?.validFor(context.actor, context.tenant, now())) return "hold";
  }
  const result = await tools.executeOnce(proposal, proposal.idempotencyKey);
  if (result.unknown) return reconcileBeforeRetry(proposal.idempotencyKey);
  return verifyAtDestination(result);
}

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

Критерии выбора и матрица приоритетов

Это отправная политика, а не универсальное юридическое правило. Адаптируйте её к своим системам, данным и обязанностям. AI-автоматизация поможет разобрать процесс, prompt engineering — поведение модели; разрешение на действие должно оставаться на уровне приложения.

Риски и ограничения

Проверьте поддельное «одобрение» в найденном тексте, согласование другого payload, истёкшие и отозванные права, смену версии объекта, перенос одобрения между tenant, двойной клик, таймаут после успешной записи и параллельных исполнителей. В каждом тесте проверяйте маршрут и отсутствие запрещённого эффекта. Логируйте ID решения и хеш действия без чувствительного содержимого. В пилоте измеряйте задержки review, отказы, устаревшие одобрения, повторы записи и исходы сверки; здесь нет заявленных показателей.

Рекомендуемый план действий

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