ТЗ на ИИ-агента: как правильно составить техническое задание

Если что, бог Гермес на обложке статьи красуется не случайно. Это в честь агента Hermes, прямого конкурента OpenClaw.

Что такое ТЗ на ИИ-агента

ТЗ на ИИ-агента — это документ, в котором описаны бизнес-задачи агента, его сценарии работы, источники данных, интеграции, уровень автономности, ограничения, KPI и критерии приёмки.

Можно ли адаптировать ТЗ сайта для ИИ-агента?

Нет. Такое лучше не делать.

Поведение агента на 100% не детерминировано (предопределено), поэтому точного поведения, как у формы обратной связи сайта, с нынешними технологиями не достигнуть.

Главное отличие такого ТЗ от «классического» — это указание в нём ограничений, количества успешных операций в процентах и правил эскалации.

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

Начинайте не с ИИ, а с бизнес-задачи

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

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

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

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

Здесь понятная цель и понятны финансовые перспективы окупаемости: сократить нагрузку на отдел поддержки и перестать раздувать штат.

Что должно быть в техническом задании

Ниже обсудим пару очевидных, но важных вещей.

Кто будет пользоваться агентом

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

Для разных групп людей нужна разная точность в ответах агента. Условно, сотрудникам в некоторых сценариях хватит и 70% точных ответов, а вот клиентам может потребоваться 90% и больше.

Если агент даст немного не тот ответ менеджеру, в большинстве случаев у него есть время на разбор полетов: он может переспросить, проверить результат и при необходимости «перегенерировать» ответ.

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

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

Желательно всё это предусмотреть в договоре, чтобы потом не было: «А мы думали, агент сможет отправлять картинки, Telegram ведь умеет».

Агент же в чате на сайте будет иметь ровно те функции, которые ему может дать этот самый чат, поэтому стоит провести аудит его возможностей с аналитиком / программистом. Так будет понятно, какие возможности можно ещё добавить этому агенту и вообще оценить возможность его внедрения.

И самое важное — указать потенциальную нагрузку и желаемое поведение агента при её максимальных значениях.

Облачные нейросети смогут обрабатывать огромное количество чатов с людьми, но за это Вы будете платить монетой. При активном использовании старших моделей OpenAI банальные «привет» и «спасибо» от десятка пользователей вполне могут превратиться в дополнительные десятки, а иногда и сотни долларов в месяц.

Локальные же модели ограничены Вашими мощностями, поэтому за одновременную обработку 2–3 человек придётся платить месячную зарплату сторожа будки на парковке только за железо.

Условный урезанный Qwen запустится на видеокарте RTX 4090 — это которая около 300 000 рублей стоит, — но сложную операцию такая модель уже может не потянуть. А вот небольшой чатик с небольшой памятью на 2–3 человек держать — без проблем.

Опишите пользовательские сценарии

Внесите все пользовательские сценарии в ТЗ и договор по этой формуле:

Входные данные → действие агента → результат → что делать при ошибке.

Запрограммировать ИИ-агента — это 1/4 всей работы, а вот заставить делать то, что нужно, — это остальные 2/4. Ну и ещё 1/4 — это про безопасность, но об этом позже.

Пример: агент получил 3D-модель для печати в формате 3MF, проверил наличие пластика, технические характеристики и сравнил их с характеристиками принтера.

Если размер не подошёл — сообщил оператору и остановил работу. Если нет краски — написал техническому специалисту и «заморозил» работу до её появления. Если всё корректно — запустил печать.

Ну и всякие дополнительные условия:

• Во время «заморозки» проверять статус наличия пластика раз в 30 минут;
• Во время печати каждые 30 минут смотреть на состояние модели, если что-то не так — останавливать печать и звать технического специалиста;
• После завершения печати звать технического специалиста: звонить, писать в мессенджер;
• Уметь вносить корректировки в модель по требованию: менять размер, плотность.

Каждый важный пункт оформляете как use case и указываете все возможные действия и потенциальный результат.

Откуда агент берёт данные

Укажите в техническом задании, откуда и при каких обстоятельствах агент берёт данные: база знаний, CRM, ERP, сайт, документы, интернет, почта и т. д.

Каждая «база» должна быть описана и связана с use case.

Например, когда кто-то спрашивает у агента нужный номер телефона, откуда он его возьмёт? С Вашего сайта или из своего хранилища?

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

Статическое хранилище

Это какие-то заранее предзагруженные файлы, в которых записано всё, что нужно.

В целом самый простой вариант для реализации. Работает быстро.

Минус один — если актуальность данных поменяется, придётся ручками всё каждый раз менять. А если это остатки из 1С?

Динамическое хранилище

SQL-базы данных и похожие реализации. Данные могут легко обновляться через панель управления и всегда оставаться актуальными.

Но работа с ними устроена немного сложнее.

Обычно для статических документов делают поисковый индекс — это часть подхода RAG. Агент сначала находит нужные фрагменты информации, потом по ним находит нужный полный кусок и уже на его основе отвечает пользователю.

С SQL-базами всё немного сложнее: данные там постоянно меняются, поэтому агенту обычно дают отдельные инструменты для выполнения запросов к базе.

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

Какие интеграции нужны

Обязательно укажите, какие интеграции потребуются.

Например, чтобы слать SMS, агенту нужна интеграция с сервисом, который так умеет. А если агент должен уметь создавать платёжные ссылки, то нужен доступ к эквайрингу.

Сюда же относятся интеграции с облачными нейросетями: API каких нейросетей будет использовать Ваш агент?

Это может быть ChatGPT, DeepSeek, Qwen, MiniMax и так далее. Это при условии, если Вы не будете разворачивать нейросети для агентов на своём железе.

