Самые дорогие споры с подрядчиком по AI-агенту начинаются не из-за технологии, а из-за фразы «агент отвечает на вопросы клиентов» в техническом задании. Под неё нельзя ни сделать работу, ни принять её, и через два месяца каждая сторона уверена, что права. ТЗ на AI-агента — это документ, который описывает не функции системы, а её поведение: что агент делает, чего не делает ни при каких условиях и по какому признаку стороны поймут, что получилось. Привычный список экранов и кнопок здесь не работает, потому что поведение модели кнопками не описывается. Ниже — из чего состоит рабочее задание, как написать его так, чтобы по нему можно было сдать проект, и какие разделы забывают чаще всего.
Список функций не описывает поведение агента
Привычное ТЗ описывает, что система умеет: такие-то экраны, такие-то операции. Для учётной системы этого достаточно — операция либо выполняется, либо нет. С агентом ключевое не набор умений, а поведение в неоднозначных ситуациях: клиент спросил то, чего нет в базе знаний, попросил скидку, начал грубить, задал вопрос про соседний продукт.
Поэтому рабочее задание отвечает на три вопроса: что агент делает, чего он не делает ни при каких условиях и по какому признаку мы поймём, что получилось. Если хотя бы на один нет ответа в документе, ответ появится позже — в переписке, на повышенных тонах.
В ТЗ на агента раздел «чего не делает» важнее раздела «что делает». Первый защищает от неприятностей, второй — только описывает ожидания.
Задание начинается с цели в деньгах, а не с описания агента
Прежде чем описывать поведение, стоит записать, зачем агент вообще нужен. Не «автоматизировать чат», а «отвечать на заявки ночью, пока их никто не обрабатывает» или «разгрузить первую линию от однотипных вопросов о статусе заказа». От этой формулировки зависит всё остальное: какие обращения агент ведёт, где передаёт человеку, какую цифру проверяют на приёмке.
Цель проверяется простым вопросом: какой показатель должен измениться и насколько, чтобы проект считался успешным? Если ответ «станет удобнее», задание писать рано. Так же мы начинаем разбор задачи в 404ai по методу «Цель → метрика»: сначала цель и метрика, потом состав работ, и только если метрика реалистична, — договор.
Шесть разделов, без которых задание не принять
- Процесс и границы. Какой именно процесс автоматизируется, где он начинается и где заканчивается. Не «продажи», а «первичная обработка входящих заявок из чата на сайте».
- Источники ответов. Откуда агент берёт факты: перечень документов и систем. Если чего-то нет в письменном виде — это отдельная строка работ.
- Запретные темы. Список вопросов, по которым отвечает только человек. Пишется явно, приложением.
- Правила передачи человеку. При каких признаках агент прекращает вести диалог, что передаёт вместе с ним и что видит сотрудник.
- Метрика приёмки. Одна цифра, способ её расчёта и период замера — зафиксированные до старта.
- Поведение при сбое. Кто отключает агента, за какое время и что происходит с потоком обращений в это время.
Каждый раздел закрывает конкретный риск. Границы — расползание объёма. Источники — выдуманные ответы. Запретные темы — юридические и репутационные ошибки. Передача человеку — потерянных клиентов. Метрика — спор при сдаче. Сбой — ночь, когда агент отвечает ерунду, а выключить его никто не может. Как устроить передачу диалога так, чтобы клиент не повторял всё заново, — в статье про эскалацию на оператора.
Пропущенные пункты всплывают, когда деньги уже потрачены
| Пропущено | Во что выливается |
|---|---|
| Право на незнание | Агент достраивает ответы вместо того, чтобы позвать человека |
| Владелец со стороны заказчика | Каждое решение уходит на согласование, срок плывёт |
| Владение данными и настройками | Обнаруживается при расставании с подрядчиком |
| Что считается успехом пилота | Пилот превращается в бесконечную демонстрацию |
| Кто платит за доработку интеграции | Спор на этапе, когда работы уже начаты |
Из всей таблицы я бы выделил право на незнание. Языковая модель по умолчанию стремится ответить, и если в задании не написано «когда в источниках нет ответа, агент говорит об этом и передаёт диалог человеку», она будет достраивать правдоподобное. Это не дефект конкретного подрядчика, а свойство технологии, и защищаться от него нужно формулировкой в задании, а не надеждой.
Требование годится, только если его можно проверить
Требование годится, если по нему можно проверить результат однозначно. «Агент общается вежливо» проверить нельзя — вежливость каждый понимает по-своему. «Агент называет себя и компанию в первом сообщении» проверить можно: это либо было, либо нет.
Практический приём — писать требования как проверяемые сценарии: если клиент спрашивает X, агент должен сделать Y. Десяток таких сценариев даёт больше, чем страница общих формулировок, и сразу превращается в тестовый набор для приёмки. Что проверять на этом наборе перед выходом на живой поток, — в разборе тестирования агента перед запуском.
Данные в задании описывают и то, что агенту знать нельзя
Отдельно стоит описать, что происходит с данными: где хранятся диалоги, кто имеет к ним доступ, попадают ли они к третьим лицам, как выгружаются по требованию. Для процессов с персональными данными это не формальность, а основание для работы.
Здесь же фиксируется, что в базу знаний не попадает: карточки клиентов, себестоимость, внутренние документы не по теме. Агент, которому дали «всё, что есть», рано или поздно процитирует клиенту то, что предназначалось для внутреннего пользования. Какие данные вообще нельзя отдавать внешним моделям, — в статье что нельзя загружать в нейросети.
Возражение: зачем ТЗ, если агента всё равно настраивают итерациями
Серьёзный контраргумент звучит так. Поведение агента невозможно предсказать заранее, реальные сценарии появляются только на живом потоке, а значит, подробное задание устареет в первую же неделю. Не проще ли запустить, посмотреть и докрутить, как это делают в гибкой разработке?
Наполовину это правда. Сценарии действительно приходят с потока, и задание, которое пытается предусмотреть всё, вредно. Но из этого следует не отказ от ТЗ, а другой его жанр. Итерации без зафиксированных границ и метрики превращаются в бесконечную настройку, где подрядчик всегда «ещё докручивает», а заказчик не может сказать, закончен ли проект.
Моя позиция: ТЗ на агента — это не спецификация поведения во всех случаях, а договор о границах и о том, как будет приниматься результат. Внутри границ итерации нормальны и ожидаемы. Сами границы — что агент не делает, где передаёт человеку, какая цифра означает успех — меняются только письменно.
Поведение задают примеры, а не перечень вопросов
Главная трудность такого задания в том, что поведение агента не сводится к списку. Перечислить все возможные вопросы клиентов невозможно, а описать общими словами — значит не описать ничего.
Работающий обход — примеры вместо перечисления. Берётся два-три десятка реальных обращений, и по каждому пишется желаемый ответ. Это и есть спецификация поведения: она однозначна, проверяема и понятна обеим сторонам без дополнительных объяснений.
Так же вводят в работу нового сотрудника первой линии. Ему не выдают список всех фраз, которые могут сказать клиенты. Ему дают несколько разобранных разговоров, перечень того, что обещать нельзя, и правило, кого звать, если непонятно. Агенту нужно ровно то же, только записанное.
Примеры подбираются не случайно. Примерно треть — типовые обращения, треть — пограничные, где неочевидно, отвечать или звать человека, треть — те, где агент точно должен отказаться. Последняя треть определяет качество задания: именно на ней потом расходятся ожидания.
Критерий приёмки должен давать одинаковый ответ обеим сторонам
Формулировка «система работает корректно» гарантирует спор при сдаче. Критерий должен быть таким, чтобы две стороны, применив его независимо, получили одинаковый ответ.
Конструкция состоит из трёх частей. Выборка: сколько случаев и как отобраны — случайно из реального потока, а не подготовлены исполнителем. Разметка: кто оценивает и по каким категориям, причём категорий немного и каждая определена. Порог: какая доля должна попасть в категорию «верно». О спорных случаях договариваются заранее; обычно достаточно правила «спорные считаются неверными» — оно простое и подталкивает исполнителя к однозначным ответам. Как пройти саму процедуру сдачи, — в статье про приёмку AI-проекта.
Изменения по ходу нормальны, неоформленные — нет
Изменения будут: после первых недель работы выяснится, что часть требований сформулирована неточно, а часть сценариев не предусмотрена. Это нормально и не является чьей-то виной.
Плохо не изменение, а его неоформленность. Устная договорённость «давайте ещё вот так» через месяц превращается в спор о том, входило ли это в объём. Достаточно короткой записи после каждой встречи: что решили, влияет ли на срок и на стоимость.
Полезно заранее договориться о запасе. Формулировка вида «до такого-то объёма уточнений включено, сверх — по отдельной оценке» снимает большую часть напряжения: мелкие правки перестают требовать переговоров, а крупные не проходят незаметно.
Процесс пишет заказчик, интеграции — подрядчик
ТЗ, написанное подрядчиком целиком, описывает то, что подрядчик умеет. ТЗ, написанное заказчиком без подрядчика, содержит требования, невыполнимые технически. Обе крайности обходятся дорого.
Рабочее распределение: заказчик пишет цель, процесс, границы, примеры и критерии приёмки — то, что знает только он. Подрядчик пишет техническую часть: интеграции, форматы, ограничения. Спорные места обсуждаются, а не отдаются одной стороне. Если подрядчик предлагает написать всё сам и не задаёт вопросов о ваших обращениях, это повод насторожиться: он описывает свой продукт, а не ваш процесс.
Когда отдельное ТЗ на агента писать не нужно
Честно говоря, не каждому агенту нужно подробное задание, а некоторым проектам не нужен и сам агент.
Задача типовая. Если нужен агент первой линии в мессенджерах с квалификацией заявок и ответами по базе знаний, это решается готовым инструментом с настройкой — например, Дирижёром, который тарифицируется от 2 ₽ за диалог. Задание здесь сводится к базе знаний, запретным темам, правилам передачи человеку и метрике. Шесть разделов остаются, но помещаются на пару страниц.
Процесс не описан даже для людей. Если сотрудники первой линии отвечают кто как умеет, а скрипта и базы знаний нет, начинать нужно с них. ТЗ на агента не заменит отсутствующий регламент, а только перенесёт хаос в автоматический режим. С чего начинать в этом случае, — в статье про базу знаний для AI-агента.
Обращений мало. Если в день приходит несколько вопросов и сотрудник отвечает на них за полчаса, агент не окупится ни при каком задании. Это один из случаев, когда мы в 404ai честно отказываемся от проекта.
Хорошее задание короче, чем кажется
Хорошее задание на первый процесс помещается на несколько страниц. Раздувание обычно означает, что в ТЗ пытаются описать сразу три процесса или подстраховаться от всех мыслимых ситуаций.
Второе особенно вредно: длинный перечень придуманных сценариев неизбежно содержит много редких случаев и упускает те, что случаются ежедневно. Реальные сценарии приходят с живого потока за первые недели, и добавлять их лучше по мере появления.
Дайте ТЗ человеку, который не участвовал в его написании, и спросите: что агент сделает, если клиент попросит скидку. Если ответ не находится в документе за минуту — раздел границ написан плохо.
По заданию видно, будет ли проект сдан
Что это меняет для заказчика? Качество будущего проекта можно оценить до подписания договора — по одному документу. Если в задании есть цель с цифрой, раздел «чего агент не делает», правило на случай незнания, два-три десятка разобранных примеров и критерий приёмки, который обе стороны применят одинаково, у проекта есть шанс закончиться сдачей, а не спором.
Проверить своё задание можно сегодня: откройте его и найдите ответы на три вопроса из начала статьи — что агент делает, чего не делает и по какой цифре вы поймёте, что получилось. Чего не нашлось, того и не хватает. Как выбрать процесс для первого агента, — в статье с чего начать внедрение, а что зафиксировать в договоре, — в статье про ответственность за ошибку AI.
