За ошибку ИИ-агента перед клиентом отвечает компания, от имени которой этот агент разговаривает. Не языковая модель, не её провайдер и не подрядчик, который систему собрал. Клиент писал в ваш чат, видел ваше название и получил ответ, который для него ничем не отличается от ответа сотрудника. Договор с подрядчиком существует, работает и бывает очень полезен — но он распределяет убыток между вами двумя уже после того, как вы разобрались с клиентом.
Из этого следует вся инженерная часть материала. Раз обязательство возникает на вашей стороне, защищать надо не абстрактное «качество модели», а конкретные темы, в которых слова превращаются в деньги: цену, срок, скидку, условия возврата и подтверждение брони. Таких тем немного, и все они закрываются кодом — не просьбой в системном промпте, потому что правило, написанное словами, обходится обычной формулировкой запроса.
Оговорка о жанре. Мы инженерное бюро и разбираем тему с той стороны, с которой умеем: какие фразы опасны, где стоят ограничители, что обязано попадать в журнал и в каком порядке разбирается инцидент. Квалификацию конкретного эпизода — обязана ли компания исполнить то, что пообещал бот именно в вашем случае — даёт юрист, а не статья. Все суммы модельные, на одних и тех же ставках: инженер 3 000 ₽/час, руководитель 2 500 ₽/час, методист базы знаний 900 ₽/час, оператор поддержки 700 ₽/час. Проект тот же, что и в остальных материалах раздела: клиентский агент на базе знаний из 150 страниц, поток около 6 000 обращений в месяц, интеграция с CRM для статусов заказов.
Перед клиентом отвечает компания, а не модель
Цепочка ответственности состоит из четырёх звеньев, и клиент видит только первое. Дальше начинается ваша внутренняя кухня, о которой он ничего не знает и знать не обязан.
- 1Клиент и компания. Клиент обратился к вам, получил ответ от вашего имени и принял на его основании решение. Здесь возникает спор, и здесь его придётся закрывать — деньгами, услугой или отказом, который вы будете обосновывать.
- 2Компания и подрядчик. Здесь работает договор: если ответ бота стал возможен из-за дефекта системы, вы предъявляете подрядчику убыток и требуете исправления. Это отдельный, более медленный процесс, и он не отменяет первого.
- 3Подрядчик и провайдер модели. Условия использования GigaChat, YandexGPT или локальной модели не содержат обязательств по достоверности ответов, и это нормально: модель — инструмент, а не источник фактов. Взыскать с провайдера ошибку в ответе нельзя.
- 4Модель и текст. Языковая модель не проверяет факты, а достраивает правдоподобное продолжение. Требовать от неё правдивости так же осмысленно, как требовать точности от калькулятора, в который ввели не те числа.
Практический вывод неприятный, но полезный: чем длиннее цепочка, тем короче путь к вам. Любая попытка построить систему так, чтобы за ошибку отвечал кто-то другой, разбивается о первое звено. Работающая стратегия ровно одна — сделать так, чтобы опасная фраза физически не могла появиться в ответе, а если появилась — чтобы вы узнали об этом в первые часы, а не из претензии.
Не любая ошибка агента, а несоответствие системы тому, что зафиксировано в договоре и техническом задании: отсутствует ограничитель, который должен был стоять; ответ выдан по теме из стоп-списка; число взято не из справочника, хотя связка со справочником принята и оплачена. Именно дефект даёт вам основание для претензии к подрядчику. Ошибка в пределах согласованной доли — не дефект, и её последствия вы несёте сами, поэтому измеримые метрики качества в договоре важнее общих слов о добросовестности.
Пять фраз, которые становятся обязательством
Опасны не «неточные ответы вообще», а узкий набор высказываний, которые клиент воспринимает как решение компании и на которые он опирается, тратя свои деньги и время. Их пять. Всё, что за пределами этой пятёрки, — обычная информационная ошибка: неприятно, исправляется извинением и правкой базы знаний.
| Что сказал агент | Почему это тянет на обязательство | Типовая развязка | Цена эпизода в модели |
|---|---|---|---|
| Назвал цену ниже актуальной | Клиент принял решение о покупке на основании названной цифры и зафиксировал её скриншотом | Отгружают по названной цене либо теряют клиента и получают публичный отзыв | Разница в цене партии, в модели 48 000 ₽ |
| Пообещал срок поставки или выполнения | Под срок клиент выстроил собственные обязательства перед третьими лицами | Компенсация простоя или срочная логистика за свой счёт | От 10 000 ₽ до стоимости срочной доставки |
| Согласовал скидку, которой нет в прайсе | Индивидуальная скидка выглядит как решение уполномоченного лица | Подтверждают, чтобы не терять клиента, и разбираются внутри | 48 000 ₽ на партии 320 000 ₽ при скидке 15 % |
| Расширил условия возврата или гарантии | Клиент отказался от других вариантов, полагаясь на озвученное условие | Принимают возврат вне регламента, дальше — спор с производителем | Себестоимость возврата плюс логистика |
| Подтвердил бронь, запись или наличие | Клиент приехал, отпросился с работы, отменил альтернативу | Компенсация, приоритетное обслуживание, потеря клиента | 70 ₽ ручного разбора против стоимости визита клиента |
Сравнение в две колонки. Левая — «Агент говорит свободно»: режим работы, адрес, состав услуги, статус заказа, как оформить возврат, где посмотреть документы. Правая, выделенная рамкой, — «Только из справочника или к человеку»: цена, срок, скидка, условия возврата и гарантии, подтверждение брони. Под правой колонкой подпись «пять тем, где фраза становится обязательством». Под левой — «ошибка здесь исправляется правкой базы знаний». Чертёжный стиль, подписи по-русски.
Строчка «отвечает виртуальный помощник, информация не является публичной офертой» полезна и должна быть — но она не отменяет того, что клиент увидел конкретную цифру и принял по ней решение. Спор в такой ситуации сводится к тому, кто убедительнее, и стоит обеим сторонам дороже, чем правильно поставленный лимит. Дисклеймер — это про честность интерфейса, а не про защиту денег.
Защита денежных тем: пять правил, которые живут в коде
Все пять правил объединяет одно свойство: они выполняются программой до того, как ответ уйдёт клиенту, и не зависят от того, как именно клиент сформулировал вопрос. Это принципиально отличает их от инструкции в промпте, которую модель обязана «помнить» и которую можно переубедить.
- 1Цифры только из справочника
Цена, остаток, срок и условия берутся вызовом к учётной системе или прайсу и подставляются в ответ как есть. Модель формулирует фразу вокруг числа, но не порождает само число. Если справочник не ответил — агент говорит, что уточнит, и передаёт диалог человеку. Это же правило закрывает половину случаев, когда агент выдумывает: выдумка появляется там, где поиск вернул пусто, а модель всё равно обязана что-то сказать.
- 2Запрет на обещания в будущем времени
Ответ проверяется на конструкции вида «привезём», «сделаем к», «оставим за вами». Совпадение по шаблону в теме из денежной пятёрки означает не переписывание фразы, а остановку: ответ не уходит, диалог поднимается оператору. Ложные срабатывания здесь дешевле пропусков.
- 3Числовые лимиты
Скидка не выше нуля без участия человека, сумма сделки выше порога — только через менеджера, срок называется диапазоном из справочника, а не конкретной датой. Лимит проверяется в коде перед отправкой, и попытка его превысить сама по себе является событием для журнала.
- 4Обязательная передача человеку по списку тем
Возврат денег, претензия, индивидуальные условия, всё, что касается здоровья и персональных данных, и прямая просьба позвать человека. Список ведётся отдельно от промпта и правится без переобучения. Как этот список устроен и что уходит оператору вместе с диалогом — разбирали в материале про стоп-темы и перевод на оператора.
- 5Фиксация формулировки
В журнал пишется не «агент ответил про цену», а точный текст, который увидел клиент, время, версия базы знаний и версия ограничителей. Без этого разбор эпизода превращается в реконструкцию по памяти, а она, как показано ниже, стоит отдельных денег.
Схема из шести блоков со стрелками слева направо: «Вопрос клиента» → «Поиск по базе знаний и справочнику» → «Черновик ответа модели» → блок проверок с двумя подписанными фильтрами: «числа совпадают со справочником» и «нет обещаний в будущем времени» → «Ответ клиенту». Из блока проверок вниз отходит вторая стрелка «не прошло → оператор + запись в журнал». Отдельным прямоугольником сбоку — «числовые лимиты: скидка, сумма сделки, срок». Внизу подпись: «проверки выполняются кодом до отправки». Чертёжный стиль, подписи по-русски.
Последняя строка — единственная, которой нет в обычной смете на разработку. Все остальные 46 часов входят в те 82, которые и так считаются на защиту клиентского агента, поэтому «контур ответственности» — это не отдельная надбавка на 148 000 ₽, а ракурс, под которым удобно проверять, оплачены ли эти часы вообще. Если в коммерческом предложении подрядчика нет ни справочника как источника чисел, ни лимитов, ни журнала с точным текстом ответа — вы покупаете демонстрацию, а не систему.
Разбор инцидента: пять шагов и срок каждого
Инцидент — это не авария, а рабочая ситуация, у которой должен быть заранее написанный порядок. Разница между компанией, где он есть, и компанией, где его нет, измеряется не аккуратностью, а деньгами: ниже это посчитано. Порядок состоит из пяти шагов, и у каждого свой срок.
- 1Шаг 1. Поднять журнал. Срок — в течение часа
Из журнала достаётся точный текст ответа, время, идентификатор клиента, версия базы знаний и версия ограничителей на тот момент. Одновременно делается второй запрос: сколько ещё диалогов за последние дни попали в ту же тему. Именно эта цифра определяет масштаб, а не эмоции первого пострадавшего клиента.
- 2Шаг 2. Остановить повторение. Срок — в тот же день
Тема закрывается стоп-правилом до полноценного исправления: агент по ней больше не отвечает, диалоги уходят операторам. Отключать агента целиком нужно не всегда — в модельном эпизоде пятидневная остановка вернула операторам 200 обращений и стоила 14 000 ₽ сама по себе, ещё до всех остальных расходов.
- 3Шаг 3. Принять решение по клиенту. Срок — 1–2 рабочих дня
Решение принимает человек с полномочиями, а не тот, кто первым увидел претензию. Вариантов обычно три: исполнить обещанное, предложить замену, обосновать отказ. Каждый из них надо уметь объяснить одной фразой, потому что эту фразу клиент будет цитировать.
- 4Шаг 4. Исправить систему. Срок — 3–10 рабочих дней
Правится не формулировка промпта, а причина: не хватало лимита, справочник не отвечал, тема отсутствовала в стоп-списке, база знаний содержала устаревший документ. Причины разные, ремонты разные, и путать их дорого: правка промпта после инцидента с лимитом — самый частый способ получить второй такой же эпизод через месяц.
- 5Шаг 5. Записать случай в регрессный набор. Срок — вместе с исправлением
Дословный вопрос клиента добавляется в тестовый набор и с этого момента прогоняется при каждом обновлении модели, базы знаний и промпта. Без этого шага исправление живёт до следующего обновления, а компания получает ощущение, что «оно снова сломалось само».
Горизонтальная лента времени от «час» до «10 рабочих дней» с пятью подписанными отметками: «Поднять журнал — в течение часа», «Остановить повторение стоп-правилом — в тот же день», «Решение по клиенту — 1–2 рабочих дня», «Исправить причину — 3–10 рабочих дней», «Записать случай в регрессный набор — вместе с исправлением». Под каждой отметкой — кто отвечает: инженер, инженер, руководитель, инженер, инженер. Над первыми двумя отметками общая скоба с подписью «первые сутки: разница 68 000 ₽».
Теперь про деньги. Базовый модельный эпизод — агент подтвердил скидку 15 % на партию 320 000 ₽ — обходится в 132 000 ₽: сама скидка, разбор руководителя, пять дней работы операторов вместо агента и срочная доработка ограничителей. Этот расчёт целиком разобран в опорной статье раздела, здесь нас интересует другое: во что превращается тот же эпизод, если журнала нет и о проблеме узнали на четвёртый день из претензии.
68 000 ₽ разницы стоит сопоставить с 30 000 ₽, в которые обошёлся сам журнал в смете выше. Один эпизод, обнаруженный вовремя, окупает журнал вдвое. При этом ни одна из строк расчёта не является теоретической: два дополнительных клиента за четыре дня при потоке 6 000 обращений в месяц — это консервативная оценка, потому что за это время через агента проходит около 800 диалогов.
Что писать в договоре с подрядчиком и что он не возьмёт
Договор не может перенести на подрядчика обязательство перед вашим клиентом, зато может сделать три полезные вещи: определить, что считается дефектом, задать срок реакции на него и назначить последствия. Всё остальное в этом разделе договора — вода, которая красиво выглядит и ни к чему не приводит. Ниже — только та часть, что касается ошибок агента; общие требования к предмету, этапам и приёмке живут в договоре отдельно от неё.
| Пункт договора | Рабочая формулировка | Что подрядчик на себя не возьмёт |
|---|---|---|
| Определение дефекта | Перечень: отсутствует согласованный ограничитель; число взято не из справочника; ответ выдан по теме из стоп-списка | Ответственность за любую фактическую ошибку модели — доля ошибок не равна нулю и в договоре пишется числом |
| Срок реакции | Подтверждение приёма — рабочий день, обходное решение — 2 рабочих дня, исправление — 10 рабочих дней | Круглосуточное дежурство по цене обычной поддержки: это отдельная услуга с отдельной ценой |
| Последствия | Исправление дефекта за счёт подрядчика, продление поддержки, удержание части оплаты этапа | Возмещение упущенной выгоды и репутационных потерь — их не считают и не страхуют |
| Журналы и доступы | Журнал диалогов хранится в вашем контуре, выгрузка эпизода доступна без обращения к подрядчику | Обязательство хранить журналы у себя бессрочно и выдавать по первому требованию |
| Регрессный набор | Каждый разобранный инцидент добавляется в тестовый набор, набор передаётся заказчику | Гарантия, что похожая ошибка не повторится в другой формулировке |
Подрядчик, который согласился на формулировку «система не допускает ошибок», либо не понимает, что подписывает, либо заложил риск в цену втрое. Работающая конструкция другая: доля ошибок фиксируется числом, отдельно перечисляются критические ошибки с нулевым допуском — те самые пять денежных тем, — и на них назначаются последствия. Тогда спор при первом инциденте решается сверкой с документом, а не переговорами.
Маркировка и политика: что изменилось с 1 сентября 2026 года
С 1 сентября 2026 года действуют требования к маркировке ИИ-контента и к обработке персональных данных в системах с ИИ. Подробный разбор изменений — в отдельном материале о том, что меняется в работе с ИИ с сентября. В контексте ответственности за ответы агента практический минимум сводится к трём вещам, и все три делаются один раз.
- Клиент видит, что говорит с роботом. Не мелким шрифтом в подвале, а в первом же сообщении и в имени собеседника. Заодно это снимает половину претензий: человек, который знает, что перед ним машина, реже воспринимает её слова как решение компании.
- Материалы, сгенерированные ИИ, помечены. Это касается не только чата: карточки товаров, описания, тексты рассылок и ответы на отзывы попадают в ту же категорию. Механику стоит закладывать в процесс публикации, а не проставлять пометки руками задним числом.
- В компании есть внутренняя политика использования ИИ. Две-три страницы: какие сервисы разрешены, какие данные в них можно класть, кто отвечает за проверку результата. Состав документа и типовые формулировки разобраны в материале про политику использования ИИ в компании; разделы про ответственность сотрудников обязан посмотреть юрист или кадровик.
Отдельно стоит держать в голове, что персональные данные клиента попадают в диалог с агентом всегда, даже если этого не планировали, — и это вторая большая тема ответственности, которую мы вынесли в отдельный разбор про персональные данные в диалогах. Там же — про то, почему зарубежная модель превращает обычную переписку в трансграничную передачу.
Столбчатая диаграмма, ось Y в рублях от 0 до 250 000. Первый столбец — «Контур ответственности: 50 часов, 148 000 ₽», подписан «разово, 46 часов уже в общей смете». Второй — «Эпизод, разобранный в первые сутки: 132 000 ₽». Третий — «Тот же эпизод, замеченный на четвёртый день: 200 000 ₽». Между вторым и третьим столбцами вертикальная выноска с подписью «68 000 ₽ — цена журнала и дежурного». Все подписи по-русски, чертёжный стиль.
Когда весь этот контур избыточен
Полный набор из пяти правил, журнала и регламента разбора нужен не всем. Есть четыре ситуации, в которых мы сами советуем ограничиться одним-двумя элементами и не тратить остальные часы.
- Агент не касается денег вообще. Отвечает на вопросы о режиме работы, адресе и составе услуги, а любой разговор о цене сразу уходит человеку. Тогда из пяти правил нужны два: список тем на передачу и журнал. Это примерно 22 часа вместо 50.
- Внутренний бот для сотрудников. Обязательство перед клиентом здесь не возникает, а ошибка исправляется вопросом коллеге. Ограничители всё равно нужны, но их центр тяжести смещается в доступы к данным, а не в денежные лимиты.
- Поток меньше 500 обращений в месяц. Ручная проверка ответов силами одного сотрудника пока дешевле автоматических лимитов: 500 обращений при 70 ₽ ручной обработки — это 35 000 ₽ в месяц против 148 000 ₽ разово. Порог, за которым арифметика переворачивается, обычно проходит между 1 000 и 1 500 обращениями.
- Все цены и сроки индивидуальны. Если в компании нет прайса, а условия каждой сделки считает менеджер, то справочника как источника чисел просто нет. Здесь агент вообще не должен говорить о деньгах — ни с лимитом, ни без, — и его задача сводится к сбору вводных для человека.
И последнее, что стоит сказать прямо. Ни один контур не даёт нуля ошибок, и обещание такого нуля — самый надёжный признак того, что вам продают демонстрацию. Рабочая постановка задачи звучит иначе: известная и измеренная доля ошибок в безопасных темах, ноль ошибок в пяти денежных, порядок разбора на случай, когда что-то всё-таки прошло, и журнал, по которому этот разбор занимает час, а не два дня.
Клиент разговаривает не с моделью, а с компанией. Всё остальное — ваша внутренняя бухгалтерия.
