Пилот ИИ-агента: план проверки, бюджет и критерии приёмки

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

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

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

Демо, пилот, MVP и промышленный запуск решают разные задачи

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

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

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

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

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

Пример паспорта: черновики ответов для поддержки

Дальше идёт учебный пример, не описание моего клиента. Компания хочет уменьшить активное время обработки типовых обращений. Пилот не отправляет ответы клиентам самостоятельно.

200 и 20 здесь выбраны для иллюстрации. Это не универсальный минимальный объём и не доказательство безопасности редкого события. Размер выборки зависит от цены ошибки, частоты задач и требуемой уверенности.

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

План пилота ИИ-агента на 30 дней

Дни 1-7: зафиксировать процесс и правила проверки

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

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

Дни 8-14: собрать минимальный маршрут и проверить отказ

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

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

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

Дни 15-21: сравнить с ручным процессом

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

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

Дни 22-30: заморозить версию и принять решение

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

На финальную встречу принесите таблицу фактов, журнал ошибок и проект решения. Результат «нужно ещё понаблюдать» требует конкретного вопроса, срока и дополнительного объёма. Иначе короткая проверка превращается в бесконечную разработку.

Как ограничить бюджет проверки

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

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

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

Пример протокола приёмки: что показывать вместо «точности 92%»

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

В 16 возвратах условно десять случаев без достаточного источника и шесть неверных черновиков. Это разные причины, хотя обе увеличивают ручную нагрузку. По времени выигрыш равен 200 × (8 - 5,5) = 500 минут, или 8 часов 20 минут. Это высвобождение времени, не доказанная денежная экономия.

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

Когда доработать, остановить или расширить пилот

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

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

Расширение требует пакета передачи: версия решения, источники, права, тесты, показатели, ошибки, расходы, ответственные и порядок остановки. Организация управления рисками и повторных измерений отражена в NIST AI RMF Core. Здесь приведён практический шаблон, а не сертификация по этому документу.

Помогу выбрать границы первого пилота

Если задача пока звучит как «автоматизировать отдел», на бесплатной диагностике в Zoom за 40-60 минут предварительно разберём один процесс: что приходит на вход, кто использует результат и где нужна проверка человеком.

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

Записаться на бесплатную диагностику