Хто відповідає за помилку ШІ-агента перед клієнтом

Розраховувати на те, що помилку бота перед клієнтом автоматично оплатить постачальник мовної моделі, не варто. Відповідальність залежить від трьох речей: права, яке застосовується до ситуації, договорів між сторонами і того, що саме зробив агент. Неправильна відповідь у чаті і неправильно оформлене повернення коштів мають різні наслідки.

Головна умова: бізнес має окремо керувати двома речами. Перша: обіцянки, які його бот дає клієнтам від імені компанії. Друга: відносини з розробником та постачальником моделі, тобто хто що гарантує і хто що виправляє.

Після статті ви зможете оцінити, які дії вашого бота несуть найбільший ризик, що обмежити технічно, які умови погодити з інтегратором і як діяти, коли клієнт приходить з претензією. Стаття пояснює підхід і не є юридичним висновком. Для оцінки ситуації за українським правом потрібна окрема консультація юриста.

Помилка відповіді і помилка дії

Слово «помилка» об'єднує дуже різні події. Для оцінки ризику їх варто розділити на дві групи.

Помилка відповіді. Бот повідомив клієнту неправильну інформацію: не ту ціну, неіснуючу умову, неправильний опис послуги. Сама система нічого не змінила, але клієнт може ухвалити рішення на підставі цієї відповіді: оформити замовлення, приїхати, відмовитися від іншої пропозиції.

Помилка дії. Агент не лише відповів, а й щось зробив у системі: застосував знижку, оформив повернення коштів, змінив умови замовлення. Тут наслідок уже настав, і його треба виправляти в обліковій системі, а не лише в розмові.

Чим більше агент може зробити сам, тим дорожчою стає його помилка і тим складніше її відкотити. Тому перше управлінське рішення не «який бот обрати», а «які дії бот може виконувати без людини».

Розбір канадського прикладу

Показовим прикладом для розмови про відповідальність за чат-бота є справа Moffatt v. Air Canada, 2024 BCCRT 149. Це рішення Civil Resolution Tribunal провінції Британська Колумбія, Канада, 2024 року. Тобто це рішення конкретного органу конкретної юрисдикції, а не загальна норма.

Цей приклад розглядаємо лише в межах наведених пунктів 27 і 28 рішення. Не робимо висновків про суму компенсації, оскарження чи інші обставини справи.

Що видно з опублікованого фрагмента:

• Пункт 27. Авіакомпанія стверджувала, що не може відповідати за інформацію, надану її агентами чи представниками, зокрема чат-ботом. Трибунал цю позицію відхилив і зазначив, що компанія відповідає за всю інформацію на своєму сайті. Тобто подати бота як окрему особу, яка сама відповідає за свої слова, у цій справі не вдалося.
• Пункт 28. Трибунал дійшов висновку, що компанія не вжила розумних заходів, щоб забезпечити точність чат-бота. Також компанія не пояснила, чому клієнти мають повторно перевіряти інформацію з однієї частини сайту в іншій його частині.

Чого з цього прикладу не випливає. Він не означає, що в Україні чи будь-якій іншій країні суд ухвалить таке саме рішення. Він не встановлює універсальної норми, за якою компанія завжди компенсує будь-яку відповідь бота. Застосовність подібної логіки до вашої ситуації оцінює юрист за правом вашої юрисдикції.

Корисний висновок для бізнесу інший, практичний. Сама по собі позиція «це сказав бот, а не ми» в цій справі не спрацювала. Тому планувати роботу бота варто так, ніби кожна його відповідь є інформацією від компанії, і будувати контроль точності відповідно.

Чотири сторони і різні договори

У типовому проєкті з ШІ-агентом беруть участь чотири сторони. Між ними діють різні договори, і відповідальність не передається автоматично ланцюжком від клієнта до постачальника моделі.

Клієнт і бізнес. Клієнт взаємодіє з компанією, а не з моделлю. Його відносини з бізнесом регулюють договір, публічна оферта, правила продажу і право захисту споживачів, яке застосовується до ситуації. Для клієнта бот є частиною сервісу компанії.

Бізнес та інтегратор. Компанія, яка розробила і підтримує бота, працює за договором з бізнесом. Що саме інтегратор гарантує, як контролює якість, як реагує на інциденти і за що відповідає, визначає цей договір. Якщо умови не прописані, спір про них виникне вже після інциденту.

Бізнес або інтегратор і постачальник моделі. Модель використовується за умовами постачальника. Ці умови регулюють доступ до сервісу і обробку даних. Що вони кажуть про відповідальність за результати генерації, треба читати в договорі, за яким ви працюєте, а не припускати.

Чому ланцюжок не працює автоматично. Навіть якщо помилка виникла через особливість моделі, клієнт може пред'явити претензію компанії, з якою він має справу. Чи зможе компанія потім звернутися до інтегратора, а інтегратор до постачальника, залежить від договорів між ними та від права, що застосовується. Наперед вважати, що «платить той, хто зробив модель», немає підстав.

