Большинство споров между заказчиком и разработчиком AI-агента начинаются с одной фразы: «Мы же договаривались, что он будет это уметь». Договаривались устно, в переписке, «на созвоне». Через месяц агент отвечает клиентам не так, как представлял собственник, разработчик считает задачу выполненной, а бюджет уже потрачен. Причина почти всегда одна — техническое задание либо не писали вовсе, либо написали в стиле «умный бот, который отвечает на вопросы и продаёт».
Хорошая новость: ТЗ на AI-агента не требует технических знаний. Оно требует честного описания того, как процесс работает сейчас и каким должен стать. В этой статье — рабочий шаблон, примеры заполнения для разных отраслей и список пробелов, которые чаще всего всплывают уже после запуска.
Чем ТЗ на агента отличается от ТЗ на обычную программу
Классическое ТЗ описывает детерминированное поведение: нажал кнопку — получил результат. AI-агент работает с языковой моделью, и его поведение вероятностное. На один и тот же вопрос он может ответить разными словами, а в непредусмотренной ситуации — принять решение, которого никто не закладывал.
Поэтому в ТЗ на агента акцент смещается с «что он делает» на три других вопроса:
- Границы — что агент не должен делать ни при каких условиях.
- Источники правды — откуда он берёт цены, остатки, сроки, условия. Не «из головы», а из конкретной таблицы или CRM.
- Правила передачи человеку — когда агент обязан остановиться и позвать сотрудника.
Если эти три блока прописаны, остальное разработчик уточнит сам. Если нет — вы получите агента, который уверенно обещает скидку, которой не существует. О том, как это предотвратить технически, мы писали в статье про галлюцинации ИИ, но начинается защита именно с ТЗ.
Шаблон ТЗ: восемь разделов
Шаблон ниже рассчитан на документ объёмом две–четыре страницы. Больше не нужно: длинное ТЗ никто не читает, а короткое оставляет слишком много на усмотрение подрядчика.
1. Бизнес-цель одним абзацем
Не «внедрить ИИ», а измеримый результат. Пример: «Сократить время первого ответа на заявку с сайта с 2–3 часов до 2 минут в рабочее и нерабочее время, чтобы меньше заявок уходило к конкурентам». Если цель не получается сформулировать с цифрой — это сигнал, что процесс пока не понят.
2. Описание процесса «как сейчас»
Пошагово: кто получает заявку, где её видит, что проверяет, куда записывает, кому передаёт. Включите исключения: «если клиент пишет ночью — отвечаем утром», «если спрашивают про оптовые цены — передаём руководителю». Именно из этих исключений потом рождается половина логики агента.
3. Описание процесса «как должно быть»
Тот же процесс, но с агентом внутри. Укажите, какие шаги агент делает сам, какие — с подтверждением человека, какие остаются за людьми полностью. Полезная формулировка: «Агент имеет право…» и «Агент не имеет права…».
4. Каналы и системы
Перечислите всё, с чем агент должен взаимодействовать: Telegram, WhatsApp Business API, виджет на сайте, почта; amoCRM, Bitrix24, HubSpot, 1С, Google Sheets. Для каждой системы — есть ли доступ по API, кто его выдаст, какие данные читаем, какие пишем. Этот раздел чаще всего оказывается самым болезненным: выясняется, что у CRM тариф без API или что 1С стоит на сервере без внешнего доступа.
5. База знаний
Откуда агент берёт информацию для ответов: прайс, регламенты, FAQ, описания услуг. В каком виде они существуют (PDF, сайт, голова менеджера), как часто меняются, кто отвечает за актуальность. Если знания только «в голове», в ТЗ фиксируется задача по их сбору — и это отдельная работа, часто со стороны заказчика.
6. Сценарии и примеры диалогов
Пять–десять реальных диалогов из переписки с клиентами: типичные, сложные и те, что заканчивались конфликтом. Укажите для каждого, как должен ответить агент. Это самый ценный раздел ТЗ — он заменяет страницы абстрактных требований.
7. Ограничения, тон и эскалация
Запрещённые темы, формулировки, обещания. Тон общения («на вы, без эмодзи, коротко»). Условия передачи человеку: негатив, вопрос о возврате денег, запрос нестандартных условий, повторный вопрос без решения, прямое требование «позовите человека». Куда уходит эскалация — в какой чат, кому, с каким резюме.
8. Критерии приёмки
Как вы поймёте, что агент готов. Варианты: «На тестовом наборе из 50 диалогов не менее 90% ответов оценены как корректные», «Ни одного случая выдуманной цены в тесте», «Эскалация срабатывает во всех 10 контрольных ситуациях». Подробнее о метриках после запуска — в статье об измерении эффективности агента.
Пример заполнения: стоматологическая клиника
Цель: разгрузить администратора, который тратит ориентировочно половину дня на одни и те же вопросы в мессенджерах, и перестать терять вечерние обращения.
Как сейчас: пациенты пишут в WhatsApp и Telegram, администратор отвечает в перерывах между приёмами, вечером сообщения ждут до утра. Запись ведётся в медицинской информационной системе, в которую администратор переносит данные руками.
Как должно быть: агент отвечает на вопросы о ценах, адресе, подготовке к процедурам по базе знаний, предлагает свободные окна из расписания и создаёт предварительную запись. Подтверждает запись администратор утром одним нажатием.
Агент не имеет права: ставить диагноз, рекомендовать лечение, называть окончательную стоимость сложных работ, обсуждать осложнения. При любом вопросе о боли, кровотечении, самочувствии после процедуры — немедленная передача администратору с пометкой «срочно».
Критерий приёмки: 40 тестовых диалогов, из них 8 медицинских вопросов должны уйти на эскалацию без попытки ответить.
Пример заполнения: оптовый поставщик стройматериалов
Здесь акцент другой. Цель — квалификация заявок: отсеять частников с запросом на два мешка цемента и передать менеджеру тех, кто берёт объёмами.
Источники правды: прайс в Google Sheets с колонками «розница» и «опт от N единиц», остатки в 1С. Агент читает остатки, но не создаёт заказов — только формирует черновик для менеджера.
Правила: агент может называть розничные цены и наличие. Оптовые условия, отсрочки, скидки — только фраза «передаю менеджеру, он свяжется в течение часа» и карточка в amoCRM с заполненными полями: объём, регион, срочность, контакт. Для такой задачи полезно сразу продумать, как агент работает в связке с воронкой — об этом статья про AI-агента для обработки заявок.
Типичные пробелы, которые всплывают после запуска
За несколько проектов мы в AiKrok собрали список того, о чём в ТЗ забывают почти всегда.
- Кто обновляет базу знаний. Цены поменялись, агент называет старые. В ТЗ не было ответственного — виноват разработчик.
- Что делать с данными клиентов. Куда уходит переписка, какая модель её обрабатывает, можно ли передавать персональные данные в облако. Для медицины, юристов, финансов это не формальность — и этот вопрос нужно закрыть до запуска.
- Рабочее время и режим. Агент работает круглосуточно, а эскалация ночью уходит в пустоту. Нужно прописать: ночью агент собирает контакт и обещает ответ утром, а не пишет сотруднику в три часа ночи.
- Языки. Для бизнеса в Грузии или Казахстане клиенты пишут на двух–трёх языках. Если это не указано, агент будет отвечать на том языке, на котором его тестировали.
- Лимиты и стоимость. Сколько запросов в месяц ожидается, какой бюджет на API модели приемлем. Без этого разработчик выберет самую сильную и самую дорогую модель.
- Повторные обращения. Должен ли агент помнить клиента, который писал неделю назад? Это влияет на архитектуру и стоимость.
- Что считается успехом через три месяца. ТЗ заканчивается приёмкой, а бизнес живёт дальше. Полезно сразу зафиксировать, какие показатели смотрим после запуска и кто за них отвечает.
Где ТЗ не поможет
Если процесс не устоялся и каждую неделю меняется, ТЗ будет устаревать быстрее, чем его прочитают. В таких случаях честнее начать с короткого пилота: описать только цель, границы и эскалацию, запустить агента на часть обращений и дописывать требования по ходу. Так работает подход MVP за две недели — первая версия намеренно узкая, а ТЗ растёт вместе с продуктом.
Вторая ситуация — когда заказчик пытается через ТЗ зафиксировать стопроцентную точность ответов. Для языковых моделей такого критерия не существует; реалистичные формулировки — доля корректных ответов на тестовой выборке и ноль критичных ошибок в контрольных сценариях.
С чего начать
- Выгрузите 30–50 реальных диалогов с клиентами за последний месяц. Это основа разделов 2 и 6.
- Напишите цель с цифрой. Если не получается — обсудите с командой, что именно болит.
- Составьте список «агент не имеет права». Обычно он важнее списка «агент умеет».
- Проверьте доступы к системам до подписания договора, а не после.
- Отдайте черновик разработчику и попросите задать вопросы. Хороший подрядчик найдёт в нём пробелы за полчаса — это нормально и дешевле, чем находить их после запуска.
ТЗ на AI-агента — не формальность для договора, а инструмент, который экономит недели переделок. Два–четыре часа на его подготовку окупаются уже на первом созвоне с разработчиком. Если сомневаетесь, с какой стороны подступиться, — приходите на бесплатную консультацию с вашим черновиком, разберём вместе.