Human approval в n8n: как не отдавать критические решения модели

Предпосылки и данные: approval начинается до вызова модели

Human approval в n8n — это не кнопка, поставленная после AI node. Это контракт, который не позволяет proposal превратиться в дорогое, необратимое или чувствительное к policy действие, пока уполномоченный человек не проверит evidence.

Сначала нужно определить action boundary. Перечислите все side effects, которые workflow может запросить: изменение CRM, отправка клиентского сообщения, согласование скидки, платёж, удаление записи, публикация контента или выдача доступа. Для каждого действия задайте owner, допустимый scope, rejection path и максимальный срок жизни proposal.

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

Минимальный approval envelope

Reviewer не должен получать только текст модели. До отправки review request сохраните типизированный envelope:

{
  "approvalId": "apr_01J...",
  "correlationId": "evt_01J...",
  "workflowVersion": "lead-routing@12",
  "actionType": "crm.update",
  "target": { "system": "crm", "recordId": "lead_8421" },
  "proposedChange": { "status": "qualified", "ownerId": "sales_17" },
  "evidence": [
    { "source": "form", "version": "2026-07-31T08:14:00Z" },
    { "source": "crm", "version": "lead_8421:v9" }
  ],
  "policyResult": { "route": "human_review", "reasons": ["high_value"] },
  "requestedAt": "2026-07-31T08:14:10Z",
  "expiresAt": "2026-07-31T10:14:10Z"
}

Envelope отделяет факты от inference, а inference — от полномочий. Модель предлагает qualified; policy layer решает, что нужен review; reviewer разрешает или отклоняет; только execution worker получает право изменить CRM.

Какие случаи требуют review

Используйте явные policy rules, а не абстрактный confidence threshold. Confidence полезен как diagnostic signal, но не является разрешением. Human review обычно обязателен, когда выполняется хотя бы одно условие:

• действие необратимо или дорого откатывается;
• оно затрагивает клиента, сотрудника, платёж, договор или право доступа;
• evidence неполное, устаревшее, противоречивое или не соответствует schema;
• действие превышает денежный, объёмный или permission threshold;
• кейс относится к сегменту, которого нет в acceptance tests;
• policy rule возвращает review или stop;
• reviewer должен зафиксировать reason в audit record.

Low-risk и reversible действия можно auto-approve только тогда, когда это явно разрешают policy, freshness данных и test coverage. Workflow должен объяснять, почему выбран автоматический route.

Проектирование workflow: последовательность APPROVE-7

Авторская схема называется APPROVE-7. В ней семь контролируемых этапов и три terminal outcome: executed, rejected или expired.

1. Получить и сохранить событие

Webhook, Trigger или polling node проверяет обязательные поля, создаёт correlation ID и сохраняет оригинальное событие в durable storage. Успешный webhook response означает «принято в обработку», а не «бизнес-действие выполнено».

2. Собрать bounded context

Получите только записи, необходимые для решения. Сохраните source identifiers, versions и timestamps. Если upstream system не выдаёт стабильную версию, запишите hash полей, использованных для proposal.

3. Создать structured proposal

AI node возвращает объект по schema: предлагаемое действие, target, field-level changes, ссылки на evidence, assumptions и uncertainty. Свободное объяснение может сопровождать объект, но не должно становиться executable command.

4. Применить deterministic policy

Code, Rule или sub-workflow node проверяет permissions, допустимые action types, value thresholds, обязательное evidence и активную workflow version. Результат — один из четырёх routes:

• auto: low-risk действие может продолжиться;
• human_review: создать approval request;
• reject: proposal нарушает известную policy;
• repair: обязательные данные отсутствуют или невалидны.

5. Создать и доставить review task

Сначала сохраните approval record, затем уведомляйте reviewer. В задаче должны быть proposed change, evidence, risk reason, expiry time и controls approve/reject. Email, Slack, Teams или внутренний UI могут доставить уведомление, но сообщение не является source of truth.

6. Принять attributable decision

Callback должен содержать approval record, reviewer identity, decision, reason и decision time. Проверьте, что reviewer авторизован, request ещё в состоянии pending, а callback не был использован. Signed single-use token может идентифицировать request, но authentication и role check всё равно должны идентифицировать человека.

7. Повторно проверить, выполнить и reconcile

Approval не останавливает изменение данных. Перед execution заново прочитайте target record и критические policy inputs. Если данные изменились, approval истёк или workflow version больше не активна, верните кейс на review. Иначе выполняйте действие со stable idempotency key, сохраните target receipt и проверьте authoritative postcondition.

