Что логировать в корпоративном LLM для аудита и расследований

Зачем логировать корпоративный LLM

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

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

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

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

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

• какие категории данных запрещены (пароли, токены, полные номера документов, медицинские данные);
• какие поля нужно маскировать или сокращать;
• какие данные хранить только агрегированно (например, статистика без текста);
• кто может видеть сырой текст и при каких основаниях.

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

Список событий: что фиксировать по минимуму

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

Практичный минимум для аудита и первых расследований:

• Аутентификация и сессии: вход и выход, создание и завершение сессии, смена роли или набора прав, вход с нового устройства или сети. Фиксируйте и удачные, и неудачные попытки.
• Вызовы модели: получение запроса на генерацию, успешная выдача ответа, отмена пользователем, повторный запрос, таймаут. Сюда же относится переключение модели (если доступно) и запуск фоновых задач, связанных с генерацией.
• Операции с данными для RAG: загрузка документа, обновление версии, индексация, переиндексация, удаление, изменение прав доступа к источнику. Эти события часто объясняют, почему ответы внезапно меняются.
• Административные действия: изменение политик (что разрешено отправлять в модель), настройка лимитов, включение или отключение функций, ротация ключей, изменения интеграций.
• События безопасности: превышение лимитов, срабатывание правил блокировки, подозрительные шаблоны запросов (массовые выгрузки, попытки получить закрытые данные), частые ошибки доступа.

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

Поля запроса и ответа: что нужно для восстановления картины

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

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

Минимальный набор полей для запроса и ответа:

• Идентификаторы: user_id, tenant_id, отдел (если есть), приложение-источник (app_id или channel).
• Трассировка: request_id, conversation_id, trace_id (чтобы собрать путь через прокси, RAG, модель, фильтры).
• Время и скорость: server_time, timezone, длительность обработки (latency_ms).
• Запрос: исходный текст или безопасная версия, язык, тип запроса, размер, hash для дедупликации.
• Ответ: текст или безопасная версия, формат (текст, JSON), длина, признаки отказа или фильтрации.

Для расследований особенно важны признаки «почему ответ не такой». Логируйте флаги вроде safety_blocked, content_filtered, policy_violation, а также версию политик или правил, которые сработали. Без этого одинаковые запросы могут давать разные ответы, и вы не поймете причину.

Пример: сотрудник утверждает, что система «выдала запрещенные данные». По trace_id вы собираете цепочку, видите user_id и приложение, сверяете server_time, находите точный текст запроса (или маскированный вариант), затем проверяете, был ли ответ отфильтрован и какой conversation_id сформировал контекст. Даже если контент в логах частично скрыт, связка идентификаторов, времени и статусов обычно позволяет восстановить картину без доступа к чувствительным данным.

Контекст и источники (RAG): как логировать обоснование ответа

Если LLM работает с поиском по базе знаний (RAG), для аудита важен не только ответ, но и то, на чем он был основан. Здесь легко либо ничего не доказать, либо наоборот превратить логи в копию базы знаний. Нужен баланс.

Контекст стоит понимать широко: системные инструкции (system prompt), шаблоны подсказок, параметры бизнес-ролей, «память» диалога (несколько предыдущих реплик), а также правила, которые добавляет приложение (например, запрет на определенные темы). В логах полезно хранить версии этих компонентов и их идентификаторы, а не только финальный склеенный текст.

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

• внутренний ID документа, название, владелец/подразделение, версия или дата актуальности;
• ID коллекции/индекса, по которому шел поиск;
• top-k результатов, оценки релевантности, примененные фильтры (права доступа, язык, тип документа);
• какой именно фрагмент был передан модели: диапазон страниц/абзацев или ID чанка;
• причина исключений: документ найден, но не показан из-за прав или политики.

Текст выдержек храните осторожно. Часто достаточно сохранять хеш фрагмента и ссылку на внутренний идентификатор чанка, а небольшой безопасный сниппет (1-2 предложения) добавлять только если это разрешено политикой. Так вы покажете, «какие факты были под рукой», не делая логи вторым хранилищем знаний.

Если источники могут содержать персональные данные или коммерческую тайну, добавьте явную пометку классификации и режим хранения. Практичный подход: маскировать поля (ФИО, ИИН, номера договоров), а для расследований давать доступ к полным выдержкам только через отдельный защищенный контур и по роли (например, служба ИБ). Пример: при споре о закупочной спецификации вы быстро увидите, что в top-k попала устаревшая версия документа, и модель опиралась на нее, даже если сам текст документа в логах не хранится целиком.

