Кто отвечает за ответ нейросети

Перед клиентом отвечает компания, которая поставила бота, — не вендор модели, не подрядчик и не сам бот. Внутри компании ответственность распределяется регламентом из 6 пунктов: где ответ уходит клиенту только после человека, где без, какие темы запрещены, кто отвечает за обещания, кто разбирает жалобу и что хранится в журнале. Это организационный вопрос, а не технический.

Дальше — разбор по слоям: что видит клиент, как это устроено внутри, что записать в регламент и как быть с обещаниями, которые модель дала от лица компании. Про то, как считать цену ошибки в деньгах, есть отдельная статья сколько стоит ошибка нейросети; здесь речь про ответственность, а не про экономику.

Кто отвечает перед клиентом

Компания, от имени которой пришёл ответ. Для клиента бот на сайте — это ваш канал связи, такой же, как почта, телефон или менеджер в мессенджере.

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

Из этого следует практический вывод: все решения о том, что бот вправе говорить, принимаются с позиции «это говорит компания». Не «это черновик», не «это подсказка», а прямая речь бренда.

Почему «ответила нейросеть» не считается объяснением

Потому что это описание механизма, а не ответ на претензию. Клиенту неважно, каким образом внутри компании родился неверный текст: он получил его от вас.

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

Тот же принцип работает и с подрядчиком, и с поставщиком доступа. Претензии к ним — это ваши внутренние отношения, которые живут в договорах и не меняют того, что компания должна клиенту. Разница между покупкой готового решения и сборкой своего в этом месте разобрана в статье API или готовое решение.

Как ответственность устроена внутри компании

Внутри она распределяется процессом, а не по факту происшествия. У каждого канала есть владелец, у каждого канала есть правило вычитки, и обе вещи записаны до запуска, а не после первой жалобы.

Три слоя, которые стоит развести явно.

• Слой канала. Кто отвечает за то, что бот вообще стоит на сайте и говорит от имени компании.
• Слой содержания. Кто отвечает за инструкцию, список запрещённых тем и вычитку.
• Слой разбора. Кто принимает жалобу, поднимает журнал и принимает решение по конкретному случаю.

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

Что записать в регламент

Шесть строк. Регламент, который помещается на страницу, читают; тот, что на двенадцати страницах, не читает никто.

Строку «где без человека» пишут списком тем, а не через «всё остальное». Формулировка через отрицание означает, что завтра в этот список попадёт тема, которую никто не рассматривал. Приёмы ограничения тематики разобраны в статье как ограничить темы чат-бота.

Где ответ уходит клиенту только после человека

Там, где ответ создаёт обязательство или уходит наружу без возможности отзыва.

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

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

Где человека можно не ставить

Там, где ошибка ловится следующим шагом процесса или видна автору до отправки.

Это внутренние черновики, подсказки оператору, краткие содержания документов, классификация обращений по темам, извлечение полей с последующей сверкой. Здесь модель работает как ускоритель, а последнее слово всё равно остаётся за человеком, просто не в виде отдельной процедуры.

Отдельно стоит проверить, что в запрос не уезжают сведения, которые вы не имеете права отправлять наружу, — режим коммерческой тайны и персональные данные разобраны в статьях коммерческая тайна и нейросети и нейросети и персональные данные.

Что делать с обещаниями, которые модель дала от лица компании

Решать по обстоятельствам конкретного случая — и решать человеком с полномочиями, а не поддержкой на месте.

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

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

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

Кто отвечает, если сценарий собирал подрядчик

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

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

Последний пункт недооценивают. Возможность быстро остановить поток — это организационное право, а не техническая кнопка: если её нет в договоре, вы будете согласовывать остановку в тот момент, когда каждая минута идёт клиентам.

Почему поиск виноватого ломает процесс

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

Рабочая замена — разбор по местам, а не по людям. Вопрос звучит не «кто это допустил», а «в каком месте процесса не было проверки, которая это поймала бы». Ответ на такой вопрос превращается в строку регламента, а не в выговор.

Второй приём — считать долю ошибок нормальным показателем, у которого есть плановое значение. Модель ошибается всегда; регламент не обещает ноль, он обещает, что ошибка не дойдёт до клиента в определённых категориях.

Что нужно хранить, чтобы разбор был возможен

Разбор возможен только по журналу, и журнал ведёте вы, а не поставщик моделей. KeyDealer даёт ключ к каталогу из 55 позиций с оплатой в рублях и показывает расход по запросам, но текст ответа клиенту, версию инструкции и имя вычитавшего человека хранит ваша система — без них спор превращается в слово против слова.

Минимальный набор полей: время, идентификатор модели, текст запроса и ответа, версия инструкции, признак вычитки и идентификатор человека, если вычитка была. Состав журнала и то, что в него класть не нужно, разобраны в статье логирование запросов к моделям.

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

Чего мы не утверждаем

Мы не даём юридических заключений. Квалификация конкретного спора, оценка переписки бота как оферты и последствия для вашей отрасли — вопросы к вашему юристу, а не к блогу сервиса доступа к моделям.

Мы не утверждаем, что регламент снимает ответственность. Он распределяет её внутри компании и делает разбор возможным, но перед клиентом компания отвечает в любом случае.

Мы не утверждаем, что приведённый список каналов с обязательной вычиткой полон. В медицине, финансах, образовании и госсекторе действуют отраслевые требования, которые могут быть строже любого внутреннего регламента.

Что нужно, чтобы попробовать

Ключ заводится за минуту на keydealer.ru/login — почта и пароль, без документов и без зарубежной карты. Оплата российской картой в рублях, один ключ на весь каталог.

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

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

Что держать в голове

Ответственность перед клиентом не делится и не передаётся. Она целиком на компании, которая поставила бота, и все остальные разговоры — внутренние.

Внутри компании работает регламент, а не поиск виноватого. У каждого канала должно быть имя владельца, правило вычитки и список тем, по которым бот молчит и передаёт человеку.

Разбор конкретного случая возможен только по журналу, а журнал невозможно завести задним числом. Как мы проверяем факты и почему у каждой цифры стоит дата — на странице о проекте. Завести ключ и проверить свой сценарий: keydealer.ru/login.