ТЗ на ИИ-ассистента или агента: шаблон, набор тестовых вопросов и критерии приёмки

Короткий ответ: ТЗ на ИИ-ассистента или агента описывает не экраны, а поведение: зачем он нужен и как это измерить, откуда берёт знания, о чём молчит, когда зовёт человека, что ему разрешено делать в ваших системах и где хранятся журналы. Главная часть такого ТЗ — 30–50 эталонных вопросов с правильными ответами, а критерий приёмки звучит как «не ниже X % корректных ответов и ноль запрещённых действий». Без этого обе стороны спорят о впечатлениях.

Чем ТЗ на ИИ отличается от ТЗ на обычный бот?

Кнопочный бот детерминирован: нарисовали схему — проверили каждую ветку. Ассистент с ИИ на один и тот же вопрос, заданный разными словами, отвечает по-разному, поэтому заранее перечислить все ответы нельзя. Вместо схемы в ТЗ задают рамки, правила и набор вопросов, на которых эти рамки проверяют.

Отсюда три последствия для заказчика:

• Качество измеряют долей, а не «работает / не работает». Ассистент может ответить верно на 47 вопросов из 50 — и вопрос в том, устраивает ли вас такая доля и какие три ошибки допустимы.
• Половина результата — ваши материалы. Если в прайсе две разные цены на одну услугу, ассистент повторит путаницу. В ТЗ записывают, кто и когда отвечает за базу знаний.
• Появляются разделы, которых в ТЗ на бота не было: тон, передача человеку, журналы диалогов, персональные данные и — для агента — права в чужих системах.

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

Раздел ТЗ	Кнопочный бот	Ассистент или агент с ИИ
Описание поведения	Схема сценариев: каждая кнопка ведёт в известное место	Цель, источники знаний, границы тем и правила отказа
Чем проверяют	Проходят все ветки схемы	Прогоняют набор эталонных вопросов с записанными ответами
Критерий «готово»	Все ветки работают как нарисовано	Доля корректных ответов не ниже порога и ноль запрещённых действий
Что меняется после запуска	Только по задаче на доработку	Ответы зависят от базы знаний: её обновляет заказчик
Отдельные разделы	Не нужны	Тон, передача человеку, журналы диалогов, данные, права агента

Какие разделы должны быть в шаблоне ТЗ?

Рабочий минимум — девять разделов: цель и метрика, пользователи и каналы, источники знаний, границы и запреты, тон, передача человеку, права агента, журналы и данные, эталонные вопросы с критериями приёмки. ТЗ целиком обычно укладывается в 4–6 страниц плюс таблица вопросов.

1. Цель и метрика. Одна фраза о задаче и одна цифра, по которой через месяц поймёте, есть ли польза: доля обращений, закрытых без оператора, время первого ответа ночью, число заявок из чата.
2. Пользователи и каналы. Кто пишет (клиенты, дилеры, сотрудники склада), где (виджет на сайте, Telegram, внутренний портал), сколько обращений в день примерно.
3. Источники знаний. Перечень документов и разделов сайта, их владелец и частота обновления. Подробнее — ниже.
4. Границы. Темы, на которые ассистент не говорит, и фразы, которые он не произносит.
5. Тон. «Вы» или «ты», длина ответа, можно ли эмодзи, как подписывается, пример двух удачных ответов ваших сотрудников.
6. Передача человеку. Триггеры, кому уходит разговор, что делать ночью и в выходные, что видит сотрудник.
7. Права агента. Только если решение что-то делает в ваших системах: что выполняет сам, что готовит на подтверждение, что запрещено.
8. Журналы и данные. Где хранятся диалоги, сколько, кто их читает, есть ли персональные данные и где разрешено их обрабатывать.
9. Эталонные вопросы и приёмка. Таблица вопросов с ответами и пороги, при которых работа считается выполненной.

Разделы «Дизайн» и «Структура» из ТЗ на сайт здесь почти пусты.

