Маскировка промптов в мониторинге и саппорте без потерь

Где промпты утекают чаще всего

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

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

Второй частый путь - алерты. Многие системы мониторинга по умолчанию копируют payload целиком в письмо, Slack, Telegram или внутренний чат. Достаточно одного неудачного шаблона, и в канале уже лежат имя клиента, номер договора, кусок переписки с ботом или фрагмент системного промпта.

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

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

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

Что скрывать, а что оставлять

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

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

Полезный минимум

Для расследования обычно достаточно оставить:

• роль сообщения: system, user, assistant
• язык текста и примерную длину в символах или токенах
• код ошибки, HTTP-статус и время запроса
• имя модели и рабочие параметры вроде temperature
• request_id, trace_id или стабильный хеш вместо исходного текста

Такой набор сохраняет контекст разбора. Инженер видит, что запрос пришел на русском, ушел в конкретную модель, занял 842 токена и вернул 429 в 14:03:12. Этого обычно хватает, чтобы понять, это лимит провайдера, сбой маршрута или ошибка клиента.

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

Рабочее правило простое: оставляйте признаки, по которым можно сравнивать инциденты, и убирайте все, что можно прочитать как содержание. В безопасный мониторинг LLM лучше передавать не сам текст, а его короткий "паспорт": роль, язык, длину, модель, время, код ответа и идентификатор.

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

Как настроить маскировку по шагам

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

Начните с карты всех точек, где может появиться исходный текст. Ищите не только промпт, но и ответ модели, вложения, system prompt, debug-поля и комментарии оператора. Затем для каждой точки задайте свое правило. В тикете обычно хватает request_id, времени, модели, кода ошибки и короткой выжимки. В алерте нужен минимум для срочной диагностики: сервис, провайдер, статус, задержка и размер запроса. Для скриншотов правило жестче: безопаснее скрывать весь текстовый блок целиком, а не отдельные слова.

Чувствительные фрагменты лучше заменять понятными метками. Простая схема часто работает лучше любой сложной: [PII] для персональных данных, [SECRET] для токенов и ключей, [PROMPT] для содержимого запроса. Дежурный видит структуру события, но не читает исходный текст.

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

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

Хорошая маскировка не мешает разбору. Она оставляет форму, длину и служебный контекст. Например, вместо полного текста можно хранить шаблон вроде "[PROMPT: 1240 chars, lang=ru, contains=[PII]]". Часто этого достаточно, чтобы понять, почему выросла задержка, сломался парсинг или сработал фильтр.

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

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

Тикеты без сырых текстов

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

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

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

Описание ошибки должно быть коротким. Одного-двух предложений обычно достаточно: "После 14:32 ответы стали пустыми для запросов с function calling. Ошибка повторяется только на одной модели, статус 502". Такой выжимки хватает, чтобы понять направление разбора.

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

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

Алерты и логи без лишних данных

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

Для первичного разбора обычно хватает метаданных: request_id или trace_id, модель, провайдер и маршрут, размер запроса и ответа, latency, число ретраев, код ошибки и тип сбоя. Это может быть timeout, rate limit, policy block или parse error. Такой набор почти всегда закрывает первую линию разбора. Дежурный видит, что сломалось, когда это началось и где проблема повторяется, но не читает пользовательский текст.

Длинные поля лучше не обрезать посередине. Если поле может содержать текст пользователя, заменяйте его целиком маркером вроде "[redacted_user_text, 1840 chars]". Частичная обрезка опасна: первые 100 символов часто уже содержат имя, номер договора или внутреннюю инструкцию.

Как держать логи в порядке

Разделяйте служебные метки и пользовательский текст на уровне схемы лога. Метаданные должны жить в отдельных полях: tenant, model, status_code, token_count, latency_ms, cache_hit, masking_status. Текст запроса и ответа либо не пишите в общий лог вообще, либо храните в отдельном контуре с более строгим доступом.

