Доступ к LLM-логам: как пройти проверку без сырых данных

Почему доступ к логам быстро становится риском

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

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

Что считать LLM-логом в вашей системе

LLM-лог - это не одна строка с промптом и ответом, а набор записей о вызове модели. В него часто попадают текст запроса, ответ модели, user_id или внутренний идентификатор сотрудника, имя модели, время запроса, IP-адрес клиента, trace_id, статус ответа, число токенов и технические ошибки.

Проблема в том, что эти поля редко лежат в одном месте. Текст переписки может храниться в логах приложения, trace_id - в системе трассировки, IP и время - в API-шлюзе, а user_id - в CRM или IAM. Поэтому, когда служба безопасности просит доступ к LLM-логам, сначала нужно договориться, что именно входит в этот набор.

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

Но и метаданные не всегда безобидны. User_id, IP-адрес, email, номер договора, номер телефона, идентификатор устройства и названия внутренних файлов часто позволяют прямо или косвенно определить человека. В тексте запроса риск еще выше: сотрудники и клиенты нередко вставляют ФИО, паспортные данные, реквизиты, медицинские детали, коммерческие условия и фрагменты переписки. Для 152-ФЗ этого уже достаточно, чтобы считать лог персональными данными, а иногда и чувствительными.

Разные команды смотрят на один и тот же лог по-разному. Для ИБ это след доступа, источник инцидента и цепочка действий по trace_id. Для разработки - способ понять, почему модель дала сбой, выросла задержка или сломался роутинг. Для юристов и DPO это набор данных, у которого есть цель обработки, срок хранения, круг допущенных лиц и правила маскирования PII.

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

Кто и зачем просит доступ

Доступ к LLM-логам обычно просят не "админы вообще", а конкретные роли с понятными задачами. Служба безопасности ищет следы инцидента. Владелец сервиса проверяет, почему ответ модели ушел не туда или почему выросло число ошибок. SRE смотрит на сбои, таймауты и маршрут запроса. Юрист и DPO подключаются, когда есть жалоба, спор с клиентом или вопрос по 152-ФЗ.

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

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

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

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

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

Во многих случаях сначала достаточно посмотреть аудит по запросу: кто, когда и к какому endpoint обращался. Текст диалога нужен заметно реже, чем кажется в начале проверки.

Как разделить уровни доступа

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

Три уровня доступа

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

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

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

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

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

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

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

Как проходит запрос на проверку

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

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

Перед выгрузкой команда задает простой вопрос: можно ли ответить без содержимого промптов и ответов. Во многих случаях хватает метаданных - времени запроса, модели, статуса ответа, ID клиента, меток AI-Law, объема токенов, признака срабатывания маскирования PII. Если задача именно такая, полный текст диалогов лучше не открывать.

Рабочий порядок

1. Принять запрос в тикете и проверить, кто его подал.
2. Зафиксировать цель, период, сервис, список полей и срок доступа.
3. Понять, можно ли обойтись метаданными или короткой выборкой вместо полных логов.
4. Получить согласование у владельца данных и ответственного за комплаенс.
5. Собрать выборку, замаскировать PII, выдать доступ на короткий срок и закрыть его автоматически.

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

После просмотра работа не заканчивается. Нужно записать, кто заходил в выгрузку, что именно он смотрел, делал ли экспорт и к какому выводу пришла проверка. Для 152-ФЗ это обычная гигиена доступа, а не бумажная формальность.

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

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

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

Что оставлять видимым

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

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

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

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

Когда можно открыть исходный фрагмент

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

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

Пример проверки без чтения всей переписки

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

Команда берет из жалобы три вещи: пример ответа, примерное время запроса и контекст, где это произошло - чат поддержки, внутренний copilot или API-вызов из сервиса. Если в системе есть trace_id, его ищут первым. Если trace_id нет, берут временной интервал, ID пользователя или сервиса и имя модели. Этого обычно хватает, чтобы найти один запрос без просмотра десятков чужих диалогов.

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

Дальше выборку сужают до одного диалога. После этого аналитик открывает не всю сессию, а короткий фрагмент вокруг спорного ответа, например 10-20 строк до и после. Поля с персональными данными остаются под маской. Если система умеет маскирование PII, номер договора можно показать так: "45-17-****89". Этого хватает, чтобы понять, совпадает ли ответ модели с реальным номером, не раскрывая его полностью.

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

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

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

Где команды ошибаются чаще всего

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

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

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

Часто проблема не в самом доступе, а в копиях. Один и тот же лог лежит в хранилище приложения, в SIEM, в выгрузке аналитика и в локальной папке инженера. Общего журнала нет, аудит доступа рвется, а сроки хранения везде разные. При проверке по 152-ФЗ это выглядит плохо даже тогда, когда исходный запрос был законным.

Отдельная слабая точка - подрядчики и тестовые стенды. В проде команда уже настроила маскирование PII, роли и согласование выгрузки. А на тестовом контуре логируют все подряд, потому что "там же не боевые данные". Потом туда попадают реальные фрагменты запросов, дампы или записи из отладки.

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

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

Быстрый чек-лист перед выгрузкой

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

Для доступа к LLM-логам обычно хватает пяти проверок.

• Запрос должен быть привязан к конкретному кейсу. Номер инцидента, тикета или внутренней проверки нужен всегда.
• Начинать лучше с метаданных, а не с текста диалогов. Часто этого уже достаточно.
• Доступ должен кто-то утвердить заранее. Сразу фиксируйте, кто согласовал выгрузку, кому ее покажут и когда доступ истекает.
• До просмотра нужно замаскировать чувствительные поля: ФИО, телефон, email, номера договоров, адреса и внутренние идентификаторы клиента.
• Все действия по данным нужно записать в одном месте: причину запроса, состав выгрузки, кто открыл файл, какие поля скрыли и к какому выводу пришли.

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

Что закрепить в процессе дальше

Один устный договор здесь не работает. Если доступ к LLM-логам нужен для проверок, оформите короткий регламент на 1-2 страницы и прогоните его на живом кейсе, например на разборе спорного ответа модели или инцидента с утечкой промпта. После такой проверки быстро видно, где процесс буксует: кто согласует выгрузку, кто снимает маску с полей, кто фиксирует цель просмотра.

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

Что стоит оформить сразу

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

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

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

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

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