Защита демо-стенда с LLM: лимиты, доступ и промпты

Что обычно идет не так после демо

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

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

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

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

С расходами все еще неприятнее. Ключ, который вы выдали "на час", спокойно тратит бюджет всю неделю. Иногда это десятки запросов. Иногда кто-то запускает длинный диалог с дорогой моделью, и счет растет без единого сигнала в рабочем чате.

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

Сам по себе единый LLM-шлюз проблему не решает, даже если он OpenAI-совместимый. Нужны отдельные лимиты, короткий срок доступа, маскирование данных и понятный журнал запросов. Иначе после обычной встречи вы получите сразу три проблемы: лишних людей в стенде, засвеченные промпты и лишние траты.

Из чего состоит пакет ограничений

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

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

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

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

Четвертый слой - скрытые служебные настройки. Гость должен видеть поле ввода и результат, а не температуру, route rules, fallback-логику, шаблоны промптов и внутренние метки. Одна кнопка "показать запрос" может за минуту раскрыть вашу внутреннюю логику.

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

Рабочий набор выглядит просто: временный токен, короткий TTL, минимум прав, скрытые служебные параметры и несколько независимых лимитов. На демо это почти не мешает, зато заметно снижает риск утечки и лишних расходов.

Кому и на сколько открывать доступ

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

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

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

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

Неделя доступа почти всегда лишняя. За это время ссылку успевают переслать коллегам, открыть с другого устройства или проверить, "что еще тут есть". Гораздо безопаснее открыть стенд за 30-60 минут до звонка и закрыть через час после него, если вы заранее не обещали окно для повторного теста.

Хорошее правило простое: доступ живет ровно столько, сколько длится интерес к текущей встрече. Если созвон закончился в 15:00, не оставляйте стенд открытым до понедельника. Такие хвосты потом и дают лишние запросы, странные логи и ненужный счет.

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

Даже если у вас стоит автоистечение, после созвона доступ лучше отключать вручную. Автоматика полезна, но она не заменяет привычку закрывать демо в тот же день.

Как собрать стенд по шагам

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

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

Обычно хватает такой схемы:

1. Создайте отдельный демо-проект с новой конфигурацией моделей и пустой историей.
2. Оставьте только те сценарии, которые нужны для сегодняшнего разговора.
3. Выпустите временный ключ или одноразовый доступ с коротким сроком жизни.
4. Поставьте лимиты на API до встречи, а не после первой аномалии в логах.
5. Подготовьте одно действие для отключения стенда: деактивацию ключа, остановку маршрута или выключение окружения.

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

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

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

Как не светить промпты, файлы и логи

Утечка в демо обычно случается не из-за модели, а из-за интерфейса. Команда показывает стенд, потом клиент пересылает ссылку коллеге, открывает DevTools или делает скриншот, и наружу уходит то, что никто не собирался показывать: системный промпт, куски файлов, debug-поля, история чужих сессий.

Первое правило простое: системный промпт должен жить на сервере. Браузер не должен получать его ни в явном виде, ни в составе сырого JSON, ни в скрытом поле формы. Если человек может увидеть инструкцию модели через вкладку Network, считайте, что он уже может ее скопировать.

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

Сразу уберите debug-панель с полным телом запроса и ответа, список загруженных файлов с исходными именами, историю прошлых чатов по той же ссылке, служебные id, токены сессии и трассировочные поля. Чем меньше лишнего видно снаружи, тем спокойнее потом разбирать показы.

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

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

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

После созвона очистите историю чата и закройте сессию по TTL. Лучше, если через 2-24 часа ссылка откроется в пустом состоянии. Если кто-то вернется к стенду на следующий день, он должен увидеть чистый экран, а не вчерашний запрос клиента.

Как не получить лишний счет

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

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

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

Длинные ответы съедают бюджет быстрее, чем кажется. Если клиент просит "просто показать", редко нужен вывод на 3000 токенов. Чаще хватает короткого ответа, чтобы оценить качество. То же самое с повторами: трех перегенераций на один вопрос почти всегда достаточно. Дальше человек уже не смотрит демо, а тестирует вас за ваш счет.

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

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

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

Пример после встречи с клиентом

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

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

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

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

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

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

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

Частые ошибки

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

Вторая ошибка - доступ не заканчивается сам. Менеджер обещал показать стенд до пятницы, а он живет месяц. За это время клиент может вернуться к нему сам, переслать ссылку подрядчику или встроить ваш endpoint в свой тест. Срок жизни доступа должен истекать без ручных действий.

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

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

Еще один частый промах - лимиты ставят после демо. Сначала открывают доступ, потом вспоминают про бюджет, rate limit и потолок по токенам. Порядок должен быть обратным. Лимиты нужно ставить до первой отправки стенда клиенту.

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

Короткий чек перед отправкой стенда

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

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

Перед отправкой проверьте следующее:

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

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

Если вы ведете демо через RU LLM, стоит отдельно посмотреть на маскирование PII, аудит-трейлы и логи. Для команд с требованиями по 152-ФЗ это обычная гигиена перед любым внешним показом, а не дополнительная опция.

Простой ориентир такой: если после звонка вы ничего не нажмете, стенд сам должен закрыться, перестать тратить деньги и не раскрыть лишнего.

Что делать дальше

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

Полезно сразу развести три режима. Короткое sales demo живет 1-3 дня, дает доступ к паре недорогих моделей и почти ничего не хранит. Пилот живет дольше, получает рабочие лимиты и отдельный журнал действий. Внутренний тест остается только вашей команде: там можно глубже смотреть логи и разбирать ошибки без риска, что эти данные увидит клиент.

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

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

Если вам нужен OpenAI-совместимый endpoint, хранение логов в РФ, биллинг в рублях и возможность оставить тот же SDK, код и промпты, демо можно вынести через RU LLM на api.rullm.com. Такой вариант особенно полезен, когда нужно быстро отделить внешний показ от основной среды и держать данные внутри российского контура.

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