Соседний материал про retries, idempotency и dead-letter flow в n8n разбирает recovery после gate. Статья про production-архитектуру n8n описывает более широкий runtime и operating model.

Интеграции и контракты

Approval store

Approval store — это state machine, а не notification channel. Минимальная запись включает:

• approvalId, correlationId и workflowVersion;
• immutable snapshots proposal и evidence;
• состояние pending, approved, rejected, expired, executing, executed или failed;
• reviewer identity, authority и reason;
• optimistic version или compare-and-set поле;
• expiry, execution receipt и reconciliation result.

Разрешайте только валидные transitions. Два клика, два канала или задержанный webhook не должны создавать два действия.

Канал reviewer

Выбирайте канал по identity и urgency. Chat approval удобен, но может скрыть evidence и создаёт риск пересылки. Отдельная review page способна показать diff, source links и history. Для high-impact действий требуйте authenticated access и typed reason вместо one-tap approval.

Target system

Executor получает command, созданный из approved proposal, а не raw callback body. Target contract должен поддерживать idempotency key или repository-side operation ledger. Если target принял request, но ответил timeout, сначала выполняйте reconciliation, а не слепой retry.

Пример входа и выхода

Вход review:

{
  "approvalId": "apr_01J...",
  "summary": "Set lead_8421 to qualified and assign sales_17",
  "riskReason": "dealValue exceeds automatic threshold",
  "currentVersion": "lead_8421:v9",
  "expiresAt": "2026-07-31T10:14:10Z"
}

Attributable decision:

{
  "approvalId": "apr_01J...",
  "decision": "approve",
  "reviewerId": "user_42",
  "reason": "Source documents confirm scope and owner",
  "decidedAt": "2026-07-31T08:19:44Z"
}

Execution output:

{
  "operationId": "op_apr_01J...",
  "status": "executed",
  "targetReceipt": "crm_req_7782",
  "postcondition": { "recordVersion": "lead_8421:v10", "matched": true }
}

Проверки перед запуском

Acceptance criteria

Controlled pilot готов только тогда, когда доказуемо выполняются все условия:

1. Каждый sensitive action type явно назван и по умолчанию направляется на review или stop.
2. Reviewer видит proposed change, current value, evidence и risk reason.
3. Reviewer identity и authority проверяются server-side.
4. Routes approve, reject, expiry и repair протестированы.
5. Duplicate callbacks не создают duplicate side effects.
6. Approval истекает, а stale source data требует revalidation.
7. Executor использует stable idempotency key.
8. Target receipt и authoritative postcondition сохраняются.
9. Notification можно повторить без создания второго approval.
10. Operators находят pending, expired и failed records по correlation ID.
11. Kill switch блокирует новые executions, сохраняя evidence.
12. Owner знает, как разрешить failed или ambiguous action.

Test fixtures

Проверяйте workflow на deterministic fixtures, а не на live happy-path demo:

• valid proposal, approved один раз;
• valid proposal, rejected с reason;
• expired approval;
• unauthorised reviewer;
• duplicate approve callback;
• racing approve и reject из разных каналов;
• target изменён после создания review;
• policy изменилась после создания review;
• target timeout до receipt;
• notification failure при сохранённом pending record.

Test result должен называть workflow version и fixtures. Успешный запуск canvas не доказывает безопасность approval boundary.

Эксплуатация и улучшение

Наблюдайте за queue, а не vanity metrics модели

Полезные signals: pending age, expired share, rejection reasons, revalidation failures, duplicate callback attempts, execution failures after approval и время от request до decision. Они описывают процесс. Одна цифра «AI accuracy» не показывает, контролировались ли high-risk cases.

Поддерживайте evidence и permissions

Reviewers меняют роли, policies меняются, target schemas развиваются. Периодически проверяйте reviewer groups, token lifetime, evidence links, workflow versions и retention rules. Удаляйте access при смене ответственности.

Улучшайте систему через сужение безопасных routes

Цель не в том, чтобы убрать человека из каждого решения. Используйте review records, чтобы найти повторяемые low-risk cases со стабильным evidence и reversible outcomes. Позже они могут получить deterministic auto route. High-impact exceptions должны оставаться reviewable даже при более сильной модели.

Production checklist

До rollout назначьте owner approval queue, owner execution failures и decision-maker для policy changes. Начинайте с одного bounded action type и non-destructive targets. Измерьте реальный review latency и failure modes, затем расширяйте scope только когда audit records показывают, что контракт работает.

Если нужно спроектировать такой bounded pilot, обсудите аудит AI-автоматизации. Полезный результат — не эффектный approval screen, а attributable, expiring и revalidated решение между AI proposal и проверяемым бизнес-действием.