Техническое задание — документ, который фиксирует объём, цену и критерии приёмки будущего ассистента. Большинство споров о «дороговизне» ИИ-проектов возникает из размытых требований: заказчик ожидал «умного помощника», а получил бота по узкому сценарию. Ниже — восемь шагов, после которых у вас на руках понятное и бизнесу, и разработчику ТЗ.
Инструкция рассчитана на руководителей и аналитиков: технических навыков не требуется, а каждый шаг можно закрыть одной рабочей встречей с подрядчиком. Если по ходу появится вопрос — бесплатный разбор задачи в НЬЮ-ССТ идёт по регламенту: ответ за 2 рабочих часа, КП со сметой за 24 часа. Готовый документ затем ложится в основу договора и приёмки.
Пошаговый план
Опишите процесс и его боль
Зафиксируйте, какой процесс автоматизируете: кто обращается, по каким вопросам, что отвечает человек сегодня. Укажите объём — число обращений в месяц и долю типовых вопросов. Это база для расчёта эффекта: без цифр невозможно определить метрики будущего пилота. Формулировку «боли» запишите одной фразой — она станет первым абзацем будущего ТЗ.
Сузьте задачу до одного сценария
Правило первого пилота: один сценарий, одна аудитория, один канал. Например, «ответ на вопросы сотрудников по регламентам отпусков», а не «ИИ для всего HR». Узкий сценарий дешевле в реализации и проще в приёмке, а развернуть его на смежные процессы можно после подтверждения метрик. Границу сценария проверьте вопросом: «что ассистент точно не делает?» — ответ тоже включите в документ.
Составьте перечень источников знаний
Соберите документы, на которых ассистент будет отвечать: регламенты, инструкции, базы знаний, типовые ответы. Проверьте их актуальность и права на использование. Технология RAG строит ответы именно на этих документах — как это работает, разобрано в материале об обучении LLM на документах компании. Для старта достаточно 20–50 документов, закрывающих самые частые вопросы.
Зафиксируйте интеграции
Перечислите системы, с которыми ассистент должен работать: 1С, CRM, СЭД, корпоративный мессенджер. Для каждой укажите действие — прочитать заявку, создать задачу, передать черновик. Чем меньше интеграций в первой версии, тем дешевле и стабильнее старт. Для каждой интеграции укажите направление обмена: чтение, запись или двусторонняя связь.
Определите метрики приёмки
Задайте измеримые критерии успеха: доля автоматических ответов без эскалации, точность ответов по базе знаний, экономия часов специалистов в месяц. Метрики пилота — это те цифры, по которым вы честно решите, масштабировать проект или остановиться. Метрики согласуйте с подрядчиком письменно — они же критерии приёмки в договоре.
Задайте режим данных и ограничения
Укажите, какие данные попадут в ассистент: если есть персональные данные, предусмотрите правовое основание обработки и, для чувствительных контуров, закрытый on-premise вариант. Отдельным пунктом — запрет передавать данные во внешние сервисы без договора обработки. Режим данных — самый дорогой пункт ТЗ: его изменение после старта пересматривает смету.
Установите этапность и бюджет
Разбейте проект на ступени: прототип — от 90 000 ₽, MVP с интеграциями — от 690 000 ₽ за 2–3 недели, пилот LLM+RAG на одном процессе — от 480 000 ₽ за 4–6 недель. Этажность защищает бюджет: каждую следующую ступень вы оплачиваете только после подтверждённого эффекта предыдущей. Рыночные коридоры цен — в разборе стоимости ИИ-ассистента. Ступени фиксируйте отдельными строками бюджета: видно, за что вы платите на каждом этапе.
Приложите примеры диалогов
Добавьте 10–20 реальных вопросов пользователей и эталонных ответов. Это лучший способ показать разработчику ожидаемое поведение без длинных описаний. На таких примерах сразу тестируется и качество базы знаний, и тон ассистента. Диалоги берите из реальной переписки, а не из головы — «придуманные» вопросы искажают картину.
Частые ошибки
Эти четыре ошибки заказчики технических заданий совершают чаще всего — проверьте свой документ по списку до отправки подрядчику.
- ТЗ «как у всех». скопированное техзадание не отражает ваши процессы: подрядчик оценивает чужую задачу, а не вашу, и смета потом «плывёт»
- Отсутствие метрик приёмки. без измеримых критериев невозможно принять работу: каждая сторона понимает «работает» по-своему
- Все интеграции сразу. попытка закрыть десять систем в первой версии удлиняет проект в разы; интеграции добавляют ступенями после подтверждения эффекта
- Персональные данные «по умолчанию». если в базу знаний попадают ПДн без правового основания, проект стартует с нарушения 152-ФЗ
Инструменты и сроки
Для прохождения плана достаточно перечисленных инструментов; ориентир по времени — 3–5 рабочих дней на подготовку ТЗ силами заказчика. Если сомневаетесь в объёме какого-то раздела — оставьте пометку и вернитесь к нему после бесплатного разбора задачи с подрядчиком.
- Шаблон ТЗ из восьми разделов
- Таблица метрик пилота
- Подборка эталонных диалогов
Что получится в итоге
На выходе у вас документ на четыре-шесть страниц: сценарий, источники, интеграции, метрики, ограничения по данным и лестница бюджета от прототипа до полного контура. С таким ТЗ можно сравнивать предложения разных подрядчиков по одной шкале — вместо «поверьте, будет хорошо» вы видите состав работ, цену каждой ступени и критерии приёмки. По практике НЬЮ-ССТ, подготовленное ТЗ сокращает дорогу до старта разработки до нескольких дней.