Как составить техническое задание на AI-автоматизацию бизнес-процесса

Коротко

• ТЗ на AI-автоматизацию держится на пяти вещах: требования, входы, выходы, исключения, критерии приёмки. Если чего-то из этого нет — вы не сможете проверить результат.
• Начинайте не с «хочу AI», а с одного узкого процесса и его границ: где он начинается, где заканчивается, что в него не входит.
• Отдельно и подробно опишите исключения — что агент делает, когда данных не хватает, ответ неоднозначен или цена ошибки высокая. Здесь живёт human-in-the-loop.
• Критерии приёмки формулируйте в цифрах и на конкретных примерах, а не «работает хорошо».
• Заложите логи, права доступа и точки контроля человеком с самого начала — дописать это потом дороже, чем спроектировать сразу.

Проблема: «сделайте нам ИИ» — это не задача

Типичная картина в малом бизнесе. Владелец видит, что менеджеры тонут в однотипных вопросах в Telegram и на WB, и формулирует задачу так: «Хочу, чтобы нейросеть отвечала на вопросы клиентов». Дальше начинается разработка, и почти сразу всплывают вопросы, на которые в этой формулировке нет ответов.

Отвечать на все вопросы или только на типовые? Что делать с вопросом «где мой заказ» — агент лезет в CRM или зовёт человека? Можно ли ему обещать сроки доставки? Возврат он оформляет сам или только объясняет процедуру? Что происходит, если клиент пишет матом или угрожает вернуть товар и «оставить единицу»?

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

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

Золотая середина — документ на 3–6 страниц, который отвечает на пять групп вопросов. К ним и перейдём.

Workflow: пять блоков рабочего ТЗ

1. Требования — что и зачем автоматизируем

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

Опишите три вещи:

• Бизнес-цель. Не «внедрить ИИ», а измеримый результат: снять с менеджеров 200 однотипных сообщений в день, сократить время первого ответа с 40 минут до 1 минуты, разгрузить оператора в ночные часы.
• Границы процесса. Где он начинается (клиент задал вопрос в боте) и где заканчивается (клиент получил ответ или разговор передан человеку). Всё, что за границами, — не ваша задача в этом ТЗ.
• Что НЕ входит. Явно: агент не оформляет возвраты, не меняет данные в заказе, не даёт скидки. Этот пункт экономит недели споров.

Если сомневаетесь, стоит ли вообще браться за процесс, посмотрите разбор как понять, что процесс пора автоматизировать — он про отбор кандидатов.

2. Входы — на каких данных работает агент

AI-агент хорош ровно настолько, насколько хороши его данные. В ТЗ перечислите все источники, к которым он обращается, и в каком виде.

Для бота поддержки магазина это может быть: база знаний по товарам (где лежит, в каком формате), статус заказа из CRM или API маркетплейса, история переписки с клиентом, правила по возвратам и доставке. Для каждого источника укажите: откуда берём, как часто обновляется, что делать, если источник недоступен.

Отдельно — формат входящего запроса. Текст в Telegram? Голосовое? Сообщение с фото бракованного товара? Комментарий под карточкой на Ozon? Если агент должен работать с картинками или голосом, это отдельные требования, а не «ну там же ИII, он разберётся».

Здесь же — примеры реальных входов. Соберите 15–20 настоящих сообщений клиентов, включая кривые, с опечатками и не по теме. Это станет и материалом для настройки, и частью тестов.

3. Выходы — что агент производит

Что именно получается на выходе и куда оно идёт. Ответ клиенту в чат? Запись в CRM? Задача менеджеру? Строка в отчёте? Уведомление в Telegram-канал команды?

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

Полезный приём: для каждого типа входа напишите один-два эталонных выхода. «Клиент спросил про статус заказа №123 → агент отвечает вот так». Эти пары «вход → правильный выход» потом станут критериями приёмки.

4. Исключения — где включается человек

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

Опишите, что агент делает, когда:

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

Для каждого исключения — конкретный сценарий: что агент говорит клиенту, кого и как уведомляет, что записывает в лог. Это и есть human-in-the-loop на практике: не «человек где-то там контролирует», а «вот в этих точках и вот таким образом».

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

5. Критерии приёмки — как понять, что работа сдана

Без этого блока приёмка превращается в спор «мне кажется, плохо» против «а по-моему, норм». Формулируйте проверяемо.

Хорошие критерии выглядят так:

