Многие команды используют фразу «проверяет человек» как успокаивающую формулу. Она звучит безопасно и ответственно, но часто означает, что никто не определил конкретную роль проверяющего.
Человек может утверждать действие, проверять выборку, разбирать исключения, проводить аудит после факта, обучать процесс через исправления или владеть бизнес-решением. Это разные паттерны. У них разные затраты, режимы отказа и требования к людям.
Эта статья даёт практическую модель выбора правильного паттерна.
Проверка человеком — это контроль, а не украшение. Если у проверяющего нет ясных полномочий, бюджета времени, чеклиста и правила остановки, процесс всё ещё фактически автоматизирован.
Начните с последствий
Не начинайте с модели. Начните с последствий неправильного вывода.
Задайте пять вопросов:
- Может ли это повлиять на клиента, сотрудника, поставщика или регулятора?
- Может ли это отправить, опубликовать, удалить, списать деньги, вернуть деньги или изменить запись?
- Может ли это раскрыть персональные, конфиденциальные, финансовые, юридические или медицинские данные?
- Будет ли неправильный ответ трудно заметить позже?
- Повредит ли ошибка доверию, даже если технически её можно откатить?
Чем больше ответов «да», тем конкретнее должна быть роль человека. Отталкиваться от последствий — не просто прагматизм: тот же риск-ориентированный подход лежит в основе фреймворка управления рисками ИИ NIST, а для систем высокого риска в ЕС действенный человеческий надзор — юридическое требование Регламента ЕС об ИИ.
Паттерн 1: человек утверждает каждое действие
Используйте это, когда действие внешнее, разрушительное, финансовое, юридическое, кадровое или видимое клиенту.
Примеры:
- отправка письма клиенту,
- публикация публичной статьи,
- возврат денег,
- удаление записей,
- изменение пункта договора,
- рекомендация по найму.
Модель готовит черновик или рекомендацию. Человек утверждает, редактирует или отклоняет. Финальное действие не происходит, пока утверждение не записано.
Хороший дизайн утверждения включает:
- понятный diff или предпросмотр,
- источники, которые были использованы,
- уверенность модели или флаги риска, если они есть,
- путь отклонения в один клик,
- обязательную причину переопределения в высокорисковых процессах,
- журнал аудита с проверяющим, временем и финальным действием.
Это самый дорогой паттерн, но для значимых действий он — правильный вариант по умолчанию.
Паттерн 2: человек проверяет исключения
Используйте это, когда большинство случаев рутинные, но часть неоднозначна или рискованна.
Примеры:
- тикеты поддержки, где упоминаются отмена, юридические угрозы, безопасность или биллинг,
- извлечение данных из счёта с низкой уверенностью или пропущенными полями,
- квалификация лидов, где неясны размер компании или намерение,
- классификация документов, когда подходят несколько категорий.
Процесс обрабатывает нормальные случаи и отправляет исключения в очередь.
Маршрутизация исключений требует конкретных правил. Одной «низкой уверенности» обычно слишком мало. Лучше работают такие триггеры:
- отсутствуют обязательные поля,
- извлечённые значения противоречат друг другу,
- язык не поддерживается,
- тип документа не распознан,
- тональность клиента выше порога риска,
- аккаунт уровня enterprise,
- действие пересечёт денежный порог или порог по данным,
- исходные данные устарели.
У очередей исключений должны быть владелец и SLA. Если никто не проверяет очередь каждый день, система не уменьшила работу, а спрятала её.
Паттерн 3: человек проверяет выборку
Используйте это, когда последствия невысокие, но важен дрейф качества.
Примеры:
- внутренние сводки,
- тегирование контента,
- извлечение пунктов действий из встреч,
- обогащение нечувствительных CRM-полей,
- предложенные ссылки на базу знаний.
Процесс работает автоматически. Человек проверяет выборку: например, 5 процентов выводов, 20 случайных случаев в неделю или каждый вывод после изменения новой версии промпта.
Выборка работает только тогда, когда исправления возвращаются в систему:
- фиксируйте, что было неправильно,
- классифицируйте тип ошибки,
- обновляйте промпт, retrieval, схему или правила инструментов,
- добавляйте примеры в evals,
- отслеживайте долю ошибок со временем.
Выборка — это система качества. Это не шлюз для запуска.
Паттерн 4: человек аудирует после факта
Используйте это, когда процесс низкорисковый, обратимый и высокообъёмный.
Примеры:
- внутреннее тегирование,
- поиск дублей,
- предложения для базы знаний только в виде черновика,
- маршрутизация затрат между моделями,
- форматирование, не видимое клиенту.
Процесс работает. Логи, дашборды и периодические аудиты обнаруживают проблемы.
Этот паттерн допустим только если:
- действия обратимы,
- у процесса есть аварийный выключатель,
- логи достаточно подробны, чтобы восстановить решения,
- цена пропущенной ошибки низкая,
- пользователи знают, как сообщить о плохом выводе.
Не используйте аудит после факта для видимых клиенту обязательств, чувствительных данных, платежей или регулируемых решений.
Паттерн 5: человек владеет решением
Используйте это, когда ИИ помогает анализировать, но не должен принимать решение.
Примеры:
- найм,
- кредитный скрининг или проверка соответствия критериям,
- юридическая стратегия,
- медицинский совет,
- серьёзность инцидента безопасности,
- выбор поставщика,
- крупные закупочные решения.
Модель может резюмировать доказательства, перечислить компромиссы, сгенерировать вопросы или сравнить варианты. Человек — владелец решения — подписывает финальное суждение.
Процесс должен явно это показывать:
- «ИИ-сгенерированный анализ, не решение.»
- «Владелец решения: имя или роль.»
- «Проверенные доказательства: источники.»
- «Известные ограничения.»
- «Финальное обоснование.»
Это предотвращает распространённый сбой: гладкая рекомендация модели становится решением по умолчанию.
Простая матрица утверждения
Используйте это как отправную точку:
| Последствие процесса | Паттерн человека по умолчанию |
|---|---|
| Внутреннее, обратимое, низкая видимость | Аудит после факта |
| Внутреннее, повторяемое, чувствительное к качеству | Проверка выборки |
| Неоднозначные случаи в рутинном потоке | Проверка исключений |
| Видимое клиенту или внешнее действие | Утверждать каждое действие |
| Разрушительное, финансовое, юридическое, кадровое, регулируемое | Человек владеет финальным решением |
Матрица — не закон. Это принуждающая рамка. Если выбираете более лёгкий паттерн, запишите почему.
Спроектируйте экран проверки
Хороший экран проверки снижает усталость проверяющего.
Показывайте:
- что предлагает система,
- какие доказательства она использовала,
- что изменится относительно текущего состояния,
- почему элемент попал на проверку,
- разрешённые действия,
- флаги риска,
- дедлайн, если он есть.
Избегайте:
- вывода полного промпта,
- требования читать сырые логи,
- скрытия исходных документов,
- только кнопок «утвердить» и «отклонить», когда нужен вариант «редактировать»,
- ситуации, где для проверки одного случая нужно открыть пять систем.
Если проверка медленная, люди будут обходить её. Если проверка непонятная, люди будут ставить штамп не глядя.
Определите правила остановки
Каждому процессу с человеком в контуре нужны правила остановки.
Примеры:
- Более 3 процентов выбранных выводов не проходят чеклист.
- Обнаружена утечка данных между клиентами.
- Более пяти высокорисковых исключений остаются непроверенными 24 часа.
- Обновление промпта или модели увеличивает долю отклонений на 50 процентов.
- Процесс создал внешнее действие, которое должно было требовать утверждения.
Правило остановки должно говорить, кто ставит процесс на паузу и что происходит дальше.
Частые ошибки
Человек подключён слишком поздно. Если проверяющий видит только финальный отполированный вывод, он может пропустить плохие исходные данные. При необходимости показывайте доказательства и промежуточное извлечение.
Слепое утверждение пакетов. Пакетное утверждение полезно, но только после того, как фильтры и выборка доказали однородность пакета.
Нет обучения проверяющих. Проверяющим нужны примеры хороших, плохих и пограничных случаев.
Нет обратной связи. Если исправления не улучшают промпты, retrieval, схемы или исходные данные, проверка становится постоянным ручным трудом.
Нет планирования мощности. 10 процентов исключений при 1000 случаях в день — это 100 человеческих задач. Это команда, а не примечание.
Вывод
Контроль человеком — не одна универсальная схема, а набор мер, выбранных по возможным последствиям.
Используйте:
- утверждение для действий с высокими последствиями,
- проверку исключений для неоднозначных случаев,
- выборку для дрейфа качества,
- аудит для низкорисковой обратимой работы,
- владение решением человеком для настоящих бизнес-решений.
Практический тест простой: если модель ошибается, кто замечает, кто может остановить процесс и что именно он делает? Если вы не можете ответить, процесс не готов.
