Как принять ИИ-бота у подрядчика: сценарии, доступы и акт проверки

Соберите комплект для приёмки

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

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

Пять групп тестов

Добавьте реальные неудобные случаи: опечатка, два вопроса сразу, старый документ, повтор события, возвращение клиента к длинному диалогу. Каждый тест должен иметь ожидаемый результат до проверки. Фраза «бот ответил корректно» слишком общая; укажите, какая информация должна прозвучать, что не должно быть обещано и где увидеть заявку.

Проверьте права и журнал

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

В практическом руководстве OpenAI по агентам границы инструментов и передача человеку описаны как ключевые элементы построения системы. NIST AI RMF подчёркивает повторяемую проверку и ответственность. Эти принципы стоит перевести в ваши конкретные тесты.

Приёмка и первый месяц

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

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

Пример одного приёмочного сценария

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

Что проверить при передаче проекта

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

Пересмотр тестов после запуска

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

Что должно быть в итоговом документе приёмки

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

Как проверить мобильную и рабочую среду

Бот может успешно пройти тест на компьютере разработчика и мешать клиенту на телефоне: виджет перекрывает форму, поле ввода уходит под клавиатуру, кнопка оператора не видна. Пройдите несколько сценариев на узком экране и в обычном браузере без авторизации. Затем проверьте рабочую нагрузку: несколько одновременных разговоров, временную ошибку CRM и повтор входящего события. В акте укажите среду теста; одна удачная демонстрация в тестовом чате не покрывает публичный сайт.

Если после исправления интерфейса меняется код интеграции, повторите тест передачи заявки. Визуальная правка не должна незаметно сломать коммерческий маршрут.

После приёмки сохраняйте тесты агента перед обновлениями.