Approval Policy Tuning в 2026: как не утонуть в unnecessary review и не открыть лишний риск

Короткая версия

Хороший approval policy tuning в 2026 обычно смотрит на:

1. False approvals
2. Unnecessary human review
3. Edit-before-approve patterns
4. Escalation quality
5. Review latency by risk class

Что особенно важно

• low-risk и high-risk actions нельзя настраивать одинаково;
• edit-before-approve часто показывает, что policy слишком узкая или packet слишком сырой;
• tuning должен учитывать reviewer capacity, а не только риск;
• policy стоит изменять по классам кейсов, а не одной глобальной ручкой.

Что показывает высокий edit-before-approve rate?

1. Approval policy — это граница автоматизации

Её задача не просто "добавить человека", а ответить на вопрос:

• где агент может действовать автономно;
• где нужен review;
• где нужен specialist escalation;
• где лучше вообще manual-only path.

Поэтому tuning полезно строить вокруг trade-off:

• safety;
• throughput;
• reviewer cost;
• user latency.

2. Одни метрики review недостаточны

Полезно смотреть не только approve rate, но и:

• сколько bad actions прошли;
• сколько benign cases зря ушли человеку;
• какие поля чаще всего редактируют;
• какие кейсы reviewers почти всегда эскалируют;
• где policy даёт много post-approval incidents.

3. Edit-before-approve — один из лучших сигналов

Этот паттерн часто показывает:

• packet неполный;
• payload сырой;
• threshold слишком строгий;
• threshold слишком слабый;
• agent consistently misses one operational detail.

Именно поэтому edit data полезно возвращать в:

• packet design;
• tool schema;
• routing;
• approval thresholds.

4. Тюнинг лучше делать по классам, а не глобально

Примеры полезной сегментации:

• money movement by amount;
• external communication by audience;
• browser actions by domain;
• support actions by policy sensitivity;
• code actions by repo or branch type.

Так policy становится точнее и менее шумной.

5. Reviewer capacity тоже часть policy

Иногда policy technically правильная, но operationally невыгодная:

• очередь слишком длинная;
• reviewers часто спешат;
• rising fatigue снижает quality;
• urgent risky cases начинают ждать слишком долго.

Поэтому tuning должен учитывать:

• available reviewer bandwidth;
• SLA pressure;
• current traffic shape.

6. Что особенно часто ломают команды

One global threshold

Одна и та же policy на всё подряд.

No feedback from edits

Редактирование происходит, но никто не смотрит на повторяющиеся patterns.

Queue pressure ignored

Policy формально "безопасная", но review layer уже не выдерживает.

Risk-only tuning

Команда всё больше ужесточает policy, не замечая, что human layer становится bottleneck.

Ops-only tuning

Команда ради скорости снимает слишком много approvals.

7. Какие метрики полезны

Минимальный approval-tuning dashboard обычно включает:

• false approval incidents;
• unnecessary human review rate;
• edit-before-approve rate;
• post-approval incident rate;
• review latency by risk class;
• escalation acceptance / rejection patterns.

Пример policy buckets

approval_rules:
  refunds:
    auto_approve_if:
      - amount < 20
      - evidence_quality = high
      - no_policy_exception = true
    require_review_if:
      - amount >= 20
      - or low_confidence = true

  external_email:
    require_review_if:
      - recipient_domain not in allowlist
      - or user_impact = high

Простой tuning question set

1. Какие cases почти всегда approve without edits?
2. Какие cases почти всегда require edits?
3. Где post-approval incidents всё ещё высоки?
4. Где queue pressure слишком велик?
5. Какие thresholds можно сузить по сегментам?

Практический совет: самый полезный approval tuning обычно начинается не с "сделаем review меньше", а с "какие exactly review decisions не дают нового safety signal". Это приводит к более чистым и менее рискованным изменениям.