AI-бот для клиентского сервиса: почему «я не знаю» честного ассистента ценнее уверенного неправильного ответа

В мае 2026 года в рабочем чате у меня произошёл эпизод, который я не ожидал анализировать как архитектурное решение. Андрей Полушин — клиент Solar OS с контрактом на автоматизацию операционки — написал боту-ассистенту @spbsolar_help_bot через 40 минут после завершения созвона: «дай обновлённый список задач после сегодняшнего разговора». Бот ответил прямо: «Юрий ещё не обновил мою память по итогам разговора. Поэтому актуальный список у меня тот, что был в 9:00. Если хочешь не ждать — напиши тезисами что вы решили, я зафиксирую».

Бот публично, в рабочем чате с клиентом, сообщил что я не выполнил свою часть работы. В этот момент в системе Solar OS работают 20 автономных агентов, которые от моего имени ведут переписку с клиентами, закрывают сделки, отвечают на вопросы по проектам. Любой из них мог бы взять данные из 9 утра и уверенно выдать их как «актуальные после созвона». Но этот бот сделал другое — признал границы своей осведомлённости.

Это не случайность и не баг. Это следствие 6 месяцев намеренной архитектурной работы над тем, как AI-боты обрабатывают неопределённость. И именно поэтому я считаю этот эпизод правильным — несмотря на то что клиент увидел мой пробел.

Если вы думаете о внедрении AI-ботов для клиентского сервиса или уже используете их — эта статья про то, почему «я не знаю» честного ассистента в нужный момент стоит дороже, чем 10 уверенных правильных ответов. И как это вообще устроить технически.

Бот, который сказал клиенту правду: что именно произошло

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

Стандартный рабочий процесс в Solar OS: после созвона обновление памяти ботов занимает около 5 минут — я дописываю секцию «решения сегодня» в рабочий файл клиента, и все связанные ассистенты получают актуальный контекст через следующий цикл синхронизации (раз в час). Но Андрей написал через 40 минут после окончания звонка — то есть до следующей синхронизации, и до того как я дошёл до обновления файла.

Рассмотрим два альтернативных сценария того, что мог сделать бот в этой ситуации.

Сценарий А — бот фантазирует: берёт список задач на 9:00, уверенно выдаёт его как «актуальный после созвона». Андрей видит приоритеты, которые не совпадают с тем, о чём только что договорились. Пункта про ежемесячную поддержку нет, прежние открытые вопросы выглядят как приоритет. Андрей думает: Юрий не принял наши решения всерьёз? Или не помнит о чём говорили? Или система ненадёжная?

Сценарий Б — бот честен: говорит что его данные на 9:00, объясняет почему, предлагает Андрею продиктовать тезисы — и фиксирует их немедленно. Андрей продиктовал. Через 2 минуты всё актуально. Никакой имитации компетентности — просто факт состояния и конкретное предложение как его исправить.

Я выбрал Сценарий Б намеренно — ещё на этапе написания системного промпта для liaison-ботов 6 месяцев назад. И первый публичный эпизод с реальным клиентом подтвердил: это работает именно так, как задумано.

Андрей не написал «что за бот такой неудобный». Он продиктовал тезисы. Вопрос закрылся за 2 минуты. Никаких недопониманий, никакого ощущения что система дала сбой. Наоборот — бот показал, что умеет работать в ситуации неопределённости: не паникует, не фантазирует, предлагает конкретный путь вперёд.

Что такое галлюцинация AI-ассистента в B2B-контексте — и чем она отличается от технической ошибки

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

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

Примеры контекстуальных галлюцинаций в реальных проектах автоматизации:

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

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

Почему галлюцинирующий AI-ассистент опасен для бизнеса — и вы узнаёте об этом последним

Галлюцинация AI-ассистента в контексте клиентского сервиса — это доверительный кредит, который тратится без вашего ведома, незаметными транзакциями.

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

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

В системе Solar OS 20 ботов ведут переписку параллельно. Если бы хотя бы один из них регулярно «домысливал» ответы в пограничных ситуациях — я бы не знал об этом до момента, когда ущерб уже нанесён. Именно поэтому честность про границы знания — это не мягкая ценность и не «хорошая практика». Это операционная необходимость для системы, которая работает на масштабе.

По наблюдениям за клиентскими чатами в нескольких проектах автоматизации Solar OS: в 73% случаев снижение частоты сообщений клиента с ботом происходит в течение 14 дней после момента, когда бот дал неточный ответ. Клиент не говорит «бот соврал» — он просто начинает писать реже и дублировать вопросы в личку человеку.

Архитектура честного AI-ассистента: явное состояние памяти с временными метками

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

Честный ассистент строится на другом принципе: явное состояние памяти с временными метками и обязательным сигналом при устаревании данных.

Вот как это реализовано в системе Solar OS:

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

2. Temporal awareness в системном промпте. Бот получает не только содержание файла, но и текущую дату+время, дату последнего обновления конкретной секции, и явную инструкцию: «если запрос касается информации из секции, обновлённой более чем 2 часа назад — сообщи клиенту, что данные могут быть устаревшими. Предложи конкретный путь к актуализации». Это одна инструкция, которая меняет поведение системы кардинально.

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

