Назад в блог

ТЗ на AI-ассистента для бизнеса: готовый шаблон без технического тумана

·17 мин чтения·Rendframe·AI, Бизнес, Планирование проекта, Автоматизация

В понедельник владелец пишет трем подрядчикам: «Нужен AI-чатбот для сайта». В пятницу получает три предложения — на 3 000, 18 000 и 70 000 евро. Одно предполагает аккуратный FAQ в углу экрана, второе — интеграцию с CRM, третье — полноценного агента, который сам меняет заказы. Сравнить такие предложения невозможно: каждый оценил другой продукт.

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

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

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

Определите, какой из трех продуктов вам нужен

Словом «чатбот» называют как минимум три разные системы. Разница между ними влияет на бюджет, срок и риск гораздо сильнее названия модели.

УровеньЧто делаетПримерГлавная сложность
1. КонсультантИщет в утвержденных материалах и отвечаетОбъясняет условия доставки или тарифКачество и актуальность базы знаний
2. КопилотЧитает рабочие данные и готовит результат для человекаНаходит заказ и составляет черновик ответаИнтеграции, проверка личности, удобство для команды
3. АгентВыполняет действия в других системахСоздает заявку, бронирует слот или меняет записьПрава, ошибки, подтверждение и откат

Для большинства небольших компаний разумный первый релиз — копилот, а не автономный агент. Он убирает поиск и повторное переписывание, но человек видит решение до того, как оно затронет деньги, клиента или учет. Автономность добавляют по одному узкому действию после доказанной работы на живом потоке.

Одностраничный бриф, который можно скопировать

Заполните пропуски обычным языком. Если поле пока неизвестно, напишите: «определить во время discovery». Это полезнее случайного требования.

НАЗВАНИЕ ПРОЕКТА
[Короткое название]

БИЗНЕС-ПРОБЛЕМА
Сейчас [кто] тратит [время/деньги] на [процесс], из-за чего [последствие].

ЦЕЛЬ ПИЛОТА
За [период] изменить [метрика] с [база] до [цель],
не ухудшив [защитная метрика].

ПОЛЬЗОВАТЕЛИ И КАНАЛ
Пользователи: [клиенты / менеджеры / партнеры]
Первый канал: [сайт / email / Telegram / CRM]
Языки: [русский / украинский / английский / другие]
Объем: [диалогов или задач в неделю]

СЦЕНАРИИ ПЕРВОЙ ВЕРСИИ
1. [Запрос → требуемый результат]
2. [Запрос → требуемый результат]
3. [Запрос → требуемый результат]

ВНЕ ГРАНИЦ ПЕРВОЙ ВЕРСИИ
[Сценарии, каналы и действия, которые сознательно не строим]

ИСТОЧНИКИ ПРАВДЫ
[Система/документ] — [владелец] — [частота обновления]

ИНТЕГРАЦИИ
Чтение: [какие поля из каких систем]
Запись: [какие узкие действия, если нужны]
Только после подтверждения: [список]

ОБЯЗАТЕЛЬНАЯ ЭСКАЛАЦИЯ
[Деньги, персональные данные, конфликт, неуверенность, исключения]
Владелец очереди: [роль]
Срок реакции: [SLA]

КРИТЕРИИ ПРИЕМКИ
[Набор реальных тестов, требуемое качество, нулевые допуски]

ЭКСПЛУАТАЦИЯ
[Логи, аналитика, хранение, мониторинг, аварийное отключение]

ФОРМАТ ПРЕДЛОЖЕНИЯ
Отдельно оценить discovery, пилот, интеграции, тестирование,
production-запуск, ежемесячные сервисы и поддержку.

Проверка за 30 секунд. Незнакомый человек должен понять, какую работу система берет на себя, откуда берет правду, чего не делает, как передает дело человеку и каким тестом вы примете результат.

Опишите результат, а не магию AI

«Улучшить сервис с помощью AI» невозможно оценить. «Сократить медианное время подготовки ответа о статусе заказа с 6 до 2 минут, не увеличив долю повторных обращений» — можно.

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

Слабая цельРабочая метрикаЗащитная метрика
Отвечать быстрееВремя до первого содержательного ответаПовторные обращения не растут
Квалифицировать больше лидовДоля лидов с полным контекстом в CRMКонверсия во встречу не падает
Снизить нагрузкуМинуты ручной работы на одну задачуКритические эскалации не пропускаются
Автоматизировать документыВремя до готового черновикаНоль неподтвержденных сумм и реквизитов

Зафиксируйте исходное значение до начала. Иначе после запуска останется красивое демо, но не ответ на вопрос, стал ли бизнес работать лучше. Для экономики проекта используйте наш практический расчет ROI автоматизации.

Соберите реальные сценарии

