Галлюцинации ИИ в коммуникациях с клиентами: на что обратить внимание и как предотвратить

Если обратиться к цифрам, то расклад примерно такой: минута работы живого оператора обходится примерно в 12 рублей. Минута ИИ‑агента в облачной модели — около 8 рублей, в собственной инфраструктуре — от 6 рублей. При объёме в 300 тысяч минут в месяц экономия составляет от 30 до 50% фонда оплаты труда на первой линии поддержки. Агент не уходит на обед, не берёт больничный и одновременно ведёт столько диалогов, сколько нужно. Для бизнеса с сезонными пиками — это не просто удобство, а структурное преимущество.

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

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

Именно поэтому вопрос не в том, внедрять ли ИИ в клиентские коммуникации. Вопрос в том, с каким уровнем контроля выходить “в прод”. В этой статье я расскажу на что нужно обратить внимание перед запуском.

Что такое галлюцинации ИИ и какие они бывают

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

Для клиентского сервиса это особенно чувствительный риск. Пользователь воспринимает ответ ИИ как официальный комментарий компании и принимает решения на его основе. Если агент сообщает неверные условия доставки, возврата товара, действия скидки или обслуживания, последствия могут выйти далеко за рамки неудобства для клиента. Известны случаи, когда компании сталкивались с судебными претензиями из‑за ошибочных ответов чат‑ботов. Один из наиболее известных примеров связан с авиакомпанией Air Canada, чат‑бот которой сообщил клиенту о несуществующей скидочной программе. Впоследствии суд признал, что компания несет ответственность за информацию, предоставленную своим цифровым помощником.

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

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

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

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

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

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

Где чаще всего возникают галлюцинации

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

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

Не менее чувствительны процессы возврата и обмена товаров или услуг. Именно здесь галлюцинации способны привести к прямым финансовым потерям. Если модель сообщает клиенту о праве на возврат, которого в действительности нет, или придумывает несуществующие условия компенсации, компания рискует столкнуться не только с репутационными издержками, но и с судебными претензиями. Один из наиболее известных примеров произошел с авиакомпанией Air Canada, чей чат‑бот сообщил клиенту о несуществующей программе скидок. Впоследствии суд признал ответственность компании за информацию, предоставленную цифровым помощником.

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

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

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

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

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

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

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

Почему ИИ‑агенты галлюцинируют и чем это чревато для вашего бизнеса

Галлюцинации искусственного интеллекта принято воспринимать как техническую проблему, однако для бизнеса это прежде всего операционный риск. Чтобы эффективно управлять им, важно понимать, откуда возникают ошибки и почему даже самые современные ИИ‑агенты периодически выдают неверные ответы.

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

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

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

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

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

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

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

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

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

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

Что делать, чтобы снизить риск галлюцинаций ИИ

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

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

Поэтому большинство промышленных решений используют подход Retrieval‑Augmented Generation (RAG). Перед формированием ответа система обращается к базе знаний компании и извлекает релевантные документы, инструкции или регламенты. Благодаря этому агент опирается не только на знания, полученные во время обучения модели, но и на актуальную корпоративную информацию. Еще более высокую точность показывает вертикальный RAG — специализированная архитектура для конкретной отрасли. Вместо поиска по всей базе знаний система работает только с узкопрофильными источниками, что снижает вероятность неверных интерпретаций.

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

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

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

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

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

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

Именно поэтому на рынке постепенно формируется практика комплексных испытаний ИИ‑агентов до запуска в продакшен. Вместо проверки отдельных ответов моделируются полноценные клиентские сценарии: от первого обращения до решения проблемы. Для каждого кейса заранее фиксируются исходные данные, ожидаемый результат, нормативные требования и критерии оценки. Затем анализируется не только итоговый ответ, но и вся логика поведения агента.

Например, в targetai для тестирования агентов используется программа и методика испытаний (ПМИ) — инженерный документ, содержащий набор типовых сценариев, классификацию наиболее распространенных типов галлюцинаций, критерии оценки качества и чек‑листы готовности к промышленной эксплуатации. Такой подход позволяет выявлять ошибки до запуска системы на реальных клиентах.

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

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

