Техническое задание на AI-агента: шаблон и примеры для малого бизнеса

Зачем ТЗ, если «можно просто настроить бота»

AI-агент — бот на основе нейросети, который не только отвечает на вопросы, но и выполняет действия: записывает, создаёт заявку в CRM, проверяет статус заказа. Подробнее о том, чем агент отличается от чат-бота и какие задачи закрывает, — в отдельной статье.

Обычный бот по кнопкам можно описать схемой. У AI-агента бесконечное число возможных диалогов, поэтому описывать нужно не диалоги, а правила: что агент должен, что ему запрещено и как проверить, что он справляется. Без ТЗ типовые проблемы такие:

• подрядчик и заказчик по-разному понимают, что значит «отвечает на вопросы клиентов»;
• агент обещает скидку или срок, которых нет, — и непонятно, ошибка это или «так настроено»;
• нет критериев приёмки, поэтому работу сдают по ощущению «вроде нормально».

Если вы уже писали ТЗ на сайт, принцип похож: описывать задачу и результат, а не реализацию. Общие правила такого документа — в статье техническое задание на сайт.

А как же ГОСТ?

Для автоматизированных систем есть ГОСТ 34.602-2020 «Техническое задание на создание автоматизированной системы», он действует с 1 января 2022 года. Его применяют в госзаказах и крупных проектах. Для малого бизнеса полное ТЗ по ГОСТу избыточно, но логика полезна: назначение и цели, требования к функциям, к данным, к безопасности, порядок приёмки. Шаблон ниже построен на ней, только проще.

Структура ТЗ: восемь разделов

Дальше — каждый раздел с подсказками.

Цель, задачи и границы агента

Раздел 1. Цель и метрики

Одна цель и 2–3 числа, по которым вы поймёте, что агент приносит пользу. Цель формулируйте через процесс, а не через технологию. Если агент нужен не клиентам, а команде, цели будут другими — о таком сценарии в разборе ИИ-ассистента для сотрудников.

• Плохо: «Внедрить AI-агента для улучшения клиентского сервиса».
• Хорошо: «Отвечать на входящие вопросы в чате сайта и мессенджере круглосуточно и принимать заказы вне рабочего времени операторов».

Метрики: доля диалогов, закрытых без человека; время первого ответа; число заказов, принятых агентом; доля диалогов с жалобой на ответ. Укажите текущие значения, если они известны, — без «было» не с чем сравнить «стало».

Раздел 2. Задачи и границы

Две колонки: «Агент делает» и «Агент не делает никогда». Вторая колонка важнее.

Типовые запреты:

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

Хорошее правило для раздела: если ошибка агента в каком-то вопросе стоит денег или репутации, этот вопрос либо в запретах, либо в списке передачи человеку. Другие частые промахи на старте собраны в разборе ошибок внедрения ИИ в бизнес.

Сценарии и база знаний

Раздел 3. Сценарии

Сценарий — короткое описание типовой ситуации и ожидаемого поведения. Не пишите диалог дословно: модель всё равно сформулирует по-своему. Пишите, что агент должен выяснить и сделать.

Формат одного сценария:

5–10 сценариев обычно покрывают большую часть обращений. Возьмите их из реальных переписок за 2–3 месяца, а не придумывайте.

Раздел 4. База знаний

База знаний — документы, из которых агент берёт факты: услуги, цены, условия, график. В ТЗ опишите:

• какие документы входят и где лежат;
• какой из них главный источник цен — он должен быть один;
• кто и как часто обновляет базу и как изменения попадают к агенту;
• что агент делает, если ответа в базе нет.

Как подготовить сами документы — по карточкам, с единым источником цен и тестовыми вопросами, — мы подробно разбирали в статье база знаний для AI-бота. В ТЗ достаточно ссылки на неё и ответственного.

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

Раздел 5. Интеграции

Для каждой интеграции — что агент читает, что пишет и с какими правами.

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

Отдельно укажите каналы с запасом. Если основной канал — один мессенджер, заложите в ТЗ возможность подключить второй без переделки базы знаний.

Если на этом месте ТЗ начинает разрастаться и непонятно, что действительно нужно на старте, — пришлите черновик, подскажем, что отложить на второй этап.

Раздел 6. Передача человеку

Здесь чаще всего ошибаются: агент либо зовёт человека по любому поводу, либо держит клиента до последнего. Пропишите:

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

Данные, безопасность и приёмка

Раздел 7. Данные и безопасность

