Перед оплатою рахунку варто отримати від продавця ШІ-рішення письмові відповіді на девʼять груп питань: які дані обробляє сервіс, чи використовуються вони для навчання моделі, де вони зберігаються і хто має до них доступ, чи веде сервіс журнал запитів і відповідей, хто відповідає перед вашим клієнтом за помилку моделі, як відбувається заміна моделі, як експортувати дані й вийти з сервісу, як рахується ціна за одиницю і що входить у підтримку. Відповіді мають лягти в лист або в договір, бо після демо в памʼяті лишається враження, а для рішення потрібен документ. Мовчання продавця або відмова відповідати письмово хоча б на одне з цих питань дає достатню підставу не купувати. Рахунок почекає кілька днів, а виправлення невдалого договору може тривати місяцями.
Коротко
- Оплату рахунку варто зупинити, доки продавець ШІ-рішення не надасть письмові відповіді на ваш чекліст.
- Першими закрийте питання про дані: що саме обробляє сервіс, чи йдуть дані на навчання моделі, де вони зберігаються і хто має до них доступ.
- Журнал запитів і відповідей дає змогу розібрати будь-яку помилку, тому зʼясуйте, чи він є, як довго зберігається і хто його бачить.
- Відповідальність перед вашим клієнтом за помилку моделі лишається за вашою компанією, і договір має показати, що в такому разі робить постачальник.
- Умови заміни моделі, експорту даних, виходу з сервісу, ціни за одиницю і підтримки треба знати до підписання, бо після оплати ваша позиція в переговорах слабшає.
Навіщо ставити продавцю ШІ-рішення письмові питання ще до оплати рахунку?
Типова ситуація виглядає так. Невелика компанія з відділом продажів хоче купити ШІ-рішення, яке допомагатиме менеджерам відповідати клієнтам і готувати внутрішні чернетки листів, комерційних пропозицій і звітів. Продавець провів демо, показав, як система за лічені секунди складає відповідь на запит клієнта, і того ж дня надіслав рахунок. Менеджери задоволені, бухгалтерія готова платити, і керівник у цей момент зупиняє оплату, щоб переслати продавцю перелік питань із проханням відповісти письмово.
Таке рішення виглядає спокійним і раціональним. Демо показує найкращий сценарій на підготовлених даних, тоді як щоденна робота складається з клієнтських імен, цін, знижок, внутрішніх домовленостей і неминучих помилок. Після оплати у продавця стає менше причин витрачати час на ваші питання, а у вас стає менше важелів для переговорів. Письмова відповідь має ще одну перевагу: її можна показати юристу, порівняти з договором і через кілька місяців нагадати постачальнику, що саме він обіцяв. Усна відповідь менеджера з продажу на дзвінку такої практичної і юридичної сили не має.
Які питання про дані компанії й навчання моделі треба закрити перед покупкою?
Почніть із того, які саме дані потраплятимуть у сервіс. У сценарії з відділом продажів це імена і контакти клієнтів, історія замовлень, ціни, умови договорів, іноді скарги. Значна частина цього масиву є персональними даними, а Закон України про захист персональних даних діє і тоді, коли з ними працює ШІ. Тому перше питання до продавця стосується категорій даних, які обробляє сервіс, місця розташування серверів і юрисдикції, в якій працює постачальник.
Друге питання стосується навчання моделі. Навчанням моделі називають використання ваших запитів і документів для вдосконалення алгоритму, який потім обслуговує інших клієнтів постачальника. На ринку корпоративні тарифи великих постачальників часто за замовчуванням не використовують дані робочого середовища компанії для навчання, і це корисний орієнтир. Орієнтир ринку все одно треба перетворити на пункт вашого договору, тому попросіть продавця письмово підтвердити, що ваші дані на навчання не йдуть, і вказати, де саме це зафіксовано.
Третє питання стосується доступу. Зʼясуйте, хто з боку постачальника може бачити ваші дані, за яких умов і чи фіксується кожен такий доступ. Рекомендації Мінцифри квітня 2026 року радять надавати ШІ-асистентам мінімально необхідний доступ, і цей принцип варто поширити на самого постачальника. Він має бачити рівно стільки, скільки потрібно для стабільної роботи сервісу.
Навіщо питати про журнал запитів і відповідей та про доступ до нього?
Журнал запитів і відповідей є записом того, що співробітник запитав у системи і що вона відповіла, з датою, часом і автором запиту. Для невеликої компанії він виконує роль памʼяті. Коли клієнт через тиждень скаржиться на неправильну ціну в листі, журнал показує, хто ставив запит, яку відповідь дала модель і чи редагував її менеджер перед відправкою. Без журналу розбір перетворюється на суперечку, в якій кожен покладається на власні спогади.
Запитайте продавця, чи веде сервіс такий журнал за замовчуванням, як довго він зберігається, хто у вашій компанії може його переглядати і чи можна його вивантажити. Окремо зʼясуйте, чи бачить журнал постачальник і з якою метою. Журнал містить ті самі клієнтські дані, тому до нього застосовуються ті самі вимоги щодо зберігання і доступу, що й до решти інформації. Зручно, коли права на перегляд можна розподілити за ролями: керівник відділу бачить запити всієї команди, менеджер бачить свої. Якщо продавець відповідає, що журнал доступний лише в дорожчому тарифі, ця інформація важлива для порівняння пропозицій, і її теж варто отримати письмово.
Хто відповідає перед клієнтом, якщо ШІ-рішення помилиться в ціні чи факті?
Модель може впевнено написати неправильну знижку, переплутати характеристики товару або вигадати умову доставки. Для вашого клієнта відправником листа є ваша компанія, і претензію він надсилає саме вам. Рекомендації Мінцифри квітня 2026 року закріплюють цю логіку: відповідальність за результат лишається за організацією, яка використовує ШІ, людина підтверджує критичні дії, а офіційні повідомлення без перевірки асистентам не делегують. Для відділу продажів це означає, що листи з цінами, строками й умовами договору йдуть клієнту тільки після перегляду менеджером.
У продавця ШІ-рішення варто зʼясувати, що саме він бере на себе. Запитайте, чи передбачає договір відповідальність постачальника за збій сервісу або за помилку, спричинену його налаштуваннями, як швидко він реагує на повідомлення про систематичну помилку і чи допомагає розібрати конкретний випадок. Якщо договір обмежує відповідальність постачальника, вам треба знати ці межі до оплати і вибудувати під них внутрішнє правило перевірки. Окремо запитайте, чи дозволяє сервіс налаштувати обовʼязкове підтвердження людиною перед відправкою листа назовні. Цей текст є загальною навчальною інформацією, тому умови конкретних сервісів і вимоги закону треба звіряти в договорі й на офіційних сторінках.
Як зʼясувати умови заміни моделі, експорту даних і виходу з сервісу?
ШІ-рішення рідко працює на одній і тій самій моделі весь час користування. Постачальник може оновити модель, перейти на іншу або вимкнути стару версію, і разом із цим зміниться стиль відповідей, якість роботи з українською мовою і поведінка системи у складних запитах. Тому запитайте, як постачальник повідомляє про заміну моделі і як завчасно, чи можна протестувати нову версію на власних запитах і чи можна певний час лишатися на попередній.
Друга частина цього розділу стосується виходу. Сьогодні сервіс здається вдалим вибором, але компанія може вирости, змінити процеси або знайти вигіднішу пропозицію. Зʼясуйте, у якому форматі можна експортувати дані: налаштування, шаблони відповідей, бази знань, журнал запитів і відповідей. Запитайте, як довго після розірвання договору дані зберігаються у постачальника, як підтверджується їх видалення і чи стягується плата за експорт. Відповідь, що експорт можливий на запит, без опису формату і строків варто вважати неповною і попросити деталізувати. Коли дані можна забрати в зручному вигляді, компанія зберігає свободу вибору і не залежить від одного постачальника.
Які питання про ціну за одиницю і підтримку закрити до підписання рахунку?
Рахунок після демо зазвичай містить одну суму, але за нею стоїть модель тарифікації. Ціною за одиницю називають те, за що саме постачальник бере гроші: за місце користувача, тобто за кожного співробітника з доступом, за обсяг оброблених токенів, тобто фрагментів тексту, які модель читає і пише, за кількість запитів або за поєднання цих показників. Попросіть продавця письмово описати одиницю тарифікації, наслідки перевищення ліміту, зміну ціни при додаванні нових користувачів і порядок повідомлення про зміну тарифу. Повний розрахунок вартості лишається окремою темою. Тут важливо лише зафіксувати правила нарахування до оплати.
Друга група питань стосується підтримки. Зʼясуйте, через які канали можна звернутися, чи є підтримка українською мовою, як швидко постачальник реагує на звернення і що входить у базовий тариф: допомога з налаштуванням, консультації щодо роботи із системою, розбір помилок. Якщо продавець обіцяє швидку реакцію, попросіть зафіксувати її в договорі. Усі ці відповіді разом дають змогу порівняти кілька пропозицій між собою за однаковими критеріями, а для керівника з типової ситуації вони стають підставою для спокійного рішення про оплату.
Що робити далі
- Зупиніть оплату рахунку і повідомте продавцю, що рішення буде ухвалене після письмових відповідей на ваш чекліст.
- Надішліть продавцю ШІ-рішення перелік питань: дані, навчання моделі, зберігання і доступ, журнал, відповідальність за помилку, заміна моделі, експорт і вихід, ціна за одиницю, підтримка.
- Порівняйте отримані відповіді з текстом договору і попросіть внести в договір ті обіцянки, яких там бракує.
- Затвердьте всередині компанії правило, за яким листи клієнтам із цінами, строками й умовами відправляються тільки після перевірки людиною.
- Якщо на будь-яке питання продавець мовчить або відповідає лише усно, відкладіть покупку і поверніться до інших пропозицій на ринку.