AI-порталAI-портал

Agent Policy Exception Audits в 2026: как разбирать не только сами исключения, но и качество их обработки

Agent policy exception audits в 2026: как анализировать, когда агент запросил exception, кто его одобрил, был ли он justified и не превращается ли exception path в скрытый bypass.

Agent policy exception audits в 2026 нужны потому, что exception path легко становится теневой нормой. Изначально исключения вводят для редких кейсов: customer emergency, special contract, temporary workaround. Но если команда не аудитит этот контур отдельно, исключения начинают жить собственной жизнью: агент слишком охотно их запрашивает, reviewers слишком легко одобряют, justification становится формальностью, а exception path постепенно превращается в обход основного policy слоя.

Policy exception audit — это проверка не только самого факта исключения, но и того, насколько оно было оправдано, корректно оформлено, ограничено по scope и не стало ли регулярным обходным маршрутом.
Самый вредный anti-pattern - считать, что раз exception всё равно одобрил человек, значит его не надо отдельно анализировать. На практике именно exception path чаще всего и дрейфует в сторону policy erosion.

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

Хороший exception audit в 2026 обычно проверяет:

  1. Почему exception был запрошен
  2. Был ли normal path реально неприменим
  3. Кто и на каком основании его одобрил
  4. Не повторяется ли тот же тип exception слишком часто
  5. Не стал ли exception скрытым bypass

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

  • exception нужно аудитить отдельно от обычных approvals;
  • repeated exception type часто означает дыру в основной policy;
  • human approval не делает exception автоматически качественным;
  • audit должен смотреть на scope, TTL и justification.
Без техники
Команда видит только список одобренных exceptions и считает, что всё под контролем.
С техникой
Audit показывает, что один и тот же exception type используется слишком часто и фактически подменяет основной маршрут.
ПромптException-audit intuition
Почему repeated policy exceptions — это warning signal, а не просто operational detail?
Ответ модели

Потому что повторяющееся исключение обычно означает, что основная policy или workflow плохо отражает реальность и начинает обходиться на практике.

1. Exception audit нужен как отдельный governance слой

Полезно оценивать:

  • necessity of exception;
  • quality of justification;
  • scope of exception;
  • approver quality;
  • recurrence of same class;
  • downstream incidents.

Иначе исключения теряются внутри общей review статистики.

2. Repeated exceptions часто говорят о structural gap

Если один и тот же exception type возникает снова и снова, это может значить:

  • policy слишком грубая;
  • route design не покрывает реальный кейс;
  • confidence thresholds неверны;
  • reviewers компенсируют плохую automation ручными исключениями.
Если exception path начинает выглядеть "нормальным рабочим способом", проблема почти всегда уже в baseline policy, а не в редких edge cases.

3. Scope и TTL exception особенно важны

Плохо:

  • broad exception without limits;
  • no expiration;
  • weak justification;
  • one approver for too many classes;
  • no link to evidence pack.

Хороший exception обычно:

  • narrow;
  • time-bounded;
  • evidence-backed;
  • tied to one outcome class.

4. Exception audit полезно связывать с incident review

Команде важно видеть:

  • какие incidents шли через exception path;
  • какие exceptions позже оказались unnecessary;
  • какие reviewers approval-ят слишком широко;
  • какие workflows чаще всего просят обход policy.

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

Exception mixed with normal approval

Отдельный risk profile теряется.

No recurrence tracking

Один и тот же обход живёт месяцами.

Human approval treated as enough

Justification quality не анализируется.

No expiration

Exception становится quasi-permanent.

No feedback into baseline policy

Повторяющиеся исключения ничего не меняют в основном маршруте.

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

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

  • exception rate by workflow;
  • repeated-exception rate;
  • exception approvals by approver;
  • incidents linked to exception path;
  • mean exception TTL;
  • percent of exceptions later converted into normal policy changes.

Плюсы

  • Exception audits помогают не превратить policy exceptions в hidden normal path
  • Показывают structural gaps в baseline workflows
  • Улучшают качество human approvals в exception cases
  • Связывают governance и incident learning

Минусы

  • Нужно отдельно моделировать exception taxonomy
  • Reviewers могут воспринимать audit как дополнительную бюрократию
  • Не все unnecessary exceptions легко выявить автоматически
  • Без feedback loop audits не улучшают policy

Пример exception record

{
  "exception_type": "temporary_policy_override",
  "workflow": "refund_agent",
  "approved_by": "ops_lead",
  "ttl_minutes": 30,
  "justification_quality": "weak"
}

Простой audit question set

1. Почему normal path не подошёл?
2. Было ли evidence достаточно сильным?
3. Не повторялся ли этот exception недавно?
4. Scope исключения был минимальным?
5. Нужно ли менять baseline policy?

Практический совет: зрелый exception audit ищет не только "правильные ли были исключения", но и "почему система вообще так часто к ним приходит".

Проверьте себя

1. Почему policy exceptions нужно аудитить отдельно?

2. Что часто означает repeated exception?

3. Какой anti-pattern особенно опасен?

Источники

  1. OpenAI API Docs - Evaluation best practices
  2. OpenAI API Docs - Trace grading
  3. OpenAI Agents SDK - Human in the loop
  4. OpenTelemetry - GenAI semantic conventions
Предыдущая
Agent Incident Response в 2026: как останавливать плохие run-ы до того, как они станут outage
Следующая
Approval Bypass Prevention в 2026: как не дать агенту обойти human gate косвенным путём