Техническое задание на ИИ‑агента: шаблон, структура и примеры формулировок

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

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

Важная мысль: ТЗ на ИИ-агента отличается от обычного ТЗ на софт прежде всего разделом приёмки. Для классической программы часто можно проверить результат по строгому правилу: нажали кнопку, получили ожидаемое состояние. У агента иначе: на один и тот же вопрос он может ответить разными словами, и оба ответа будут корректными. Поэтому принимать ИИ-агента нужно не «на глаз» и не по красивой демонстрации, а через заранее подготовленный набор тестовых случаев.

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

Чем ТЗ на агента отличается от ТЗ на обычную программу

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

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

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

Структура ТЗ: одиннадцать разделов

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

1. Бизнес-цель и измеримый результат. Что должно измениться в деньгах, времени, конверсии, нагрузке или качестве обслуживания.
2. Описание процесса «как есть». Кто участвует сейчас, какие системы используются, сколько времени занимает процесс, где узкое место.
3. Границы агента. Что агент делает сам, что делает только с подтверждением человека, чего не делает никогда.
4. Сценарии эскалации на человека. Когда и куда агент передаёт диалог, что видит сотрудник после передачи.
5. Источники знаний и владелец актуализации. Документы, базы, регламенты, ответственный за обновление.
6. Инструменты и интеграции. CRM, ERP, телефония, календарь, склад, платёжные системы, внутренние API.
7. Каналы и интерфейсы. Сайт, мессенджеры, телефон, внутренний портал, особенности каждого канала.
8. Требования к данным и безопасности. Персональные данные, доступы, хранение логов, размещение в контуре компании.
9. Логирование, аудит и наблюдаемость. Какие действия агента записываются и как разбираются инциденты.
10. Критерии приёмки и тестовый набор. Набор реальных случаев, пороги качества, проверка выбора инструментов.
11. Эксплуатация. Поддержка, обновления, резервный сценарий, регламент изменений.

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

Раздел за разделом: что писать и как формулировать

Бизнес-цель и измеримый результат

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

Так не надо: «Повысить эффективность работы отдела продаж с помощью ИИ».

Так надо: «Сократить время первого ответа на входящую заявку с сайта с 40 минут до 2 минут в режиме 24/7. База: 380 заявок в месяц, из них 31% приходит вне рабочего времени».

Описание процесса «как есть»

Здесь фиксируется базовая линия: как процесс работает до внедрения. Нужно указать участников, системы, среднее время обработки, стоимость операции, частые ошибки и узкие места. Если до проекта не замерить исходное состояние, после запуска будет нечего сравнивать. Именно так появляются проекты, которые вроде бы «работают», но не дают доказуемого эффекта.

Рабочая формулировка: «Сейчас заявки с сайта попадают в CRM, затем распределяются между менеджерами вручную. В рабочее время средний первый ответ — 40 минут, вне рабочего времени — на следующий день. Около 18% заявок остаются без ответа дольше 12 часов. Цель агента — квалифицировать заявку, ответить на типовые вопросы и записать клиента на консультацию без ожидания менеджера».

Границы агента

Границы — один из самых важных разделов. Агенту нельзя просто написать «отвечает на вопросы клиентов». Такая фраза не защищает бизнес от ситуаций, когда агент пообещает скидку, подтвердит срок по договору или даст юридическую оценку. Нужны три зоны: делает сам, делает с подтверждением, не делает никогда.

Так не надо: «Агент отвечает на вопросы клиентов и помогает оформить заявку».

Так надо: «Агент самостоятельно отвечает по каталогу услуг, проверяет статус заказа, записывает на консультацию и создаёт заявку в CRM. С подтверждением менеджера отправляет коммерческое предложение и меняет дату записи. Никогда не называет индивидуальные скидки, не обсуждает сроки по конкретному договору, не подтверждает наличие сверх остатков в системе и не даёт юридические оценки».

Сценарии эскалации

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

Не менее важно описать, что видит сотрудник. Плохой сценарий — просто переключить клиента на оператора и заставить его повторять всё заново. Хороший сценарий — передать краткое резюме диалога, исходный вопрос, уже проверенные данные, причину эскалации и рекомендуемое следующее действие.

Источники знаний и владелец актуализации

ИИ-агент отвечает ровно настолько хорошо, насколько хороши источники, из которых он берёт знания. В ТЗ нужно перечислить документы, базы, страницы сайта, регламенты, инструкции, FAQ, коммерческие материалы. Для каждого источника полезно указать формат, объём, дату актуальности и владельца.

Так не надо: «Подключить все документы компании».

Так надо: «Подключить каталог услуг в формате PDF, прайс-лист в XLSX, регламент обработки заявок в DOCX и публичный FAQ на сайте. Владелец каталога и прайса — руководитель продаж, периодичность обновления — раз в месяц. При противоречии между прайс-листом и PDF приоритет имеет прайс-лист».

Инструменты и интеграции

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

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

Каналы, данные, безопасность и эксплуатация

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

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

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

