soul·dev блог
Техническое задание на AI-тренажер: шаблон требований для закупки
Чтобы закупка AI-тренажера не превратилась в спор о красивом демо, требования нужно формулировать через сценарии, оценку, данные и приемку результата.
Зачем нужно отдельное ТЗ
AI-тренажер нельзя закупать только как доступ к модели. Для бизнеса важен не сам факт диалога, а воспроизводимая практика: сценарий, попытка, оценка, отчет, повторение и интеграция с обучением. Поэтому ТЗ должно описывать рабочий процесс, а не только технический стек.
Хорошее ТЗ помогает сравнивать поставщиков по одному и тому же кейсу. Если каждый показывает свое демо, сравнение превращается в субъективное впечатление. Если все собирают один сценарий и оценивают одни ответы, становится видно, кто действительно умеет работать с корпоративной методологией.
Блок 1: сценарии и роли
В ТЗ нужно указать, какие роли тренируются: продавец, оператор, CSM, руководитель, интервьюер, администратор или наставник. Для каждой роли стоит описать типовые ситуации, уровень сложности, допустимые и недопустимые действия, а также поведение AI-собеседника.
Важно требовать не один универсальный сценарий, а возможность создавать варианты: спокойный клиент, раздраженный клиент, неполный контекст, сопротивление цене, юридическое ограничение, высокий риск обещать лишнее. Именно вариативность отделяет тренажер от статичного теста.
Блок 2: оценка и объяснимость
Отдельным разделом нужно зафиксировать критерии оценки: структура разговора, выявление потребности, эмпатия, точность информации, соблюдение регламента, работа с возражением, фиксация следующего шага. По каждому критерию желательно описать шкалу и примеры ошибок.
Требуйте объяснимость результата. Система должна показывать не только итоговый балл, но и почему ответ был оценен именно так, какие фразы повлияли на вывод, где сотрудник нарушил стандарт и что ему повторить перед следующей попыткой.
Блок 3: интеграции и данные
Для корпоративного внедрения важно заранее определить, куда попадут результаты: LMS, HRIS, BI, корпоративный портал или отдельный кабинет руководителя. В ТЗ стоит указать обязательные поля выгрузки: пользователь, сценарий, попытка, баллы по критериям, дата, статус и рекомендации.
Если в компании уже есть LMS, проверьте, нужен ли SCORM, xAPI, API или простая выгрузка. Не все сценарии требуют глубокой интеграции на пилоте, но архитектурная возможность должна быть понятна до масштабирования.
Блок 4: безопасность и ограничения
ТЗ должно описывать, какие данные можно загружать, где хранятся диалоги, кто видит результаты, как удаляются данные и как ограничиваются чувствительные сценарии. Для медицинских, финансовых и юридических процессов важно отдельно запретить модели давать советы за пределами роли сотрудника.
Также стоит прописать требования к логированию, разграничению доступа, обработке персональных данных и возможности запускать пилот на обезличенных кейсах. Без этого хороший обучающий сценарий может стать риском для комплаенса.
Критерии приемки пилота
Приемка не должна ограничиваться фразой 'сценарий работает'. Минимальные критерии: сотрудники проходят попытки без помощи тренера, оценки различают сильные и слабые ответы, руководитель понимает отчет, методолог видит типовые ошибки, а результаты можно использовать для решения о допуске или повторной тренировке.
Если после пилота команда может сказать, кого нужно доучить, какой блок курса слабый и какие сценарии стоит добавить следующими, AI-тренажер доказал практическую полезность.