Human review: где человек обязан остаться финальным ответственным

Сотрудник видит готовую рекомендацию AI, зелёный индикатор и кнопку «подтвердить». На проверку — сорок секунд. Исходные документы спрятаны в другом окне, очередь растёт, а отклонение нужно объяснять руководителю. Формально человек присутствует. По существу система уже решила за него.

Human review становится реальным только тогда, когда конкретный человек понимает предмет, видит достаточные доказательства, располагает временем, вправе отклонить рекомендацию без наказания и может остановить процесс. Галочка, подпись или место в цепочке не создают ответственность сами по себе.

По состоянию на 28 августа 2026 года Narayana AI Academy & Studio ↗ представлена на публичной карте Narayana ↗ как направление «В развитии». Страница описывает будущий маршрут, где human review назван обязательным, а человек — принимающим финальное решение. Это публичный замысел предложения, не доказательство проведённого обучения, работающей Studio, внедрённого review-контура, AI-пилота, автоматизации, CRM, партнёрства, соответствия праву, безопасности или результата. Из-за registrar hold фактчек страницы и карты выполнен через верифицированный production-origin `201.24.116.180`; canonical сохраняется, а доступность нужно перепроверить перед публикацией.

Ниже — независимая проектная модель. Она не описывает действующий процесс Narayana, не является юридическим заключением и не обещает безошибочность, соответствие закону, безопасность, ROI или замену специалиста.

Пять ролей, которые нельзя называть одним словом

Фраза «проверено человеком» скрывает разные действия. Если роли не разделены, организация не понимает, кто проверяет систему, кто принимает решение и кто отвечает перед затронутым человеком.

Один человек иногда совмещает несколько ролей, но это нужно фиксировать явно. Технический специалист может подтвердить, что модель работает в заявленной версии, и не иметь права отказать кандидату в найме. Редактор может исправить текст письма и не иметь полномочия изменить цену. Руководитель может утвердить выплату, но не оценить безопасность интеграции без технической проверки.

Человек в контуре и человек над контуром

В модели human-in-the-loop человек проверяет отдельный случай до того, как система совершит действие. Такой контроль нужен, когда последствия значимы, решение трудно отменить, исходные данные неоднозначны или полномочие нельзя делегировать автоматике.

В модели human-on-the-loop система действует в заданных границах, а человек наблюдает, получает сигналы и может вмешаться. Этот вариант работает только там, где монитор способен заметить отклонение раньше ущерба, понимает состояние системы и действительно успевает остановить её. Если десять процессов меняются быстрее реакции, кнопка аварийной остановки создаёт иллюзию контроля.

Есть и полностью автоматизированный маршрут. Он может быть разумен для ограниченных, низкозначимых, обратимых операций с проверенными границами: например, сортировки внутреннего чернового потока без отправки наружу. Но выбор режима должен следовать из последствий, обратимости, времени реакции и применимого права, а не из желания сократить очередь.

NIST AI RMF Core ↗ предлагает документировать роли и ответственность для human–AI configurations, обучать участников, определять human oversight и планировать monitoring на протяжении жизненного цикла. NIST AI 600-1 ↗ переносит этот подход на генеративные системы и подчёркивает оценку риска, incident disclosure и управление содержанием. Это добровольные американские рамки, а не российское право и не свидетельство внедрения.

Когда финальное решение нельзя превращать в автопилот

Универсального списка для всех организаций нет. Но чем сильнее решение меняет права, деньги, доступ, здоровье, безопасность, работу или публичную репутацию человека, тем выше требование к компетентному владельцу и отдельному маршруту обжалования.

К решениям повышенного воздействия обычно относятся:

• приём, увольнение, дисциплинарная мера, оплата труда и оценка сотрудника;
• кредит, страхование, выплата, существенная цена или отказ в услуге;
• медицинская рекомендация, диагноз, лечение или приоритет помощи;
• физический доступ, безопасность объекта и действия, способные причинить вред;
• юридически значимое уведомление, договорное обязательство или отказ;
• публикация факта о человеке, обвинение, санкция или ограничение участия;
• передача персональных, конфиденциальных либо специальных категорий данных.

Это не означает, что любой такой процесс запрещено поддерживать AI. Модель может искать сведения, выявлять противоречия, готовить черновик или предупреждать о пропуске. Но финальный ответ должен принадлежать человеку с предметной компетентностью и полномочием, а не сотруднику, назначенному «для галочки».

Регламент ЕС 2024/1689 ↗, применимый в своей юрисдикции и не являющийся российским правом, требует для high-risk AI соразмерного human oversight, включая компетентность, обучение, полномочия, понимание ограничений, способность не переоценивать выход и право прервать систему. Рамочная конвенция Совета Европы об AI ↗ связывает прозрачность и надзор с ответственностью, документированием, возможностью оспорить решение и подать жалобу. Применимость конвенции зависит от участия государства и внутреннего права; это не готовый чек-лист соответствия Narayana.

