Принимать AI-проект нужно не по эффектной демонстрации, а по заранее согласованной программе испытаний. Проверьте полный бизнес-маршрут на закрытой репрезентативной выборке: получение входа, качество результата, человеческое подтверждение, запись в целевую систему, обработку исключений и журнал. Отдельно примите права доступа, безопасность, производительность, стоимость эксплуатации, документацию и ручной резервный режим. Метрики и запрещённые ошибки фиксируются до теста; подрядчик не должен настраивать решение на итоговой выборке. Результат приёмки — протокол с фактами, дефектами, сроками исправления и решением: принять, принять условно, повторить испытания или отклонить. Бизнес-KPI оценивается в пилотной эксплуатации относительно базовой линии.
Оглавление
- Кому нужна программа приёмки
- Что проверять
- Экономика приёмки
- Метрики качества
- Готовый сервис и разработка
- Пошаговый план
- Ошибки
- Чек-лист
- FAQ
Кому нужна программа приёмки
Бизнес-владелец подтверждает, что решение меняет нужный процесс и не создаёт неприемлемых действий. Пользователи проверяют рабочий маршрут и исключения. ИТ принимает архитектуру, интеграции, развёртывание и поддержку. Безопасность проверяет данные, роли и журнал. Закупки или юристы сопоставляют фактический результат с договорёнными артефактами. Проектный руководитель собирает единый протокол.
Распределите ответственность заранее. Фраза «заказчик проверяет качество» слишком размыта. Должно быть понятно, кто утверждает выборку, кто классифицирует критичную ошибку, кто предоставляет систему для теста и кто подписывает решение.
Что нужно принимать
Функциональный маршрут
Проверьте каждый согласованный сценарий от реального события до финальной записи. Например, письмо поступило, вложение распознано, критичные поля извлечены, сотрудник увидел источник, исправил одно значение, подтвердил результат, а карточка появилась в целевой системе. Отдельная загрузка файла в интерфейсе подрядчика не доказывает этот маршрут.
Качество результата
Испытания проходят на закрытой выборке, отражающей обычные и пограничные случаи. Метрики считаются по важным классам и полям. Запрещённые ошибки — например, выдуманный реквизит или действие без подтверждения — регистрируются отдельно, даже если среднее высокое.
Человеческий контроль
Пользователь должен видеть исходник, статус, неопределённость и последствия действия. Проверяются подтверждение, исправление, отклонение, передача исключения и отмена. Обратная связь сохраняется и доступна для анализа.
Интеграции
Испытайте авторизацию, преобразование полей, повторную отправку, дубли, ограничение API, недоступность системы, очередь и восстановление. Успешный «идеальный» вызов — только начало приёмки.
Безопасность
Сопоставьте реализованные потоки с согласованной схемой. Проверьте роли, минимальные права, секреты, шифрование, журнал, хранение, удаление, резервные копии и внешние зависимости. Требования определяет контекст заказчика; универсальный чек-лист не заменяет его политику.
Производительность и устойчивость
Измерьте время полного ответа при обычной и пиковой нагрузке, поведение таймаута, повтор, деградацию внешней модели и ручной режим. Ограничьте расходы и проверьте оповещение при аномальном объёме.
Эксплуатация
Примите мониторинг, метрики качества, журнал затрат, процедуру инцидента, обновления и ответственных. Уточните, что происходит при смене модели, справочника или формата входа.
Документация и передача
Нужны архитектура, схема данных, инструкция пользователя и администратора, окружения, конфигурация, API, перечень зависимостей, известные ограничения, тесты, доступы и порядок восстановления. Содержание зависит от договора, но оно должно позволять поддерживать результат.
Экономика приёмки
Приёмка требует времени, но её стоимость нужно сравнивать с ценой дефекта в эксплуатации. Простой подход — приоритизировать тесты по риску:
Риск = вероятность сбоя × последствия × обнаруживаемость до действия.
Ниже условный пример, а не статистика проектов.
| Сценарий | Модельная вероятность | Модельное последствие | Приоритет теста | |---|---:|---:|---| | Неверная подсказка, подтверждаемая человеком | 5% | 300 ₽ времени | средний | | Дубликат записи в системе | 2% | 5 000 ₽ разбора | высокий | | Отправка без разрешения | 0,5% | 100 000 ₽ последствия | критичный | | Задержка некритичного отчёта | 10% | 200 ₽ | низкий |
Числа заменяются фактическими оценками владельца. Критичный сценарий тестируется даже при низкой вероятности. Тестовый план не должен равномерно распределять усилия между всеми функциями.
Стоимость владения тоже проходит приёмку. Проведите нагрузочный или расчётный сценарий с реальным объёмом: лицензии, запросы, инфраструктура, хранение, поддержка. Сверьте лимиты и оповещения. Если финансовая модель проекта опиралась на стоимость одной операции, подтвердите её фактом.
Как зафиксировать качество
Для структурированных задач используйте объективные метрики. Извлечение данных измеряется по каждому критичному полю и по документу целиком. Классификация — по классам, особенно редким. Поиск — по наличию релевантного источника в верхних результатах. Время — от рабочего события до доступного результата.
Для вариативного текста создайте рубрику: фактическая опора, полнота обязательных пунктов, отсутствие запрещённого, корректный тон, полезность и объём правки. Каждый критерий имеет шкалу и примеры. Критичные нарушения не компенсируются красивым стилем.
Дополните модельные метрики операционными:
- доля потока, к которому применимо решение;
- время проверки и исправления;
- доля принятых без изменений, с изменениями и отклонённых;
- число операций, завершивших полный маршрут;
- стабильность результата при повторе, если она требуется;
- ошибки и задержки интеграций;
- стоимость одной обработанной операции.
Текстовая схема приёмки:
Согласованные требования + закрытая выборка
↓
функция → качество → контроль человека
↓
интеграции → безопасность → устойчивость
↓
документация → эксплуатация → TCO
↓
протокол: принято / условно / повтор / отклонено
Различия приёмки по типу решения
Готовый сервис
Принимаются конфигурация, роли, интеграция, условия данных, тарифный объём, экспорт и поддержка. Код продукта не передаётся, поэтому особенно важны выгрузка, журнал и план смены. Проверьте различия тестового и промышленного тарифа.
Интеграционное решение
Отдельно тестируются границы ответственности: готовая модель, собственные правила, коннекторы и интерфейс. Сбой каждого слоя должен диагностироваться. Замена модели не должна неожиданно ломать бизнес-логику.
Собственная разработка
Помимо поведения принимаются репозиторий или артефакты в договорённом объёме, сборка, окружения, зависимости, тесты, развёртывание, мониторинг и знания команды. Термин «исходный код» недостаточен: без конфигурации, документации и данных воспроизводимости он может быть непригоден.
Независимо от типа решения, заказчик должен получить доступ к своим данным, результатам и журналам в согласованном формате. Конкретные права и лицензии фиксируются договором, а не предполагаются.
Пошаговый план приёмки
- Верните исходную границу. Список сценариев, вне границы, роли и системы.
- Сверьте критерии. Метрики, пороги, запрещённые ошибки и бизнес-KPI были согласованы до теста.
- Заморозьте версию. Код, модель, конфигурация, промпты и справочники получают идентификаторы.
- Защитите тестовый набор. Подрядчик не использовал его для настройки; дубли исключены.
- Подготовьте среду. Доступы, журналы, тестовые системы и исходное состояние зафиксированы.
- Проведите функциональные сценарии. Обычные, пограничные, отказные и запрещённые.
- Посчитайте качество. Автоматические метрики и экспертная рубрика по утверждённой методике.
- Проверьте интеграции и нагрузку. Включая недоступность, повтор и дубли.
- Проведите безопасность. По согласованной модели угроз и политике компании.
- Проверьте эксплуатацию. Мониторинг, оповещения, расходы, ручной режим и восстановление.
- Передайте знания. Пользовательская и техническая документация, обучение ответственных.
- Оформите протокол. Результат каждого теста, свидетельство, дефект, критичность и срок.
- Запустите ограниченную эксплуатацию. Бизнес-KPI измеряется на реальном процессе.
- Примите финальное решение. Только после согласованных исправлений и повторной проверки.
Ошибки заказчика
Критерии появляются после результата. Спор становится субъективным. Метрики и выборка должны быть согласованы заранее.
Подрядчик тестирует сам себя. Испытания нужны с участием заказчика и воспроизводимыми свидетельствами.
Средняя метрика скрывает риск. Критичный класс провален, но общий показатель высокий. Считайте по классам и запрещённым ошибкам.
Принимается только интерфейс. Интеграции, права, расходы и восстановление остаются неизвестными.
Бизнес-KPI требуют в лаборатории. Влияние на цикл и пользователей проверяется в ограниченной эксплуатации, а не на файлах.
Нет условной приёмки. Мелкие дефекты блокируют всё либо критичные обещают исправить «потом». Введите категории и сроки повторного теста.
Доступы остаются у подрядчика. Передача секретов, администраторов и процедур откладывается до инцидента.
Нет ручного режима. Сбой системы останавливает процесс. Резервный путь должен быть известен и проверен.
Единый чек-лист
- [ ] Сценарии и вне границы совпадают с договорённостью.
- [ ] Есть матрица требований и свидетельств.
- [ ] Версия всех компонентов заморожена.
- [ ] Закрытая выборка репрезентативна и независима.
- [ ] Критичные ошибки определены заранее.
- [ ] Метрики считаются по важным полям и классам.
- [ ] Проверено время человеческой проверки.
- [ ] Испытаны подтверждение, исправление и эскалация.
- [ ] Интеграции проверены на сбой, повтор и дубли.
- [ ] Роли и минимальные права подтверждены.
- [ ] Журнал позволяет расследовать действие.
- [ ] Проверены нагрузка, лимиты и стоимость.
- [ ] Работают мониторинг и оповещения.
- [ ] Ручной режим и восстановление испытаны.
- [ ] Документация соответствует версии.
- [ ] Доступы и знания переданы заказчику.
- [ ] Дефекты занесены в протокол с критичностью.
- [ ] Бизнес-KPI проверяется относительно базовой линии.
Связанные материалы
До договора определите KPI проекта и подготовьте данные. Требования к контуру удобно сверить со страницей безопасности. Формат ограниченной проверки описан в Proof of Value.
FAQ
Можно ли принять AI-проект по демонстрации?
Нет. Демо показывает выбранный успешный маршрут и часто использует знакомые данные. Приёмка требует независимого набора, отказных сценариев, полного цикла, прав, эксплуатации и воспроизводимого протокола.
Как зафиксировать качество, если ответы вариативны?
Разделите объективные обязательные элементы, экспертную рубрику и запрещённые ошибки. Оценщики проходят калибровку, спорные случаи разбираются по правилу. Дополните качество временем правки и долей принятия.
Что должно остаться у заказчика?
Данные и результаты, документация, доступы, конфигурация и код в договорённом объёме, инструкции эксплуатации, журнал изменений, тестовые свидетельства и возможность экспорта. Точный состав фиксируется до работ.
Когда проверять бизнес-эффект?
Базовая линия фиксируется до запуска. После технической приёмки проводится ограниченная эксплуатация, где сравниваются полный цикл, качество и adoption. Нельзя обещать причинный эффект по лабораторной выборке.
Следующий шаг
Соберите текущие требования, сценарии и критерии в одну матрицу. Затем закажите независимый разбор процесса и приёмки, чтобы проверить не только ответ модели, но и готовность решения к ежедневной эксплуатации.