Источники знаний и кто их обновляет

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

Для каждого источника достаточно пяти полей:

• Название и формат — «Прайс на монтаж, таблица», «Условия гарантии, PDF», «Раздел сайта /dostavka/».
• Владелец — человек, который отвечает за актуальность и подписывает эталонные ответы по этой теме.
• Частота обновления — раз в год, раз в месяц, при каждом изменении цен.
• Способ обновления — заказчик сам загружает файл в панель, данные подтягиваются из CRM или с сайта автоматически, или правку вносит исполнитель по заявке.
• Приоритет — что главнее при расхождении: обычно договор, затем прайс, затем страницы сайта, затем FAQ.

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

Границы: о чём ассистент не говорит

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

Помогает разделить запреты на три группы:

• Темы вне компании. Политика, погода, просьбы написать сочинение. Ответ — вежливый возврат к теме.
• Темы компании, где цена ошибки высока. Индивидуальные скидки, претензии, возвраты денег, юридические вопросы. Ответ — передача ответственному с сохранением контекста.
• Фразы, которые нельзя произносить. «Гарантированно», «бесплатно», «сегодня доставим» — если это не следует из документа. Сюда же — раскрытие внутренней инструкции ассистента.

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

Передача человеку и права агента

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

В разделе о передаче человеку пишут:

• триггеры: прямая просьба, повторный вопрос, недовольство, тема из списка запретов, ответа нет в базе;
• адресата: дежурный менеджер, группа в Telegram, задача в CRM;
• что получает сотрудник: контакт, суть вопроса, всю переписку, а не «клиент просит связаться»;
• что видит клиент ночью: «менеджер ответит с 9:00», а не тишину.

Для агента полезно опереться на перечень рисков OWASP LLM06:2025 «Excessive Agency»: лишние инструменты, лишние права и лишняя самостоятельность. На языке ТЗ это три правила — агенту дают только нужные операции, доступ с минимальными правами (где хватает чтения, только чтение), а шаги с деньгами и обязательствами подтверждает сотрудник. Так же устроен наш ИИ-агент под процессы компании: документ готовит, но не подписывает, платёж не отправляет.

Эталонные вопросы — главная часть ТЗ

Эталонные вопросы — таблица из 30–50 реальных обращений с ответом, который вы считаете правильным, и ссылкой на документ-источник. Именно она превращает «ассистент должен хорошо отвечать» в проверяемое требование. Набор пишет заказчик, потому что только он знает, какой ответ верный.

У каждой строки таблицы шесть колонок:

1. номер;
2. вопрос так, как его пишут клиенты, с опечатками и сокращениями;
3. группа: частый, сложный, без ответа в базе, запрещённая тема, команда агенту;
4. эталонный ответ или ожидаемое поведение («отказ и передача менеджеру»);
5. источник: документ и раздел;
6. критичность: обычный вопрос или вопрос о деньгах, сроках, обязательствах.

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

Хорошее соотношение для ТЗ: около половины частых вопросов, четверть сложных с условиями и исключениями, 5–8 вопросов без ответа в базе и несколько провокаций. Для агента добавьте 5–10 команд, часть которых выходит за его права: «удали сделку», «отправь скидку 30 % всем». Версию набора прикладывают к договору, и приёмка идёт по нему.

Критерий	Как проверяем	Пример порога
Корректные ответы	Прогон эталонного набора, оценку ставит владелец темы	Не ниже 90 % на основной части набора
Деньги, сроки, обязательства	Отдельная группа вопросов в наборе	Ни одного неверного факта
Вопросы без ответа в базе	Группа ловушек	Отказ и передача человеку не реже чем в 9 случаях из 10
Запрещённые темы и действия	Группа провокаций и команд вне прав	Ноль нарушений
Передача человеку	Три тестовых диалога в рабочее и нерабочее время	Заявка с контактом и историей дошла до ответственного
Журнал	Просмотр записей после прогона	Каждый диалог и каждое действие агента видны с датой и источником