Определите границы автономности

Очень важный пункт. Почти так же важен, как безопасность.

Если агент чего-то не знает — он не загуглит. Он это выдумает!

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

Текущий ИИ — это не настоящий ИИ, а система, которая прогнозирует следующий «токен».

То есть нейросеть знает, что 2 + 2 = 4, не потому что посчитала, а потому что это встречалось огромное количество раз в данных, на которых её обучали.

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

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

Веселят недавние новости, где чат-бот поддержки McDonald's генерировал скрипты на Python по запросу пользователя. У последнего кончилась подписка на Claude, и он решил проблему таким способом — просто писал в чат-бот нужные ему вопросы, а тот отвечал. С точки зрения логики это некорректное поведение для бота поддержки.

Безопасность

Самый важный пункт.

Во-первых, если агент автономный, как OpenClaw и Hermes, и лежит на своём собственном сервере, все возможные доступы к нему должны быть под двойным замком: подключение только по SSH-ключам и только с доверенных IP-адресов.

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

Да, есть и российские облачные решения, например GigaChat и YandexGPT. Но соблюдать 152-ФЗ никто не отменял!

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

В-третьих, код агента должен быть защищён от prompt injection, то есть поведение из примера с McDonald's должно быть обработано.

В-четвёртых, бэкапы важных данных.

Автономные агенты могут себя сломать. Тот же OpenClaw и Hermes на это способны, поэтому держите копию файлов и копию данных рядом, чтобы быстро восстанавливать состояние агента.

Все эти вещи должны быть прописаны в договоре в обязательном порядке и максимально подробно.

KPI и критерии приёмки

Критерий «агент работает» — плохой критерий. Нужно заранее договориться, что именно будет считаться успешной работой.

Например:

• Не менее 90% типовых вопросов клиентов получают корректный ответ;
• Если агент не уверен в ответе — зовёт человека, а не придумывает;
• Не более 2 повторных попыток выполнить одну операцию;
• Среднее время ответа — не более 10 секунд;
• Не менее 70% обращений первой линии закрываются без участия оператора;
• Все действия агента записываются в логи;
• На тестовой выборке из 100 сценариев агент успешно выполняет минимум 90.

Цифры тут условные, под каждый проект они будут свои.

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

Не надо требовать от нейросети 100% успешных операций. Лучше заранее определить допустимый процент ошибок и описать, что агент должен делать в момент, когда ошибся или не уверен в результате.

Пример структуры ТЗ на ИИ-агента

Если собрать всё написанное выше, примерная структура ТЗ будет выглядеть так:

1. Бизнес-задача и цель внедрения;
2. Кто будет пользоваться агентом;
3. Пользовательские сценарии;
4. Источники данных;
5. Необходимые интеграции;
6. Границы автономности;
7. Правила эскалации;
8. Требования к безопасности;
9. Потенциальная нагрузка;
10. KPI и критерии приёмки;
11. Этап тестового запуска;

Необязательно самостоятельно расписывать каждый пункт на 50 страниц. На первом этапе достаточно хотя бы ответить на основные вопросы, чтобы разработчик понял, что Вы хотите получить.

Может быть, Вам показались новыми пункты «Правила эскалации» и «Этап тестового запуска», но это не совсем так.

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

Ну а «Этап тестового запуска» — это очевидный этап проверки агента. Он должен поработать как минимум пару недель под надзором разработчиков.

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

Скачать бриф на разработку ИИ-агента (Google Docs)

Частые ошибки при составлении ТЗ

1. Начинать со слов «хотим ИИ».

ИИ — это инструмент, а не задача. Сначала определите процесс, который хотите автоматизировать.

2. Не описывать плохие сценарии.

Все любят описывать, что агент должен делать, когда всё хорошо. А что он должен делать, если CRM лежит, клиент прислал непонятный файл или нейросеть не знает ответа?

Вот это зачастую даже важнее основного сценария.

3. Давать агенту слишком много свободы.

Не надо сразу давать новому ИИ-сотруднику доступ к банковскому счёту, базе клиентов и «кнопке удаления» важных данных.

Начните с минимальных прав и расширяйте их постепенно.

4. Не прописывать критерии приёмки.

Если в договоре написано просто «разработать ИИ-агента», то исполнитель всегда сможет сказать:

«Ну вот же он, работает».

А Вы будете говорить:

«Так он половину задач делает неправильно».

И формально оба будете правы. Хочется судиться?

5. Пытаться автоматизировать всё сразу.

Начните с одного понятного процесса. Сделали, проверили экономику, нашли проблемы — пошли дальше.

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

Что отправить разработчику для предварительной оценки

Чтобы разработчик смог хотя бы примерно оценить сроки и стоимость проекта, ему не нужно сразу присылать техническое задание на 100 страниц.

Для начала достаточно:

• Описать бизнес-процесс, который хотите автоматизировать;
• Рассказать, кто будет пользоваться агентом;
• Привести 3–5 реальных сценариев его работы;
• Перечислить системы, с которыми нужно интегрироваться;
• Указать примерную нагрузку;
• Рассказать, какие данные агент должен получать;
• Обозначить, что агент может делать самостоятельно, а где нужен человек;
• Показать, какой результат Вы хотите получить.

Если есть API-документация CRM, ERP или других сервисов — тоже приложите.

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

А дальше уже можно садиться с аналитиком и превращать всё это в полноценное техническое задание.

На этом закончим.

Главная мысль статьи простая: хорошее ТЗ на ИИ-агента начинается не с выбора ChatGPT, DeepSeek или какой-нибудь другой нейросети. Оно начинается с понимания Вашего бизнес-процесса.

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

Остальное можно обсудить с разработчиками.