# Human-in-the-Loop для AI: как строить approval gates

> Проектируем human oversight для AI: risk tiers, state machine согласования, routing signals, reviewer UX, queue SLA, audit logs и метрики релиза.
> Author: Roman Belov · Published: 2026-04-06 · Source: https://futurecraft.pro/ru/blog/human-in-the-loop/

Human-in-the-loop часто рисуют одним блоком между моделью и действием. Сам блок
прост. Сложно определить, за что отвечает человек, какие доказательства он видит,
сколько у него времени и что произойдёт, если никто не ответит.

Кнопка review не передаёт ответственность абстрактному «человеку». Product team
по-прежнему отвечает за routing policy, reviewer tooling, audit trail и failure
behavior.

## Начните с действия, а не с модели

Один model output создаёт разный риск. Черновик ответа о возврате и сам возврат
денег — не одно действие. Предложить database migration и выполнить её — тоже.

Классифицируйте действие по наблюдаемым факторам:

| Фактор | Ниже риск | Выше риск |
|---|---|---|
| Последствия | Форматирование, tags | Деньги, права, здоровье, доступ |
| Обратимость | Простая правка или rollback | Необратимо или дорого восстановить |
| Масштаб | Один draft | Много пользователей или records |
| Обнаружимость | Ошибка видна сразу | Вред проявится позже или вне системы |
| Полномочия | Пользователь уже разрешил | Новое обязательство или permission |
| Время | Можно дождаться review | Решение нужно немедленно |

Результат — несколько action policies, а не расплывчатый label `high-risk`:

```typescript
interface ActionPolicy {
  actionType: 'draft_reply' | 'send_reply' | 'issue_refund';
  reviewMode: 'none' | 'sample' | 'required';
  maxAmount?: number;
  expiresAfterMs: number;
  timeoutOutcome: 'expire' | 'return_to_user' | 'keep_pending';
  requiredReviewerRole?: string;
  requiredEvidence: string[];
}
```

В регулируемых и safety-critical сценариях таблица не заменяет domain, legal,
security и compliance review. Она превращает их требования в исполняемые правила.

## Используйте четыре режима oversight

Большинству систем мало выбора между `auto` и `manual`.

### 1. Draft для пользователя

AI создаёт редактируемый artifact, но не имеет права исполнить действие.
Пользователь остаётся actor. Подходит для писем, отчётов, code changes и форм.

Интерфейс должен честно показывать границу. Заранее выбранная кнопка «сразу
отправить» превращает формальный review в автоматизацию по привычке.

### 2. Approval до действия

Система готовит typed action и останавливается. Reviewer с нужной ролью approve,
edit или reject до execution. Режим нужен для необратимых действий, расширения
permissions, существенных финансовых последствий и неоднозначной policy.

### 3. Interrupt при исключении

Агент ведёт ограниченный workflow, но останавливается при policy event: нет
обязательных данных, повторно упал tool, источники конфликтуют, input вышел за
evaluated distribution или действие лежит вне делегированных полномочий.

### 4. Post-action audit

Действие выполняется, затем выбранные случаи проверяются. Это допустимо только при
обнаружимых и обратимых ошибках с принятым residual impact. Sampling должен
включать targeted slices и случайные случаи. Проверка только тех outputs, которые
сама модель назвала сомнительными, не находит слепые зоны routing signal.

Пользователю также нужен **appeal или correction path**. Внутренний sampling не
поможет человеку, которого ошибочное решение затронуло сегодня.

## Confidence — сигнал, а не разрешение

Поле `confidence: 0.93` не становится calibrated probability. Оно может отражать
стиль ответа, формулировку prompt или привычку модели ставить высокий score, а не
вероятность корректного действия.

Полезные routing signals:

- deterministic schema и policy checks;
- отсутствие обязательного evidence;
- retrieval coverage и конфликт источников;
- расстояние от evaluated task distribution;
- disagreement независимо спроектированных проверок;
- task score, откалиброванный на labeled outcomes;
- повторный сбой tool или validation;
- явная просьба пользователя о человеке.

Калибруйте каждый сигнал на representative data. Для score `s` сгруппируйте
примеры по диапазонам и сравните predicted confidence с observed pass rate.
Проверяйте language, tenant, task subtype и другие slices, меняющие качество.
Один global threshold способен скрыть слабую группу.

Для каждого candidate threshold постройте:

- объём review;
- harmful error rate среди автономных действий;
- false escalation rate;
- reviewer capacity и wait time;
- outcome по важным slices;
- стоимость safe fallback.

Не оптимизируйте общую accuracy, если false approval и false escalation имеют
разные последствия.

## Разделите proposal, approval и execution

Модель предлагает typed action. Side effect не должен происходить внутри вызова
генерации.

```typescript
interface ActionProposal {
  proposalId: string;
  actionType: string;
  arguments: Record<string, unknown>;
  evidenceRefs: string[];
  policyVersion: string;
  createdAt: string;
  expiresAt: string;
  contentHash: string;
}

interface ReviewDecision {
  proposalId: string;
  contentHash: string;
  reviewerId: string;
  decision: 'approved' | 'edited' | 'rejected';
  reasonCode: string;
  decidedAt: string;
}
```

Approval ссылается на точный hash proposal. Если arguments изменились, старое
решение недействительно. Перед execution система ещё раз проверяет текущие
permissions, policy, expiry и idempotency.

```text
PROPOSED -> PENDING_REVIEW -> APPROVED -> EXECUTING -> EXECUTED
                          \-> REJECTED
                          \-> EXPIRED
```

State transitions должны быть atomic. Double click, повторная доставка queue или
retry после network timeout не могут дважды выдать возврат. Храните idempotency
key логического действия и operation ID внешней системы.

