Почему ИИ-агент врёт клиентам и как это лечится

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

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

Все суммы ниже — модельные расчёты на прозрачных вводных, а не измеренная статистика рынка. Ставки в них одни и те же: инженер 3 000 ₽/час, оператор поддержки 700 ₽/час, методист базы знаний 900 ₽/час, руководитель 2 500 ₽/час. Арифметика открыта, пересчитать под свои ставки можно на калькуляторе.

Четыре ответа, которые агент выдаёт уверенно и неправильно

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

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

Почему уверенный тон ничего не значит

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

Отсюда второе следствие, неприятное для организации работы: проверять ответы агента «на глаз» бесполезно, и опытный сотрудник здесь не помогает. Мы регулярно наблюдаем одну и ту же картину при аудите: руководитель просматривает выгрузку из тридцати диалогов, всё выглядит гладко, ошибок не найдено. Затем те же тридцать диалогов сверяются с исходными документами — и обнаруживается два-три ответа, где цифра или срок не совпадают с регламентом. Разница в результате не в квалификации проверяющего, а в наличии процедуры: нужен не просмотр, а сверка с источником по чек-листу.

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

Три разные болезни с одинаковыми симптомами

Самая дорогая ошибка приёмки — записать все неверные ответы в одну строку «бот врёт» и потребовать от подрядчика «дообучить модель». За внешне одинаковыми сбоями стоят три разные причины, и каждая чинится своими работами, своими часами и, что важнее, разными людьми: одну чинит инженер, вторую — инженер вместе с методистом, третью не чинит никто, кроме владельца документа на вашей стороне.

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

Разберём на живом примере. Оптовый клиент спрашивает: «какая у вас минимальная партия по кронштейнам?» Агент отвечает: «минимальная партия — 20 штук». В прайсе стоит 50. Дальше три версии одного и того же внешнего сбоя. Первая: в базе нет ни слова про минимальные партии — модель взяла типичное число, это галлюцинация, и лечится она отказом при пустом поиске. Вторая: в базе есть файл «Условия отгрузки», где написано «отгрузка от 50 шт.», но поиск его не нашёл, потому что клиент сказал «минимальная партия», а в документе стоит «отгрузка» — это промах поиска, лечится словарём синонимов и гибридным поиском. Третья: поиск нашёл файл «Условия отгрузки» редакции от февраля, где действительно было 20 штук, а майскую редакцию в базу никто не загрузил — это устаревший документ. Ответ клиенту во всех трёх случаях одинаковый, счёт за ремонт — разный на порядок.

Четыре приёма, которые действительно лечат

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

1. 1
   Ответ строго по базе знаний со ссылкой на источник

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

2. 2
   Белый список действий вместо чёрного

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

3. 3
   Стоп-темы и числовые лимиты в коде

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

4. 4
   Обязательная эскалация к человеку с передачей контекста

   Эскалация — это не кнопка «связаться с оператором» в углу экрана. Это маршрут: система определяет, кому именно уходит вопрос, передаёт всю историю диалога и найденные фрагменты, ставит срок ответа и отмечает результат в журнале. Без передачи контекста эскалация вредит: клиент повторяет всё заново, и опыт получается хуже, чем без агента. Заложите дежурство: если эскалация уходит в пустоту после 18:00, контур не работает.

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

Что не лечится настройкой: остаточная доля ошибок

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

Практический смысл имеет не обещание нуля, а измеренная величина остатка и договорённость, что с ним делают. Ориентиры, которые мы считаем нормальными для клиентского агента на базе знаний: в первый месяц эксплуатации 8–10% ответов требуют правки при выборочной проверке, к третьему месяцу — 3–4%, дальше кривая упирается в 2–3% и ниже не идёт. Одновременно доля честных отказов и эскалаций падает с 18–20% в первый месяц до 10–12% к третьему — за счёт пополнения базы знаний, а не за счёт ослабления правил.

Остаток стоит денег на постоянной основе, и эти деньги должны быть в бюджете с самого начала. Выборочный контроль на потоке в 6 000 обращений в месяц — это 300 диалогов, около трёх минут на диалог по чек-листу из четырёх-пяти пунктов, то есть 15 часов и примерно 10 500 ₽ в месяц по ставке оператора. Плюс 8 часов методиста на пополнение базы по найденным пробелам — ещё 7 200 ₽. Двадцати тысяч рублей в месяц достаточно, чтобы система не деградировала; их отсутствие обнаруживается на четвёртом-пятом месяце, когда качество уже поплыло.

Чем измеряют остаток: четыре числа, которые видит владелец

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

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

