Кто отвечает перед клиентом за ошибку ИИ-агента

Не стоит рассчитывать, что за ошибку бота перед клиентом автоматически заплатит поставщик языковой модели. Ответственность зависит от трёх факторов: применимого права, договоров между сторонами и того, что именно сделал агент. Неправильный ответ в чате и неправильно оформленный возврат денег имеют разные последствия.

Главное условие: бизнесу нужно отдельно управлять двумя вещами. Первое — обещаниями, которые его бот даёт клиентам от имени компании. Второе — отношениями с разработчиком и поставщиком модели: кто что гарантирует и кто что исправляет.

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

Ошибка ответа и ошибка действия

Слово «ошибка» объединяет разные события. Для оценки риска разделим их на две группы.

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

Ошибка действия. Агент не только отвечает, но и что-то делает в системе: применяет скидку, оформляет возврат денег или меняет условия заказа. Последствие уже наступило, и исправлять его нужно в учётной системе, а не только в переписке.

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

Разбор канадского примера

Показательный пример для обсуждения ответственности за чат-бота — дело 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 журналирование и мониторинг не предотвращают чрезмерную агентность, но помогают ограничить ущерб. При разборе претензии журнал — один из источников фактов. Его доступность, полноту и доказательную ценность оценивают отдельно. Не храните секреты и лишние персональные данные; установите срок хранения и круг доступа.

Какие условия согласовать

Часть рисков закрывают договорённости с интегратором и внутри компании, а не настройки. До запуска согласуйте следующие темы. Конкретные формулировки договора готовит юрист.

Внутри компании также определите, кто вправе решать, что бот обещает клиентам: руководитель продаж, поддержки или юрист. Иначе каждая претензия превращается в выяснение, кто должен принимать решение.

Как отвечать на претензию

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

Учебный пример: бесплатная доставка

Пример вымышлен. Интернет-магазинный бот ответил клиенту, что доставка бесплатна для заказов от 1 000 грн. Действующее правило магазина: бесплатная доставка от 1 500 грн. Клиент оформил заказ на 1 200 грн и увидел стоимость доставки в итоговой сумме. Он пишет в поддержку и прикладывает снимок переписки.

Таблица показывает, какие факты нужно установить до принятия решения. Она заранее не определяет, обязана ли компания предоставить бесплатную доставку: это решает уполномоченный человек с учётом правил компании и применимого права.

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

Порядок действий

1. Восстановите факты. Найдите разговор в журнале, вызовы инструментов и версию источника, из которого бот получил сведения. Сверьте снимок клиента с журналом.
2. Проверьте обещание. Сравните ответ бота с действовавшими тогда правилами. Определите, была ли это ошибка ответа или бот также выполнил действие.
3. Передайте уполномоченному сотруднику. Решение принимает человек с соответствующими полномочиями с учётом правил компании, при необходимости — после консультации юриста. Сообщите клиенту, кто и когда ответит.
4. Исправьте источник ошибки. Обновите данные, ограничьте бота цитатами из каталога и добавьте сценарий в тесты. Если ошибка повторяется, временно отключите проблемный сценарий и передавайте такие вопросы сотрудникам.
5. Зафиксируйте инцидент. Запишите, что произошло, какое решение принято и что изменено. Это пригодится для будущих претензий и обсуждения с интегратором.

Часто задаваемые вопросы