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

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

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

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

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

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

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

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 не должен происходить внутри вызова генерации.

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.

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-агентов. Если в routing участвует LLM judge, калибруйте его отдельно: см. гайд по LLM-as-judge.

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

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
• NIST AI RMF Core: human oversight responsibilities
• Google PAIR Guidebook: Feedback and Control
• OpenAI: A practical guide to building agents
• Anthropic: Trustworthy agents in practice

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