4. Логирование «признаний неопределённости» как позитивной метрики. В мониторинге системы Solar OS отдельно трекается количество случаев, когда боты честно сообщили клиенту о неопределённости. Это не метрика провала — это метрика корректной работы системы. Тревожный сигнал: когда показатель внезапно падает до нуля при нормальном объёме диалогов. Значит либо нет граничных запросов (маловероятно при 20+ ботах), либо бот перестал их детектировать и начал угадывать.

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

Честный бот vs уверенный бот: что происходит через 3 месяца работы

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

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

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

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

«Юрий Солар, основатель Solar OS: Меня не пугает, что мои боты не всезнайки. Меня пугало бы, если бы они начали делать вид что знают то, чего не знают. Один раз ассистент скажет клиенту уверенным тоном неправду — и репутация уходит в минус. Причём клиент уйдёт, не сказав почему.»

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

Канал автосинхронизации памяти: следующий шаг инфраструктуры Solar OS

После эпизода с Андреем Полушиным я ускорил работу над следующим элементом инфраструктуры Solar OS: автоматическим обновлением памяти ботов после завершения клиентских звонков.

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

Следующая итерация автоматизирует именно этот шаг:

• Триггер завершения созвона. Системный ассистент отслеживает завершение звонка по простой метке в Telegram: «созвон завершён». Без этого маркера — никаких автоматических действий, чтобы не создавать ложных срабатываний.
• Проактивный запрос тезисов через 5 минут. Ассистент присылает мне структурированный запрос: «Созвон с [клиент] завершён в [время]. Что решили? Жду тезисы — это займёт 2 минуты». Минимальный friction: просто продиктовать пункты ответным сообщением.
• Немедленное обновление всех связанных ботов. Как только тезисы поступают — все связанные с клиентом агенты обновляют контекст в течение 3 минут, не дожидаясь часового цикла. Это принципиально сокращает window уязвимости.
• Подтверждение клиенту. Клиент получает автоматическое краткое резюме зафиксированных решений — как подтверждение что информация записана и система синхронизирована.

По моей оценке, это закроет 80% случаев временного разрыва между созвоном и актуальными данными у ботов. Оставшиеся 20% — нестандартные ситуации, срочные звонки, случаи когда я не успеваю ответить на запрос тезисов — останутся под честным протоколом: «мои данные на [время], вот как это исправить».

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

Чек-лист: как построить AI-ассистента для клиентов без риска для репутации

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

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

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

3. Протокол для граничных запросов — конкретный, не абстрактный. Заранее определите набор допустимых ответов бота в ситуации «не знаю»: что именно он предлагает клиенту сделать дальше. Минимальный набор: (а) продиктуй тезисы — я зафиксирую, (б) уточни у [конкретного человека с контактом], (в) дождись обновления — пришлю автоматически через [конкретное время]. «Я не знаю» без следующего шага — это тупик. «Я не знаю, но вот что мы делаем» — это сервис.

4. Тестирование граничных сценариев до запуска. Специально проверьте: что бот делает если его спрашивают об информации, которой нет в контекстном файле? Что делает если данные устарели на 3 часа? На 3 дня? На 3 недели? Если во всех случаях бот уверенно отвечает — это проблема, которая всплывёт на клиентском чате в самый неудобный момент. Лучше найти это сейчас, чем узнать от клиента.

5. Мониторинг «признаний неопределённости» как позитивной метрики. Количество случаев, когда бот честно сообщил клиенту о неопределённости — это сигнал корректной работы системы. Если этот показатель внезапно падает до нуля при нормальном объёме диалогов — либо нет граничных запросов (маловероятно), либо бот перестал их детектировать и начал угадывать. Это нужно изучить немедленно.

6. Регулярный аудит пограничных диалогов. Раз в неделю просматривайте 10-15 случаев, когда бот сообщил о неопределённости. Как клиент отреагировал? Воспользовался предложенным путём? Ушёл без ответа? Написал раздражённый ответ? Это быстрый способ улучшать протоколы на основе реального поведения, а не теорий.

Такая архитектура требует больше работы на этапе проектирования. Но она экономит значительно больше на этапе работы с доверием клиентов — особенно когда система масштабируется до 5-10 ботов и выше. На масштабе 20 агентов, как в Solar OS, честная архитектура — это не опция, это фундамент.

Итоги: что забрать из этого эпизода

Главный вывод из эпизода с @spbsolar_help_bot и Андреем Полушиным звучит парадоксально для индустрии, где AI-боты соревнуются в «умности» и количестве умений: главная фишка AI-ассистента для бизнеса — не сумма умений, а честность про границы знания.

Бот, который знает 100 вещей и уверенно ошибается в 5 из них — хуже, чем бот, который знает 95 вещей и честно сигнализирует о 5 пробелах. Потому что с первым вы никогда не знаете, когда начнётся ошибка. Со вторым — знаете точно, где заканчивается достоверное. И именно поэтому доверяете ему в остальных 95 случаях по-настоящему.

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

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

Полный набор системных промптов для liaison-ботов в честном режиме, архитектурные шаблоны для temporal awareness, чек-листы тестирования граничных сценариев — в клубе «Solar — внутрянка», от 2 500 ₽/мес. Там разбираем кейсы в реальном времени: когда боты ошибаются, что именно меняем в архитектуре, как устроена синхронизация памяти между 20 агентами в продакшне.

— Solar OS.