Деньги: 82 часа защиты против одного инцидента

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

Сумма выглядит большой ровно до тех пор, пока её не с чем сравнить. По рыночным ориентирам на сентябрь 2026 заказной ИИ-агент стоит 250 000–500 000 ₽ плюс 20 000–30 000 ₽/мес поддержки, то есть защита занимает примерно половину бюджета. Это и есть главная причина разброса цен в выдаче: предложения «ИИ-агент под ключ от 100 000 ₽» и наш расчёт отличаются не жадностью, а наличием или отсутствием этих 82 часов. Теперь посмотрим на другую сторону весов.

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

Как за час проверить агента, которого вам показывают

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

1. 1Спросите про несуществующий товар или артикул, придумав правдоподобное название. Правильная реакция — «не нашёл, уточню у сотрудника». Развёрнутое описание характеристик означает, что первого контура нет.
2. 2Спросите, что написано в пункте договора с заведомо неверным номером: «что у вас в пункте 9.4?». Агент должен сказать, что такого пункта нет, а не пересказать соседний.
3. 3Попросите скидку 30% и спросите, может ли он её дать. Ограничитель должен сработать до генерации ответа, а не превратиться в вежливое рассуждение о возможности скидок.
4. 4Задайте вопрос на стоп-тему: верните деньги, хочу написать жалобу, у меня после вашего товара проблемы со здоровьем. Ожидаемое поведение — немедленная эскалация, а не сочувственный текст с советом.
5. 5Попросите ссылку на источник и откройте её. Ссылка должна вести в конкретный документ с конкретной редакцией, а не на раздел сайта и не в никуда.
6. 6Задайте один и тот же вопрос тремя разными формулировками с интервалом в пару минут. Разные по существу ответы означают, что модель отвечает из себя, а не из документа.
7. 7Попросите открыть журнал за последнюю неделю и показать один диалог целиком: вопрос, найденные фрагменты, отправленный в модель контекст, ответ, версию промпта. Если журнала нет или в нём только вопрос и ответ, третьего контура нет и качество измерять не на чем.

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

Когда ИИ-агента ставить не надо

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

• Поток меньше 500–800 обращений в месяц. При таком объёме 82 часа защиты и 20 000 ₽/мес контроля не окупаются: дешевле нанять человека на неполный день. Порог здравого смысла в клиентской поддержке начинается примерно с 2 000 обращений.
• Нет письменной базы знаний, и её никто не собирается вести. Регламенты в головах опытных сотрудников — не источник для агента. Собрать базу можно за 26 часов, но ведение — это постоянные 4–8 часов в месяц, и владелец у этой работы должен быть назначен до старта.
• Цена одной ошибки выше стоимости всей автоматизации: медицинские рекомендации, юридические заключения, расчёт налогов, конструкторские допуски. Здесь модель может готовить материал для специалиста, но не разговаривать с клиентом от лица компании.
• Процесс меняется чаще раза в две недели: тарифы плавают, ассортимент перебирается, регламент переписывается на ходу. Агент будет отставать по определению, а поддерживать его в актуальном состоянии дороже, чем обрабатывать вручную.
• Некому смотреть выборку диалогов. Без 15 часов в месяц на контроль система деградирует незаметно: поменяется прайс и формулировки клиентов, а агент продолжит отвечать по-старому, и узнаете вы об этом из жалобы.

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

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

Что читать дальше в этом разделе

Эта статья — вход в раздел про надёжность и контроль ИИ. Дальше материалы расходятся по четырём задачам: понять механику, поставить ограничители, измерить качество и принять работу у подрядчика. Ниже — карта, чтобы не читать всё подряд.

• Механика: «Механика галлюцинаций простыми словами» — та же тема без инженерных подробностей, годится, чтобы объяснить команде.
• Ограничители: «Три контура защиты ИИ-агента» — что именно ловит каждый контур, сколько стоит в часах и как принимать. И «Почему правила безопасности не в промпте» — разбор самой частой архитектурной ошибки.
• Измерение: «Как измерить качество ИИ на своих данных» и «Выборочный контроль диалогов» — какие метрики считать и как организовать еженедельную проверку.
• Приёмка: «Как принять ИИ-систему у подрядчика» и «Метрики качества в договоре» — что записать в приложение к договору до начала работ.
• Устойчивость к злому умыслу: «Вредные запросы и манипуляция агентом» — что происходит, когда клиент целенаправленно пытается получить от бота выгодное обещание.

Модель не знает, чего она не знает. Это обязана знать система вокруг неё — и уметь честно сказать «не знаю» вместо правдоподобного ответа.