Российское право: человек в интерфейсе не закрывает вопрос

Актуальный текст Федерального закона № 152-ФЗ проверен на официальном интернет-портале правовой информации ↗. Для точных ссылок на положения ниже используется консолидированный текст СПС «КонсультантПлюс» — это справочная правовая система, а не официальный портал опубликования.

Статья 16 закона № 152-ФЗ ↗ ограничивает решения, основанные исключительно на автоматизированной обработке персональных данных, если они порождают юридические последствия или иначе затрагивают права и законные интересы человека, кроме предусмотренных случаев. Она также предусматривает объяснение порядка и последствий, возможность возражения и рассмотрение возражения оператором. Добавление номинального reviewer не доказывает, что обработка перестала быть «исключительно автоматизированной»: важны реальное влияние человека, данные, процедура и последствия.

Статья 18.1 ↗ требует организационных мер: ответственного, политики и локальных актов, контроля и ознакомления работников. Статья 19 ↗ — правовых, организационных и технических мер защиты персональных данных, обнаружения инцидентов, восстановления и контроля эффективности. Какая норма применима к конкретному AI-процессу, зависит от оператора, цели, категорий данных, оснований, поставщиков, архитектуры и последствий; это должен оценивать квалифицированный специалист.

Главная практическая граница: нельзя обещать «законность благодаря human review». Проверка — лишь один элемент системы управления, а юридическая ответственность остаётся у людей и организаций, которым она назначена законом и договором.

Почему внимательный сотрудник всё равно ошибается

Human review часто проектируют как запасную пару глаз. Исследования автоматизации показывают, почему этого недостаточно.

Классическая работа Parasuraman и Riley о use, misuse, disuse и abuse автоматизации ↗ связывает чрезмерное доверие с пропусками мониторинга и смещением решений, а недоверие — с игнорированием полезной автоматизации. В эксперименте Skitka, Mosier и Burdick об automation bias ↗ участники с неидеальным помощником допускали ошибки пропуска и следования неверной рекомендации даже при доступных правильных признаках.

Mica Endsley в обзоре уроков human–automation research ↗ показывает, что рост автономности меняет ситуационную осведомлённость и способность человека быстро вернуть контроль. Это особенно важно для human-on-the-loop: долгое пассивное наблюдение — плохая подготовка к редкому сложному вмешательству.

Современные исследования не дают простой формулы «AI плюс человек всегда лучше». Метаанализ Vaccaro, Almaatouq и Malone ↗ объединил 106 экспериментов и 370 эффектов: в среднем связка человек–AI была лучше человека без AI, но хуже лучшего из двух самостоятельных вариантов; для задач выбора наблюдались потери, а результаты существенно различались. Авторы отдельно указывают на гетерогенность и ограничения корпуса.

В исследовании Green и Chen ↗ взаимодействие с алгоритмической оценкой риска меняло решения людей неодинаково и не устраняло проблему справедливости автоматически. Buçinca и соавторы ↗ показали, что cognitive forcing может снижать чрезмерное следование AI, но создаёт цену в усилиях и удобстве. Вывод не в том, чтобы усложнить каждую кнопку, а в том, чтобы дать проверяющему независимую работу до показа рекомендации там, где это оправдано риском.

Девять условий содержательного human review

1. Названо решение, а не «проверка вообще»

Reviewer должен понимать, что именно он утверждает: факт, текст, доступ, сумму, действие или исключение. Проверка черновика письма и одобрение возврата денег — разные решения.

2. Есть полномочие и право сказать «нет»

Сотрудник может отклонить выход, изменить его, вернуть ручной маршрут и остановить процесс. Отказ не должен автоматически ухудшать его KPI. Если система поощряет согласие и наказывает сомнение, финальным становится алгоритм.

3. Есть предметная компетентность

Ревьюеру нужны знания процесса, ограничений AI, типов ошибок, конфиденциальности и маршрутов эскалации. Назначение самого младшего сотрудника не создаёт независимый контроль.

4. Видны первичные доказательства

На экране должны быть исходный запрос, допустимые источники, дата и версия, существенные ограничения, рекомендация и причина срабатывания. Процент уверенности без основания не заменяет доказательство.

5. Есть время и управляемая нагрузка

Норматив рассчитывают не по средней скорости на простом случае, а по сложным и редким. Очередь, доля отклонений, пропуски, время на случай и усталость — такие же показатели качества, как latency модели.

6. Мнение формируется независимо

Для части значимых задач полезно сначала показать факты и попросить предварительное решение, а затем открыть рекомендацию AI. Это уменьшает якорение. Порядок интерфейса нужно тестировать, а не считать универсальным лекарством.

