Шаблон техзадания на LLM‑бота: требования, интеграции, безопасность, метрики

Представьте ситуацию: понедельник, 9 утра, вы запускаете умного AI-бота для клиентской поддержки. К обеду выясняется, что бот пообещал всем клиентам скидку 90% — просто потому, что в его промпте не было четких ограничений, а в базе знаний лежал старый документ 2010 года про акцию. Телефон разрывается, маркетинг в истерике, CTO седеет на глазах.

Знакомая картина? К сожалению, мы видели её не раз. Когда команды начинают LLM-проект, все сразу хотят «писать промпты» и спорить, что лучше — GPT-4 или Claude 3. Но почему-то забывают о фундаменте. А хорошее ТЗ (или PRD — Product Requirements Document) — это не бюрократия и не пыльная папка для галочки. Это ваш спасательный жилет, который вытащит проект, когда всё пойдет не так.

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

TL;DR — Самое важное в ТЗ

Мы заметили, что большинство факапов с LLM-ботами происходят из-за пробелов именно в этих шести областях. Проверьте себя:

• Деньги и Цели: Зачем нам бот? Снизить нагрузку на поддержку, повысить NPS, продавать 24/7? Если ответ «потому что у конкурентов есть» — подумайте ещё раз.
• Границы (Scope): Где бот работает (WhatsApp, сайт, Telegram), а куда ему лезть категорически запрещено. Чёткие границы спасут от 80% проблем.
• Данные: Откуда бот берет знания? Насколько они чистые и свежие? Устаревшая база знаний — бомба замедленного действия.
• Люди (RACI): Кто пишет промпты? Кто отвечает, если бот нагрубит клиенту? Кто правит базу знаний? Без ответственных — хаос.
• Паранойя (Безопасность): Как мы прячем персональные данные и не даем боту сболтнуть лишнего. Один слив — и репутация под откос.
• Критерии успеха: Как мы поймем, что пора открывать шампанское? Или срочно откатывать релиз? Без цифр — только эмоции.

Если все шесть пунктов проработаны — у вас крепкий фундамент. Теперь можно детализировать.

Структура документа (Шаблон)

Прежде чем нырять в детали, давайте посмотрим на карту. Вот структура, которую мы рекомендуем использовать. Можете скопировать её как оглавление вашего документа в Notion, Confluence или обычном Google Doc — не важно, где вы ведёте документацию.

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

• 1. Executive summary — суть проекта для тех, кто читает по диагонали (спойлер: это ваше руководство).
• 2. Scope — каналы, языки, режим работы. Где бот живёт, а куда ему вход воспрещён.
• 3. Сценарии — о чём и как будет говорить бот. Конкретные диалоги, а не абстракции.
• 4. Источники данных — CRM, база знаний, внешние API. Откуда бот черпает мудрость.
• 5. Интеграции — техническая «мякотка» для разработчиков.
• 6. Роли (RACI) — кто за что отвечает. Чтобы потом не искать виноватых.
• 7. Безопасность — красные линии и защита данных. Параноики живут дольше.
• 8. Логи и мониторинг — глаза и уши техподдержки. Без них вы слепы.
• 9. Метрики успеха — KPI и цифры. Как понять, что всё работает.
• 10. План пилота — дорожная карта запуска. От тестов до продакшена.
• 11. Риски — что может пойти не так. Лучше знать заранее.

Теперь разберём каждый раздел подробнее. Приготовьтесь — будет много практики и минимум воды.

1) Цели и бизнес-гипотезы

Первый и самый важный вопрос: «Зачем?». Звучит банально, но именно здесь спотыкается большинство проектов. Если честный ответ — «потому что AI сейчас в тренде» или «у конкурентов есть, и нам надо» — остановитесь и подумайте ещё раз.

Бот должен решать конкретную бизнес-боль. Не абстрактную «цифровую трансформацию», а измеримую проблему: операторы тонут в однотипных вопросах, клиенты ждут ответа по 10 минут, продажи останавливаются в нерабочее время.