Не придумывайте «типичного клиента» на совещании. Возьмите 50–100 настоящих сообщений или задач, обезличьте и разложите по следующему действию. Такая выборка сразу обнаружит опечатки, смешение языков, голосовые транскрипты, несколько намерений в одном сообщении и вопросы, на которые у самой компании нет согласованного ответа.

ВходНужный результатДанныеДействиеКогда остановиться
«Где мой заказ?»Проверенный статус и трекингНомер + второй признак клиентаТолько чтениеДанные не совпали
«Подойдет к модели X?»Подтвержденная совместимостьАктуальный каталогОтвет с источникомПрямого подтверждения нет
«Хочу демо»Квалифицированный лидCRM, календарь, критерии ICPПредложить слотНужен нестандартный договор

Первый релиз ограничьте тремя-пятью частыми сценариями. Остальное отметьте как вне границ или передавайте человеку. «Отвечать на любые вопросы о компании» — это не требование, а будущий список инцидентов.

Назовите источники правды

AI не исправляет противоречивые данные. Он лишь быстрее находит одну из версий. Для каждого факта нужны источник, владелец и правило актуальности.

Доставка: публичная политика на сайте
Владелец: операционный менеджер
Обновление: после смены перевозчика или тарифа
Приоритет: выше старых PDF и сообщений в чатах

Цена и наличие: каталог/ERP через API
Владелец: ecommerce-менеджер
Обновление: в реальном времени
Запрет: не брать цены из прошлых диалогов

Не просите подрядчика «загрузить весь Drive». Подготовьте реестр: источник, тип данных, ответственный, дата проверки, разрешенные пользователи, срок хранения и приоритет при конфликте.

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

Разделите ответы, действия и согласования

Модульная схема AI-ассистента: каналы, знания, интеграции, действия, подтверждение человеком и мониторинг
Безопасный информационный путь может быть автоматическим. Действие с последствиями останавливается перед четким человеческим подтверждением.

В списке интеграций не пишите «подключить CRM». Назовите объекты, поля и права. Чтение контакта, создание заметки, смена этапа и удаление сделки — четыре разных разрешения.

УровеньПримерПравило первого релиза
ОтветОбъяснить политику со ссылкойАвтоматизация после тестов
Черновик действияПодготовить запись в CRM или письмоЧеловек проверяет и подтверждает
Обратимое действиеДобавить тег или создать задачуУзкие права, журнал и отмена
Рискованное действиеВернуть деньги, изменить бронь, отправить договорЯвное человеческое подтверждение
Необратимое действиеУдалить данные или закрыть финансовую операциюВне первой версии

OWASP относит prompt injection и excessive agency к ключевым рискам систем с языковыми моделями и рекомендует минимальные права, проверку вызовов инструментов и человеческое согласование высокорисковых операций. Текст клиента, письмо, веб-страница или документ — недоверенный вход, даже когда он выглядит как обычная инструкция.

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

Составьте приемочные тесты до разработки

«Работает хорошо» — не критерий. До старта соберите закрытый набор реальных примеров, который разработчик не использует для настройки. Добавьте обычные, неоднозначные, редкие и намеренно опасные случаи.

  1. частый вопрос с однозначным ответом;
  2. опечатки и разговорный язык;
  3. русский, украинский и переключение языка;
  4. несколько намерений в одном сообщении;
  5. отсутствующее обязательное поле;
  6. конфликт источников;
  7. ответа в источниках нет;
  8. неверный номер или неудачная проверка личности;
  9. запрос на запрещенное действие;
  10. инструкция «игнорируй правила» в сообщении или документе;
  11. недоступная CRM, медленное API или таймаут;
  12. повтор той же операции для проверки дублей.

Для каждого теста укажите ожидаемые факты, разрешенное и запрещенное действие, маршрут эскалации. Измеряйте отдельно правильность маршрута, подтвержденность фактов, утечки, нежелательные действия, полноту журнала и задержку.

  1. Нулевой допуск: чужие данные, выдуманное финансовое обещание, нежелательная операция.
  2. Порог качества: задается на вашей выборке отдельно по сценарию и языку.
  3. Запасной маршрут: при неуверенности, сбое или неверном формате — человек.
  4. Теневой запуск: первые реальные кейсы без отправки и записи.

NIST рассматривает риск-менеджмент AI как работу на всем жизненном цикле. В брифе это означает ответственного за качество, регулярную выборку диалогов, журнал инцидентов и возможность быстро вернуть систему в режим черновиков.

Продумайте эксплуатацию

Демо показывает лучшую минуту системы. ТЗ должно описать остальной год:

  • скорость: допустимая задержка и поведение при таймауте;
  • доступность: часы работы, резервный маршрут, уведомление о сбое;
  • логи: вход, источники, версия правил, инструменты, согласование и результат;
  • приватность: маскирование, хранение, удаление, роли и экспорт;
  • расходы: лимиты и цена при 2× и 10× объеме;
  • изменения: кто обновляет знания и как тестируются новые версии;
  • поддержка: кто реагирует на инцидент и поломку стороннего API;
  • выход: экспорт данных, конфигурации, тестов и журналов при смене поставщика.