Критерии приёмки: как принимать то, что каждый раз отвечает по-разному

Критерии приёмки — ядро ТЗ на ИИ-агента. Без них проект обычно принимают по демонстрации: подрядчик показывает несколько удачных диалогов, все кивают, агент выходит в работу, а через месяц начинается спор, почему он «не так» отвечает реальным клиентам. Для ИИ-агента демонстрация не является приёмкой. Приёмка делается через тестовый набор.

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

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

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

В ТЗ также стоит ограничить число шагов агента. Параметр max_steps задаёт максимальное количество рассуждений и вызовов инструментов в рамках одной задачи; на старте его обычно держат низким, например около 10. Если агенту нужно двадцать шагов, чтобы ответить на типовой вопрос, проблема чаще всего не в модели, а в архитектуре процесса.

Пример порогов приёмки: доля корректно обработанных простых случаев — не ниже 95%; доля корректных эскалаций на пограничных случаях — 100%; доля верного выбора инструмента — не ниже 90%; отсутствие необратимых действий без подтверждения — абсолютное требование. Последний пункт не должен усредняться: один ошибочный необратимый шаг может стоить дороже, чем десятки неточных ответов в FAQ.

Почему не стоит писать в ТЗ «точность 99,9%»? Потому что реальные агентские системы пока заметно далеки от такой надёжности на сложных сценариях. В исследовании ToolFailBench лучший результат среди 19 моделей на бенчмарке добросовестного использования инструментов составил 86,33% чистых вызовов. На бенчмарке клиентских задач с политиками и действиями τ²-bench-Verified лидеры показывали около 82% в среднем, а в самом трудном домене — примерно 70–74%. В работе SilentProbe при незаметном сбое внешнего API агенты обнаруживали проблему в 12% случаев, исправляли в 0%, а ложный успех сообщали в 41% случаев.

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

Метрики: четыре слова, которые постоянно путают

В проектах с чат-ботами и ИИ-агентами часто смешивают четыре метрики: отклонение, удержание, решение и решение с первого раза. Ошибка кажется терминологической, но на практике она меняет смысл отчёта. Можно показать красивое удержание и при этом не решить проблему клиента.

Практическое правило: настоящее отклонение подтверждается тем, что клиент не вернулся с той же проблемой в течение 5–7 дней. Если человек закрыл чат, потому что устал спорить с агентом, это не успех, хотя в сырой статистике такой диалог может выглядеть как «не эскалировался».

Разрыв между заявленным удержанием и реальным решением в отраслевых оценках может достигать 20–30 процентных пунктов. Инструмент, который показывает 70% удержания, на деле может давать около 45% реального решения. Поэтому в критериях приёмки лучше закреплять именно метрику решения, а не удержания. Если подрядчик отчитывается только удержанием, он выбирает показатель, который даёт самое красивое число.

Для ориентира: в отраслевых обзорах медианное отклонение по первой линии часто находится около 41%, верхний квартиль — ближе к 59%. По типам обращений разброс огромный: возвраты и сброс пароля могут автоматизироваться выше 70%, а сложные претензии — оставаться ниже 25%. Эти цифры стоит использовать осторожно, как порядок величин, а не как универсальную норму для любого бизнеса.

Семь ошибок в ТЗ, из-за которых проект потом переделывают

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

Вторая ошибка — отсутствие базовой линии. Если не замерить, как было до внедрения, потом невозможно доказать, что стало лучше. Третья — нет списка того, чего агент не делает никогда. Это самый частый источник инцидентов: агент начинает уверенно отвечать там, где должен остановиться.

Четвёртая ошибка — приёмка «на глаз». Красивая демонстрация не заменяет тестовый набор. Пятая — забытая эскалация: в ТЗ написано «переключить на оператора», но не указано, в какой канал, кому именно, с каким контекстом и в какие сроки.

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

Что не нужно писать в ТЗ

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

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

Также не нужно прописывать точные формулировки всех ответов агента. Для ИИ-системы это ложная точность. Лучше описать тон общения, запреты, структуру ответа, обязательные уточнения и источники. Конкретные реплики появятся после анализа реальных диалогов. Число пользователей тоже лучше описывать как вводные для расчёта нагрузки, а не как самостоятельное архитектурное требование.

Шаблон

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

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

Хороший шаблон дисциплинирует обе стороны. Заказчик заранее видит, какие решения нужно принять до старта. Подрядчик получает не абстрактное «сделайте ИИ-агента», а документ, по которому можно оценить архитектуру, интеграции, объём базы знаний и сложность приёмки.

Что делать дальше

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

Если нужен готовый документ, скачайте шаблон ТЗ, внесите исходные цифры и соберите 10–15 реальных обращений клиентов для будущего тестового набора. На разборе заполненного шаблона обычно быстро становится понятно, какой класс решения нужен: простой бот, агент с базой знаний, агент с инструментами или полноценная схема с интеграциями, логированием и регрессионными проверками.

Автор Антон Амосов

Поделиться Скопировано!