Независимость включает и конфликт интересов. Reviewer не должен одновременно получать бонус за максимальную долю автоматических одобрений, отвечать за продажу системы и оценивать её ошибки. Если разделить роли невозможно, конфликт фиксируют, вводят выборочную вторую проверку и дают безопасный внешний маршрут эскалации. Для особо значимого решения две подписи полезны только тогда, когда второй человек получает собственные данные и полномочия; последовательное копирование первого мнения удваивает ритуал, а не контроль.

7. Override действительно работает

Кнопка отмены должна прекращать действие во всех связанных системах, а не менять только статус на экране. Нужны проверка rollback, fallback без AI и понятный владелец восстановления.

8. Есть эскалация и апелляция

Reviewer передаёт спорный случай более компетентной или независимой роли. Затронутый человек получает понятный способ задать вопрос, представить дополнительные сведения и оспорить решение. Апелляцию не должен автоматически рассматривать тот же output или тот же заинтересованный сотрудник.

9. Решение оставляет пригодный журнал

Журнал фиксирует версию системы и правил, входные источники, рекомендацию, автора финального решения, время, изменение, основание override, эскалацию и результат жалобы. При этом лог не должен собирать избыточные персональные данные или храниться бессрочно.

OECD AI Principle об accountability ↗ связывает ответственность с ролями, контекстом, traceability, документированием и постоянным risk management; принцип о human-centred values ↗ — с agency и oversight. ISO/IEC 42001:2023 ↗ задаёт международную рамку системы менеджмента AI. Ни один из этих документов не является российским законом, аудитом Narayana, сертификатом или гарантией качества.

Исследование Santoni de Sio и van den Hoven о meaningful human control ↗ предлагает две полезные идеи: система должна реагировать на значимые человеческие основания, а результат — прослеживаться к людям, способным понять систему и моральный смысл своей роли. Это философско-инженерная рамка, не юридический тест, но она хорошо разоблачает декоративную подпись.

Матрица режима: approve, monitor или не автоматизировать

Перед запуском полезно заполнить не колонку «human review: да/нет», а матрицу.

Если хотя бы одно критичное условие контроля не выполнено, выбор не сводится к «добавим reviewer». Возможны сужение задачи, read-only режим, запрет действия, двойная проверка, возврат ручного процесса или отказ от AI.

Минимальный регламент одного решения

1. Назвать владельца процесса и юридически/организационно уполномоченного финального решающего.
2. Разделить автоматическую рекомендацию, technical review, editorial review и operational approval.
3. Описать последствия, обратимость, affected persons и запрещённые действия.
4. Определить требуемые данные, источники и то, что reviewer обязан увидеть.
5. Проверить компетентность, обучение, независимость, нагрузку и резервного специалиста.
6. Настроить `accept`, `edit`, `reject`, `escalate`, `stop` и ручной fallback.
7. Дать человеку понятный канал уведомления, уточнения и апелляции там, где решение его затрагивает.
8. Логировать доказательства и изменения с минимизацией, доступом, сроком хранения и удалением.
9. Тестировать не только точность модели, но и ошибки человека с AI, время реакции, долю отмен и сбои override.
10. Заранее записать условия `go`, `rework`, `hold`, `stop` и повторной оценки после изменения модели, данных или процесса.

Успешная демонстрация на десяти удобных примерах не доказывает готовность к потоку. Нужны редкие ошибки, конфликтующие данные, высокая нагрузка, отсутствие специалиста, сбой интеграции, жалоба и попытка отмены уже начатого действия.

Как это относится к Narayana AI Academy & Studio

Для направления «В развитии» human review может быть только принципом будущего дизайна. Публичная страница упоминает правила проверки, доступа и ответственности, модуль регламента и последовательность Studio `Diagnose → Pilot → Human review → Scale`. Она не показывает утверждённый use case, фактического оператора, назначенных владельцев, матрицу полномочий, нагрузочные тесты, журнал решений, рабочий override, апелляцию, incident response или результаты пилота.

Честный следующий шаг — собрать на синтетических данных прототип карточки решения и провести tabletop-упражнение: один участник выдаёт ошибочную рекомендацию, второй проверяет предмет, третий эмулирует затронутого человека, четвёртый тестирует отмену и журнал. Только после отдельной правовой, предметной, технической и информационной проверки можно решать, допустим ли ограниченный реальный пилот.

Финальная ответственность — не способность нажать кнопку последним. Это полномочие понять последствия, доступ к доказательствам, право изменить ход процесса, обязанность объяснить решение и возможность исправить его. AI может рекомендовать. Technical review может подтвердить работу системы. Editorial review — качество публикации. Operational approver — утвердить действие. Но организация не может делегировать модели собственную ответственность перед человеком.