Если у компании еще нет владельцев данных, доступов и базовых метрик, начните с практической подготовки онлайн-бизнеса к AI. Это часто сокращает самую дорогую часть разработки.

Как получить сопоставимые сметы

Не просите одну цену «под ключ». Пусть каждый поставщик отдельно оценит одинаковые блоки и перечислит предположения.

БлокЧто должно войтиЧто часто забывают
DiscoveryПроцесс, данные, риски, прототип потокаВремя ваших сотрудников
Пилот1 канал, 3–5 сценариев, черновики, аналитикаПодготовка реальных тестов
ИнтеграцииСистема, объект, направление и правоЛимиты API и платные коннекторы
БезопасностьРоли, секреты, фильтры, согласования, аудитПентест и исправления
ProductionМониторинг, алерты, откат, документацияПереезд из демо-среды
ЕжемесячноМодели, хостинг, каналы, поддержкаПроверка людьми и повторные вызовы

Попросите цены при текущем, двойном и десятикратном объеме. Отдельно — запуск, сторонние платежи и работа по запросу. Сравнивайте не только итог: смотрите, кто проверил предположения, сузил права, предложил теневой режим и объяснил, что произойдет при смене модели, тарифа или API.

Два заполненных примера

Копилот для поддержки интернет-магазина

Проблема: два менеджера вручную ищут заказы и правила;
в пик ответы теряются между email и чатом.

Цель: сократить медианное время черновика по ORDER_STATUS
с 5 до 2 минут; повторные обращения не растут.

Первый релиз: email, русский и украинский, 600 обращений/неделю.
Сценарии: статус, доставка, возврат — только сбор данных.

Источники: система заказов, API перевозчика, активные политики.
Действия: читать статус, готовить черновик. Не менять заказ.

Эскалация: неудачная проверка, деньги, адрес, конфликт,
отсутствующий факт. Владелец — дежурный, SLA 30 минут.

Приемка: 120 закрытых кейсов; 100% рискованных действий переданы;
0 утечек; 0 выдуманных статусов и сроков.

Полный маршрут пилота есть в нашем материале AI-поддержка интернет-магазина за 7 дней.

Ассистент для квалификации B2B-лидов

Проблема: основатель проводит 12–15 звонков в неделю;
треть не соответствует минимальному профилю клиента.

Цель: 80% заявок имеют полный контекст до звонка;
конверсия квалифицированных заявок во встречу не падает.

Первый релиз: форма сайта + email, английский и украинский.
Сценарии: задача, срок, исходная система, роль и объем.

Действия: создать черновик лида; предложить разрешенные слоты.
Не назначать бюджет за клиента и не обещать срок проекта.

Эскалация: тендер, регулируемые данные, нестандартный договор.
Владелец — business development.

Приемка: 80 исторических лидов + 30 крайних кейсов;
ни один потенциально ценный лид не отклонен автоматически.

15 вопросов подрядчику

  1. Какое предположение сильнее всего влияет на бюджет?
  2. Что сознательно исключено из первого релиза?
  3. Как система показывает источник каждого факта?
  4. Что происходит при конфликте источников?
  5. Какие точные права получит каждая интеграция?
  6. Какие проверки выполняются обычным кодом?
  7. Где нужно подтверждение человека и как оно выглядит?
  8. Как тестируются prompt injection и нежелательные действия?
  9. Кто владеет тестовым набором после проекта?
  10. Что происходит при недоступной CRM или таймауте?
  11. Что логируется, кто видит логи и когда они удаляются?
  12. Какова цена при 1×, 2× и 10× объеме?
  13. Кто обновляет знания и отвечает за регрессии?
  14. Как отключить автоматические действия, не останавливая сервис?
  15. Что мы получим при смене подрядчика?

Красные флаги

  • точная «95% точность» до просмотра ваших кейсов;
  • одна сумма без предположений, интеграций и ежемесячных расходов;
  • «обучим на всех данных» без реестра и прав доступа;
  • полные права администратора «для удобства»;
  • безопасность описана только системным промптом;
  • есть демо, но нет теневого теста, журнала и аварийного выключения;
  • неясно, кому принадлежат код, конфигурация, промпты и тесты;
  • все исключения отложены на потом, а запуск сразу автономный.

Частые вопросы

Нужно ли полное ТЗ до первой встречи?

Нет. Одной страницы достаточно для первичной оценки. Детальная спецификация появляется после проверки процесса, данных и интеграций.

Сколько сценариев включать в MVP?

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

Нужно ли сразу подключать CRM?

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

Как оценить качество AI-чатбота?

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

Что важнее: портфолио или цена?

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

Источники и дальнейшее чтение

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