Human-in-the-loop: где человек должен оставаться в AI-процессе

Human-in-the-loop — это не человек, который наблюдает за каждым ответом модели. Это явный operational contract: система знает, какая работа может продолжаться автоматически, какие события обязаны ждать решения назначенного reviewer, какие доказательства он получает и что происходит, если никто не ответил. Без этих правил кнопка «согласовать» остаётся декорацией, а не контролем.

Ниже разобран узкий технический вопрос: где человек должен оставаться в AI-процессе. Материал поддерживает broad commercial page AI-специалист в Армении архитектурными критериями и не заменяет её. Здесь нет предположения, что каждому процессу нужен AI или что один human review делает небезопасный процесс безопасным.

Проблема: uncertainty превращается в действие

Модель может классифицировать, извлекать данные, составлять резюме и предлагать действие. Риск меняется, когда output становится действием: клиенту отказывают, деньги переводятся, запись перезаписывается, доступ выдаётся, жалоба закрывается или сообщение публикуется. На этой границе confidence — только один из сигналов. Команда обязана учитывать последствия, обратимость, доказательства, полномочия и допустимое время ожидания.

Полезно разделить workflow на пять стадий:

1. Observe: получить запрос, source documents, identity и текущее состояние систем.
2. Infer: создать classification, draft, score или proposed action.
3. Validate: проверить schema, permissions, source coverage, policy и business rules.
4. Decide: approve, reject, edit, escalate или abstain.
5. Act: изменить system of record или вызвать внешний эффект.

Human review обычно находится между validation и consequential action. Он может потребоваться раньше, если система не установила identity, permission, качество источников или применимое правило. Главный design choice — не «человек или AI», а какие decision rights остаются у человека и при каких условиях.

HIL-GATE: архитектура проверяемого human review

Авторский паттерн HIL-GATE делает review отдельным runtime state, а не скрытым исключением внутри application code.

event -> context builder -> model proposal -> deterministic validation
                                         |-> low risk + valid -> bounded action
                                         |-> review trigger -> review queue
review queue -> evidence packet -> named reviewer -> approve/edit/reject/escalate
                                         |-> signed decision -> action executor
timeout -> safe fallback; incident -> stop switch; correction -> audit + evaluation

Каждый переход сохраняет стабильный case_id. Evidence packet должен включать исходный input, model output, источники, результаты правил, uncertainty signals, предполагаемый side effect, предыдущее состояние системы и recovery option. Reviewer не должен собирать один кейс вручную из пяти инструментов.

Архитектуре нужны девять компонентов:

• Context builder: сохраняет исходные данные и current state без незаметного переписывания.
• Proposal service: возвращает structured output и умеет abstain.
• Policy validator: применяет deterministic permissions, thresholds и prohibited-action rules.
• Review router: выбирает очередь, reviewer role, priority и deadline.
• Evidence packet: показывает минимальный полный набор для решения.
• Decision ledger: фиксирует кто, что, когда, почему и на какой версии решил.
• Action executor: повторно проверяет state непосредственно перед side effect.
• Fallback controller: обрабатывает timeout, недоступные зависимости и disagreement.
• Observability loop: превращает overrides и incidents в evaluation cases.

Это больше, чем approval message в мессенджере. Между proposal и execution система обязана сохранить identity, authorization, idempotency и state.

Где human gate обязателен

Human gate нужен, если выполняется хотя бы одно из следующих условий.

Последствия существенны или плохо обратимы

Financial transfer, кадровые решения, медицинские или юридические выводы, блокировка аккаунта, safety-инструкции и договорные обязательства нельзя исполнять только потому, что model score прошёл threshold. Reviewer должен иметь полномочия и компетенцию принять последствие. В регулируемой области может требоваться профильный специалист; обычный operations approver его не заменяет.

Доказательства неполны, конфликтуют или не traceable

Если утверждение нельзя связать с допустимым источником либо две системы расходятся в данных о клиенте, товаре или сумме, automation должен направить кейс на review или abstain. Убедительное объяснение не является доказательством. Review interface должен показывать provenance и unresolved conflicts.

Intent, permission или identity неоднозначны

Модель может понять запрос, но система всё ещё не способна доказать право requester на действие. Permission checks должны находиться вне модели. Unknown identity, cross-tenant data, необычное elevation прав или новый action scope требуют deterministic deny либо human escalation.

Кейс новый или вне evaluation distribution

Низкое сходство с evaluation cases, новый language pattern, неизвестный тип документа, пропущенные поля или изменившаяся upstream schema — полезные out-of-distribution signals. Они не доказывают ошибку, но показывают, что automatic performance для этого кейса не установлена.

Policy содержит легитимные исключения

Жёсткое правило может отклонить кейс, для которого существует документированное исключение. Модель не должна его изобретать, а automation — скрывать. Кейс направляется человеку с explicit exception authority, rationale сохраняется.

Действие публично представляет компанию

Draft можно создавать автоматически; публикацию часто нельзя. Public statements, чувствительные support replies, существенные изменения цены и ответы на жалобы требуют brand, legal или operational judgment. Gate можно ослабить только для узких approved templates с проверенными low-impact variables.

REVIEW-7: матрица trigger conditions

HIL-GATE использует REVIEW-7, чтобы выбрать act, wait или stop.

Матрица конфигурируется для каждого action, а не целого приложения. Чтение draft, отправка внутренней рекомендации и возврат платежа имеют разные thresholds, даже если используют одну модель.

Спроектируйте review contract

Human gate требует явного контракта между product, engineering и operations.

Trigger contract. Сначала перечислите deterministic triggers: amount limits, restricted fields, permission changes, policy flags, missing sources, validation errors и новые action types. Model-derived uncertainty используйте как дополнительный сигнал. Один global confidence threshold ненадёжен: confidence калибруется по-разному для разных tasks и classes.

