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

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

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

Зафиксировать границу пилота до итогового теста

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

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

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

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

Какие свидетельства положить на стол

В The ML Test Score готовность ML-системы рассматривается через проверки данных, модели, инфраструктуры и мониторинга. Для управленческого решения этот принцип можно превратить в следующую таблицу.

Область Свидетельство готовности Что блокирует расширение
Качество операции Сопоставление с исходным процессом на заранее определённой выборке Проверялись только удобные случаи
Исключения Результаты обработки нештатных и неизвестных входов Система скрывает ошибку правдоподобным ответом
Данные и полномочия Согласованный перечень источников, доступов и действий Неясно, какие данные покидают разрешённую среду
Эксплуатация Журнал заданий, уведомления, ответственный за сбой, проверенный откат Восстановление зависит от присутствия разработчика
Польза Измерение полного цикла с проверкой и исправлениями Учитывается только скорость генерации

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

Отличать проверку ответов от проверки рабочего процесса

В теневом режиме система получает входы, но её результат не меняет рабочие записи и не влияет на клиента. Это позволяет сравнить ответы и изучить ошибки. Однако такая проверка не показывает, сколько времени сотрудник потратит на новый интерфейс и как будет действовать при противоречии между моделью и документом.

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

Сложные документы нельзя незаметно исключать из знаменателя. Отдельно показывайте долю входов, подходящих под условия пилота, долю автоматически завершённых операций и долю возвратов человеку. Высокое качество на узком подмножестве может быть полезным результатом, если это подмножество честно описано.

Отсутствие инцидентов в небольшом тесте не доказывает отсутствие риска. Поэтому опасные сценарии проверяют целенаправленно, а остаточную неопределённость записывают в решение.

Пример итогового решения

Ниже — вымышленный пример формулировки, а не отчёт о проведённом проекте.

Разрешить ограниченную эксплуатацию извлечения реквизитов из документов согласованного формата. До записи в учётную систему результат подтверждает оператор. Остальные форматы остаются в ручном процессе. Массовую обработку не включать до проверки восстановления после сбоя. За эту проверку отвечает команда интеграции; решение о расширении принимает владелец документооборота. При расхождении сумм или потере связи с источником задание передаётся оператору без автоматической записи.

В этой записи понятны область разрешения, нерешённый вопрос, владелец и резервный порядок. Формулировка «пилот успешен, рекомендуем масштабирование» этих сведений не содержит.

Как не застрять в бесконечной доработке

Для продолжения пилота нужна проверяемая гипотеза. Например: «Ошибки связаны с двумя вариантами формы; после исправления проверим новые документы обоих вариантов». Вместе с гипотезой задают бюджет, срок и условие прекращения эксперимента.

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

Вопросы стоимости раскрыты отдельно в материале о сроках и бюджете AI-проекта, а устройство тестового набора — в руководстве по оценке AI-агентов. Итоговый протокол связывает эти результаты с одним решением и ответственным за него.