Approval Fatigue Management в 2026: как не превратить human-in-the-loop в конвейер без внимания

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

Хороший approval-fatigue management в 2026 обычно включает:

1. Queue triage
2. Packet quality
3. Adaptive thresholds
4. Sampling and audit
5. Reviewer calibration

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

• trivial approvals не должны выглядеть так же, как risky ones;
• fatigue часто вызвана плохим routing, а не "ленивыми людьми";
• edit-heavy cases и blind-approve patterns нужно видеть отдельно;
• часть approval traffic лучше убирать до human layer, а не внутри него.

Почему много approve-кнопок подряд опасны даже в supposedly safe процессе?

1. Fatigue почти всегда начинается до review queue

Частые причины:

• слишком широкие approval rules;
• слабый routing по risk;
• noisy model outputs;
• poor approval packets;
• unnecessary escalations from tool layer.

Поэтому лечить fatigue только внутри reviewer UI обычно поздно.

2. Trivial и risky approvals нужно разводить

Полезные различия:

• low-risk editable drafts;
• medium-risk external messages;
• high-risk money/data actions;
• policy exceptions;
• incident-time overrides.

Если всё это приходит в одну и ту же форму и очередь, attention budget reviewers тратится не там, где он реально нужен.

3. Packet quality влияет на fatigue не меньше, чем queue volume

Review утомляет сильнее, когда packet:

• слишком длинный;
• скрывает action inside prose;
• не показывает diff;
• не объясняет, почему кейс вообще попал на review;
• не даёт edit path.

Хороший packet снижает когнитивную нагрузку и делает decision space уже.

4. Adaptive thresholds полезнее статичных правил

В production полезно пересматривать:

• какие кейсы реально требуют human review;
• где auto-approve можно оставить только после sampling;
• где confidence thresholds слишком консервативны;
• где approval class пора разделить на две.

Именно так queue не зарастает benign шумом.

5. Fatigue нужно измерять, а не угадывать

Полезные сигналы:

• very fast approve streaks;
• drop in edit rate;
• growth of blind-approve patterns;
• reviewer disagreement spikes;
• rising post-approval incident rate;
• falling packet open-depth.

Это лучше, чем пытаться понять fatigue по субъективным жалобам.

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

One-size-fits-all approval flow

Все кейсы выглядят одинаково.

No fatigue metrics

Утомление видно только после ошибки.

Over-reviewing benign cases

Человеческое внимание тратится на слабые сигналы.

No calibration loop

Reviewers постепенно расходятся в трактовках.

Treating fatigue as individual weakness

Команда обвиняет людей вместо перепроектирования системы.

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

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

• approvals per reviewer per hour;
• median review time by class;
• edit rate by packet type;
• audit disagreement rate;
• post-approval incident rate;
• fast-approve streak frequency.

Пример fatigue signal

{
  "reviewer_id": "rev_41",
  "window_minutes": 30,
  "approvals": 92,
  "median_review_seconds": 4.2,
  "edit_rate": 0.01,
  "fatigue_signal": "high"
}

Практический checklist

1. Separate benign and risky approval classes
2. Improve packet clarity before adding reviewers
3. Tune thresholds to reduce trivial review load
4. Track fatigue-specific signals, not only throughput
5. Run calibration and audit loops regularly

Практический совет: если human review существует ради качества, его нужно защищать как scarce resource. Внимание reviewer-а почти всегда дороже, чем кажется по dashboard throughput.