Модель и настройки: что важно для воспроизводимости

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

Минимальный набор для каждого вызова:

• идентификатор модели (имя, версия или ревизия), провайдер и регион развертывания;
• параметры генерации (temperature, top_p, max_tokens, stop);
• включенные политики безопасности (фильтры, режимы, уровни строгости);
• действующие лимиты и квоты (токены на запрос, скорость, суточные ограничения);
• версия промпта или шаблона (ID, хеш, номер релиза) и активные системные инструкции.

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

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

Пример: сотрудник жалуется, что модель стала «слишком осторожной» и перестала отвечать на типовые вопросы. Логи показывают: версия модели та же, но изменился режим фильтра на более строгий и снизился max_tokens. Это объясняет короткие ответы и частые отказы.

Ошибки и отказы: какие детали помогут в расследовании

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

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

Отдельный слой - ошибки качества, когда формально «успешно», но результат непригоден: пустой ответ, слишком короткий, нарушен обязательный формат (JSON, таблица, поля), или модель ушла в другую тему. Здесь помогает хранить итоговый статус проверки качества (pass/fail) и причину, а не только сам ответ.

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

Для ретраев достаточно короткого, но точного следа:

• число попыток и итог (успех или окончательный отказ);
• интервалы ожидания между попытками;
• причина каждой повторной попытки;
• менялись ли параметры (например, другой маршрут, другой провайдер).

Наконец, делайте снимок окружения: версия сервиса, конфигурация (идентификатор профиля, а не весь файл), идентификатор узла/контейнера, регион, версия ключевых зависимостей. Простой пример: «ошибка формата JSON» может оказаться не моделью, а обновлением валидатора на одном узле, которое началось в 14:32 и затронуло только часть трафика.

Защита данных в логах: маскирование и минимизация

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

Не храните в чистом виде то, что можно использовать сразу и без контекста. В первую очередь это:

• пароли, одноразовые коды, ответы на секретные вопросы;
• API-токены, ключи, сертификаты, приватные ключи;
• session cookies и идентификаторы, которые дают доступ к аккаунту;
• полные номера карт и CVV;
• персональные номера и документы (например, ИИН), если они не нужны для расследования.

Дальше настройте редактирование (redaction) по понятным правилам. Для телефонов оставляйте только последние 2-4 цифры, для ИИН или паспортных данных - только первые и последние символы, для карт - только BIN и последние 4. Маскирование делайте до записи в лог (на уровне приложения или прокси), а не «позже в хранилище».

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

Разделяйте логи по смыслу. Технические логи (время, ошибки, идентификаторы, метрики) должны быть доступны шире. Содержательные логи (тексты запросов и ответов, фрагменты из RAG-источников) храните отдельно, с более короткой ретеншн и более жесткими ролями.

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

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

Хранение логов: ретеншн, целостность и архив

Логи корпоративного LLM быстро разрастаются, поэтому заранее решите, где они живут и сколько живут. Это влияет и на стоимость, и на то, сможете ли вы восстановить картину инцидента. Хорошее правило: храните логи централизованно и разделяйте среды (dev, test, prod), чтобы тестовые данные не смешивались с боевыми.

Ретеншн: разные сроки для разных частей

Разделите данные на уровни хранения. Контент (текст запроса и ответа) обычно самый чувствительный и самый тяжелый. Метаданные (время, идентификаторы, модель, ошибки) чаще нужны дольше.

Практичная схема:

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

Целостность, архив и удаление

Для аудита важно, чтобы логи нельзя было тихо подправить. Используйте неизменяемое хранилище (WORM или режим append-only), а для контроля целостности фиксируйте хеши и цепочки хешей по батчам или по дням. Тогда при проверке можно доказать, что запись не менялась.

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

Минимальный набор практик:

• единый центральный сбор логов с разделением по средам;
• регулярные бэкапы и тест восстановления (не на бумаге, а реально);
• отдельный архив для долгого хранения метаданных;
• контроль целостности (хеши, подписи, неизменяемость);
• процедура безопасного удаления с фиксацией факта удаления.

Доступ к логам: роли, контроль и прозрачность

