ТЗ на разработку ИИ-агента: готовая структура и пример

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

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

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

Что должно решить ТЗ на ИИ-агента

До разработки документ должен дать одинаковые ответы заказчику и исполнителю на пять вопросов:

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

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

Бриф, техническое задание и системная инструкция — не одно и то же

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

Техническое задание фиксирует согласованный объём: состояния процесса, контракты данных, интеграции, права, отказные сценарии, требования к эксплуатации и приёмке.

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

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

Структура ТЗ на ИИ-агента из 13 разделов

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

Как описать требования к ИИ-агенту без двусмысленности

1. Начните с результата процесса, а не с технологии

Слабая формулировка: «создать интеллектуального агента для отдела продаж».

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

Во втором варианте видны событие, объект, выход и человек. Пока не обязательно выбирать модель, векторную базу или агентный фреймворк. Эти решения появляются после того, как команда понимает задачу.

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

2. Нарисуйте границы процесса

Запишите стартовое событие, финальный результат и системы по пути. Отдельно перечислите то, что сознательно не входит в первую версию.

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

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

3. Опишите вход и выход как контракт

Фраза «получает заявку из CRM» скрывает десятки решений. Укажите объект, поля, формат, источник, обязательность и поведение при отсутствии значения.

Для входа полезно зафиксировать:

• событие запуска и идентификатор объекта;
• обязательные и необязательные поля;
• допустимые форматы файлов и ограничения размера;
• язык, кодировку и часовой пояс;
• доверенный источник каждого поля;
• правила обработки пустых, конфликтующих и устаревших данных.

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

4. Разделите знания, инструменты и инструкции

Знания отвечают на вопрос «на каких материалах агент основывает вывод». Инструменты — «какие операции он может выполнить». Инструкции — «как он выбирает следующий шаг».

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

Для каждого инструмента задайте отдельный контракт:

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

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

5. Зафиксируйте уровни автономности

Не используйте один переключатель «автономный / неавтономный». Разложите каждое действие по риску:

1. чтение разрешённых данных;
2. подготовка черновика;
3. действие после подтверждения;
4. самостоятельное обратимое действие в ограниченном контуре;
5. запрещённое действие.

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

6. Опишите плохие сценарии раньше красивых

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

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

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

7. Согласуйте эксплуатационные ограничения

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

Не придумывайте точные числа до замеров. Пометьте неизвестные как [определить на пилоте], назовите способ измерения и владельца решения. Такая запись полезнее случайного требования «ответ не дольше двух секунд», которое не связано с процессом.

8. Требуйте наблюдаемость и версионность

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

Отдельно опишите:

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

Без этого демонстрация может работать, а эксплуатация останется непрозрачной.

Готовый шаблон ТЗ на ИИ-агента

Скопируйте блок в рабочий документ. Поля в квадратных скобках нужно заполнить, ненужные пункты — удалить с объяснением. Для предварительной оценки допустимы пометки неизвестно и решить на обследовании, если указан владелец решения.

1. Паспорт проекта

• Название: [рабочее название].
• Владелец бизнес-процесса: [роль и имя].
• Пользователи: [группы пользователей].
• Проблема текущего процесса: [что происходит сейчас].
• Целевой результат: [какой объект или решение должно появиться].
• Причина использовать агентную логику: [неструктурированные данные, контекстные решения, исключения].

2. Область решения

• Стартовое событие: [триггер].
• Конец процесса: [готовый результат и получатель].
• Входит в первую версию: [список].
• Не входит: [явные исключения].
• Зависимые команды и системы: [список].

3. Пользователи и роли

• Кто ставит задачу: [роль].
• Кто просматривает результат: [роль].
• Кто подтверждает рискованные действия: [роль].
• Кто разбирает исключения: [роль].
• Кто поддерживает решение: [роль].

4. Входы и выходы

• Входной объект и источник: [описание].
• Обязательные поля: [список].
• Необязательные поля: [список].
• Допустимые файлы и ограничения: [форматы и лимиты].
• Выходной объект и структура: [описание или схема].
• Получатель результата: [человек или система].
• Поведение при неполных данных: [правило].

5. Сценарии и состояния

• Основной сценарий: [шаги от входа до выхода].
• Ветвления: [условие → действие].
• Состояния задачи: [список].
• Условие успешного завершения: [проверяемое условие].
• Условия остановки: [список].

6. Данные и база знаний

• Разрешённые источники: [название, владелец, ссылка или система].
• Запрещённые источники: [список].
• Правило актуальности: [как определяется действующая версия].
• Персональные и конфиденциальные данные: [категории и правила].
• Хранение, передача и удаление: [политика].

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