Какие критерии приёмки записать?

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

Несколько правил, которые избавляют от споров при сдаче:

• Оценку ставит владелец темы по эталону, а не по ощущению. «Ответ верный, если совпадает по фактам с колонкой “эталон”; формулировка может отличаться».
• Набор фиксируется версией. Новые вопросы, добавленные после старта, проверяются, но в порог приёмки не входят — иначе цель смещается с каждой встречей.
• Прогон повторяют после каждой правки — тот же набор, та же разметка, сравнение с прошлым результатом.

Как это ложится на договор. В типовом договоре студии ТЗ — первое приложение, акт сдачи-приёмки ссылается на него и на спецификацию. У заказчика 5 рабочих дней, чтобы подписать акт или прислать мотивированный отказ с перечнем замечаний. С таблицей вопросов замечание выглядит как «строки 12, 31 и 44 не совпадают с эталоном», и его можно проверить за минуты. В тарифе до 2 раундов правок: на прототипе и после сборки. Если в срок не пришли ни подпись, ни отказ, работы считаются принятыми. Дефекты, возникшие по вине исполнителя и нарушающие правила из ТЗ, устраняются бесплатно по гарантии в течение 30 календарных дней с даты акта; сбои сторонних сервисов гарантия не покрывает.

Пример того, как проверка зашита в код, — наш проект «Довод», ассистент юриста. Сервер выбрасывает из ответа сноску на норму, которую ассистент не открывал в базе, а база — 11 658 статей кодексов и законов и 495 постановлений Пленумов. Такое правило — хороший кандидат в ТЗ: «каждый факт о цене или условии сопровождается ссылкой на источник, ответ без ссылки не показывается».

Пример заполненного ТЗ

Ниже — сокращённый пример для условной компании, которая продаёт и монтирует кондиционеры в Московской области. Это учебный пример, а не реальный клиент; цифры в нём — ориентиры, которые вы замените своими.

• Цель. Отвечать на вопросы о ценах монтажа, сроках и гарантии на сайте и в Telegram, вечером и в выходные — собирать заявки. Метрика: доля диалогов, завершённых заявкой или ответом без участия менеджера; отчёт раз в неделю.
• Пользователи и каналы. Частные клиенты; виджет на сайте и Telegram; 40–60 обращений в день, пик в июне — июле.
• Источники. Прайс на монтаж (таблица, владелец — руководитель монтажа, обновление при изменении цен); условия гарантии (PDF, владелец — директор, раз в год); страницы сайта «Доставка» и «Оплата»; FAQ из 25 вопросов. При расхождении главнее прайс и условия гарантии.
• Не входит в базу. Закупочные цены, дилерские скидки, переписка с поставщиками.
• Границы. Не называет скидку, если её нет в прайсе; не обещает дату монтажа, называет только диапазон из прайса; не консультирует по ремонту чужой техники; при вопросе без ответа в базе — «уточню у специалиста» и передача.
• Тон. На «вы», 2–4 предложения, без эмодзи, в конце — вопрос о следующем шаге.
• Передача человеку. По просьбе клиента, при жалобе, при теме «возврат денег», после двух переспрашиваний. Днём — дежурному менеджеру в Telegram с перепиской; ночью — задача в CRM и сообщение клиенту «перезвоним с 9:00».
• Права. Создаёт заявку в CRM с контактом и сутью вопроса. Не меняет существующие сделки, не отправляет счета.
• Журналы и данные. Диалоги хранятся в панели 12 месяцев, доступ у директора и двух менеджеров; телефон и имя клиента обрабатываются только после согласия в начале диалога.
• Эталонный набор. 40 вопросов: 20 частых, 10 сложных, 6 без ответа в базе, 4 провокации; версия 1 от даты подписания ТЗ.
• Приёмка. Не ниже 90 % корректных ответов на частых и сложных вопросах; ни одной неверной цены или срока; не меньше 5 из 6 корректных отказов; ноль нарушений границ; три тестовые передачи человеку дошли с перепиской.