Тогда дашборды, алерты и поиск по инцидентам работают по служебным полям, а не по сырому телу запроса. Если команда использует OpenAI-совместимый шлюз, например RU LLM, это удобно делать прямо на уровне прокси: в алерт попадают audit-поля и метрики, а не payload целиком.

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

Хорошая проверка простая. Отправьте тестовый запрос с заметным маркером вроде "SECRET-TEST-123", вызовите ошибку и проследите весь путь алерта: интерфейс, почта, чат, мобильные пуши, история инцидента. Если маркер всплыл хоть где-то, правило еще не работает.

Скриншоты и записи экрана

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

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

Что должно остаться в кадре

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

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

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

Один шаблон для всей команды

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

Подойдет простой набор правил:

• один стиль размытия для текста и ID
• короткая подпись под кадром: сервис, время, тип ошибки
• фиксированная область, которую можно показывать
• запрет на полный экран, если проблему видно в одном окне

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

Пример разбора инцидента

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

В нормальной схеме саппорт получает не текст запроса, а короткую карточку инцидента: request_id, время запроса, имя модели, тип канала и маски вроде [ACCOUNT] и [PHONE]. Этого достаточно, чтобы открыть trace и не трогать исходные данные клиента.

Если запрос идет через RU LLM, команде помогают аудит-трейл и встроенное маскирование PII: в тикете уже видно, какие части система скрыла до того, как запись попала в мониторинг.

Саппорт видит, что проблема случилась в 14:06, модель ответила слишком уверенно, а в маске дважды встретился токен [ACCOUNT]. Сам prompt он не читает. Он передает инженеру request_id и короткое описание: "ошибка в ответе после подстановки счета".

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

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

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

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

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

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

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

Вторая ошибка еще проще: инженер или агент саппорта копирует сырой текст в комментарий к тикету, потому что так быстрее. Через час тикет видят другие очереди, подрядчик на поддержке или менеджер без нужного уровня доступа. Маскировка в логах уже не помогает, если секреты уехали в help desk руками команды.

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

Еще одна проблема - разные правила в разных системах. В SIEM текст уже обезличен, в APM все еще виден кусок запроса, а в help desk хранится полный диалог. Команда думает, что политика есть, но у каждой системы своя версия правил. Даже если шлюз вроде RU LLM маскирует PII и ведет аудит по запросам, утечка все равно случится дальше по цепочке, если тикеты и алерты живут по другим правилам.

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

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

Быстрая проверка перед запуском

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

Маскировка работает только тогда, когда дежурный все равно понимает, что случилось. Для этого ему нужны не слова пользователя, а понятные опорные данные: request_id, trace_id, код ошибки, модель, маршрут, время, длина запроса, метки PII и причина срабатывания правила. Если система пишет "policy_block: personal_data" или "provider_error: 429", полный prompt обычно не нужен.

Перед запуском проверьте несколько вещей. Тикет должен открываться без полного prompt, а в карточке должны быть ID запроса, тип сбоя, метки риска и технический контекст. Дежурный должен понимать причину без чтения текста: по статусу, таймингам, модели, route_id и истории повторов. Алерт в почте и чатах не должен тянуть тело запроса в тему, превью или вложение. Скриншот не должен показывать ФИО, телефоны, токены, номера договоров и другие секреты. Оригинал должен храниться в одном месте и открываться только по роли.

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

Для команд, которые строят процесс вокруг RU LLM, удобно передавать в тикет trace_id, аудит-трейл и метки AI-Law вместо исходного текста. Это помогает разбирать инциденты без лишних копий данных в саппорте.

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

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

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

На ближайшую неделю хватит четырех шагов:

• выбрать самый проблемный канал утечки и обновить шаблон тикета
• назначить владельца правил маскировки
• убрать чувствительный текст как можно ближе ко входу в логи
• прогнать 10-20 реальных кейсов и убедиться, что разбор не стал медленнее

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

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

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