В марте 2026 года NIST выпустил обзор проблем мониторинга внедрённых ИИ-систем: ухудшение качества трудно заметить, разрозненные журналы – свести вместе, а людей для контроля не всегда хватает. Для меня это повод задать вопрос «как оценить пилот ИИ» ещё до запуска. Если после приёмки некому поймать ошибку и восстановить ход обработки, передавать процесс в работу рано. Эти трудности разобраны в обзоре NIST.
- Пилот рабочего процесса можно принять, когда владелец подтвердил результат сопоставимыми замерами, а команда умеет работать по новому регламенту.
- До старта нужно договориться о границах процесса, критериях качества, способе подсчёта показателей и условиях остановки.
- В замер входят проверки, исправления, повторная обработка и ожидание человека. По одному времени ответа модели об эффекте для бизнеса судить нельзя.
- Критичные ошибки проверяют отдельно: средняя скорость и общая доля правильных ответов могут их скрыть.
- Исследовательский эксперимент может закончиться проверенной гипотезой. Чтобы передать процесс в эксплуатацию, нужны ещё роли, доступы и понятный команде порядок разбора исключений.
Как оценить пилот ИИ: что согласовать до старта
Я считаю пилот принятым, когда руководитель процесса может объяснить, что изменилось, подкрепить вывод замерами и поручить команде работать по новым правилам. Удачный ответ на демонстрации этого не доказывает.
Но я бы не требовал такого от любого эксперимента. Если задача – выяснить, способна ли модель извлекать сведения из документов, достаточно проверить гипотезу в оговорённых условиях. Полный эксплуатационный регламент здесь преждевременен. И всё же положительный результат эксперимента ещё не даёт оснований переключать на него входящий поток.
Для рабочего пилота я бы заранее заполнил короткую карточку:
- Граница: какое событие запускает процесс и какой результат завершает его.
- Владелец: кто принимает результат и вправе изменить порядок работы.
- Качество: что считаем правильной обработкой, исправимой ошибкой и недопустимым событием.
- Замер: откуда берём сведения, кто их проверяет и какие случаи включаем в расчёт.
- Решение: при каких условиях принимаем, дорабатываем или останавливаем пилот.
Например, «ИИ разбирает заявки» – постановка, с которой трудно что-либо принять. Для условного пилота границу можно описать так: обращение поступило в общую очередь, сведения перенесены в карточку, назначен ответственный, карточка принята им в работу. Продажу и последующее обслуживание в этот замер не включаем.
Пороги нужны до того, как появятся результаты. Иначе слишком легко выбрать показатель, по которому новая схема выглядит выигрышно. В рекомендациях AI Cloud по оценке пилота критерии качества, затрат и безопасности тоже предлагают записывать заранее. Универсальный порог я бы оттуда не брал: допустимую ошибку определяет ваш процесс.
Как сравнить процесс до и после: таблица приёмки
Возьмём условный пример обработки входящих заявок, а не кейс клиента CRT. ИИ извлекает сведения из обращения, предлагает категорию и ответственного. Сотрудник проверяет спорные случаи. Числовых результатов в таблице нет: здесь нужны ваши замеры.
Сначала соберите сопоставимые группы заявок. В обеих должны быть обычные обращения, неполные сведения, вложения и неоднозначные формулировки – в пропорциях, близких к рабочему потоку. Если до внедрения считали всё подряд, а после оставили только удобные письма, сравнение придётся переделать.
| Что принимаем | Как измерять до и после | Как сформулировать условие приёмки |
|---|---|---|
| Завершённую обработку | От поступления заявки до принятия корректной карточки ответственным; возвраты входят в тот же путь | Согласованный показатель полного времени достигнут, незавершённые заявки учтены отдельно |
| Качество карточки | Проверять обязательные поля, категорию и адресата по одинаковым правилам | Выполнен порог качества; критичные ошибки разобраны отдельно |
| Трудозатраты людей | Учитывать чтение, проверку, исправление, повторный ввод и разбор исключений | Суммарная нагрузка укладывается в согласованный предел |
| Возвраты | Отмечать карточки, которые пришлось вернуть после первоначального принятия | Доля возвратов не превышает установленный предел; причины известны |
| Сложные случаи | Проверять, куда попала заявка без нужных сведений или с противоречиями | Заявка передана назначенному сотруднику, видна в очереди и не потеряна |
| Затраты на обработку | Считать эксплуатационные расходы и труд людей относительно числа принятых результатов | Выполнено согласованное экономическое условие с учётом исправлений |
| Готовность к сбою | Провести учебную остановку автоматизации и обработать оставшуюся очередь вручную | Команда восстановила обработку без потери и дублирования заявок |
В рабочую версию таблицы добавьте столбцы «До», «После», «Порог», «Источник сведений» и «Кто подтверждает». Пока конкретного порога нет, перед вами заготовка для обсуждения. Подписывать её как акт приёмки рано.
Я бы внимательнее всего смотрел на трудозатраты людей. Разделяйте время прохождения заявки и активную работу сотрудников. Заявка может долго ждать в очереди, хотя человек занят ею недолго. Бывает и наоборот: очередь сократилась, но сотрудники без конца перепроверяют карточки. Руководителю нужно видеть эту разницу.
Проверки без исправлений тоже отнимают время (даже когда сотрудник лишь подтвердил, что всё верно). Вычёркивать их из расчёта как «технические действия» нельзя. Считайте и повторные обращения к модели, обслуживание интеграции, ручную обработку отказов. Разовые расходы на запуск показывайте отдельно от регулярных, иначе итог сравнения будет зависеть от выбранного отчётного периода.
Если старых замеров нет, сначала измерьте текущий порядок работы. У «Мозаики» есть точное правило: не восстанавливать отсутствующие сведения о дефектах по памяти. Я с ним согласен. Пустая ячейка честнее нуля, который никто не измерял.
Запишите также, что изменилось в условиях работы: состав команды, нагрузка, правила маршрутизации. Если вместе с ИИ вы поменяли расписание сотрудников, весь выигрыш приписывать модели нельзя. Незакрытые заявки вынесите в отдельный список с возрастом и причиной задержки. Убрать их из расчёта – самый короткий путь к красивому времени обработки.
Какие ошибки нельзя спрятать за средней скоростью
В условном процессе неверно выбранная категория и потерянная заявка требуют разной реакции. Первую можно исправить до передачи ответственному. Вторую могут вообще не заметить. Я бы заранее выделил события, при которых автоматическую обработку приостанавливают, даже если остальные показатели радуют.
Для нашего примера это могут быть потеря обращения, передача карточки сотруднику без нужных прав или закрытие заявки без результата. Перечень согласует владелец процесса. Ошибки, которые поймал проверяющий, отмечайте отдельно от тех, что прошли дальше. Число дефектов может совпадать, а вот контроль в этих случаях сработал по-разному.
Здесь и обнаруживается тупик, описанный в обзоре NIST: разрозненные журналы распределённой инфраструктуры мешают контролю, а деградацию – ухудшение работы системы – трудно обнаружить. Авторы обобщают проблемы практиков и литературы, а не рассказывают о провале конкретного клиента. Но для руководителя вывод вполне прикладной: записи могут быть, а разобраться по ним в ошибке всё равно не получится.
На приёмке я предлагаю выбрать спорную заявку и восстановить её путь: что поступило на вход, какую версию настройки использовали, что предложил ИИ, что исправил человек, куда ушла карточка. Если цепочку приходится собирать по личным перепискам, контроль пока не готов.
Поручение «смотреть внимательнее» этот пробел не закроет. Сам NIST отмечает, как трудно масштабировать ручной мониторинг. Поэтому на пилоте нужно проверить, хватает ли назначенным людям времени на контроль при рабочей нагрузке. На демонстрации они ведь могут отложить остальные дела.
Кто отвечает за результат, когда ИИ ошибается
Фраза «решение остаётся за человеком» имеет смысл, только если у человека есть полномочия. Проверяющему нужны доступ к исходному обращению, возможность исправить результат, отклонить его и передать сложный случай дальше. И рабочее время на эти действия.
Я разделяю ответственность так: владелец процесса принимает бизнес-результат, сотрудник выполняет предусмотренную проверку, технический ответственный устраняет сбой. За конкретной ролью нужно закрепить и право остановить автоматизацию. Нет смысла спрашивать с оператора за механизм, к которому у него нет доступа.
На приёмке я бы попросил команду пройти сценарий отказа:
- Найти заявку, которую нельзя обработать по обычному правилу.
- Передать её человеку вместе с исходными сведениями и причиной передачи.
- Приостановить автоматические действия в предусмотренных границах.
- Продолжить работу вручную и затем сверить очередь перед возобновлением.
Стоит проверить и ситуацию, когда назначенного сотрудника нет. Кто подхватит исключение, если он не на смене? Где руководитель увидит зависшую заявку? Ответ «напишем разработчику» меня бы не устроил: работа не должна зависеть от того, оказался ли он сейчас на связи.
Такой подход согласуется с NIST AI RMF Core: документ предлагает определять человеческий контроль, документировать измерения и проверять системы в условиях, близких к эксплуатации. На него можно опереться при организации работы. Готового акта приёмки для вашего проекта он не заменит.
Что передать команде вместе с работающим процессом
Для меня регламент готов, когда сотрудник может по нему обработать обычную заявку и понять, куда направить необычную. Перечня возможностей инструмента для этого мало.
В комплект передачи я включил бы границы применения, роли и замещение, доступы, правила проверки результата, порядок исправлений и остановки. Рядом нужны примеры исключений, источник показателей и имя того, кто будет регулярно их просматривать. Для обновлений стоит записать, кто разрешает менять настройку и что после этого перепроверяют.
Проверять, чему научились сотрудники, лучше за работой: человек проходит сценарий без подсказок автора решения. Если он знает, куда нажать, но не может объяснить, когда нельзя принимать ответ ИИ, обучение ещё не закончено.
Мы в CRT описываем внедрение ИИ в компании через пилот одного процесса: замер до, перестройка, обучение людей и замер после. Метрику и способ измерения согласуем до старта; передаём работающий процесс и регламент. Таков публичный состав AI FLOW. Таблица выше помогает обсудить приёмку на общем примере, внутреннюю методику CRT она не описывает.
Какое решение принять по итогам пилота
Я бы записывал итоговое решение вместе с доказательствами и границами: где после пилота разрешено применять новую схему.
Принять – если выполнены согласованные условия, качество подтверждено, исключения управляемы, а команда готова работать. Разрешение относится к проверенному процессу и нагрузке. Переносить его на другие отделы и типы обращений без проверки нельзя.
Доработать – если понятно, почему конкретный критерий не выполнен. В решении запишите, что меняем, кто отвечает и в каких условиях проверяем повторно. Формулировка «продолжим улучшать» позволяет пилоту длиться бесконечно.
Остановить – если обнаружен недопустимый риск либо согласованное условие эффекта не выполнено и обоснованного пути исправления нет. Нехватка сведений тоже не повод подписывать успех: сначала нужно закрыть пробел в измерении. Отрицательный результат полезен, если помогает решить, куда больше не тратить силы.
Вопросы и ответы
Можно ли принять пилот ИИ, если данных пока мало?
Недостаточная выборка ограничивает выводы о пилоте ИИ, особенно о редких ошибках. Можно подтвердить работоспособность на проверенных случаях, но нельзя выдавать это за готовность всего процесса. Следующий этап должен иметь ограниченный охват, правила контроля и заранее определённые условия завершения замера.
Что делать, если после внедрения ИИ стало больше ручных проверок?
Включить время проверок в общие трудозатраты и разобраться в причине роста. Дополнительный контроль может быть временным условием пилота или постоянной частью нового процесса. Эффект оценивают с фактической нагрузкой; предполагаемое сокращение проверок нужно подтверждать отдельно.
Кто должен подписывать результаты пилота ИИ?
Бизнес-результат подтверждает владелец процесса, имеющий полномочия принять новый порядок работы. Техническую готовность и выполнение требований к доступам подтверждают соответствующие ответственные. Подпись подрядчика не заменяет проверки со стороны команды, которая будет эксплуатировать процесс.
Что делать
Я бы начал с таблицы приёмки и заполнил её вместе с владельцем процесса и сотрудником, которому предстоит разбирать исключения. Если по строке невозможно назвать источник сведений или ответственного, разобраться с этим нужно до запуска. В AI FLOW мы начинаем с исследования процесса и согласования замера, чтобы решение о продолжении можно было обосновать проверяемым результатом.
Обсудить задачу
