← Назад в блог

Почему у меня запрещено ставить LLM на клиентскую сторону

У меня в студии работает 13 автономных задач на Claude. Они ведут мой LinkedIn, пишут статьи для блога, мониторят SSI-систему, отправляют уведомления в Telegram. Я им доверяю — и сплю спокойно. Потому что если Claude напишет что-то не то в моём имени, я это увижу. Но если бы он написал это в ответ на вопрос покупателя о возврате товара на сайте моего клиента — это другая история. Именно поэтому у меня есть правило: никаких LLM на клиентской стороне. Пока.

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

Что такое «клиентская сторона» в моём понимании

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

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

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

Граница не в технологии. Граница в том, кто видит output и несёт ли бизнес ответственность за его содержание перед внешним человеком.

Три фундаментальных различия

Когда AI делает ошибку внутри моей системы — я вижу её в логах. У меня есть STOP-файл, JSONL-логи, Telegram-уведомления о статусе каждой задачи. Если статья вышла не той интонацией — я вижу это до публикации или сразу после. Цена ошибки — мои нервы и время на исправление.

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

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

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

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

Риски LLM в продакшне: что происходит, когда это игнорируют

На Хабре в 2026 году прошла волна публикаций от команд, которые поставили LLM в поддержку e-commerce и обнаружили паттерн, который один автор назвал «идеальным лжецом». Модель галлюцинировала с уверенностью. Придумывала сроки доставки, которых не было в базе. Обещала скидки, которые не существовали. Давала инструкции по возврату, прямо противоречившие реальной политике магазина. Покупатели получали ответы, звучавшие как официальная позиция компании.

Это не баг конкретной модели. Это свойство LLM: генерация правдоподобного текста, а не верифицированной информации. «Правдоподобный» и «правильный» — не одно и то же. В контексте вопроса о сроках доставки правдоподобный ответ может быть катастрофически неправильным.

Команды в этих историях откатывали продукт через 1-3 недели. Самое неприятное — они не всегда находили все ошибки. Часть покупателей просто ушла тихо, без претензий.

Почему prompt engineering не решает проблему

Стандартный контраргумент: «мы пропишем хороший системный промпт, ограничим scope, дадим модели только проверенные данные через RAG». Я слышу это часто. И это разумный путь — но он не устраняет проблему, он смещает её.

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

У меня в 13 внутренних задачах Claude тоже иногда ошибается. В статье появляется неточная формулировка, задача выполняется не так, как я планировал. Это нормально — я в контуре. Но перенести эту логику на клиентскую сторону — значит принять, что n% разговоров с покупателями будут содержать ошибку. Это решение, которое я не готов принимать за клиента.

Где AI допустим в клиентском контексте

Это не значит, что AI вообще нельзя трогать в e-commerce. Есть зоны, где он работает без прямого general reasoning:

  • Ранжирование без объяснений. Elasticsearch с поведенческими сигналами, ML-модель для упорядочивания результатов — это не LLM, который объясняет покупателю «почему этот товар вам подойдёт». Сигнал → вес → порядок. Нет генерации текста — нет галлюцинаций.
  • Персонализация весов. Модель, которая решает, показывать ли баннер — без объяснений, без диалога. Бинарное, детерминированное решение.
  • Внутренняя предобработка контента. Черновики описаний товаров, которые товаровед вычитывает и редактирует до публикации. AI ускоряет человека, но не заменяет его в коммуникации с покупателем.

Во всех этих случаях AI не разговаривает с покупателем. Он обрабатывает данные внутри системы, а результат видит либо сотрудник, либо покупатель получает его в детерминированной форме без LLM-генерации в real time.

Чеклист: когда я готов пересмотреть правило

Я не говорю «никогда». Я говорю «пока нет». Критерии, при которых я изменю подход:

  1. Полный observability разговоров. Не выборка — каждый диалог логируется и есть система для их ревью. Пока масштаб меньше 100 диалогов в день — возможно.
  1. Ограниченный scope с детерминированным fallback. LLM отвечает только на вопросы из проверенной базы знаний; если confidence ниже порога — передаёт человеку. Не «старается ответить», а честно говорит «не знаю, уточните у менеджера».
  1. Нет доступа к транзакционным данным в real time. Не к ценам, не к остаткам, не к статусам заказов — пока эти данные не верифицированы внешней системой с гарантированной консистентностью.
  1. Клиент понимает и принимает риск. Не «мы внедрили AI» в пресс-релизе — а реальное понимание того, что 0.5% разговоров могут содержать неточность, и это допустимо для их бизнес-модели.
  1. Есть процедура работы с последствиями. Что происходит, когда LLM ошибся? Кто разбирает претензию? За сколько времени?

Пока у клиента нет ответов на все пять пунктов — правило действует. Не из страха перед AI. Из уважения к тому, что разница между «моя ошибка» и «ошибка перед чужим покупателем» — не техническая, а этическая.

Внутри студии я продолжу ставить Claude на всё, где это имеет смысл. 13 задач станут 20. Но граница останется там же: approval gate на всё, что видит клиент.

*Внутренние ссылки: Где я намеренно держу approval gate · Как я доверяю AI-агенту в продакшне · Баг, который написал Claude*