• на наборе из 50 реальных вопросов агент даёт корректный ответ минимум в 45 случаях, а в остальных — корректно передаёт человеку (не выдумывает);
• ни в одном из тестовых диалогов агент не обещает конкретную дату доставки и не оформляет возврат самостоятельно;
• при недоступности CRM агент не падает, а отвечает заглушкой и зовёт оператора;
• каждое действие агента видно в логе: что пришло, что он решил, что сделал, к каким данным обращался;
• среднее время ответа в чате — не больше 5 секунд.

Обратите внимание: критерии не «agent работает идеально», а «в 45 из 50, а остальные безопасно эскалированы». С вероятностными системами так и надо — вы принимаете не безошибочность, а предсказуемое поведение на ошибках.

ROI: сколько это экономит и когда окупается

ROI считается не по строчке «внедрили AI», а по конкретному процессу с цифрами из блока требований.

Возьмём бот поддержки из примера. Менеджеры обрабатывали 200 однотипных сообщений в день, по 3 минуты на каждое — 10 часов работы. Агент закрывает 70% из них полностью и ещё 15% готовит к передаче с готовым контекстом. Даже если считать только полностью закрытые, это около 7 часов ручной работы в день, которые уходят на другое.

Дальше — простая арифметика. Стоимость часа менеджера умножаете на сэкономленные часы за месяц, вычитаете стоимость разработки и ежемесячные расходы на API/поддержку и смотрите, за сколько месяцев проект выходит в плюс. Для узкого, хорошо описанного процесса это обычно 2–4 месяца.

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

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

Риски и как их закрыть в ТЗ

• Галлюцинации. Агент уверенно выдумывает факт — срок, наличие, условие возврата. Лечится строгим требованием отвечать только по данным из источников и эскалацией при их нехватке. Пропишите это как требование, а не как надежду.
• Расширение полномочий по-тихому. Начали с «отвечать на вопросы», через месяц захотелось «пусть ещё и возвраты оформляет». Каждое новое действие — отдельная оценка рисков и обновление блока исключений, а не «добавьте по-быстрому».
• Права доступа. Агент не должен иметь доступ к тому, что ему не нужно для задачи. Читать статусы заказов — да, лезть в финансы или персональные данные всех клиентов — нет. Опишите минимально необходимый набор прав.
• Отсутствие логов. Если не видно, что и почему сделал агент, вы не разберёте инцидент и не докажете, что было. Лог — обязательное требование, а не опция.
• Ломкость на обновлениях. Поменяли промпт или модель — поведение поплыло. Поэтому нужны версии промптов и тот самый набор тестовых диалогов, который прогоняется перед каждым изменением.

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

Как это внедрить: порядок действий

1. Выберите один процесс. Самый частый, самый однотипный, с понятной ценой ошибки. Не весь отдел поддержки, а «вопросы о статусе заказа».
2. Соберите реальные данные. 15–30 настоящих входов, включая неудобные. Без них ТЗ пишется в вакууме.
3. Пройдите пять блоков. Требования, входы, выходы, исключения, критерии приёмки — по каждому конкретика и примеры.
4. Отдельно опишите точки контроля человеком и права доступа. Это не приложение к ТЗ, а его часть.
5. Согласуйте критерии приёмки до старта разработки. Если по ним нельзя однозначно принять работу — переписывайте, пока можно.
6. Запускайте в режиме подсказчика. Первые недели агент готовит ответы, а человек подтверждает. Так вы соберёте статистику ошибок на реальном потоке и только потом отпускаете безопасные сценарии в автономный режим.

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

FAQ

Чем ТЗ на AI-автоматизацию отличается от обычного ТЗ на разработку? Обычная программа делает ровно то, что закодировано. AI-агент работает вероятностно и может ошибаться, поэтому в ТЗ появляется целый блок про исключения и поведение при ошибках, а критерии приёмки формулируются не как «всегда правильно», а как «правильно в N случаях из M, остальные безопасно эскалированы».

Насколько подробным должно быть ТЗ? Обычно 3–6 страниц: пять блоков с конкретикой и примерами. Меньше — не по чему принимать работу, больше — как правило, вода или преждевременная детализация интерфейса вместо описания логики решений.

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

Что писать в критериях приёмки, если результат вероятностный? Задавайте порог на тестовом наборе и правила безопасности. Например: на 50 реальных запросах не меньше 45 корректных ответов; ни одного случая, когда агент выдумал факт или выполнил запрещённое действие; при нехватке данных — всегда эскалация. Это проверяемо.

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

Можно ли начать без идеального ТЗ? Можно и нужно начать с одного узкого процесса и пилота в режиме подсказчика. Но пять блоков стоит прописать даже для пилота — иначе нечем мерить результат и не с чем сравнивать после запуска.