Система ошиблась: сообщила клиенту неверную цену, оформила не ту заявку, отказала в том, в чём отказывать не следовало. Возникает вопрос, кто за это отвечает.
Ответ, который стоит принять до всех тонкостей:
> Ответственность перед клиентом несёт компания, а не алгоритм. С точки зрения того, кто пострадал, разницы между ошибкой сотрудника и ошибкой системы нет: обязательства принимала на себя организация.
Дальше начинается распределение — между заказчиком, подрядчиком и поставщиком модели. Оно определяется договорами, и в этом главная практическая мысль: распределяется то, что записано.
Оговорка обязательна: я не юрист. Ниже — как это выглядит с точки зрения того, кто такие системы делает, и что стоит зафиксировать до запуска. Правовую квалификацию даёт юрист.
Почему «ошибся алгоритм» не работает как аргумент
Три причины, каждая самостоятельная.
Систему внедрили вы. Решение применять её и допускать к работе с клиентами — ваше.
Правовой субъектности у системы нет. Алгоритм не может быть стороной обязательства, ответчиком, нарушителем.
Ошибка предсказуема. Вероятностный характер модели известен заранее, и он не является чрезвычайным обстоятельством. Систему, которая иногда ошибается, вы допустили к работе, зная это.
Из последнего следует практический вывод, определяющий проектирование: если цена ошибки высока, конструкция должна её предотвращать, а не полагаться на редкость.
Три стороны и их зоны
Заказчик
Отвечает перед клиентом и регулятором за результат.
Отдельно — за то, что находится в его зоне и часто определяет качество больше подрядчика: достоверность материалов, на которых работает система, полноту и актуальность документов, наличие проверки там, где она предусмотрена, соблюдение внутренних правил сотрудниками.
Практически это значит: если система ответила неверно, потому что в базе знаний лежал устаревший прайс, — это не дефект системы.
Подрядчик
Отвечает за то, что система соответствует согласованному: работает как описано, содержит предусмотренные проверки и ограничения, не имеет дефектов реализации.
За что подрядчик не может отвечать: за то, что модель вероятностна, за качество ваших материалов, за решения, принятые людьми по результатам работы системы.
Что стоит согласовать явно — и это самое важное в разделе:
- согласованные показатели качества и на каком наборе они измеряются;
- какие проверки и ограничения входят в поставку;
- что делать при обнаружении дефекта и в какие сроки;
- что не гарантируется — явным перечнем.
Последний пункт полезен обеим сторонам. Подрядчик, обещающий, что система не ошибётся, обещает невыполнимое — «10 вопросов подрядчику по внедрению ИИ».
Поставщик модели
Отвечает по своим условиям, и они обычно сильно ограничивают ответственность за результат генерации. Это стоит прочитать до, а не после: рассчитывать на возмещение убытков от неверного ответа модели, как правило, не приходится.
Как снизить риск конструкцией
Здесь зона подрядчика, и здесь же — большая часть того, что реально работает.
Проверка перед необратимым действием. Отправка клиенту, платёж, изменение учётных данных — через человека. Тогда ошибка модели не становится ошибкой компании — «Человек в контуре проверки».
Ограничение полномочий. Система не может сделать того, чего ей не разрешено, — не «запрещено в инструкции», а невозможно — «Ограничение действий ИИ-агента».
Отказ вместо догадки. Нет данных — система говорит «не знаю» и передаёт человеку.
Ссылки на источник. Ответ, опирающийся на документ, проверяем — «Цитирование источников».
Журнал. При разборе нужно показать, что произошло: какой был запрос, что нашлось, что ответила система. Без журнала разобраться невозможно, а доказать — тем более.
Информирование пользователя. Клиент должен понимать, что общается с автоматической системой, и иметь возможность позвать человека — «Передача диалога оператору».
Разбор: разбор инцидента, который удалось провести
Задача. Бот сообщил клиенту срок поставки, компания его не выдержала, клиент предъявил претензию.
Что позволило разобраться. Журнал с записью не только ответа, но и того, какие фрагменты базы знаний были найдены.
Что показал разбор. Система нашла и процитировала актуальный раздел регламента. Срок в регламенте был указан верно. Но в регламенте отсутствовала оговорка про регион клиента — она существовала как устная практика и в документ не попала.
То есть система ответила правильно по документу, а документ был неполон.
Что из этого следовало. Дефекта системы не было. Была неполнота материалов — зона заказчика. При этом претензию клиента это не снимало: обязательство перед ним принимала компания.
Что сделали.
По инциденту — урегулировали с клиентом.
По материалам — провели ревизию регламента, добавили региональные оговорки. Заодно нашли ещё несколько мест, где устная практика расходилась с документом.
По системе — добавили правило: в темах, где известны частые исключения, ответ дополняется предложением уточнить у менеджера.
По процессу — ввели ежемесячный разбор диалогов, где система отвечала уверенно, а клиент потом обращался повторно. Это ловит расхождения между документами и практикой.
Что стоит забрать. Возможность провести такой разбор — сама по себе результат проектирования. Если бы журнал содержал только «вопрос — ответ», без найденных фрагментов, разговор свёлся бы к взаимным предположениям. И зафиксированное разделение зон — «мы отвечаем за поиск по документам, вы за содержание документов» — позволило обсуждать причину, а не искать виноватого.
Что зафиксировать до запуска
Список для договора и внутренних документов:
- Что система делает и чего не делает — явным перечнем.
- Согласованные показатели качества и набор, на котором они измеряются.
- Что не гарантируется.
- Зона ответственности за материалы — обычно заказчика.
- Обязательные проверки человеком — где именно.
- Порядок разбора инцидента и что для этого сохраняется.
- Условия поставщика модели — прочитанные, а не предполагаемые.
- Информирование пользователей о том, что отвечает автоматическая система.
Пункты 2 и 3 стоит обсудить до подписания: они предотвращают спор о том, была ли ошибка дефектом или ожидаемым поведением.
Частые вопросы
Кто отвечает, если ИИ ошибся и клиент понёс убытки?
Перед клиентом отвечает компания: обязательства принимала она, а алгоритм не является субъектом права. Дальше вопрос распределяется между заказчиком, подрядчиком и поставщиком модели — по тому, что записано в договорах. Правовую квалификацию конкретной ситуации даёт юрист.
Можно ли переложить ответственность на подрядчика?
Частично и в согласованных пределах: подрядчик отвечает за соответствие системы описанию, наличие предусмотренных проверок и отсутствие дефектов реализации. Он не может отвечать за вероятностный характер модели, за достоверность ваших материалов и за решения, которые люди принимают по результатам работы системы.
Отвечает ли поставщик модели?
По своим условиям, которые обычно существенно ограничивают ответственность за результат генерации. Рассчитывать на возмещение убытков от неверного ответа, как правило, не приходится, и это стоит прочитать до внедрения, а не после инцидента.
Как доказать, что произошло?
Журналом, в котором сохранены запрос, найденные материалы, переданный контекст и ответ. Без такой записи разбор превращается в обмен предположениями. Возможность разобрать инцидент закладывается при проектировании, а не появляется в момент, когда она понадобилась.
Снимает ли предупреждение «отвечает бот» ответственность?
Не снимает, но существенно: пользователь должен понимать, с чем взаимодействует, и иметь возможность позвать человека. Это влияет и на восприятие ситуации, и на оценку добросовестности действий компании.
Что делать, чтобы ошибка не стала дорогой?
Ставить проверку человеком перед необратимыми действиями, ограничивать полномочия системы технически, предусматривать отказ вместо догадки при нехватке данных и вести журнал. Тогда ошибка модели остаётся внутренним событием, а не обязательством перед клиентом.
Что дальше
Технические меры — «Ограничение действий ИИ-агента» и «Человек в контуре проверки». Что проверить перед запуском — «Аудит безопасности ИИ-систем». Что спросить у подрядчика — «10 вопросов подрядчику».
Проектирование систем с явным разделением зон ответственности — часть работы по внедрению ИИ и разработке ИИ-агентов.