Логи корпоративного LLM часто содержат и тексты запросов, и следы внутренних действий (RAG, маршрутизация, ошибки). Поэтому доступ к ним должен быть таким же строгим, как к бизнес-данным. Иначе даже правильная схема логирования обернется утечкой через журнал.

Роли и принцип минимальных прав

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

• пользователь: видит только свои запросы и статусы, без чужих сессий;
• аналитик: видит метрики и агрегаты, иногда обезличенные фрагменты;
• ИБ/комплаенс: доступ к полным логам по инциденту и с оформлением основания;
• администратор: доступ к техлогам (ошибки, задержки), но не обязательно к тексту.

Удобный прием - два уровня логов: «контентные» (запросы, ответы, выдержки источников) и «технические» (trace_id, модель, время, коды ошибок). Технические логи открываются шире, контентные - только по заявке.

Поиск, учет просмотров и экспорт

Для расследований важен быстрый поиск. Обычно достаточно фильтров по trace_id, пользователю, документу-источнику (id/хеш), модели и версии промпта.

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

• фрагмент по trace_id с временным окном;
• метаданные вместо полного текста, если этого достаточно;
• маскированные поля (ПДн, номера, токены);
• подтверждение целостности (хеш/подпись);
• отметку о получателе и сроке хранения копии.

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

Пошагово: как спроектировать логирование для LLM

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

Практичный план:

1. Определите цели и владельцев. Аудит, расследования, качество ответов, контроль расходов на токены - и кто принимает решения по каждому направлению (ИБ, ИТ, продукт).
2. Опишите события и поля. Зафиксируйте единые форматы (время, пользователь, модель, источники, ошибки) и идентификаторы (user_id, session_id, request_id), чтобы разные системы «склеивались».
3. Введите сквозной trace_id. Он должен проходить от интерфейса до RAG-поиска, фильтров доступа, вызова модели и постобработки. Тогда один инцидент ищется одним запросом.
4. Маскируйте до записи. Убирайте или заменяйте ПДн и секреты еще до попадания в лог, и добавьте тесты, которые ловят утечки.
5. Настройте алерты по аномалиям. Иначе о проблеме вы узнаете только от пользователей.

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

• рост ошибок (таймауты, 429/5xx, падение поиска по источникам);
• всплеск токенов и стоимости на пользователя или команду;
• появление новых типов источников или резкое изменение топ-источников.

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

Пример сценария: как логи помогают найти причину инцидента

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

Сначала находят конкретную сессию по связке conversation_id, user_id, времени запроса и приложению-источнику (портал, мессенджер, Service Desk). Так вы отсекаете похожие диалоги и сразу видите, был ли один запрос или цепочка уточнений.

Дальше проверяют контекст выполнения: системную инструкцию (system prompt), включенные инструменты (например, поиск по базе знаний), параметры безопасности. Здесь часто всплывает, что запрос шел не через основной клиент, а через интеграцию с другими настройками.

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

Чаще всего причина одна из трех:

• ошибка фильтра по меткам доступа (документ без нужной классификации или с неправильной);
• неверные права на документ в исходной системе (доступ открыт шире, чем ожидается);
• промпт или шаблон ответа подталкивал модель к пересказу конфиденциальных деталей.

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

Быстрый чеклист и следующие шаги

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

Короткий чеклист:

• у каждого запроса есть уникальный идентификатор (request/trace), привязка к пользователю или сервису и точное время;
• зафиксирована воспроизводимость: какая модель отвечала, ее версия, ключевые настройки генерации и какая политика безопасности применялась;
• для RAG видно обоснование: какие источники подтягивались, их версии и какой фрагмент реально попал в контекст;
• ошибки не теряются: коды, таймауты, причины отказа и на каком шаге это произошло (поиск, сбор контекста, генерация);
• логи устроены безопасно: метаданные отделены от содержимого, чувствительные поля маскируются, а доступы к самим логам тоже логируются.

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

Чтобы не утонуть в объеме:

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

Если нужна практическая помощь с инфраструктурой и интеграцией, это часто удобнее делать вместе с системным интегратором. Например, GSE.kz (gse.kz) как производитель серверов и интегратор в Казахстане помогает собирать корпоративные контуры для LLM и настраивать поддержку, чтобы логирование, хранение и контроль доступа были частью единой системы.