• Какие персональные данные собирает агент — минимально необходимые.
• Согласие на обработку: где и в какой момент клиент его даёт.
• Где хранятся журнал диалогов и заявки. При сборе данных граждан РФ запись и хранение должны идти в базах данных в России — ч. 5 ст. 18 закона № 152-ФЗ.
• Какая модель используется и уходят ли в неё персональные данные.
• Кто из сотрудников и подрядчика имеет доступ к диалогам.

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

Раздел 8. Приёмка

Приёмка — сердце ТЗ. Без неё всё остальное — пожелания. Приёмку удобно обсуждать ещё тогда, когда вы выбираете подрядчика по внедрению ИИ.

1. Тестовый набор. 50–100 реальных вопросов из переписок, включая сложные и провокационные: «а скидку?», «у конкурентов дешевле», вопрос не по теме, грубость. Для каждого — эталонный ответ или ожидаемое действие.
2. Пороги. Например: 90% ответов верные по фактам; 100% вопросов из списка запретов отклонены или переданы человеку; ни одной выдуманной цены.
3. Кто проверяет. Сотрудник заказчика, который знает продукт, вместе с подрядчиком.
4. Пилот. 2–4 недели на части трафика, например только в нерабочее время, с чтением всех диалогов.
5. Метрики пилота из раздела 1 и решение по итогам: запуск на весь трафик, доработка или остановка.
6. Что передаётся заказчику: инструкции агента, база знаний, тестовый набор, описание интеграций, доступы.

Заполненный условный пример: доставка воды

Пример условный — компания и цифры придуманы для иллюстрации, это не кейс студии.

Компания доставляет питьевую воду в бутылях 19 литров в Новосибирске. Около 900 обращений в месяц в чате сайта и мессенджере, операторы работают с 8 до 20.

1. Цель и метрики. Принимать заказы и отвечать на вопросы круглосуточно. Метрики: 60% диалогов без оператора; заказы, принятые с 20:00 до 8:00; время первого ответа — до 1 минуты.

2. Задачи и границы.

3. Сценарии. Новый заказ; повторный заказ по номеру телефона; вопрос о зоне доставки; возврат пустых бутылей; жалоба на опоздание (сразу человеку); заказ для офиса больше 20 бутылей (человеку).

4. База знаний. Прайс (главный источник цен, обновляет руководитель), карта зон доставки, правила залога, 40 частых вопросов. Обновление — в день изменения.

5. Интеграции. CRM: читает историю заказов по телефону, создаёт заказ. Расписание доставки: читает свободные интервалы. Права на отмену — нет.

6. Передача человеку. Жалобы, офисные заказы, вопросы не из базы. Ночью — задача в CRM и сообщение клиенту «Оператор ответит после 8:00».

7. Данные. Имя, телефон, адрес. Согласие — перед первым вопросом об адресе. Журнал диалогов и заказы — на сервере в России. В модель не уходит телефон: агент передаёт его в CRM напрямую.

8. Приёмка. Тестовый набор — 80 вопросов. Пороги: 92% верных ответов, 0 выдуманных цен, 100% жалоб переданы человеку. Пилот — 3 недели только ночью.

Оценка нагрузки на модель для этого примера: 900 диалогов × ~12 000 токенов ≈ 10,8 млн токенов в месяц. По тарифам Yandex AI Studio на дату статьи это около 8 600 ₽ на YandexGPT Pro 5.1 или около 2 200 ₽ на YandexGPT Lite в синхронном режиме. Такую оценку полезно вписать в ТЗ, чтобы ежемесячные расходы не стали сюрпризом.

Чек-лист: ТЗ готово, если…

1. Цель сформулирована через процесс, есть 2–3 метрики и их текущие значения.
2. Есть список «агент не делает никогда» — минимум 5 пунктов.
3. Описаны 5–10 сценариев из реальных переписок.
4. Указан единственный источник цен и ответственный за обновление базы.
5. Для каждой интеграции понятно, что агент читает, что пишет и чего не может.
6. Прописаны триггеры передачи человеку и время ответа человека.
7. Известно, где хранятся данные и уходят ли персональные данные в модель.
8. Есть тестовый набор и пороги приёмки в цифрах.
9. Описан пилот: срок, часть трафика, решение по итогам.
10. Перечислено, что подрядчик передаёт заказчику по завершении.

Если хотите, чтобы ТЗ проверил человек, который запускал такие проекты, или собрать его вместе по вашим перепискам, — оставьте контакт.