Окремо про прозорість. Стаття 50 європейського AI Act встановлює обов'язки прозорості для постачальників і користувачів ШІ-систем. Настанови Єврокомісії щодо цих обов'язків опубліковані 20 липня 2026 року, а самі обов'язки застосовуються з 2 серпня 2026 року. Чи поширюються вони на вашу компанію, залежить від того, чи підпадає вона під дію регламенту. Стаття 50(1) зобов’язує постачальників систем для прямої взаємодії з людьми забезпечити інформування про ШІ, зокрема з винятком для випадків, коли це й так очевидно з контексту. Там, де повідомлення обов’язкове, воно стосується прозорості взаємодії. Правильності цін, умов і обіцянок воно не замінює.

Що обмежувати технічно

Технічні рішення не визначають юридичну відповідальність, але визначають, скільки помилок узагалі може статися і наскільки великими вони будуть. OWASP у переліку ризиків для застосунків на мовних моделях описує надмірну агентність (Excessive Agency). Це ситуація, коли система виконує шкідливі дії у відповідь на несподіваний, неоднозначний чи маніпульований результат моделі. Причин три: надмірна функціональність, надмірні повноваження і надмірна автономність.

Для бота, який говорить з клієнтами про ціни й умови, це перетворюється на чотири практичні правила.

Ціни і умови лише з каталогу. Бот не формулює ціну сам, а бере її з облікової системи чи каталогу через інструмент і цитує. Те саме стосується умов доставки, гарантії, повернення. Якщо даних у джерелі немає, бот відповідає, що уточнить у менеджера, а не вгадує.

Ліміти на рівні системи. Якщо бот може застосувати промокод чи знижку, максимальний розмір і перелік дозволених знижок перевіряє код, а не інструкція в промпті. OWASP рекомендує обмежувати повноваження розширень мінімально необхідними і застосовувати авторизацію в цільових системах, а не покладатися на рішення моделі.

Підтвердження спірних дій. Повернення коштів, нестандартна знижка, зміна умов договору проходять через людину. OWASP прямо рекомендує людське погодження для дій з великим впливом. Бот у такому сценарії збирає дані і формує заявку, а рішення ухвалює уповноважений співробітник.

Журнал змін і розмов. Зберігайте діалоги, виклики інструментів з параметрами і версії джерел, з яких бот брав дані: прайс-лист, правила доставки, регламент повернень. За OWASP, журналювання і моніторинг не запобігають надмірній агентності, але допомагають обмежити шкоду. Для розбору претензії журнал є одним із джерел фактів. Його доступність, повноту та доказове значення оцінюють окремо. Не зберігайте секрети й зайві персональні дані; визначте строк зберігання та коло доступу.

Які умови погодити

Частину ризиків закривають не налаштування, а домовленості: з інтегратором і всередині компанії. Нижче перелік тем, які варто прописати до запуску. Конкретні формулювання договору готує юрист.

Окремо всередині компанії визначте, хто має повноваження ухвалювати рішення щодо обіцянок бота: керівник продажів, підтримки чи юрист. Без цього кожна претензія перетворюється на з'ясування, хто має вирішувати.

Як відповідати на претензію

Клієнт написав: бот пообіцяв одне, а компанія робить інше. Від того, наскільки впорядковано ви на це відреагуєте, залежить і стосунок з клієнтом, і ваша позиція, якщо спір піде далі. Розберемо навчальний приклад.

Навчальний приклад: безкоштовна доставка

Цей приклад вигаданий. Бот інтернет-магазину на питання клієнта відповів, що доставка безкоштовна для замовлень від 1000 грн. Чинне правило магазину: безкоштовна доставка від 1500 грн. Клієнт оформив замовлення на 1200 грн, а в підсумку побачив вартість доставки. Він пише в підтримку зі скриншотом розмови.

Таблиця нижче показує, які факти треба встановити до будь-якого рішення. Вона не визначає наперед, чи зобов'язана компанія надати безкоштовну доставку: це вирішує уповноважена людина з урахуванням правил компанії і застосовного права.

Окремо зверніть увагу на рядок «Звідки бот узяв відповідь». Якщо бот процитував застарілий документ у своїй базі знань, проблема в процесі оновлення даних. Якщо він вигадав поріг сам, проблема в тому, що бот формулює умови, а не цитує їх. Від цього залежить, що саме виправляти.

Порядок дій

1. Відновіть факти. Знайдіть розмову в журналі, виклики інструментів і версію джерела, з якого бот брав інформацію. Скриншот клієнта звірте з журналом.
2. Перевірте обіцянку. Порівняйте сказане ботом з правилами, що діяли на той момент. Визначте, чи це помилка відповіді, чи бот ще й виконав дію.
3. Передайте уповноваженому співробітнику. Рішення щодо обіцянки ухвалює людина з повноваженнями, з урахуванням правил компанії і, за потреби, після консультації з юристом. Клієнту повідомте, хто і коли дасть відповідь.
4. Виправте джерело помилки. Оновіть дані, обмежте бота цитуванням з каталогу, додайте сценарій у тести. Якщо помилка повторювана, тимчасово вимкніть проблемний сценарій і передайте такі питання людям.
5. Зафіксуйте інцидент. Запишіть, що сталося, яке рішення ухвалили і що змінили. Цей запис знадобиться і для наступних претензій, і для розмови з інтегратором.

Часті питання