Human in the loop — участие человека в процессе работы ИИ. В этой статье разберём проверку готового результата: кто сверяет документ, кто разрешает его использовать и когда работу нужно остановить. Такой маршрут помогает закрепить ответственность за конкретное решение, а не ограничиваться отметкой «согласовано».
Что такое human in the loop при использовании результатов ИИ
В этой статье human in the loop, или HITL, означает порядок работы с участием человека перед использованием результата ИИ. Исполнитель передаёт подготовленный материал на проверку, а назначенный сотрудник принимает решение в пределах своих полномочий. Точку вмешательства закрепляют заранее: до отправки письма, публикации инструкции или передачи задания исполнителю. Проверяющему нужны основания для решения и возможность вернуть материал.
Дальше речь пойдёт о рабочем маршруте согласования. Обучение моделей и технические способы сбора обратной связи остаются за его пределами.
Для маршрута недостаточно указать фамилию ответственного. Нужно определить, что именно он проверяет, какие материалы получает и какое действие вправе разрешить. Иначе исполнитель может принять редакторскую правку за разрешение отправить документ клиенту.
Допуск привязывайте к версии и назначению.
Например, разрешение обсудить черновик на внутренней встрече не означает разрешения отправить его заказчику. При смене адресата могут измениться последствия ошибки и требования к проверке.
Предлагаемый порядок — редакционная рекомендация для настройки процесса внутри организации. Ссылки на NIST в конце статьи предназначены для дополнительного изучения добровольной рамки управления рисками. Внутреннее согласование не служит подтверждением правового соответствия или сертификации.
Расскажите, чему хотите научить команду. Обсудим задачи и формат обучения.
Шаг 1. Опишите задачу и последствия ошибки
Начните с назначения результата и последствий возможной ошибки. Владелец задачи определяет, кто получит материал, для какого действия его используют и что потребуется исправить при обнаружении расхождения. На этой основе он выбирает участников согласования. Один текст может потребовать разных маршрутов: личную заметку и инструкцию всему подразделению используют с разными последствиями.
Перед передачей черновика заполните карточку задачи:
- Назначение: какое действие или решение поддерживает результат.
- Адресат: кто получит материал и сможет передать его дальше.
- Основания: какие утверждённые документы и данные нужны проверяющему.
- Среда обработки: где организация разрешила работать с этими материалами.
- Последствия ошибки: кого затронет исправление и можно ли отозвать результат.
- Критерии допуска: что должно быть подтверждено перед использованием.
Условный пример: HR готовит памятку о внутреннем обучении по утверждённой программе. Неточность в описании упражнения потребует исправить памятку. Выдуманное условие обязательного участия затронет ожидания сотрудников. Такое условие должен проверить владелец программы, а разрешение на рассылку принимает сотрудник с соответствующими полномочиями.
Тема документа одна, маршрут проверки может различаться.
Отдельно задайте основания остановки. Например, обязательные условия ещё не утверждены, исходные материалы противоречат друг другу или участники не вправе разрешить действие. Для каждого основания укажите, кому передать вопрос и кто продолжит работу после ответа.
Заранее определите способ отзыва результата. Исправления файла в общей папке недостаточно, если адресаты уже получили копии. В карточке укажите, кто уведомит получателей и заменит материал.
Правила обращения с данными берите из принятого в организации порядка. Если разрешённая среда обработки не определена, вопрос нужно решить до передачи материалов в сервис. Согласование готового текста не заменяет это решение.
Шаг 2. Назначьте проверяющего и того, кто разрешает использование
Разделите подготовку результата, предметную проверку и разрешение на использование. Исполнитель отвечает за черновик и комплект материалов. Проверяющий сверяет содержание с основаниями задачи. Согласующий принимает решение о применении документа в пределах своих полномочий. Вопросы за пределами компетенции этих участников передают профильному специалисту. Для каждой роли нужно обозначить границы ответственности и порядок замещения.
Таблица ниже — редакционный образец распределения ролей. Все ситуации условные. Организация адаптирует их к своим процессам и полномочиям.
| Условная ситуация и последствия ошибки | Что проверить | Кто проверяет | Кто разрешает использование | Основание остановки |
|---|---|---|---|---|
| Личная рабочая заметка; исправление затронет автора | Соответствие задаче и исходным материалам | Исполнитель по установленным критериям | Исполнитель в пределах полномочий | Заметку собираются использовать для решения, которое затронет других |
| Инструкция команде; ошибка изменит порядок работы | Действия, исключения и ответственных | Владелец процесса | Сотрудник с правом утверждать инструкцию | Текст расходится с принятым регламентом |
| Письмо клиенту; текст содержит обещание | Условия, сроки и границы обязательств | Владелец соответствующих условий | Уполномоченный отправитель | Обещание не подтверждено |
| Материал с данными, допустимость передачи которых неясна | Ограничения на содержание и канал передачи | Назначенный профильный специалист | Ответственный с соответствующими полномочиями | Вопрос о допустимости передачи не решён |
Один сотрудник может совмещать роли, если внутренние правила это допускают. Там, где организация установила независимое согласование, исполнитель не утверждает собственную работу.
Должности недостаточно.
Руководитель может разрешать отправку, но не знать предметных деталей. Специалист способен обнаружить ошибку, но не иметь права принять обязательство перед клиентом. Назначение должно учитывать компетенцию и полномочия одновременно.
Для каждой роли определите заместителя. Если проверяющий недоступен, документ сохраняет статус ожидания. Истечение срока ответа не превращайте в разрешение: исполнитель должен знать, кому передать задержанный вопрос.
Полномочие остановить использование тоже закрепите явно. Участнику проверки нужен понятный способ сообщить об остановке тому, кто собирается отправить или опубликовать материал.
Шаг 3. Задайте критерии допуска и глубину проверки
Критерий допуска связывает предмет проверки, подтверждающий материал и решение. Вместо поручения «проверить внимательно» укажите, какое условие нужно подтвердить и где находится основание. Проверяющий отмечает результат сверки, а согласующий видит оставшиеся вопросы. Если обязательный критерий не выполнен, документ возвращают на исправление или передают вопрос сотруднику, который вправе изменить условия задачи.
Для рабочей карточки подойдёт такой чек-лист:
- Назначение: результат отвечает задаче и учитывает адресата.
- Полнота: обязательные условия и исключения присутствуют.
- Основания: ответственный подтвердил существенные утверждения по материалам задачи.
- Числа: назначенный сотрудник сверил значения и расчёты.
- Обещания: владелец условий подтвердил обязательства и ограничения.
- Передача: ответственный проверил содержание и канал отправки по правилам организации.
Рядом с пунктом укажите основание, проверяющего и статус. Условная запись: «Условия участия — утверждённая программа — владелец программы — подтверждено». Если программа не утверждена, статус не должен выглядеть как завершённая проверка.
Подтверждение должно быть доступно согласующему.
Эта статья не разбирает приёмы проверки ссылок и расчётов. Здесь задача руководителя — назначить исполнителя такой проверки и определить, какой результат тот передаст на согласование. Например, сверенную таблицу расхождений или ссылку на утверждённые условия.
Мнение. Выборочную проверку можно рассмотреть для повторяющихся задач с ограниченными последствиями и обратимым действием. Условие применимости — заранее заданные границы выборки и порядок расширения контроля после ошибки. Для существенных внешних обязательств рекомендуем согласование каждого результата.
Универсального процента выборки здесь нет. Организация определяет, какие результаты проверяют полностью, какие попадают в выборку и при каких отклонениях использование приостанавливают.
Не заменяйте основание решения оценкой уверенности в ответе. В карточке допуска нужно записать, что именно проверил сотрудник и на какие материалы он опирался.
Шаг 4. Проведите результат через маршрут согласования
Передавайте на согласование зафиксированную версию вместе с карточкой задачи, исходными материалами и критериями допуска. Проверяющий должен видеть, какой документ ему поручили сверить и куда записать замечания. Согласующий получает итог проверки и нерешённые вопросы. Решение относится к этой версии и указанному назначению; дальнейшие действия исполнителя должны соответствовать границам разрешения.
Рабочий маршрут можно организовать так:
- Исполнитель сохраняет версию и прикладывает материалы задачи.
- Проверяющий отмечает выполнение критериев и конкретные расхождения.
- Исполнитель исправляет замечания и возвращает затронутые части на проверку.
- Спорный вопрос передают профильному специалисту; связанное действие приостанавливают.
- Согласующий разрешает применение версии либо фиксирует остановку.
- Исполнитель использует допущенный материал по согласованному назначению.
Предусмотрите понятные решения: «допустить», «вернуть на исправление», «передать специалисту», «остановить использование». При возврате укажите расхождение и ожидаемое исправление. При передаче — вопрос, адресата и ответственного за продолжение работы. При остановке — условие, которое мешает использованию.
Возврат запускает повторную проверку.
Если исправление меняет обещание, число или вывод, проверьте связанные части документа. Замена формулировки может потребовать правки приложения и сопроводительного сообщения. Для технических исправлений организация может установить упрощённый порядок, обозначив его границы.
Не снимайте обязательный критерий только потому, что истёк срок задачи. Сначала зафиксируйте, какого подтверждения не хватает и кто может решить вопрос.
При срочной задаче можно рассмотреть более узкое назначение результата. Например, разрешить внутреннее обсуждение черновика без отправки клиенту, если участники вправе принять такое решение. Границы допуска запишите отдельно.
После содержательной правки или смены аудитории верните материал на согласование в затронутой части. Устное «всё нормально» без указания версии оставляет исполнителю слишком много догадок.
Условный пример: письмо клиенту с неподтверждённым обещанием
Вся ситуация в этом разделе — условный пример. Сотрудник готовит письмо о запуске обучения по утверждённому плану. Готовность участников ещё согласуется, но черновик ИИ уже подтверждает запуск. Владелец проекта проверяет статус подготовки, а уполномоченный отправитель решает, можно ли отправить письмо. Участники заранее знают, кто вправе подтвердить условие и кто разрешает действие.
В исходном плане записано: «Запуск после подтверждения готовности участников и материалов». В черновике появляется фраза: «Подтверждаем запуск обучения в согласованный срок». Она скрывает незавершённое согласование и создаёт у адресата другое ожидание.
Исполнитель сохраняет черновик и прикладывает план. Владелец проекта возвращает документ с замечанием: «Готовность участников ещё не подтверждена. Уберите подтверждение запуска; основание — условие утверждённого плана».
Исправленный фрагмент: «Срок запуска подтвердим после согласования готовности участников и материалов».
Проверяющий повторно сверяет обещание с планом. Затем уполномоченный отправитель разрешает использовать исправленную версию для письма указанному клиенту. В записи о допуске остаются замечание, основание, исправление и решение.
| Участник условного примера | Его действие | Граница полномочий |
|---|---|---|
| Исполнитель | Готовит и исправляет письмо | Не подтверждает готовность запуска самостоятельно |
| Владелец проекта | Сверяет обещание со статусом подготовки | Не подменяет решение уполномоченного отправителя |
| Уполномоченный отправитель | Разрешает отправку проверенной версии | Не считает непроверенные условия подтверждёнными |
Если клиент просит назвать конкретный срок, исполнитель передаёт вопрос владельцу проекта. Проверка формулировки не даёт сотруднику права назначить срок.
Допуск письма не распространяется на остальные материалы проекта.
Если после согласования исполнитель добавит обещание предоставить запись обучения, новое условие потребуется проверить у его владельца. Отправлять изменённое письмо по прежнему разрешению нельзя, если оно выходило за границы допуска.
Проблема этого примера — распределение полномочий. Стилистическая редактура могла улучшить письмо, сохранив неподтверждённое обещание. Чтобы разрешить отправку, понадобились проверка условия и отдельное решение уполномоченного сотрудника.
Почему присутствия человека недостаточно
Для содержательной проверки нужны доступ к основаниям, понятные критерии, время и право остановить использование. Если сотрудник видит только итоговый текст и кнопку согласования, отметка об одобрении не объясняет, что он проверил. Поэтому маршрут должен сохранять связь между критерием, основанием и решением. Без этой связи трудно восстановить причины допуска при обнаружении ошибки.
Признак формального контроля — одинаковое «согласовано» независимо от состава материалов. Для разбора такого случая полезно установить, где подтверждено спорное условие и кто его сверил. Если в записи есть только общая оценка текста, основание допуска остаётся неясным.
Назначение ответственного само по себе проблему не решает.
Мнение. Если проверяющему не хватает материалов, времени, компетенции или права вернуть результат, сначала измените условия работы. Эта рекомендация применима там, где от сотрудника ожидают содержательное решение, а не регистрацию чужого согласования.
Учитывайте нагрузку. Когда все документы направляют одному специалисту, проверка может превратиться в очередь. Разделите задачи по последствиям ошибки, назначьте заместителей и уточните, какие проверки действительно дают основания для решения.
Отдельный сбой — использование документа до завершения проверки. В маршруте должны быть понятны место хранения допущенной версии, ответственный за отправку и способ уведомления об остановке.
После допуска тоже возможны ошибки. Проверяющий может пропустить расхождение, а исходный документ — содержать неточность. Поэтому заранее определите, кто отзывает материал, сообщает адресатам об исправлении и возвращает задачу на проверку.
Правовые решения, обработку персональных данных и отраслевые требования организация согласует со своими специалистами. Статус допуска рабочего документа не заменяет такую работу и не гарантирует отсутствие ошибок.
Шаг 5. Зафиксируйте решение и обновляйте порядок проверки
Журнал проверки должен позволять восстановить, кто разрешил использовать конкретную версию и на каком основании. Для этого фиксируйте задачу, назначение, версию, участников, замечания и итоговый статус. Время просмотра и исправлений учитывайте отдельно от ожидания согласования. Ссылки на разрешённые материалы помогут сохранить основания решения без лишнего копирования чувствительных данных в журнал.
Минимальная запись может выглядеть так: «Письмо клиенту — исправленная версия — условия сверены владельцем проекта по утверждённому плану — отправка разрешена уполномоченным сотрудником». Это условный образец, а не запись из проекта AURMIND.
Статусы должны различать направление на проверку, завершение проверки и разрешение на использование. Иначе отчёт покажет движение документов, но не ответит, какие из них можно применять.
Факт. Доля направленных на проверку результатов и доля допущенных результатов — разные показатели по определению. Условный расчёт: из 10 подготовленных материалов 8 направили на проверку, а 5 допустили. При общем знаменателе 10 это соответственно 80% и 50%. Числа — вводные примера, не статистика AURMIND и не целевые значения.
В названии показателя указывайте, что именно считаете. Для доли исправлений обозначьте знаменатель: все проверенные результаты или только завершённые проверки. Сравнивайте группы с сопоставимыми задачами и одинаковыми правилами учёта.
Меньше исправлений не обязательно означает лучший результат.
Могли измениться задачи, требования или глубина контроля. Разбор обнаруженных ошибок помогает понять, нужно ли уточнить критерий, сменить проверяющего или добавить недостающее основание. Не делайте вывод по одной доле без просмотра причин.
Перед запуском маршрута сверьте готовность:
- Назначены проверяющий, согласующий и заместители.
- Участникам доступны основания и критерии.
- Определены остановка и передача спорного вопроса.
- Решение связано с версией и назначением.
- Пройден условный рабочий пример, включая возврат на исправление.
Практический результат такой подготовки — карточка одной задачи и проверенный на примере маршрут. В корпоративном обучении ИИ его можно использовать как задание команды: оценить решение с учётом времени проверки, исправлений и повторного согласования.
Для обсуждения обучения выберите подходящий способ связи и опишите рабочую задачу команды.
Рабочая схема
Эта схема показывает порядок действий в описанном примере. Проверки каждого этапа разобраны в статье.
Частые вопросы
Нужно ли хранить весь диалог с нейросетью вместе с решением?
Состав записи определите по потребности процесса и правилам организации. Для восстановления допуска нужны версия результата, основания и решение. Диалог сохраняйте, если он помогает объяснить существенные ограничения и его хранение разрешено. Копировать переписку целиком по привычке не нужно.
Что делать, если проверяющий и согласующий расходятся во мнении?
Запишите предмет разногласия и передайте вопрос ответственному за процесс. Отделите спор о содержании от решения о допустимости действия. Пока обязательный критерий не подтверждён, сохраняйте статус ожидания или остановки по принятому порядку. Изменение самого критерия требует решения сотрудника с соответствующими полномочиями.
Нужно ли получать новое согласование при повторном использовании прежнего текста?
Проверьте границы исходного допуска: назначение, адресата, условия и актуальность оснований. Повторное использование можно разрешить заранее для определённого сценария. Если условия изменились, верните материал на проверку в затронутой части.
Источники
- Artificial Intelligence Risk Management Framework (AI RMF 1.0) — NIST. Документ для сверки контекста добровольного управления рисками ИИ; конкретные положения в статье не цитируются.
- NIST AI RMF Playbook — NIST. Материал для дополнительного изучения; предложенный в статье маршрут согласования — редакционная рекомендация, а не цитата из документа.
