ТЗ на ИИ-агента: пять пунктов, без которых проект разваливается

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

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

1. Одна задача, а не «отвечать на всё»

Плохо: «Агент консультирует клиентов по всем вопросам о компании и продуктах».

Хорошо: «Агент в чате на сайте отвечает на вопросы о статусе заказа, доставке и возврате. Всё остальное передаёт оператору».

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

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

2. Метрика качества — до старта, а не на приёмке

Без метрики приёмка превращается в «нравится — не нравится». Директор задал агенту три вопроса, на один получил странный ответ — проект «не работает». Или наоборот: демо прошло гладко, а в бою агент ошибается в каждом пятом разговоре, и никто этого не видит.

Метрика — это набор реальных вопросов с эталонными ответами и порог, который надо пройти. Вопросы берутся из истории переписки, а не придумываются: придуманные всегда проще настоящих.

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

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

3. Данные доступны за три дня

Проекты с агентами чаще всего буксуют не на моделях, а на доступах. База знаний существует в головах двух старших операторов. API CRM закрыто службой безопасности, и согласование займёт месяц. Выгрузку переписки «сделаем на следующей неделе» — и так шесть недель подряд.

Поэтому в ТЗ перечисляют источники и по каждому — кто даёт доступ и к какой дате:

• Откуда агент берёт ответы: база знаний, регламенты, прайс, FAQ. В каком виде они лежат и кто их обновляет.
• С какими системами работает: CRM, 1С, helpdesk, мессенджеры. Есть ли API и тестовый контур.
• На чём проверяем: выгрузка реальных обращений за последние месяцы.

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

4. Когда агент зовёт человека

Агент, который не умеет передать разговор, опаснее, чем отсутствие агента. В ТЗ описывают три вещи.

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

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

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

5. Кто владеет кодом

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

• исходный код и инструкции агента (промпты);
• проверочный набор вопросов с эталонами;
• база знаний и скрипты, которые её обновляют;
• документация по развёртыванию.

И отдельно — на чьё имя оформлены аккаунты: ключи API моделей, токены ботов, серверы. Они должны быть вашими с первого дня, иначе «передача проекта» превратится в переговоры. Подробнее — в статье «Что вы получаете на руки после проекта».

Чего в ТЗ быть не должно

• Названия модели. «Агент на GPT» — это решение, а не требование. Требование — «данные не покидают Россию» или «стоимость разговора не выше N рублей». Модель под него подберёт исполнитель.
• Текстов промптов. Они будут переписаны десятки раз за проект.
• Стопроцентной точности. Её не даёт ни агент, ни человек. Исполнитель, который на неё соглашается, либо не читал ТЗ, либо не собирается выполнять.
• Качеств без критерия. «Вежливый», «экспертный», «человечный» — проверить нельзя, значит, и принять нельзя.

Страница, которая получается в итоге

Если по каким-то пунктам ответа пока нет — это нормально, для этого и нужен аудит перед проектом. Мы проводим его бесплатно и за один рабочий день называем оценку; часть пунктов этой страницы обычно заполняется прямо на первом созвоне.