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