Принимайте пилот по завершённой работе, а не по эффектной демонстрации. Зафиксируйте один процесс, сопоставьте его с ручным способом, посчитайте принятые результаты и все затраты, проверьте остановку при сбое. Затем попросите сотрудника повторить сценарий без автора и решите: расширять, доработать или остановить.
Перед проверкой: что именно вы принимаете
Эта инструкция относится к моменту после ограниченного пилота и до расширения на новые отделы, клиентов или бюджеты. Если вы ещё выбираете первую задачу, начните с учебного пилота на одной операции. Если агент пока только подключается к сервисам, сначала проверьте его на тестовых входах и правах.
Ниже не универсальная форма юридического акта. Договор, условия оплаты и ответственность согласуются отдельно. Это рабочий лист для решения собственника: что произошло в процессе, сколько усилий стоило и кто сможет им управлять завтра.
1. Назовите границу результата
Напишите одну фразу: «Пилот обрабатывает какие обращения, до какого состояния и без каких действий». Например: «По входящим B2B-запросам из тестовой формы готовит черновик квалификации в тестовой CRM, но не пишет клиенту и не меняет цены». Приёмка касается именно этой работы, а не обещания «автоматизировать продажи».
Ожидание: есть владелец процесса, описание входа и критерий «принято». Источник: согласованное задание и карточка результата в целевой системе. Если нет: не расширяйте пилот, сначала определите единицу работы.
2. Сравните с тем же процессом без ИИ
Возьмите сопоставимые типы задач и одинаковую границу работы. Если раньше сотрудник находил обращение, уточнял данные и заносил его в CRM, нельзя сравнивать всё это только со скоростью генерации текста агентом. Запишите период, число входов, сложность выборки, ручное время и долю результатов, которые действительно принимались. Когда старого замера нет, честно укажите «исходная точка неизвестна» и проведите её на следующем наборе.
Ожидание: сравнение одинакового выхода при понятном качестве. Источник: журнал задач и замер сотрудников за зафиксированный период. Если нет: фразу «стало быстрее» пока не используйте в решении.
3. Посчитайте принятые результаты, а не ответы модели
Для каждого входа поставьте один статус: принят, требует исправления, отклонён или исход неизвестен. У принятого результата укажите, где его увидел проверяющий: карточка CRM, документ, очередь или публичная страница. Если сервис сообщил «запрос принят», но конечный объект ещё не проверен, это не принятый результат. В разборе технической приёмки для CMS Magazine отдельно показано, почему зелёный статус может скрывать проверку не того объекта.
Ожидание: знаменатель всех входов и список принятых, отклонённых, неизвестных. Источник: реестр входов плюс чтение конкретных объектов в конечной системе. Если нет: качество и цену результата считать рано.
4. Измерьте всю работу людей
Засеките не только время ответа агента. Включите подготовку данных, проверку, исправления, уточнения у коллег и разбор сбоев. Один красивый прогон не показывает трудозатраты на поток. Полезно вести строку на каждый вход: время человека, статус и причину возврата. Не переносите клиентские контакты в открытую таблицу для разбора.
Ожидание: общее человеческое время на принятый объём и сопоставимый ручной замер. Источник: рабочий журнал пилота. Если нет: экономия времени остаётся гипотезой.
5. Рассчитайте полную стоимость принятой работы
Сложите труд людей, оплату моделей и сервисов, поддержку и расходы на интеграцию за выбранный период. Разовые работы и постоянные расходы показывайте отдельно, чтобы не маскировать цену следующего месяца. Затем разделите расходы периода на число принятых результатов, а не на число вызовов модели. При нуле принятых результатов стоимость одного принятого результата не определена — это не «ноль рублей».
Ожидание: формула, период и состав расходов видны. Источник: табель времени, счета, договорённость о сопровождении и реестр принятых задач. Если нет: не называйте проект окупившимся.
6. Проверьте границу риска и способ остановки
Назовите действия с последствиями: отправка клиенту, изменение бюджета, платежи, удаление или массовая запись. Для них покажите права агента, момент проверки человеком и кнопку или инструкцию остановки. Проверку сбоя проводите на тестовых объектах: что происходит, когда результат внешней операции неизвестен? Автоматический повтор без выяснения исхода может создать дубль. OWASP рекомендует ограничивать функции и права агента и оставлять контроль человека для значимых действий; входные тексты могут содержать попытки изменить поведение модели.
Ожидание: рискованное действие не происходит без установленного контроля; неизвестный исход виден. Источник: тестовые роли, журнал, инструкция остановки. Если нет: оставьте пилот в режиме черновика.
7. Дайте сотруднику повторить сценарий без автора
Пусть сотрудник компании, который не собирал пилот, выполнит обычную задачу по инструкции в корпоративном тестовом аккаунте. Он должен знать, где увидеть результат, кому передать исключение, как остановить следующие действия и кто оплачивает сервисы. Если всё это может сделать только автор решения, перед вами может быть полезная услуга с сопровождением — но не самостоятельная система. Такой формат тоже допустим, если зависимость и цена названы прямо.
Ожидание: повторяемый сценарий, владелец эксплуатации и решение «расширить / доработать / остановить» с датой следующей проверки. Источник: наблюдаемый прогон сотрудника и переданная инструкция. Если нет: масштабирование преждевременно. Подход с документированной оценкой, мониторингом и возможностью вмешательства согласуется с добровольной рамкой управления рисками ИИ NIST; она не заменяет договор или отраслевые требования.
Шаблон задания на приёмку ИИ-пилота
Скопируйте рабочий лист в задачу или скачайте текстовый шаблон. Для каждого пункта заполните четыре поля. «Нет данных» — допустимое наблюдение, но не основание отметить пункт принятым.
| Проверка | Ожидание | Наблюдение | Источник | Решение |
|---|---|---|---|---|
| 1. Граница | Один процесс и критерий принятия | Заполнить | Задание, объект | Да / исправить |
| 2. Сравнение | Тот же выход без ИИ | Заполнить | Журнал, замер | Да / неизвестно |
| 3. Качество | Все входы и принятые результаты | Заполнить | Реестр, целевая система | Да / исправить |
| 4. Люди | Всё время подготовки и проверки | Заполнить | Табель пилота | Да / измерить |
| 5. Деньги | Полные расходы за период | Заполнить | Счета, табель | Да / измерить |
| 6. Риск | Остановка и неизвестный исход | Заполнить | Тест, роли, журнал | Да / ограничить |
| 7. Передача | Повтор сотрудником без автора | Заполнить | Прогон, инструкция | Да / доработать |
Процесс: [одна операция и граница пилота] Период и версия системы: [даты, версия, тестовый/рабочий контур] Владелец приёмки: [роль] Единица принятого результата: [что проверяем и где] Ручная база сравнения: [источник, период, качество, время] Ограничения: [что агенту запрещено без человека] Для каждого из 7 пунктов заполните: ожидание / наблюдение / источник доказательства / решение. 1. Граница результата: [...] 2. Сопоставимая ручная работа: [...] 3. Все входы и принятые результаты: [...] 4. Полное время команды: [...] 5. Все расходы и стоимость принятого результата: [...] 6. Сбой, неизвестный исход и остановка: [...] 7. Повтор сотрудником и владелец эксплуатации: [...] Итог: расширить / доработать / остановить. Что ещё неизвестно: [...] Кто проверит и когда: [...] Не включайте в общий ИИ-чат персональные данные клиентов, пароли или секреты.
Почему быстрый ответ ещё не означает выгоду: учебный расчёт
Ниже намеренно вымышленные числа для арифметики, не результат клиента и не прогноз. Компания проверяет 20 однотипных задач. Вручную на каждую уходит 12 минут: всего 240 минут, или 4 часа. При условной стоимости часа сотрудника 900 ₽ это 3 600 ₽.
С агентом подготовка, проверка и исправления заняли 220 минут человеческой работы: 3 300 ₽ при той же ставке. Подписка и вызовы за период стоили ещё 2 000 ₽; всего 5 300 ₽. Все 20 результатов приняли только после человеческой проверки. Получается 265 ₽ на принятый результат против 180 ₽ вручную. Сэкономленные 20 минут не окупили платный сервис в этом учебном примере.
Это не приговор пилоту: у компании могут быть другие важные выгоды — качество, скорость ответа клиенту, доступность процесса в пиковые часы. Но их тоже надо измерить отдельно, а не предположить. Если четыре результата требуют переделки, время этой переделки уже должно входить в 220 минут, иначе расчёт приукрасит итог.
Частые вопросы
Сколько тестов достаточно для приёмки ИИ-пилота?
Универсального числа нет. Оно зависит от цены ошибки и разнообразия входов. Согласуйте критические сценарии до показа, учитывайте все обработанные входы и отдельно фиксируйте исключения. Для пилота с правом отправлять сообщения или менять деньги одной удачной демонстрации недостаточно; ограничения и путь остановки важнее красивого среднего результата.
Можно ли принимать пилот, если часть данных неизвестна?
Можно принять ограниченную часть: например, режим подготовки черновиков. Неизвестный итог внешней записи, не измеренное время команды или отсутствие стоимости сопровождения нельзя превращать в «полностью готово». Запишите, что принято сейчас, что остаётся не проверенным, кто и когда закрывает пробел. Решение о расширении оставьте отдельным.
Нужно ли собственнику лично проверять каждую запись?
Нет. Подрядчик и владелец процесса готовят реестр и доказательства; собственник заранее выбирает значимые критерии и смотрит выборку вместе с исключениями. Для массовых действий важны полный знаменатель и правила обработки неудач. Цель этого листа — управленческое решение, а не замена тестировщика или технического аудита.
Источники и границы материала
- NIST AI RMF Core — документирование тестирования, мониторинг после внедрения и управление рисками; проверено 30 сентября 2026 года. Рамка добровольная.
- OWASP LLM06:2025 Excessive Agency — риск избыточных функций, прав и автономии; проверено 30 сентября 2026 года.
- OWASP LLM01:2025 Prompt Injection — риск инструкций во входных данных; проверено 30 сентября 2026 года.
Семь проверок и формулы — практическая методика школы, не пересказ нормативного акта. Числа в примере полностью учебные; они не доказывают фактическую окупаемость какого-либо внедрения. Здесь нет скриншотов чужих кабинетов или выдуманного клиентского кейса.
Об авторе и школе · Нашли неточность? Напишите редакции.