• Миссия: Сформулируйте в одном предложении. «Разгрузить первую линию поддержки на 30%» или «Продавать 24/7 без ночных смен». Чем конкретнее — тем лучше.
• KPI: Переведите миссию в цифры. FCR (First Contact Resolution) ≥ 45%, CSAT ≥ 4.6, время ответа < 3 секунд. Без цифр — нет контроля.
• Экономика: Посчитайте юнит-экономику. Сколько стоит один диалог с оператором? А с ботом? Какую экономию ожидаете? Например: «Снизить стоимость контакта с 500₸ до 50₸».

Когда мы начинали один из проектов, заказчик сказал: «Хотим современного бота». Мы потратили две недели, чтобы докопаться до настоящей цели — оказалось, им нужно было сократить время обработки заявок с 24 часов до 2. Вот это цель. А «современный бот» — это следствие.

2) Scope и каналы

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

Чётко очертите границы. Запишите, что бот делает, а что — категорически нет. Эти списки потом станут вашим щитом от бесконечных «а давайте ещё добавим...».

• Каналы: Где будет жить бот? Виджет на сайте, WhatsApp, Telegram, Instagram? Наш совет — начните с одного канала. Освойте его, отладьте, а потом масштабируйте. Пытаться запустить везде сразу — гарантированный хаос.
• In Scope (Что делаем): Конкретный список. Топ-20 частых вопросов, проверка статуса заказа, запись на приём, информация о ценах. Чем точнее — тем легче потом оценить, справляется ли бот.
• Out of Scope (Чего НЕ делаем): Тоже конкретный список. Жалобы — сразу на человека. Возвраты денег — только через оператора. Юридические консультации — ни при каких обстоятельствах. Эти «красные линии» спасут вас от репутационных потерь.

Хороший scope — это когда любой член команды может за 30 секунд ответить на вопрос «А бот это умеет?». Если для ответа нужно лезть в документацию — scope недостаточно чёткий.

3) Пользовательские сценарии

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

Представьте, что вы пишете сценарий для фильма. Каждый диалог — это мини-история с началом, серединой и концом. Карта пути клиента (Customer Journey Map) здесь очень поможет — она покажет все точки касания и возможные развилки.

• Продажи: Клиент пишет «Хочу купить ноутбук» → Бот уточняет бюджет и задачи → Подбирает 2-3 варианта → Отправляет ссылку на оплату или переводит на менеджера для сложных случаев.
• Поддержка: «Где мой заказ?» → Бот просит номер заказа или находит его по номеру телефона → Запрашивает статус в CRM → Отвечает: «Ваш заказ №12345 передан в доставку, ожидайте курьера сегодня с 14 до 18».
• Fallback (План Б): Клиент написал что-то непонятное. Бот попробовал уточнить — не помогло. Ещё раз — снова мимо. Что дальше? Правильный ответ: молча передать диалог оператору с пометкой «AI не справился» и всей историей переписки.

Особое внимание — к fallback-сценариям. Это то, что отличает хорошего бота от бесячего. Плохой бот будет бесконечно переспрашивать «Я вас не понял, повторите». Хороший — тихо позовёт человека и передаст контекст.

Мы рекомендуем прописать минимум 10-15 конкретных сценариев до начала разработки. Это кажется занудством, но экономит недели на этапе внедрения.

4) Данные и источники (RAG)

LLM сам по себе — это просто «мозг», который умеет красиво говорить. Но без памяти он бесполезен для вашего бизнеса. Ему нужны актуальные данные: о ваших продуктах, процессах, клиентах. И здесь начинается самое интересное — RAG (Retrieval-Augmented Generation).

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

• CRM-сущности: К каким полям сделки и клиента нужен доступ? Имя, история покупок, текущий баланс, статус заказа. Но не всё подряд — только то, что реально нужно для ответов.
• База знаний: Соберите все источники: Confluence, PDF-инструкции, FAQ на сайте, внутренние регламенты. Важно: проверьте их на актуальность перед загрузкой. Старый прайс-лист 2019 года может стоить вам репутации.
• Актуальность: Как часто обновляются данные? Что если инструкция изменилась? Бот узнает об этом сразу, раз в час или раз в сутки? Пропишите SLA на обновление базы знаний.

Один из самых частых провалов — это когда бот отвечает на основе устаревших данных. Клиент спрашивает о цене, бот называет прошлогоднюю. Клиент приходит оплачивать — а цена другая. Скандал, негатив, потеря доверия.

5) Интеграции и технические детали

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

