В 2026 году большинство заявок в студию уже содержат пункт «нужен ИИ». Но заказчики часто приносят ТЗ, написанное под классический CRUD: экраны, кнопки, API. С AI так не работает — здесь нет детерминированного результата, есть вероятность, гиперпараметры и зависимость от данных. Если не зафиксировать это в ТЗ, проект уйдёт в бесконечные правки «бот глупый» или «рекомендации не те».
\n\nПочему стандартное ТЗ проваливается на AI-задачах
\nКлассическое ТЗ описывает поведение системы (пользователь нажал — открылось модальное окно). AI-задача требует описания качества результата (модель выдала релевантный ответ в 90% кейсов). Разница фундаментальна:
\n- \n
- Нет чётких входов/выходов — работаем с неструктурированными данными (текст, голос, фото). \n
- Нужны обучающая и тестовая выборки — без них невозможно проверить качество. \n
- Интеграция с LLM/векторными БД требует отдельного раздела по инфраструктуре и лимитам токенов. \n
Мы на проектах App72 начинаем с платного дискавери, чтобы превратить «хочу умного бота» в формализованные требования. Ниже — структура ТЗ, с которой разработка идёт без сюрпризов.
\n\nЧек-лист: обязательные разделы ТЗ на приложение с AI
\nИспользуйте эту таблицу как шаблон. Пункт «Не применимо» ставить нельзя — каждый пункт закрывает риск бюджета или сроков.
\n| Раздел ТЗ | Что фиксируем | Критерий приёмки (Definition of Done) |
|---|---|---|
| 1. Бизнес-сценарий и User Story | Конкретная задача: «Клиент задаёт вопрос по базе знаний → получает ответ со ссылкой на документ». Не «умный чат-бот». | Сценарий пройден end-to-end на стенде заказчика. |
| 2. Входные данные и источники | Форматы (PDF, JSON, API CRM), объём (Гб), частота обновления, язык, наличие разметки. | Тестовый датасет загружен, парсинг проходит без ошибок > 99%. |
| 3. Целевые метрики качества (Quality Gates) | Accuracy / F1 / Recall для классификации; BLEU / ROUGE / LLM-as-a-judge для генерации. Пороговые значения для запуска. | Метрики на тестовой выборке ≥ пороговых значений в ТЗ. |
| 4. Архитектура AI-пайплайна | Выбор модели (Open-source vs API), RAG/файн-тюнинг/промпт-инжиниринг, векторная БД, оркестратор (LangChain/LangGraph). | Схема согласована, PoC на 50 запросах работает в контуре. |
| 5. Интеграции и сайд-эффекты | Запись логов в БД, вызов вебхуков CRM, списание токенов с баланса пользователя, фоллбек на оператора. | Все интеграции покрыты автотестами, ошибки логируются в Sentry. |
| 6. Безопасность и приватность | PII-маскирование, on-premise vs cloud, соответствие 152-ФЗ, rate limiting, prompt injection protection. | Аудит безопасности пройден, чек-лист OWASP LLM Top 10 закрыт. |
| 7. Мониторинг и обратная связь | Дашборд: latency, cost per 1k tokens, % фоллбеков, user feedback (like/dislike). План ретренинга. | Дашборд доступен заказчику, алерты настроены. |
| 8. План запуска и роллбэка | Канареечный релиз (5% → 100%), фича-флаги, процедура отката на старую версию/оператора за 5 мин. | Роллбэк отработан на стейджинге, время < 5 мин. |
Данные — это новый код: как описать требования к датасету
\nСамая частая причина срыва сроков — «данные приготовят к следующему спринту». В ТЗ нужно зафиксировать:
\n- \n
- Минимальный объём для старта обучения/индексации (например, 500 диалогов для классификации интента). \n
- Формат разметки: JSONL с полями
input,expected_output,meta. \n - Политика обновления: кто и как пополняет базу знаний после релиза (CMS, админка, автоматический импорт из Confluence). \n
- Этичность/биас: проверка на токсичность, утечку ПДн, галлюцинации на контрольной выборке. \n
Без этого пункта команда AI-инженеров будет ждать данные вместо того, чтобы обучать модель. В пакете
Нужна оценка проекта? Напишите в Telegram или оставьте заявку на сайте — подготовим ТЗ и прототип.