ИИ-проекты срываются не на коде, а на ТЗ: «умный ассистент для клиентов» превращается в бесконечные доработки, потому что никто не зафиксировал, что именно он должен делать и как это проверять. Хорошее ТЗ на ИИ-разработку отличается от обычного: в нём есть метрики качества модели, правила работы с данными и сценарии, где ИИ обязан передать человеку. Гайд даёт структуру такого документа.
Документ по этой структуре годится и для аутсорса, и для внутренней команды: он одинаково дисциплинирует обе стороны. Частный случай — ТЗ на ИИ-ассистента; здесь универсальный шаблон под любую ИИ-разработку: ассистент, классификация, извлечение данных, голосовые сценарии.
Экономика: правильное ТЗ экономит доработки, которые по рынку сентября 2026 стоят 2 800–3 800 ₽/ч. Бизнес-аналитика и подготовка ТЗ силами подрядчика — отдельная услуга; прототип по готовому ТЗ — от 90 000 ₽, пилот — от 480 000 ₽ за 4–6 недель.
Гайд для владельцев процессов и заказчиков разработки: он не требует навыков написания технической документации — структура из восьми разделов заполняется по шагам. Полученный документ одинаково понятен внутренней команде, внешнему подрядчику и сметчику; по нему же проходит приёмка, поэтому спорные места лучше закрывать на бумаге до старта, а не в переписке после сдачи.
Пошаговый план
Опишите процесс «как есть»
Зафиксируйте текущее состояние: кто участвует в процессе, какие действия совершает, сколько времени занимает каждый шаг, где хранятся данные. Не проектируйте будущее, пока не описали настоящее — иначе ТЗ будет описывать фантазию. Приложите реальные примеры: 5–10 типовых обращений, документов, диалогов. Примеры — самый ценный артефакт этого раздела: по ним подрядчик понимает задачу точнее, чем по десяти страницам текста.
Сформулируйте цель и границы
Цель — измеримая: «сократить время первого ответа с 4 часов до 15 минут», а не «автоматизировать поддержку». Границы — что входит и что не входит в разработку: каналы, категории обращений, интеграции. Отдельно перечислите, что ИИ делать не должен. Чёткие границы защищают бюджет: каждая «маленькая доработка» вне границ — это отдельное решение и отдельные деньги.
Определите класс данных и режим обработки
Перечислите, какие данные попадут в систему: публичные, внутренние, персональные. Для персональных данных и КИИ фиксируйте on-premise контур: ни один запрос не уходит за периметр организации. Российские API с договором обработки допустимы задачам с меньшей чувствительностью данных. Этот раздел согласуется с ответственным за персональные данные до старта разработки, а не при приёмке.
Опишите сценарии работы
Для ассистента — ветки диалога: типовые вопросы, уточняющие вопросы системы, сценарий «не знаю» с передачей человеку, эскалация. Для классификации — категории и правила пограничных случаев. Для извлечения данных — поля и форматы. Ключевой сценарий, который пишут чаще всего: что система делает, когда не уверена в ответе. Именно он отличает зрелое ТЗ от наивного.
Зафиксируйте источники знаний и данных
Перечислите базы знаний, из которых система отвечает: регламенты, инструкции, база знаний, каталоги. Укажите формат, объём, частоту обновления и ответственного за содержание. Если данных нет — включите в ТЗ этап их подготовки: инвентаризацию, очистку, нарезку. Правило: качество ответов ИИ не может быть выше качества базы; ТЗ должно это признавать явно.
Задайте метрики приёмки
Метрики — сердце ИИ-ТЗ. Пропишите измеримые критерии: доля автоматических ответов (например, от 25%), корректность ответов относительно базы знаний (например, от 90% на контрольном наборе), время ответа, доля эскалаций. Определите, кто и как измеряет на приёмке: контрольный набор вопросов, замер на пилоте. Без метрик приёмка превращается в спор о вкусах — со ставками 2 800–3 800 ₽/ч этот спор дороже самой разработки.
Опишите интеграции и окружение
Системы, с которыми работает ИИ: 1С, CRM, СЭД, телефония, сайт. Форматы обмена, направления потоков данных, права доступа системы. Ограничения окружения: закрытый контур, требования СЗИ, версии. Для агентных сценариев — лимиты полномочий: какие действия ИИ выполняет сам, какие только предлагает человеку. Раздел проверяется ИТ-службой заказчика на реализуемость до подписания.
Добавьте комплаенс и безопасность
Ссылки на применимые требования: 152-ФЗ (персональные данные), 243-ФЗ (учёт ИИ, маркировка контента), внутренняя политика использования ИИ. Требования к логированию: журнал запросов и ответов, retention. Проверка до запуска: аудит по OWASP LLM Top-10, при высоких рисках — red teaming. Включите требование зафиксировать систему в AI BOM сразу после запуска — не «потом».
| Раздел | Что содержит | Кто проверяет |
|---|---|---|
| 1. Описание процесса «как есть» | участники, шаги, время, примеры | владелец процесса |
| 2. Цель и границы | измеримая цель, что входит/не входит | заказчик |
| 3. Класс данных и режим | типы данных, on-premise/API, основания | ответственный за ПДн |
| 4. Сценарии работы | ветки диалога, «не знаю», эскалации | владелец процесса |
| 5. Источники знаний | базы, форматы, обновление, ответственный | владелец контента |
| 6. Метрики приёмки | доля авто-ответов, точность, время | заказчик + подрядчик |
| 7. Интеграции и окружение | 1С/CRM/СЭД, права, лимиты агента | ИТ-служба |
| 8. Комплаенс и безопасность | 152-ФЗ, 243-ФЗ, логи, аудит | ИБ + юрист |
Что делает ТЗ сильным
Силу документу дают четыре вещи. Примеры — реальные фрагменты процессов вместо абстрактных описаний: по десяти примерам разработчик понимает задачу точнее, чем по десяти страницах текста. Измеримость — каждая метрика приёмки записана числом и способом проверки. Границы — перечислено не только то, что входит, но и то, что не входит: именно «невходящее» защищает бюджет от ползучего объёма. Согласованность — класс данных и режим обработки подписаны ответственным за персональные данные до старта, а не на приёмке, когда менять архитектуру поздно.
Чек-лист
Готовность ТЗ к передаче в разработку — проверьте каждый пункт.
- Процесс «как есть» описан с примерами (5–10 штук)
- Цель измерима, границы перечислены явно
- Класс данных определён, режим согласован с ответственным за ПДн
- Сценарий «не знаю» и эскалация человеку описаны
- Источники знаний перечислены с ответственным за содержание
- Метрики приёмки записаны числами, не «качественно»
- Контрольный набор для приёмки собран до старта
- Интеграции проверены ИТ-службой на реализуемость
- Лимиты полномочий ИИ-агента установлены
- Комплаенс: 152-ФЗ, 243-ФЗ, логирование, требование аудита до запуска
- ТЗ включает фиксацию системы в AI BOM после запуска
- ТЗ согласовано владельцем процесса, ИТ-службой и ответственным за ПДн
- Определён порядок изменения ТЗ (who и как согласовывает доработки)
Ошибки новичков
Пять ошибок ТЗ, которые гарантированно удорожают ИИ-разработку.
- Метрики «на словах». «ассистент должен отвечать хорошо» не принимается; без чисел (точность, доля авто-ответов) приёмка — бесконечный спор
- Отсутствие сценария «не знаю». система выдумывает ответ вместо передачи человеку; это не баг, а дыра в ТЗ
- Данные «наверняка найдутся». база знаний не подготовлена — качество ответов низкое, а виноватым назначают разработчика; подготовка данных — раздел ТЗ
- Границы без «что не входит». каждая идея заказчика становится доработкой по ставкам 2 800–3 800 ₽/ч; объём растёт незаметно
- Комплаенс в конце проекта. требования 152-ФЗ/243-ФЗ вспоминают на приёмке, и система переделывается: режим данных закладывается в архитектуру, а не прикручивается
Инструменты и сроки
Достаточно шаблона структуры из таблицы выше и таблиц метрик. Срок: 3–5 рабочих дней при готовых примерах процесса; если данные в хаосе — аудит процессов и данных (от 90 000 ₽, 3–5 дней) перед написанием ТЗ. Прототип по готовому ТЗ — от 90 000 ₽.
- Шаблон структуры ТЗ (8 разделов из таблицы)
- Набор реальных примеров процесса
- Таблица метрик приёмки
Что получится в итоге
Готовое ТЗ — документ, по которому можно сметить, разработать и принять систему без споров: цель, сценарии, данные, метрики и границы на нескольких страницах. Такое ТЗ работает и как фильтр подрядчиков: сильная команда задаёт по нему вопросы, слабая — сразу обещает «всё сделать за неделю». Запуск пилота по нему — от 480 000 ₽ за 4–6 недель, с метриками, зафиксированными до старта.