Бот не существует в вакууме. Он должен «разговаривать» с вашей CRM, получать данные из внешних систем, отправлять уведомления. Каждая такая связка — потенциальная точка отказа. Чем лучше вы их опишете, тем меньше сюрпризов на этапе разработки.

• API CRM: Какие методы нужны? GET для чтения данных, POST для создания записей? Какие лимиты на запросы (Rate Limits)? Важно: если у CRM лимит 100 запросов в минуту, а у вас 200 одновременных диалогов — будут проблемы.
• Webhooks: Какие события должны триггерить действия бота? Клиент оплатил → бот пишет «Спасибо, ваш заказ принят!». Заказ отправлен → бот присылает трек-номер. Опишите каждый триггер.
• Отказоустойчивость: Что если CRM лежит? Что если API партнёра не отвечает? Бот не должен зависать или показывать ошибку. Правильный ответ: «Я сейчас не могу проверить статус заказа, но передам ваш вопрос менеджеру — он свяжется с вами».

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

6) Роли (Кто виноват и что делать)

Классическая проблема любого проекта: когда что-то идёт не так, все показывают пальцем друг на друга. Чтобы этого избежать, нужна матрица ответственности — RACI. Пропишите заранее, кто за что отвечает, и у вас будет меньше политических игр и больше конкретики.

RACI — это Responsible (исполняет), Accountable (отвечает за результат), Consulted (консультирует), Informed (в курсе дела). Для каждой задачи — чёткое распределение.

• Product Owner: Отвечает за бизнес-результат. Метрики, деньги, приоритеты функций. Это тот человек, который скажет «запускаем» или «откатываем».
• Prompt Engineer: «Дрессировщик» бота. Пишет и правит промпты, настраивает тон общения, борется с галлюцинациями. От него зависит, будет ли бот звучать по-человечески или как робот из 90-х.
• Security Officer: Следит, чтобы данные не утекли, а бот не сболтнул лишнего. Проверяет логи, настраивает PII scrubbing, ставит guardrails.
• Юристы: Согласовывают оферты и дисклеймеры. «Я бот, моя информация может быть неточной — для важных решений свяжитесь с менеджером». Без этого — юридические риски.

Совет из практики: назначьте одного человека «адвокатом бота» — того, кто отвечает за его репутацию. Он читает логи диалогов, ловит косяки, инициирует улучшения. Без такого человека бот быстро деградирует.

7) Безопасность (Safety First)

Если предыдущие разделы — про то, как сделать бота полезным, этот — про то, как не сделать его опасным. Безопасность в LLM-проектах — это не «потом допилим», а фундамент. Один инцидент с утечкой данных может стоить дороже, чем весь проект.

Здесь работает правило «параноики живут дольше». Лучше перестраховаться десять раз, чем потом объясняться перед клиентами и регуляторами.

• PII Scrubbing: Автоматическое удаление или маскирование персональных данных в логах. Номера телефонов, карт, паспортов — всё это должно замазываться до того, как попадёт в хранилище. Даже для отладки.
• RBAC: Бот видит только то, что положено его роли. Если бот для клиентов — он не должен иметь доступ к зарплатам сотрудников, внутренним отчётам или конфиденциальным переговорам. Минимальные необходимые права — и ни байтом больше.
• Guardrails: Программные «заборы», которые не дают боту выходить за рамки. Запрет обсуждать политику, религию, конкурентов. Запрет давать юридические или медицинские консультации. Запрет оскорблять, даже если клиент провоцирует.

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

8) Логирование и Наблюдаемость

Запустить бота — это полдела. Дальше начинается самое интересное: понять, что он делает в бою. Без логов и мониторинга вы слепы. А слепой пилот долго не летает.

Наблюдаемость (observability) — это не роскошь, а необходимость. Вы должны в любой момент понимать: сколько диалогов ведёт бот, о чём спрашивают клиенты, где бот ошибается, насколько быстро отвечает.

• Trace ID: Уникальный идентификатор каждого диалога. Когда клиент жалуется «бот мне нахамил», вы должны за минуту найти этот диалог и разобраться. Без Trace ID — это часы копания в логах.
• Дашборды: Визуализация в реальном времени. Количество активных диалогов, топ тем за день, процент эскалаций на человека, среднее время ответа. Эти графики должны быть на экране у ответственного за бота.
• Хранение: Где лежат логи и как долго хранятся? Помним про GDPR, Закон РК о персональных данных и другие регуляторные требования. Логи с PII — отдельная головная боль.

