Четырёх недель достаточно, чтобы проверить узкую ИИ-задачу на реальном процессе, но недостаточно, чтобы «внедрить ИИ в компанию». Поэтому пилот ограничивают одним входом, одним типом результата, небольшой группой пользователей и заранее записанным решением, которое предстоит принять.
Цель пилота — не показать эффектную демонстрацию. Он должен ответить на четыре вопроса: достигает ли результат нужного качества, сокращает ли работу с учётом проверки, проходит ли по данным и доступам, выдерживает ли полная стоимость ожидаемый объём. Если ответ нельзя получить за четыре недели, задача выбрана слишком широко или до старта не подготовлены исходные данные.
До старта: карточка гипотезы#
Заполните карточку до первого запроса к сервису:
| Поле | Что записать |
|---|---|
| задача | одно повторяемое действие с понятным результатом |
| пользователи | конкретная группа и число участников |
| вход | формат, источник, категории данных |
| результат | что считается принятым |
| текущий процесс | шаги, время, качество, объём |
| ожидаемое изменение | показатель и направление, без гарантии |
| критические ошибки | что немедленно останавливает пилот |
| проверка | кто читает или подтверждает результат |
| срок | даты начала, контрольных точек и решения |
| владелец | один человек, отвечающий за итог |
Хорошие кандидаты имеют достаточную частоту, записанные правила и дешёвую проверку: черновик по утверждённым материалам, классификация входящих, выжимка из встречи, поиск по документации. Не берите для первого пилота решение по деньгам, правам людей, безопасности или уникальные случаи, где итог невозможно быстро проверить.
Сценарий не должен зависеть от функции, которой пока нет. Если нужно сначала оцифровать архив, договориться о процессе и создать интеграцию, это отдельная подготовительная работа. Четыре недели начнутся после того, как тестовый вход доступен.
Зафиксируйте базу «до»#
Измерьте текущий процесс на фактических операциях. Память сотрудника «обычно минут двадцать» не годится. В журнале фиксируйте дату, тип, время активной работы, ожидание, переделку, результат и исключения. Возьмите период, в котором представлены обычные и сложные случаи.
Базовые метрики:
- число операций;
- медиана и распределение времени на одну;
- доля результатов, принятых без переделки;
- число ошибок по типам;
- число возвратов и повторной работы;
- время специалистов, участвующих в проверке;
- внешние затраты;
- пропускная способность;
- случаи, которые процесс не смог обработать.
Не смешивайте ожидание и активную работу. ИИ может ускорить подготовку черновика, не меняя общий срок из-за согласования. Оба показателя полезны, но отвечают на разные вопросы.
Зафиксируйте версии инструкций и входных данных. Если посередине пилота команда одновременно поменяет процесс, эффект нельзя будет связать с инструментом.
Запишите пороги решения заранее#
Порог — внутреннее условие, а не универсальная рыночная норма. Компания определяет его по цене ошибки и альтернативным затратам. Нужны четыре группы:
- качество: минимальная доля принятых результатов и максимальная доля смысловых ошибок;
- безопасность: нулевая терпимость к названным критическим нарушениям или другой утверждённый порядок;
- трудозатраты: допустимое время подготовки плюс проверки;
- экономика: предел стоимости принятого результата при рабочем объёме.
Добавьте условия устойчивости: результат получают не только автор настройки, но и обычные пользователи; качество не пропадает на сложных примерах; ошибку можно воспроизвести; при недоступности работает резервный процесс.
Решение формулируют заранее: масштабировать при выполнении всех обязательных порогов; доработать один ограниченный цикл при понятной устранимой причине; закрыть, если нарушена граница данных, качество нестабильно или проверка съедает выигрыш. Не двигайте порог после результатов.
Неделя 1. Контур, данные и контрольный набор#
Результат первой недели — воспроизводимый тестовый стенд, а не готовая автоматизация.
День 1–2: описать процесс и доступы#
Подтвердите карточку гипотезы с пользователями. Нарисуйте путь данных. Разделите разрешённое, обезличиваемое и запрещённое. Создайте отдельные тестовые аккаунты и минимальные права. Проверьте официальные условия выбранного сервиса для фактического тарифа на дату 14 августа 2026 года: использование запросов, хранение, удаление, подрядчики и экспорт.
День 2–3: собрать примеры#
Возьмите реальные обезличенные случаи. Набор должен включать типовые, сложные, пограничные и те, где правильное поведение — отказ или передача. Не отбирайте только аккуратные входы, на которых демонстрация неизбежно успешна.
День 3–4: создать эталоны#
Специалисты вручную отмечают ожидаемый результат, допустимые варианты, источники и недопустимые элементы. Для текста нужна рубрика точности, полноты и объёма правок; для классификации — правильный класс и маршрут; для поиска — допустимый источник.
День 5: первый прогон#
Все примеры проходят одной версией настройки. Сохраните вход, ответ, время, затраты и оценку. Не исправляйте инструкцию между примерами: иначе набор тестирует разные системы.
Контрольная точка недели: данные допустимы, тест воспроизводится, критические ошибки видны, базовая версия зафиксирована. Если нет, пилот не переходит к реальному потоку.
Неделя 2. Настройка и теневой режим#
Цель — улучшить решение на учебной части и проверить на отложенной, не показывая результат внешнему получателю.
Разделите набор до настройки. На учебной части меняйте структуру входа, инструкцию, источники и обработку ошибок. После ограниченного числа итераций прогоните отложенную часть один раз. Если продолжать править под каждый тест, получится запоминание набора, а не устойчивое качество.
В теневом режиме система обрабатывает реальные операции параллельно старому процессу. Пользователь или клиент получает обычный подтверждённый результат. Команда сравнивает предложение ИИ с фактическим итогом и записывает причины расхождений:
- не хватило данных;
- неверный или устаревший источник;
- потеряно условие;
- добавлена выдуманная деталь;
- нарушен формат;
- случай вне границ;
- эталон был неоднозначным;
- пользователь применил другой процесс.
Не лечите все ошибки удлинением запроса. Исправляйте соответствующий слой: данные, источник, маршрутизацию, интерфейс или правило отказа.
Контрольная точка недели: отложенный набор проходит обязательные условия, критические случаи корректно останавливаются, команда понимает основные причины ошибок, версия заморожена для рабочего прогона.
Неделя 3. Ограниченный рабочий запуск#
Подключите небольшую группу будущих пользователей. На безопасном первом пилоте ИИ предлагает результат, а человек подтверждает его до использования. Не давайте системе новых полномочий только ради проверки скорости.
Перед стартом проведите короткое практическое обучение:
- какой сценарий разрешён;
- какие данные нельзя передавать;
- как проверить результат;
- когда отклонить и сделать вручную;
- как отметить причину правки;
- куда сообщить об инциденте;
- как перейти на резервный процесс.
В рабочем журнале на каждую операцию:
| Поле | Зачем |
|---|---|
| пользователь и версия | увидеть зависимость от навыка и конфигурации |
| тип входа | разделить простые и сложные случаи |
| время до черновика | оценить техническую задержку |
| время проверки | посчитать реальную работу человека |
| принят/исправлен/отклонён | определить полезный результат |
| тип правки | найти системную причину |
| критическая ошибка | запустить остановку |
| итоговое время | сравнить с базой |
Владелец ежедневно смотрит критические события, но не меняет систему посреди недели без необходимости безопасности. Если изменение обязательно, зафиксируйте новую версию и не объединяйте её показатели с прошлой.
Контрольная точка недели: процесс работает у нескольких обычных пользователей, проверка измерена, резервный маршрут испытан, нет неразобранных критических инцидентов.
Неделя 4. Повторный тест и решение#
Заморозьте конфигурацию и повторите полный контрольный набор. Сравните не только средний балл, но и каждый обязательный пример с первой неделей. Отдельно прогоните случаи, добавленные из реального потока, но не заменяйте ими исходные — иначе регрессия останется незаметной.
Соберите экономику:
- разовые часы обследования, настройки и интеграции;
- доступ и переменная обработка;
- время обучения;
- время проверки и исправлений;
- поддержка и разбор ошибок;
- стоимость резервного процесса;
- число принятых результатов.
Методика полного бюджета есть в статье о стоимости внедрения ИИ. Для решения сравните фактическую стоимость принятого результата с записанным порогом, а не только с ценой старого процесса.
Проведите разбор с владельцем процесса, пользователями, ИТ и ответственными за данные. Итоговый документ содержит: границы теста, версии, исходную базу, результаты контрольного и рабочего прогона, ошибки, затраты, нерешённые риски и одно решение.
Три допустимых решения#
Масштабировать#
Все обязательные пороги выполнены, критические ошибки отсутствуют по принятому правилу, результат устойчив у разных пользователей, стоимость приемлема, владельцы эксплуатации назначены. Масштабирование всё равно идёт ступенями: новая группа, затем новый объём, а новая тема проходит отдельный тест.
Доработать#
Причина провала локальна и проверяема: конкретный документ, один класс входа, интерфейс подтверждения. Назначьте одно изменение, срок и повторный набор. «Нужно ещё улучшить модель» без диагноза — не план доработки.
Закрыть#
Задача не проходит по данным, проверка дороже ручной работы, качество нестабильно, процесс слишком редкий или нет владельца знаний. Закрытие — полезный результат пилота: компания купила проверку гипотезы ограниченной ценой и не строит дорогую систему на слабом основании.
Не переименовывайте провал в «исследовательский успех», если первоначальное решение не принято. Сохраните выводы и контрольный набор, чтобы вернуться при изменении процесса или технологии.
Что нельзя менять в середине пилота#
Не добавляйте новые отделы, темы и интеграции. Не переходите на другой сервис без отдельной версии сравнения. Не меняйте критерий принятого результата. Не исключайте сложные примеры как «нехарактерные», если они встречаются в рабочем потоке. Не просите заинтересованного автора настройки быть единственным оценщиком.
Можно и нужно остановить использование при критическом риске. Безопасность важнее чистоты эксперимента. После остановки зафиксируйте событие, отключите контур, сохраните допустимые материалы для разбора и решите, возможен ли новый ограниченный запуск.
Финальный чек-лист#
- одна задача и одна группа пользователей;
- измерен текущий процесс;
- записаны пороги и стоп-условия;
- проверены данные, доступы и условия сервиса;
- тест разделён на учебную и отложенную части;
- есть примеры отказа и эскалации;
- неделя 2 проходит в тени;
- рабочий запуск требует человеческого подтверждения;
- время проверки считается отдельно;
- версии не смешиваются;
- неделя 4 повторяет исходный набор;
- итог — одно из трёх явных решений.
Четыре недели дисциплинируют проект: не позволяют бесконечно настраивать демонстрацию и одновременно не требуют преждевременного большого договора. Ценность срока не в магическом числе, а в четырёх последовательных результатах — измеренная база, воспроизводимый тест, проверенный рабочий поток и решение, принятое по правилам, которые существовали до результатов.
Артефакты, которые остаются после пилота#
Независимо от решения сохраните карточку гипотезы, обезличенный контрольный набор, рубрику оценки, журнал версий, карту данных, схему процесса, бюджет и итоговый разбор. Укажите владельцев и ограничения повторного использования. Не храните рабочие выгрузки дольше установленного срока только потому, что проект завершён.
Если пилот масштабируется, эти материалы становятся основой приёмки следующих релизов. Если закрывается, они не дают повторить тот же эксперимент под новым названием без учёта причин. Если откладывается, обновите внешние условия и источники перед новым запуском, а не считайте старый результат автоматически актуальным.
Проведите короткое ретро отдельно от презентации руководству. Пользователи называют места, где инструмент добавил скрытую работу; проверяющие — повторяющиеся ошибки; ИТ — нестабильные звенья; владелец данных — нарушения и исключения. В итог входят наблюдения, подтверждённые журналом, и вопросы, на которые пилот не отвечал. Такая честная граница делает следующий шаг управляемым.