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