Хорошая практика — настроить алерты на аномалии. Если процент эскалаций резко вырос или время ответа подскочило — вы узнаете об этом сразу, а не через неделю из жалоб клиентов.

9) Таблица Метрик Успеха

«Работает» и «работает хорошо» — разные вещи. Чтобы понимать, насколько бот справляется, нужны чёткие метрики. Без них вы будете опираться на ощущения, а ощущения обманчивы.

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

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

10) План Пилота (Roadmap)

Не пытайтесь запустить бота сразу на 100% трафика. Это как прыгать в бассейн, не проверив, есть ли там вода. Пилотный запуск — ваша страховка от катастрофы.

Вот примерный план, который мы используем. Конкретные сроки зависят от сложности проекта, но последовательность этапов — универсальная.

• Этап 1 — Подготовка: Финализация ТЗ, сбор и чистка данных для базы знаний, согласование доступов к API. На этом этапе 80% работы — организационная.
• Этап 2 — Настройка: Подключение RAG, загрузка базы знаний, написание промптов. Первые тесты в песочнице (Playground). Ловим очевидные косяки.
• Этап 3 — UAT: Внутреннее тестирование на сотрудниках. Пусть менеджеры, саппорт и продажники потыкают бота как клиенты. Они найдут то, что вы не заметили.
• Этап 4 — Soft Launch: Запуск на 5-10% реального трафика. Мониторинг «с лупой» — каждый диалог под контролем. Готовность откатить за минуту.
• Этап 5 — Go/No-Go: Анализ результатов пилота. Если метрики в норме — постепенное масштабирование. Если нет — возврат к этапу 2 с выводами.

Главное правило пилота: лучше медленно и правильно, чем быстро и с факапом. Репутацию потом восстанавливать дольше, чем потратить лишнюю неделю на тесты.

11) Риски (Чего бояться)

Последний, но не менее важный раздел. Любой честный план должен включать ответ на вопрос: «Что может пойти не так?». Если вы не видите рисков — вы их просто не ищете.

Пропишите основные риски заранее и подумайте о mitigation — что будете делать, если риск реализуется. Это не паранойя, это профессионализм.

• Юридические риски: Где физически хранятся данные? Соблюдаете ли вы требования по локализации? Что будет, если регулятор постучится? Проконсультируйтесь с юристами до запуска, а не после.
• Негатив клиентов: Часть людей принципиально не любит общаться с роботами. Это нормально. Дайте им возможность быстро переключиться на человека. И продумайте «человечный» стиль общения — бот не должен звучать как бездушная машина.
• Бюджетные риски: Модели вроде GPT-4 или Claude могут «съесть» бюджет, если не следить за токенами. Один длинный контекст — и стоимость диалога улетает в космос. Настройте лимиты и мониторинг расходов с первого дня.
• Галлюцинации: LLM иногда выдумывает факты. Это не баг, это особенность технологии. Митигация: RAG, чёткие промпты, guardrails и регулярный аудит ответов.

Совет: заведите «журнал инцидентов». Каждый раз, когда бот ошибается — записывайте. Через месяц у вас будет бесценный список для улучшений.

Заключение: ТЗ — это не бюрократия

Мы прошли через все 11 разделов, и если вы дочитали до сюда — вы уже на голову выше большинства команд, которые запускают LLM-ботов «на коленке».

Да, составление подробного ТЗ — это работа. Иногда кажется, что проще сразу начать кодить. Но поверьте нашему опыту: каждый час, потраченный на проработку требований, экономит дни на этапе разработки и недели на этапе исправления багов в продакшене.

Хорошее ТЗ — это не про бюрократию. Это про то, чтобы все участники проекта были на одной волне. Чтобы разработчик понимал, что делать. Чтобы бизнес знал, чего ожидать. Чтобы безопасники спали спокойно. И чтобы клиенты получили бота, который реально помогает, а не бесит.

Скопируйте этот шаблон, адаптируйте под себя — и удачного запуска. А если застрянете на каком-то этапе — мы всегда готовы помочь.