Human-in-the-loop в n8n: approval-gate для AI workflow, tools и рискованных действий ¶

Обновлено: 2026-05-29

Короткий ответ ¶

Human-in-the-loop в n8n нужен, когда AI workflow может сделать действие с внешними последствиями: отправить письмо, изменить CRM, создать возврат, удалить данные, вызвать API, опубликовать контент или раскрыть чувствительную информацию. Правильная схема — не “человек перечитывает всё”, а риск-ориентированный approval-gate: низкий риск автоматизируется, средний идёт на выборочный review, высокий требует approve/deny, критический эскалируется. Все решения должны попадать в audit log вместе с входом, tool arguments, reviewer, временем и результатом.

Почему approval нужен именно для tool calls ¶

AI-ответ сам по себе может быть ошибочным, но AI tool call опаснее: он меняет внешний мир. Модель может неправильно понять намерение пользователя, выбрать не тот tool, подставить неверный ID, перепутать сумму, не учесть права или повторить действие после retry. Human approval ставится перед выполнением tool, чтобы человек видел: что именно будет сделано, с какими аргументами и почему AI предлагает это действие.

Approval должен показывать не “AI хочет что-то сделать”, а конкретику:

• tool name;
• business object;
• аргументы;
• риск;
• источник запроса;
• краткое объяснение;
• ожидаемый результат;
• последствия отказа;
• ссылка на execution.

Risk-based policy ¶

Не ставьте человека на каждое действие. Это убьёт скорость и люди начнут автоматически нажимать approve. Разделите операции по риску.

Policy должна быть кодом или таблицей правил, а не только текстом в prompt. Prompt может объяснять агенту политику, но финальный gate должен проверять tool name, arguments, user role и risk level обычной логикой.

Архитектура approval workflow ¶

Production-схема:

1. Trigger — chat, Telegram, email, webhook.
2. Intent + risk classifier — определяет действие и риск.
3. AI Agent — предлагает tool call.
4. Tool policy checker — проверяет, можно ли выполнять автоматически.
5. Approval request — отправляет карточку ревьюеру.
6. Wait for approve/deny — workflow ждёт решение.
7. Execute tool — только после approve.
8. Post-action validation — проверяет результат.
9. User response — сообщает outcome.
10. Audit log — сохраняет всё.

Если approval denied, workflow не должен просто падать. Он должен вернуть безопасный ответ: “действие не выполнено”, возможно — задать уточнение или предложить безопасную альтернативу.

Что показывать ревьюеру ¶

Карточка approval должна быть короткой, но достаточной.

{
  "approval_id": "appr_20260529_001",
  "risk_level": "high",
  "requested_by": "telegram:user:777000",
  "tool_name": "update_crm_deal_stage",
  "arguments": {
    "deal_id": "D-1042",
    "new_stage": "won"
  },
  "reason": "Пользователь сообщил, что клиент подписал договор.",
  "checks": {
    "user_role_allowed": true,
    "deal_exists": true,
    "amount_changed": false
  },
  "decision_options": ["approve", "deny", "request_more_info"]
}

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

Каналы approvals ¶

Approval можно делать через Chat, Slack, Telegram, email, внутреннюю админку или helpdesk. Выбор зависит от SLA.

Для critical actions лучше не полагаться на один канал. Отправьте approval в основной канал и escalation уведомление ответственному.

Timeout policy ¶

Каждый approval должен иметь timeout и default action. Для опасных действий default — deny. Для низкорисковых черновиков можно создать тикет “ожидает проверки”. Никогда не оставляйте workflow бесконечно висеть без статуса.

Пример политики:

{
  "risk_low": { "timeout_minutes": 5, "default": "auto_approve_if_confidence_high" },
  "risk_medium": { "timeout_minutes": 30, "default": "escalate" },
  "risk_high": { "timeout_minutes": 120, "default": "deny" },
  "risk_critical": { "timeout_minutes": 15, "default": "deny_and_page_owner" }
}

Audit log ¶

Audit log — обязательная часть human-in-the-loop. Минимальные поля:

• approval_id;
• execution_id;
• trace_id;
• request_source;
• user_id;
• tool_name;
• tool_arguments_hash;
• risk_level;
• reviewer_id;
• decision;
• decision_reason;
• created_at, decided_at;
• tool_result_status;
• rollback_reference.

Аргументы tool можно хранить полностью только если они не содержат sensitive data. Иначе сохраняйте redacted version и hash.

Approval для AI Agent tools ¶

Если AI Agent подключён к tools, не давайте ему прямой доступ ко всем действиям. Каждому dangerous tool добавьте human review. Tool должен иметь узкий контракт: например create_refund_request, а не call_payment_api. Чем конкретнее tool, тем проще ревьюеру понять последствия.

Плохой tool:

{ "tool": "crm_api", "method": "POST", "path": "/anything", "body": {} }

Хороший tool:

{
  "tool": "create_support_ticket",
  "input": {
    "customer_id": "C-1001",
    "subject": "Webhook не принимает заявки",
    "priority": "high",
    "source": "telegram"
  }
}

Human review не заменяет validation ¶

Человек не должен проверять то, что можно проверить автоматически. До approval workflow должен проверить:

• существует ли объект;
• совпадает ли owner;
• разрешена ли операция роли пользователя;
• корректен ли формат суммы/email/ID;
• не было ли такого действия раньше;
• не превышен ли лимит;
• нет ли policy violation.

Человек подтверждает смысл и риск, а не исправляет технический мусор.

Метрики ¶

Отслеживайте:

• approval rate;
• deny rate;
• timeout rate;
• average approval time;
• auto vs manual split;
• false approvals;
• reviewer workload;
• incidents after approved actions;
• сколько запросов ушло в request_more_info;
• стоимость задержки.

Если deny rate высок, агент слишком часто предлагает опасные действия. Если timeout rate высок, канал approval выбран плохо или SLA нереалистичный. Если approve rate 99%, возможно, gate слишком широкий и люди кликают механически.

Типовые ошибки ¶

1. Approval ставится после tool execution, а не до.
2. Ревьюер видит только текст AI, но не tool arguments.
3. Нет timeout/default action.
4. Deny не обрабатывается и workflow падает.
5. Approval logs не сохраняются.
6. Один reviewer подтверждает собственные рискованные запросы.
7. Человек проверяет всё подряд и теряет внимание.
8. Prompt обещает approval, но dangerous tool всё равно подключён напрямую.