Approval не равен authorization. Reviewer не может согласовать то, что ему самому
запрещено выполнить напрямую.

## Проектируйте review queue с учётом отказа

Очереди мало FIFO и флага `urgent`.

У каждой записи задайте:

- tenant и access scope;
- action type, impact и затронутые объекты;
- creation и expiry time;
- reviewer role и separation of duties;
- evidence refs и freshness;
- текущее состояние workflow;
- safe timeout outcome;
- deduplication и idempotency keys.

Capacity planning начинается с arrival rate, handling time, staffing windows и
целевого wait time. Измеряйте распределение, а не только среднее. Очередь может
работать днём и стабильно ломаться каждые выходные.

При падении capacity не ослабляйте policy незаметно. Безопаснее:

- остановить AI feature или high-risk action;
- вернуть управление пользователю;
- дать несущественным proposals истечь;
- направить к согласованной on-call role;
- уменьшить scope фичи;
- выполнять обратимую low-risk работу по заранее reviewed fallback.

Timeout должен быть виден пользователю. `Pending review` не выглядит как
завершённое действие.

## Дайте reviewer интерфейс для принятия решения

Reviewer нужны факты, влияющие на решение, а не стена model text.

Покажите:

- proposal и затронутый объект;
- before/after state;
- excerpts авторитетных источников со ссылками и timestamps;
- failed rules, missing inputs и route reason;
- сопоставимые policy examples, когда они полезны;
- явные edit, reject и request-more-information;
- последствия approval.

Не используйте скрытый chain-of-thought как explanation. Краткий evidence summary
и ссылки на источники проверяются лучше. Не показывайте убедительный rationale
модели раньше фактов: он создаёт anchoring.

Снижайте fatigue: группируйте похожие low-risk reviews, ротируйте задания,
планируйте перерывы, следите за decision time и reversal rate. Seeded
quality-control cases помогают заметить потерю внимания, но reviewers должны
знать о программе и использовании результатов.

## Измеряйте человека и систему вместе

HITL metrics связывают routing, queue health, решения reviewers и итог:

- autonomous, sampled, required-review, expired и appealed volume;
- harmful error rate по route и action type;
- false escalation и missed escalation;
- queue age percentiles и SLA misses;
- approval, edit, rejection и reversal rates;
- reviewer agreement на целевой double-review выборке;
- time per decision и изменение в течение смены;
- incidents после approval;
- performance по language, customer segment и risk slice.

Disagreement reviewers не всегда означает их ошибку. Причиной бывает неоднозначная
policy или недостаточный evidence. Исправьте policy и UI, пересмотрите labels в
evaluation set, затем настраивайте модель.

## Превратите правки в управляемое обучение

Храните structured reason codes и corrected outputs, но не отправляйте каждую
правку напрямую в prompt или fine-tuning. Reviews могут конфликтовать, содержать
чувствительные данные или отражать временное исключение policy.

Используйте контролируемый цикл:

1. redact или ограничить sensitive data;
2. adjudicate неоднозначные и high-impact examples;
3. версионировать labeled evaluation set;
4. определить источник сбоя: retrieval, prompt, model, tool, policy или UI;
5. изменить один компонент;
6. прогнать offline evals и shadow tests;
7. сделать canary нового route и сохранить rollback.

Evaluation sets разобраны в
[гайде по тестированию AI-агентов](/ru/blog/ai-agent-testing-evaluation/). Если в
routing участвует LLM judge, калибруйте его отдельно: см.
[гайд по LLM-as-judge](/ru/blog/llm-as-judge-automated-quality-gate/).

## Аудит без склада персональных данных

Audit record объясняет, кто мог сделать что и почему:

- версии proposal, policy, prompt/workflow, model и tools;
- evidence identifiers и access decisions;
- route reason и validation results;
- reviewer identity и role;
- edits, решение, timestamp и execution result;
- appeal, reversal или incident link.

Минимизируйте raw prompts и PII. Применяйте retention и deletion policy к review
artifacts. Разделите operational и analytics access. Делайте audit logs
tamper-evident соразмерно риску системы.

## Production checklist

- [ ] Actions классифицированы по impact, reversibility, scope, authority и time.
- [ ] У каждого action есть oversight mode и safe timeout outcome.
- [ ] Self-reported confidence модели не используется как единственный сигнал.
- [ ] Routing signals откалиброваны на representative slices и наблюдаются.
- [ ] Proposal, approval и execution — отдельные immutable events.
- [ ] Executor повторно проверяет authorization, expiry, policy и idempotency.
- [ ] Reviewer видит authoritative evidence и может edit, reject или запросить данные.
- [ ] Queue capacity и off-hours behavior проверены до запуска.
- [ ] Пользователь видит pending review и может appeal важный outcome.
- [ ] Corrections идут в reviewed eval pipeline, а не automatic training.
- [ ] Audit records полезны без хранения лишних PII.

## Первоисточники

- [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework)
- [NIST AI RMF Core: human oversight responsibilities](https://airc.nist.gov/airmf-resources/airmf/5-sec-core/)
- [Google PAIR Guidebook: Feedback and Control](https://pair.withgoogle.com/guidebook-v2/chapter/feedback-controls/)
- [OpenAI: A practical guide to building agents](https://openai.com/business/guides-and-resources/a-practical-guide-to-building-ai-agents/)
- [Anthropic: Trustworthy agents in practice](https://www.anthropic.com/research/trustworthy-agents)

Human oversight работает, когда меняет полномочия системы на точной границе. Если
человеку не хватает времени, evidence, permission или безопасной возможности
сказать «нет», loop существует только на архитектурной схеме.