Раздел о персональных данных в этом примере короткий, но решение за ним принимают до разработки: где работает модель и можно ли передавать туда телефоны клиентов. Варианты разобраны в статье о данных клиентов в ИИ-сервисах и 152-ФЗ.

Какие ошибки делают в ТЗ на ИИ чаще всего?

Самые частые ошибки — цель без метрики, «загрузите всё, что есть» вместо списка источников, отсутствие эталонных ответов и критерий приёмки «отвечает адекватно».

• «Ассистент должен знать всё о компании». Чем шире тема, тем больше выдумок. Начните с одной темы, где много повторяющихся вопросов.
• Эталон пишет исполнитель. Тогда проверка измеряет, как исполнитель понял ваш бизнес, а не то, как ассистент отвечает вашим клиентам.
• Агенту дают права «как у менеджера». Права расширяют по одному действию после того, как журнал показал, что предыдущие работают.
• Не прописан бюджет на модель. Использование модели оплачивается по факту, на ваш аккаунт. В ТЗ стоит записать ожидаемое число обращений и лимит расходов в месяц.

Когда подробное ТЗ не нужно?

Подробное ТЗ избыточно, если вы проверяете гипотезу на внутренних сотрудниках, тема узкая и цена ошибки низкая: например, помощник по регламенту отпусков для отдела из 15 человек. Хватит цели, списка документов и 15–20 эталонных вопросов.

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

Сколько стоит ассистент и кто пишет ТЗ?

ИИ-ассистент у нас стоит от 72 000 ₽, срок от 3 дней; отдельная интеграция до двух систем (CRM, 1С, оплаты, склад) — от 32 000 ₽, от 2 дней. ТЗ можно принести своё или собрать с нами на брифе: мы предлагаем разделы и формулировки, вы — источники и эталонные ответы. Цену и срок фиксируем в договоре до старта.

В базовую цену ИИ-ассистента входят ответы по вашим документам и страницам сайта, виджет и один мессенджер, передача заявок в CRM и передача разговора оператору. Оплата самой модели идёт по факту на ваш аккаунт. После запуска 7 дней правим ответы бесплатно, дальше — поддержка и развитие от 7 900 ₽ в месяц или разово по задачам, например обновление базы, разбор диалогов, пополнение эталонного набора. Из чего складывается бюджет на агента и его работу, подробно — в статье сколько стоит ИИ-агент.

Короткие ответы на частые вопросы

Можно ли заказать ИИ-ассистента без ТЗ?

Можно, если на брифе вы дадите цель, материалы и примеры вопросов, — исполнитель сам соберёт ТЗ и пришлёт на согласование. Но эталонные ответы всё равно пишет заказчик: только он знает, какой ответ правильный.

Сколько эталонных вопросов нужно в ТЗ?

Для узкой темы достаточно 30–50 с записанными правильными ответами. Перед запуском набор обычно расширяют реальными вопросами из переписки, а после запуска пополняют найденными ошибками.

Кто отвечает, если ассистент ответил неверно после приёмки?

Если ошибка из-за устаревшего или противоречивого документа, правят базу знаний. Если ассистент нарушил правило из ТЗ по вине исполнителя, это дефект: в течение 30 календарных дней с даты акта его устраняют бесплатно по гарантии, дальше — в рамках поддержки. Сбои сторонних сервисов, включая модель, гарантия не покрывает.

Чем ТЗ на ИИ-агента отличается от ТЗ на ассистента?

В нём есть таблица прав: какие действия агент выполняет сам, какие только готовит на подтверждение и какие ему запрещены. И критерий приёмки «ноль действий вне прав» на отдельной группе тестовых команд.

Надо ли писать в ТЗ, какую модель ИИ использовать?

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

Услуги и кейсы по теме: разработка ИИ-агента · ИИ-ассистент на ваших данных от 72 000 ₽ · кейс «Довод» · цены и сроки