Как на практике выглядит проверка ИИ

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

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

Для запуска в продакшен устанавливается минимальный порог качества. На практике это означает, что агент должен успешно проходить более 95% тестовых сценариев. Если доля ошибок превышает допустимый уровень, система возвращается на доработку. В зависимости от причины корректируются сценарии диалога, обновляется база знаний, меняются настройки модели или пересматривается архитектура взаимодействия между системами.

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

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

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

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

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

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

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

8 советов, как избежать галлюцинаций ИИ

Генеративный ИИ в клиентском сервисе — не экзотика. Компании его уже внедряют. Вопрос не в том, использовать или нет, а в том, с каким уровнем контроля выходить в продакшен.

Галлюцинации — не баг конкретной модели. Это следствие природы технологии. По данным журнала «Управление производством», они возникают примерно в каждом пятом ответе. Каждый из них компания обнаруживает либо по жалобе клиента, либо по запросу регулятора, либо по иску.

Управляемый запуск выглядит иначе: агент проходит ПМИ, набирает 95%+ зелёных симуляций, получает протокол с классификацией ошибок и рекомендациями по доработке. Только после этого — в продакшен. И дальше — регулярный цикл: обновление базы знаний, новые симуляции, контроль отклонений.

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

targetai строит именно такой процесс: платформа targetos, методика испытаний, ПМИ, симуляции и цикл улучшения. Для компаний, которые хотят автоматизировать клиентский сервис без скрытых операционных и правовых рисков.

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

Знайте, где ошибки бьют больнее всего. Для МСБ критичны пять зон: ложные цены, сроки, адреса и условия (фактические ошибки); выдуманные правила возврата и скидок (регламентные ошибки); неверная классификация клиента и применение не той льготы (контекстные ошибки); неверное ветвление сценария — когда клиент попадает не к тому специалисту (процедурные ошибки); добавление деталей, которых нет в вашей базе знаний (генеративные ошибки). Если у вас есть хотя бы одна из этих зон — это уже повод для аудита.

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

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

Не игнорируйте параметр temperature — он напрямую влияет на риски. Параметр temperature управляет «творческой вольностью» модели. При значении выше 0,5 ответы становятся более разнообразными и менее предсказуемыми. В сервисных сценариях, где нужна строгая бизнес‑логика, высокая температура повышает риск галлюцинаций. Если вы настраиваете агента самостоятельно или работаете с подрядчиком — этот параметр должен быть явно согласован.

Помните: последствия ошибок реальные и дорогостоящие. Неверная инструкция приводит к покупкам по несуществующим льготам или пропуску сроков возврата — и компания возмещает убытки вручную. Если бот обещает услугу, которой нет, или неверно трактует договор — это уже предмет иска. Российские регуляторы штрафуют за нарушение прав потребителей на суммы до 1–3% оборота. Показательный пример — чат‑бот Air Canada, сообщивший клиенту о несуществующей скидке: суд встал на сторону клиента.

Тестируйте поведение агента целиком, а не отдельные ответы. Распространённая ошибка МСБ — проверить несколько вопросов и признать агента готовым. Компании тестируют корректность отдельных ответов, но не поведенческую логику агента. Галлюцинации возникают примерно в 20% ответов, но без стресс‑тестов большинство из них остаются незамеченными до выхода в продакшен. Прогоняйте агента через полные сценарии: от приветствия до закрытия кейса, включая нестандартные ситуации — возвраты, льготы, отмены.

Установите чёткий порог готовности перед запуском. Разумный порог — 95% корректных сценариев из 30+ тестовых симуляций. До достижения этого порога агент не должен выходить в продакшен — он возвращается на доработку: правится сценарий, обновляется база знаний, корректируется архитектура. Это не гарантия нулевых ошибок, но понятный и управляемый уровень риска — в отличие от запуска «посмотрим, как пойдёт».