Для каждого инструмента: [название, операция, вход, выход, права, лимит, тайм-аут, ошибки, повтор, откат, окружение].

8. Автономность и согласования

Для каждого действия: [объект, операция, уровень автономности, подтверждающая роль, лимит, запись в журнал].

9. Исключения и эскалация

Для каждого исключения: [событие, безопасное состояние, сообщение пользователю, получатель, данные для продолжения].

10. Качество и безопасность

• Недопустимые результаты: [список].
• Проверки входа: [список].
• Проверки ответа и действия: [список].
• Защита от повторных и запрещённых операций: [правила].
• Требования к аутентификации и доступам: [политика].
• Аварийная остановка: [механизм и владелец].

11. Нефункциональные требования

• Нагрузка и пики: [описание или способ замера].
• Время ответа: [по типам операции].
• Доступность и окна обслуживания: [требование].
• Лимиты расходов: [на запуск и период].
• Хранение и удаление журналов: [срок и правило].

12. Наблюдаемость и изменения

• Поля журнала запуска: [список].
• Бизнес-метрики: [список].
• Технические сигналы: [ошибки, задержки, расходы].
• Версионирование: [модель, инструкции, инструменты, база знаний, тесты].
• Порядок выпуска и отката: [шаги и роли].

13. Приёмка и передача

• Тестовый набор: [источник, состав, версия, владелец].
• Критерии по каждому сценарию: [ожидаемый результат].
• Критические ошибки: [список с нулевой терпимостью или отдельным порогом].
• Условие решения запускать / доработать / остановить: [правило].
• Передаваемые артефакты: [код, конфигурация, схемы, тесты, инструкции, журнал изменений].
• Обучение и поддержка: [формат, роли, каналы и границы].

Заполненный пример ТЗ на ИИ-агента

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

Задача: подготовка входящей B2B-заявки для менеджера

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

Не входит. Агент не рассчитывает цену, не обещает сроки, не отправляет ответ клиенту, не меняет существующие сделки и не удаляет записи.

Вход. Идентификатор формы, дата и время, имя, компания, контактный канал, текст обращения, согласие на обработку данных. Данные поступают с сервера формы. Если нет контактного канала или согласия, запись не передаётся в CRM и получает статус нужны данные.

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

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

Инструменты. Чтение входящей заявки, поиск по утверждённой базе, создание черновика в тестовом контуре CRM, запись события в журнал. Отправка сообщений и изменение цены отсутствуют в наборе инструментов.

Права. Данные заявки и каталог — чтение. Черновик CRM — создание только в отдельном статусе. Перевод в рабочую карточку — после подтверждения менеджером. Изменение и удаление существующих объектов запрещены.

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

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

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

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

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

Критерии приёмки ИИ-агента

Фраза «точность не ниже 95%» бесполезна без определения выборки, типа ошибки и метода подсчёта. Один неверный ответ и одно ошибочное действие имеют разную цену.

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

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

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

Что передать подрядчику вместе с ТЗ

Сам текст — только часть входного пакета. Для оценки обычно нужны:

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

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

Если предложения нескольких команд трудно сравнить, используйте 12 вопросов для выбора подрядчика по ИИ-агентам. А чтобы проверить, из каких блоков складывается оценка, заранее посмотрите факторы стоимости внедрения ИИ-агента.

Когда не нужно писать большое ТЗ самостоятельно

Не тратьте недели на документ, если ещё неизвестны реальные ветки процесса, качество данных и цена ошибки. В этом случае полезнее подготовить короткий бриф, примеры и список ограничений, а затем провести обследование вместе с исполнителем.

Большое ТЗ до исследования особенно опасно в трёх ситуациях:

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

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

Частые ошибки в техническом задании на ИИ-агента

Описывать функции вместо состояний и результатов

«Анализировать», «понимать» и «обрабатывать» нельзя принять. Назовите объект, состояние после действия и способ проверки.

Спрятать неопределённость под названием модели

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

Оставить интеграции одной строкой

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

Проверять только хороший путь

Полезность агента видна на неполных данных, конфликте правил, недоступной системе и запрещённом действии. Эти сценарии должны быть в тестовом наборе до приёмки.

Не назначить владельца после запуска

Инструкции, знания, модели и API меняются. Без владельца тестов и процесса качество будет ухудшаться незаметно.

Смешать пилот и всю будущую платформу

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

FAQ

Кто должен писать ТЗ на ИИ-агента

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

Можно ли получить оценку без готового ТЗ

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

Нужно ли указывать конкретную модель

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

Чем ТЗ на ИИ-агента отличается от ТЗ на чат-бота

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

Как часто обновлять ТЗ после запуска

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

Короткий вывод

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

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