Техническое задание на ИИ-проект — документ, фиксирующий сценарий, данные, ограничения и измеримые критерии приёмки. Ключевое отличие от классического ТЗ: у ИИ-системы нет признака «работает / не работает», поэтому приёмка ведётся по метрикам на проверочном наборе.
Классическое ТЗ описывает детерминированное поведение: «при нажатии кнопки открывается форма». ИИ-система отвечает верно в большинстве случаев и ошибается в остальных — и ТЗ обязано определить, какая доля ошибок допустима, на каких данных и как это измеряется. Без этого приёмка превращается в спор о вкусах.
Чем ТЗ на ИИ отличается от классического
Приёмка по метрикам, а не по признаку. Вместо «система правильно отвечает на вопросы» — «доля верных ответов не ниже 85% на согласованном проверочном наборе из 100 вопросов, доля галлюцинаций не выше 3%». Проверочный набор собирается и фиксируется до начала работ; как это делать — в статье про проверочный набор и бенчмарк.
Сценарий вместо перечисления функций. Классическое ТЗ перечисляет экраны и функции; ТЗ на ИИ описывает сценарий: какие обращения входят, какие — нет, что система делает с пограничными случаями, куда передаёт то, с чем не справилась. Границы сценария важнее его середины.
Примеры входов и выходов обязательны. Десяток пар «реальное обращение — приемлемый ответ» заменяют страницы описаний и оставляют меньше пространства для споров при приёмке. Примеры включают неудобные случаи: обращение с опечаткой, вопрос без ответа в базе, запрос вне сценария.
Недетерминированность и изменчивость вендора. Поведение модели меняется при обновлении API вендора без изменений с вашей стороны. ТЗ фиксирует это явно: переоценка на наборе при обновлениях — обязанность исполнителя, деградация ниже порогов — основание для доработки в рамках сопровождения.
Что должно быть в ТЗ обязательно
Сценарий и его границы. Типы обращений или документов, частота, язык, каналы. Что произойдёт с обращением вне сценария: отказ по шаблону, передача человеку, ничего. Это не деталь, а половина конструкции.
Измеримые критерии приёмки. Метрики с порогами: точность, полнота, доля корректных отказов, доля обращений, закрытых без человека. По каждой метрике — как измеряется и кем собирается набор. Порог без методики измерения неисполним.
Данные и доступы. Какие системы и выгрузки предоставляются, в каком виде, за какой срок; кто со стороны заказчика отвечает за доступы. Ограничения: персональные данные — только обезличенные, журналирование обращений обязательно. Проверьте реальное состояние данных до фиксации сроков — тема готовности данных.
Ограничения среды. Где работает система (облако, контур компании), допустимые внешние API, требования к времени ответа, нагрузка в пике, требования разграничения доступа к данным внутри системы.
Этапность и критерии перехода. Этапы с датами не работают без критериев перехода: «после достижения порогов на наборе — расширение сценария». Этапы: диагностика данных, пилот, внедрение, сопровождение — логика этапа проверки изложена в статье про пилотный проект.
Что не входит. Явный список исключений защищает обе стороны: интеграция с системой X, дообучение модели, поддержка второго языка — вне объёма. Отсутствие списка исключений означает, что спор о границах возникнет на приёмке.
Где уместно полное ТЗ и где достаточно одной страницы
Полное ТЗ — для внедрения и тендера. Несколько исполнителей, фикс-прайс, приёмка комиссией: здесь детальность окупается, потому что документ становится основой договора и арбитражем споров.
Одна страница — для пилота. Гипотеза, критерии успеха, сценарий, данные, срок. Развёрнутое ТЗ на пилот противоречит его смыслу: пилот и существует, чтобы выяснить детали, которые не известны заранее. Полное ТЗ пишется по результатам пилота — на знании, а не на предположениях.
ТЗ пишется до выбора модели, а не после. Требования вида «должна использоваться модель X версии Y» связывают руки: модель устареет или не подойдёт по стоимости. Фиксируйте требования к результату и ограничениям, выбор инструмента оставьте исполнителю с обоснованием.
Последовательность работы над ТЗ
Шаг 1 — сценарий и границы. Сначала фиксируется, какие обращения или документы входят и что происходит с остальными. Сценарий согласуется с владельцем процесса, а не с ИТ: у него ответственность за результат и знание потока.
Шаг 2 — примеры. Десяток реальных пар «вход — приемлемый выход», включая пограничные случаи. Примеры выявляют разногласия сторон до того, как они станут стоить этапа разработки: спор о примере занимает десять минут, спор о готовой системе — недели.
Шаг 3 — данные и доступы. Перечень источников, форма передачи, сроки, ответственные. Здесь же проверяется фактическая готовность данных — до подписания сроков, а не после.
Шаг 4 — метрики и пороги. Список метрик, методика измерения, набор, пороги приёмки и зона провала. Если пороги неизвестны — закладывается замер или пилот с мягкими порогами и пересмотр по итогам.
Шаг 5 — ограничения и этапность. Среда, безопасность, нагрузка, время ответа; этапы с критериями перехода и списком того, что в объём не входит. Документ ревьюят обе стороны; правки после подписания — приложениями с оценкой влияния.
Анти-паттерны
ТЗ без метрик. «Система должна давать качественные ответы» — приёмка превращается в обмен мнениями: исполнителю кажется качественно, комиссии нет. Механизм провала: у сторон нет общей линейки, решение принимает настойчивость, а не результат.
ТЗ на «искусственный интеллект» без сценария. «Внедрить ИИ для повышения эффективности процессов» — не ТЗ, а пожелание: под него подходит всё, и в итоге не работает ничего. Сценарий определяется до технологий; выбор сценария — решение заказчика, а не исполнителя.
Метрики без набора. Порог 90% указан, набор не определён: на лёгком наборе порог берётся впустую, на боевом — недостижим. Набор, его размер и источник фиксируются в ТЗ вместе с порогами.
ТЗ, скопированное из классической разработки. Экраны, роли, справочники — и ни слова о данных и метриках качества. Такой документ не покрывает главные риски ИИ-проекта и создаёт ложную уверенность.
Изменение критериев задним числом. Посреди работ порог «уточняется» под текущий результат. Если критерии реально неверны — меняйте отдельным приложением с осознанием причин, а не тихой правкой файла.
Частые вопросы
Насколько детальным должно быть ТЗ?
Детальность там, где последствия дорогие: критерии приёмки, данные, доступы, ограничения безопасности. Минимум там, где детали выяснятся работой: архитектура, выбор модели, внутренние пайплайны. Правило: ТЗ описывает результат и границы, а не способ достижения.
Можно ли обойтись без ТЗ?
Для пилота — да, одной страницей с гипотезой и критериями. Для внедрения с фикс-прайсом или несколькими исполнителями — нет: без документа споры о границах и качестве решаются переговорной силой. Даже минималистичное ТЗ лучше устных договорённостей.
Кто пишет ТЗ — заказчик или подрядчик?
Содержательную часть — сценарий, критерии эффекта, ограничения — пишет заказчик: это его процесс и его данные. Техническую — методику измерения метрик, требования к набору, архитектуру — формулирует исполнитель. Типовая схема: заказчик описывает сценарий и желаемый результат, исполнитель превращает это в проверяемые критерии, заказчик соглашается.
Что делать, если требования меняются по ходу работ?
Заранее заложить процедуру: изменения фиксируются приложением к ТЗ с оценкой влияния на срок и стоимость. Для ИИ-проектов это норма, а не исключение — сценарий уточняется на реальных данных. Опасно не изменение, а изменение без следа и без пересчёта сроков.
Как согласовать пороги метрик, если никто не знает реальных значений?
Пороги назначаются после короткого замера, а не из воздуха: прогон базового варианта на наборе 50–100 вопросов занимает дни и даёт стартовую точку. Другой путь — этап пилота в ТЗ с отдельными, более мягкими порогами, и финальные пороги фиксируются по итогам.
Как ТЗ связано с договором?
ТЗ — приложение к договору: критерии приёмки из ТЗ становятся основанием для оплаты этапов, а процедуры изменения — гарантией от одностороннего пересмотра. Кейсы споров почти всегда сводятся к фразам, которых не было в ТЗ, — поэтому спорные места пишутся, а не подразумеваются. Что фиксировать в договоре с ИИ-подрядчиком — в статье выбор подрядчика.
Нужно ли ТЗ на сопровождение?
Отдельный короткий документ — да: состав регулярных работ (пополнение набора, ревизия базы знаний, переоценка при обновлениях), время реакции на инциденты, порядок и стоимость доработок, метрики, по которым сопровождение считается работающим. Без этого «сопровождение» сводится к обращениям по мере поломок, а деградация системы обнаруживается пользователями раньше владельца.