Evidence contract. Зафиксируйте, что видит reviewer: original request, structured proposal, citations, relevant history, rule failures, changed fields и predicted impact. Скрывайте лишние personal data. Interface должен отделять source facts, model inference и reviewer notes.

Decision contract. Определите outcomes: approve, edit and approve, reject, request information, escalate или mark incident. Один free-form comment плохо подходит для audit и evaluation. Нужен reason code и optional explanation.

Authority contract. Свяжите actions с reviewer roles и separation-of-duty. Человек, подготовивший high-risk change, может не иметь права его согласовать. Authorization повторно проверяется при отправке решения.

Timing contract. Задайте deadline, escalation target и safe timeout. «Ждать бесконечно» создаёт зависшие workflows, а «автоматически согласовать через 30 минут» уничтожает смысл gate. Safe timeout обычно сохраняет прежнее состояние, не вызывает external action и уведомляет owner.

Recovery contract. Сохраните pre-action state, idempotency key и rollback procedure. Approval не отменяет recovery: reviewer может ошибиться, а state — измениться до execution.

Race conditions и безопасное execution

Review создаёт паузу между proposal и action. За это время invoice может быть оплачен, inventory изменится, клиент отзовёт consent или оператор обновит запись. Выполнение старого proposal без повторной проверки создаёт time-of-check/time-of-use failure.

Executor должен потребовать:

• тот же case_id и неиспользованный idempotency key;
• signed decision от authorized reviewer;
• совпадающие policy, prompt и schema versions;
• current-state fingerprint либо explicit rebase;
• повторную validation permissions и prohibited actions;
• atomic write либо compensating action;
• immutable audit event.

Если current state отличается, approved patch нельзя применять молча. Evidence packet пересобирается, а при существенной разнице запрашивается новое решение.

Failure modes, которые должна выдержать система

Rubber-stamping

При длинной очереди и непрозрачном interface reviewers нажимают approve без проверки. Измеряйте decision latency, override patterns и повторяющиеся approvals, но не считайте скорость доказательством качества. Улучшайте evidence packet, убирайте low-value reviews и выборочно проверяйте approved cases.

Queue overload

Если каждый кейс идёт человеку, система добавила latency к ручной работе. Shadow mode должен оценить review volume до запуска. Разделяйте queues по risk и skill, вводите workload caps и сохраняйте non-AI fallback при перегрузке.

Automation bias

Reviewer может доверять точной на вид рекомендации модели. Показывайте sources до persuasive prose, не выбирайте approve по умолчанию, открывайте uncertainty и policy failures. Где уместно, добавляйте blinded control cases для проверки независимого judgment.

Missing accountability

«Operations согласовал» недостаточно. Сохраняйте reviewer identity, role, input versions, reason code, decision timestamp, execution result и последующую correction. Audit events защищаются от несанкционированного изменения и подчиняются retention policy.

Stale approval и duplicate action

Approval может прийти после timeout или дважды. Решение должно быть single-use и иметь явный expiry, executor — быть idempotent. Late approval создаёт видимый conflict, а не второй side effect.

Feedback poisoning

Reviewer edits полезны для evaluation, но не являются автоматическим ground truth. Поспешная правка, policy exception или compromised reviewer могут ошибаться. Corrections проходят curation до использования в prompts, retrieval или training.

Тестирование до production

Unit tests должны покрывать все deterministic triggers и допустимые state transitions. Contract tests проверяют review payload, identity propagation, version fields и action API. Integration tests должны пройти approve, reject, edit, timeout, escalation, dependency failure и duplicate submission.

Evaluation set включает обычные cases и намеренные edge cases:

• конфликтующие sources и missing evidence;
• low-confidence correct и high-confidence wrong outputs;
• cross-tenant identifiers и permission changes;
• stale state между review и execution;
• reviewer unavailable, deadline exceeded и queue overload;
• rollback success, failure и partial side effects;
• русские и английские кейсы, если оба языка используются в operations.

Перед включением actions запустите shadow mode: proposals и routes создаются, но действующий процесс не меняется. Сравните routing с решениями операторов. Затем используйте draft mode, где final action выполняет человек. Только узкий, reversible и evaluated low-risk slice может перейти к bounded auto-execution.

Production checklist

• Назначенный process owner определил risk tolerance и stop conditions.
• Каждый consequential action имеет явную human или deterministic boundary.
• Reviewer roles enforced приложением, а не только документацией.
• Evidence packets разделяют source facts, inference и policy results.
• Decisions structured, attributable, versioned и single-use.
• Timeout имеет safe fallback и escalation owner.
• State и permissions проверяются непосредственно перед execution.
• Writes idempotent; recovery и rollback проверены.
• Review volume, latency, overrides, incidents и corrections observable.
• Stop switch отключает execution, не уничтожая evidence.
• Evaluation cases покрывают failure paths и оба поддерживаемых языка.
• У команды есть критерии уменьшения, увеличения или отключения automation.

Рекомендуемая последовательность внедрения

Начните с одного workflow slice, нанесите на карту decisions, evidence, actors и side effects. Примените REVIEW-7 к каждому action, затем запишите trigger, evidence, decision, authority, timing и recovery contracts. Постройте ledger и executor до полировки prompt. Запустите shadow mode, измерьте queue volume и disagreement, исправьте evidence packet и только затем разрешите reversible action.

Human-in-the-loop работает, когда создаёт ясные decision rights и recoverable execution, а не когда человек вставлен в каждый шаг. Для широкой оценки применимости автоматизации используйте страницу AI-автоматизация. Доказательства реализации собраны в кейсах. Для focused architecture review подготовьте один workflow, стоимость failure, representative cases и system-of-record boundary.