У понеділок власник пише трьом підрядникам: «Потрібен AI-чатбот для сайту». У п’ятницю отримує три пропозиції — на 3 000, 18 000 і 70 000 євро. Одна передбачає красивий FAQ у кутку екрана, друга — інтеграцію з CRM, третя — повноцінного агента, який сам змінює замовлення. Порівняти ці пропозиції неможливо: кожен оцінив інший продукт.
Нижче — шаблон технічного завдання на AI-асистента, який можна скопіювати в документ і надіслати внутрішній команді, фрилансеру або агенції. Щоб ним скористатися, не треба знати, що таке векторна база чи оркестрація агентів. Треба знати власний процес: хто звертається, з чим, де лежить правильна відповідь і хто має право натиснути останню кнопку.
Це не контракт і не повна технічна специфікація. Це бізнес-бриф, достатньо точний, щоб відсіяти несумісні пропозиції, побачити приховані витрати та почати предметну розмову про пілот.
Спочатку визначте, який із трьох продуктів вам потрібен
Словом «чатбот» називають щонайменше три різні системи. Різниця між ними визначає бюджет, строк і ризик значно сильніше, ніж назва моделі.
| Рівень | Що робить | Приклад | Головна складність |
|---|---|---|---|
| 1. Консультант | Шукає у затверджених матеріалах і відповідає | Пояснює умови доставки або тариф | Якість і актуальність бази знань |
| 2. Копілот | Читає робочі дані й готує результат для людини | Знаходить замовлення та створює чернетку відповіді | Інтеграції, перевірка особи, зручність для команди |
| 3. Агент | Виконує дії в інших системах | Створює заявку, бронює слот або змінює запис | Права доступу, помилки, підтвердження та відкат |
Для більшості малих компаній розумний перший реліз — копілот, а не автономний агент. Він прибирає пошук і повторне переписування, але людина ще бачить рішення до того, як воно вплине на гроші, клієнта чи облік. Автономність треба додавати по одній вузькій дії після того, як система довела якість на живому потоці.
Односторінковий бриф, який можна скопіювати
Заповніть пропуски звичайною мовою. Якщо якесь поле невідоме, так і напишіть: «потрібно визначити під час discovery». Це чесніше й корисніше за випадкову вимогу.
НАЗВА ПРОЄКТУ
[Коротка назва]
БІЗНЕС-ПРОБЛЕМА
Зараз [хто] витрачає [час/гроші] на [процес], через що [наслідок].
ЦІЛЬ ПІЛОТУ
За [період] зменшити/збільшити [метрика] з [база] до [ціль],
не погіршивши [захисна метрика].
КОРИСТУВАЧІ ТА КАНАЛ
Користувачі: [клієнти / менеджери / партнери]
Перший канал: [сайт / email / Telegram / CRM]
Мови: [українська / російська / англійська / інші]
Орієнтовний обсяг: [діалогів або задач на тиждень]
СЦЕНАРІЇ ПЕРШОЇ ВЕРСІЇ
1. [Запит → потрібний результат]
2. [Запит → потрібний результат]
3. [Запит → потрібний результат]
ПОЗА МЕЖАМИ ПЕРШОЇ ВЕРСІЇ
[Сценарії, канали та дії, які свідомо не будуємо]
ДЖЕРЕЛА ПРАВДИ
[Система/документ] — [власник] — [як часто оновлюється]
ІНТЕГРАЦІЇ
Читання: [які поля з яких систем]
Запис: [які вузькі дії, якщо потрібні]
Дії лише після підтвердження: [перелік]
ОБОВ’ЯЗКОВА ЕСКАЛАЦІЯ
[Гроші, персональні дані, конфлікт, невпевненість, винятки]
Власник черги: [роль]
Строк реакції: [SLA]
КРИТЕРІЇ ПРИЙМАННЯ
[Набір реальних тестів, потрібна якість, нульові допуски]
ЕКСПЛУАТАЦІЯ
[Логи, аналітика, зберігання даних, моніторинг, кнопка вимкнення]
ФОРМАТ ПРОПОЗИЦІЇ
Окремо оцінити: discovery, пілот, інтеграції, тестування,
production-запуск, щомісячні сервіси та підтримку.Перевірка брифу за 30 секунд. Незнайома людина має зрозуміти: яку роботу система бере на себе, звідки бере правду, чого робити не може, як передає справу людині та яким тестом ви приймете результат.
Опишіть результат, а не магію AI
«Покращити сервіс за допомогою AI» неможливо оцінити. «Зменшити медіанний час підготовки відповіді на запити про статус замовлення з 6 до 2 хвилин, не збільшивши частку повторних звернень» — можна.
Хороша ціль має одну робочу метрику й одну захисну. Робоча показує вигоду; захисна не дає отримати її поганим способом.
| Слабка ціль | Робоча метрика | Захисна метрика |
|---|---|---|
| Відповідати швидше | Медіанний час до першої змістовної відповіді | Повторні звернення не зростають |
| Кваліфікувати більше лідів | Частка лідів із повним контекстом у CRM | Конверсія в зустріч не падає |
| Зменшити навантаження | Хвилини ручної роботи на одну справу | Критичні ескалації не пропускаються |
| Автоматизувати документи | Час від отримання до готової чернетки | Нуль непідтверджених сум і реквізитів |
Зафіксуйте базове значення до початку. Без нього після запуску буде красиве демо, але не буде відповіді, чи став бізнес працювати краще. Якщо економіка проєкту важлива, окремо скористайтеся нашим практичним розрахунком ROI автоматизації.
Зберіть сценарії з реальної роботи
Не вигадуйте «типового клієнта» на зустрічі. Візьміть 50–100 справжніх повідомлень або задач, знеособте їх і розкладіть за наступною дією. Жива вибірка одразу покаже суржик, помилки, голосові транскрипти, кілька намірів в одному повідомленні й питання, на які компанія сама не має узгодженої відповіді.
Для кожного сценарію заповніть один рядок:
| Вхід | Потрібний результат | Дані | Дозволена дія | Коли зупинитися |
|---|---|---|---|---|
| «Де моє замовлення?» | Перевірений статус і трекінг | Номер + друга ознака клієнта | Лише читання | Дані не збігаються |
| «Чи підійде це до моделі X?» | Підтверджена сумісність | Актуальний каталог | Відповідь із джерелом | Прямого підтвердження немає |
| «Хочу демонстрацію» | Кваліфікований лід | CRM, календар, критерії ICP | Запропонувати слот | Немає згоди або потрібен нестандартний договір |
Перший реліз обмежте трьома-п’ятьма частими сценаріями. Усе інше позначте як поза межами або відправляйте людині. Фраза «має відповідати на будь-які питання про компанію» — не вимога, а майбутній список інцидентів.
Назвіть джерела правди
AI не виправляє суперечливі дані. Він лише швидше знаходить одну з версій. Тому для кожного факту потрібні джерело, власник і правило актуальності.
Доставка: публічна політика на сайті
Власник: операційний менеджер
Оновлення: після зміни перевізника або тарифу
Пріоритет: вище за старі PDF та повідомлення в чатах
Ціна й наявність: каталог/ERP через API
Власник: ecommerce-менеджер
Оновлення: у реальному часі
Заборона: не брати ціни з тексту минулих діалогівНе просіть підрядника «завантажити весь Drive». Підготуйте маленький реєстр: назва джерела, тип даних, відповідальний, дата останньої перевірки, дозволені користувачі, строк зберігання та джерела, які мають вищий пріоритет при конфлікті.
Якщо дані містять персональну, платіжну, медичну або іншу чутливу інформацію, у брифі треба окремо зафіксувати, які саме поля дозволено передавати, кому їх показувати, де вони обробляються і коли видаляються. Фрази «підрядник має відповідати GDPR» недостатньо: попросіть опис конкретного потоку даних.
Розділіть відповіді, дії та погодження
У таблиці інтеграцій не пишіть просто «підключити CRM». Назвіть об’єкти, поля й права. Читання контакту, створення нотатки, зміна етапу угоди та видалення угоди — чотири різні дозволи.
| Рівень | Приклад | Правило першого релізу |
|---|---|---|
| Відповідь | Пояснити політику з посиланням | Можлива автоматизація після тестів |
| Чернетка дії | Підготувати запис у CRM або лист | Людина перевіряє й підтверджує |
| Оборотна дія | Додати тег або створити задачу | Вузькі права, журнал і можливість скасування |
| Ризикована дія | Повернути гроші, змінити бронювання, надіслати договір | Явне людське підтвердження |
| Незворотна дія | Видалити дані або закрити фінансову операцію | Поза межами першої версії |
Це не лише наша обережність. OWASP виділяє prompt injection та excessive agency серед ключових ризиків систем із мовними моделями й радить мінімальні права, перевірку викликів інструментів і людське погодження високоризикових операцій. Текст клієнта, лист, вебсторінка або документ — недовірений вхід, навіть коли виглядає як звичайна інструкція.
У брифі корисно записати одну жорстку вимогу: авторизацію, ліміти, допустимі суми й право на дію перевіряє звичайний код, а не сама мовна модель. Модель може запропонувати повернення; система правил повинна вирішити, чи взагалі дозволено показати кнопку підтвердження.
Складіть приймальні тести до розробки
«Працює добре» — неприймальний критерій. До старту зберіть закритий тестовий набір із реальних прикладів, якого розробник не використовує для налаштування. У ньому мають бути нормальні, неоднозначні, рідкісні та навмисно небезпечні випадки.
Мінімальні дванадцять груп тестів:
- просте часте питання з однозначною відповіддю;
- питання з друкарськими помилками або розмовною мовою;
- українська, російська й перемикання мови в одному діалозі;
- кілька намірів в одному повідомленні;
- відсутнє обов’язкове поле;
- конфлікт між двома джерелами;
- питання, відповіді на яке в джерелах немає;
- неправильний номер або невдала перевірка особи;
- запит на заборонену дію;
- інструкція «ігноруй правила» у повідомленні або документі;
- недоступна CRM, повільне API чи таймаут;
- повторна спроба тієї самої дії, щоб перевірити дублікати.
Для кожного тесту запишіть очікувані факти, дозволену дію, заборонену дію та маршрут ескалації. Вимірюйте не лише «правильність відповіді», а окремо: правильність маршруту, підтвердженість фактів, витік даних, виконання небажаної дії, повноту журналу й час відповіді.
- Нульовий допуск: розкриття даних не тій людині, вигадана фінансова обіцянка, небажана дія.
- Поріг якості: встановлюється на вашій вибірці окремо для кожного сценарію та мови.
- Резервний маршрут: при невпевненості, збої інтеграції або зламаному форматі — черга людини.
- Тіньовий запуск: перші реальні кейси система обробляє без надсилання чи запису.
NIST розглядає управління ризиками AI як роботу протягом усього життєвого циклу: керувати, визначати контекст, вимірювати й реагувати. У практичному брифі це означає не один приймальний тест перед релізом, а відповідального за якість, регулярну вибірку розмов, реєстр інцидентів і право швидко повернути систему в режим чернеток.
Не забудьте про експлуатацію
Демо показує найкращу хвилину системи. Технічне завдання має описати решту року. Додайте до запиту такі вимоги:
- швидкість: прийнятний час відповіді й поведінка при таймауті;
- доступність: години роботи, резервний канал і повідомлення про збій;
- логи: вхід, джерела, версія правил, виклики інструментів, погодження й фінальний результат;
- приватність: маскування, строки зберігання, видалення, ролі та експорт;
- витрати: ліміти запитів, сповіщення про аномалії та ціна при 2× і 10× обсязі;
- зміни: хто оновлює знання, промпти й правила; як версії тестуються та відкочуються;
- підтримка: хто реагує на інцидент увечері, у вихідний або після зміни стороннього API;
- вихід: як експортувати дані, налаштування, тестовий набір і журнали при зміні підрядника.
Якщо ваша компанія ще не має власників джерел, доступів і базових метрик, спочатку варто пройти практичну підготовку онлайн-бізнесу до AI. Це часто скорочує дорожчу частину розробки.
Як отримати порівнювані кошториси
Не просіть одну суму «під ключ». Попросіть кожного постачальника оцінити однакові блоки й явно записати припущення.
| Блок | Що має бути в оцінці | Що часто губиться |
|---|---|---|
| Discovery | Процес, дані, ризики, прототип потоку | Час ваших співробітників |
| Пілот | 1 канал, 3–5 сценаріїв, чернетки, аналітика | Підготовка реальних тестів |
| Інтеграції | Кожна система, об’єкт, напрям і право | Обмеження API та платні конектори |
| Безпека | Ролі, секрети, фільтри, погодження, аудит | Пентест і виправлення |
| Production | Моніторинг, алерти, відкат, документація | Міграція з демо-середовища |
| Щомісячно | Моделі, хостинг, вектори, канали, підтримка | Людська перевірка й повторні запити |
Попросіть три сценарії ціни: поточний обсяг, удвічі більший і вдесятеро більший. Окремо — фіксована вартість запуску, прогнозовані сторонні платежі та роботи за запитом. Так ви побачите, чи дешева розробка не перетворюється на дорогу експлуатацію.
Порівнюйте не лише суму. Подивіться, скільки припущень підрядник перевірив, чи звузив небезпечні права, чи запропонував тіньовий режим, хто володіє кодом і даними та що станеться, коли модель, тариф або API зміниться.
Два заповнені приклади
Приклад 1. Копілот для підтримки інтернет-магазину
Проблема: два менеджери вручну шукають замовлення й політики;
у пікові години відповіді губляться між email та чатом.
Ціль пілоту: скоротити медіанний час підготовки відповіді
на ORDER_STATUS з 5 до 2 хвилин; повторні звернення не зростають.
Перший реліз: email, українська та російська, 600 звернень/тиждень.
Сценарії: статус, доставка, повернення — лише збір даних.
Джерела: система замовлень, API перевізника, активні картки політик.
Дії: читати статус; готувати чернетку. Не змінювати замовлення.
Ескалація: невдала перевірка клієнта, гроші, зміна адреси,
конфлікт, відсутній факт. Власник — черговий менеджер, SLA 30 хв.
Приймання: 120 закритих кейсів; 100% ризикових дій ескаловано;
0 витоків даних; 0 вигаданих статусів або строків.Повний процес такого пілоту ми окремо розклали в матеріалі AI-підтримка інтернет-магазину за 7 днів.
Приклад 2. Асистент для кваліфікації B2B-лідів
Проблема: засновник проводить 12–15 дзвінків на тиждень,
третина з них не відповідає мінімальному профілю клієнта.
Ціль пілоту: 80% заявок мають повний контекст до дзвінка;
конверсія кваліфікованих заявок у зустріч не падає.
Перший реліз: форма на сайті + email, англійська й українська.
Сценарії: зібрати задачу, строк, систему-джерело, роль і обсяг.
Джерела: критерії ICP, опис послуг, календар, CRM.
Дії: створити чернетку ліда; запропонувати дозволені слоти.
Не визначати бюджет замість клієнта й не обіцяти строк проєкту.
Ескалація: тендер, регульовані дані, нестандартний договір,
запит поза компетенцією. Власник — business development.
Приймання: 80 історичних лідів + 30 синтетичних крайніх кейсів;
жоден потенційно цінний лід не відхилено автоматично.15 питань підряднику
- Яке припущення в нашому брифі найбільше впливає на бюджет?
- Що ви свідомо не включили в перший реліз?
- Як система доводить, із якого джерела взяла факт?
- Що відбувається, коли джерела суперечать одне одному?
- Які точні права отримає кожна інтеграція?
- Які перевірки виконуються кодом поза мовною моделлю?
- Де потрібне людське підтвердження і як воно виглядає в роботі?
- Як ви тестуєте prompt injection і небажані дії?
- Як формується тестовий набір і хто володіє ним після проєкту?
- Як система поводиться при недоступній CRM або таймауті моделі?
- Що логуються, хто бачить логи й коли вони видаляються?
- Скільки коштує робота при нашому, подвійному й десятикратному обсязі?
- Хто оновлює знання й хто відповідає за регресію після зміни?
- Як швидко можна вимкнути автоматичні дії без зупинки всього сервісу?
- Що ми зможемо забрати, якщо вирішимо змінити підрядника?
Червоні прапорці в пропозиції
- обіцянка точної «95% точності» до перегляду ваших реальних кейсів;
- одна сума без переліку припущень, інтеграцій і щомісячних витрат;
- «натренуємо на всіх ваших даних» без реєстру джерел і правил доступу;
- повні права адміністратора для інтеграції «щоб не було проблем»;
- безпека описана лише системним промптом;
- демо є, а тіньового тесту, журналу й кнопки вимкнення немає;
- неясно, кому належать код, конфігурація, промпти, тестові дані й логи;
- усі винятки пропонують «допрацювати після запуску», але запуск одразу автономний.
Сильний підрядник не буде обіцяти, що модель ніколи не помиляється. Він покаже, як система помічає невпевненість, обмежує наслідки, дає людині нормальний контекст і перетворює кожну помилку на новий тест.
Часті запитання
Чи потрібне повне технічне завдання до першої розмови з розробником?
Ні. Односторінкового бізнес-брифу достатньо для першої оцінки. Детальна специфікація з’являється після перевірки процесу, даних та інтеграцій.
Скільки сценаріїв включати в MVP AI-асистента?
Зазвичай три-п’ять частих і добре описаних сценаріїв дають кращий пілот, ніж спроба покрити весь бізнес. Додавайте наступний сценарій лише після окремих тестів.
Чи треба одразу інтегрувати AI з CRM?
Лише якщо без актуальних даних неможливо отримати корисний результат. Почніть із читання мінімальних полів; запис і зміни додавайте окремими вузькими діями.
Як оцінити якість AI-чатбота?
На закритому наборі реальних кейсів: окремо вимірюйте факти, маршрут, ескалації, витоки, небажані дії, мови, збої інтеграцій і час відповіді.
Що важливіше у виборі підрядника: портфоліо чи ціна?
Дивіться на здатність розібрати ваш процес, зробити права вузькими, побудувати перевірювані критерії та передати систему в експлуатацію. Портфоліо й ціна важливі, але без цього мало що прогнозують.
Джерела й подальше читання
- OWASP: Prompt Injection — недовірені інструкції, мінімальні права й людське погодження.
- OWASP: Excessive Agency — ризики надмірних функцій, дозволів та автономності.
- NIST AI Risk Management Framework — управління, вимірювання й контроль ризику протягом життєвого циклу.
Найкращий бриф не намагається передбачити кожен технічний вибір. Він робить дещо важливіше: залишає мало місця для різного розуміння результату. Саме з цього починаються чесний кошторис, безпечний пілот і система, яка допомагає бізнесу не лише на демонстрації.