Логи LLM с персональными данными: что маскировать до отправки в наблюдаемость
Для расследования полезно видеть запрос, но полный разговор может содержать адрес, номер договора, медицинские сведения или секретный ключ. Копирование всего контекста в трассы создаёт ещё одно хранилище чувствительных данных с отдельными правами и сроками. Наблюдаемость нужно проектировать с минимизацией содержания.
Начните с перечня вопросов, которые команда хочет решать по логам. Для многих достаточно статуса, версии, длительности, размера входа и технической связи между этапами.
Разбор на примере
Данные ниже вымышлены: они показывают способ разбора, а не измерения действующего сервиса.
| Данные | Учебная политика | Почему |
|---|---|---|
| Технический request_id | Сохранить | Корреляция этапов |
| Полный адрес клиента | Убрать или ограничить | Не нужен для задержки |
| Секрет авторизации | Не записывать | Не является диагностическим фактом |
| Обезличенный тип ошибки | Сохранить | Анализ отказов |
Маскирование после отправки в сторонний сервис не отменяет факта первоначальной передачи. По возможности фильтруйте данные до экспорта и проверяйте сообщения исключений: библиотеки иногда включают туда аргументы запроса.
Простая замена шаблонов не найдёт все чувствительные сведения. Имена и свободный текст могут не соответствовать регулярному выражению. Для расширенного режима диагностики нужны отдельные основания, доступ и срок хранения.
Порядок диагностики
Создайте синтетический запрос с тестовыми адресом, номером и секретом. Проверьте весь путь: приложение, очередь, обработчик ошибок, трасса и экспортёр. Поиск контрольных строк должен показать, где данные сохранились неожиданно.
Ограничьте доступ к подробным данным и ведите журнал его использования. Сохраняйте минимальный обезличенный набор для воспроизведения вместо бесконечного архива разговоров. После изменения SDK или логгера повторите проверку: новый автоматический атрибут может вернуть ранее исключённое содержание. Отдельно проверьте резервные копии диагностического хранилища.
Что этот способ не гарантирует
Техническая маскировка не заменяет требования к обработке персональных данных и договоры с поставщиками. Конкретная политика зависит от среды. Не объявляйте данные полностью анонимными только потому, что из текста удалено имя.
OpenTelemetry рассматривает минимизацию и обработку чувствительных данных при сборе телеметрии. Официальная документация помогает уточнить технический механизм; предложенный диагностический протокол — наш учебный пример.
Если хотите связать этот разбор с системной практикой, посмотрите программу LLMOps & Evaluation на Latorn: она охватывает контур оценки, версии промптов, мониторинг и выпуск LLM-приложений. Перед оплатой сопоставьте требования курса со своим опытом и задачей проекта.
Следующий шаг: LLMOps: измерение качества, расходы и выпуск изменений. По смежным вопросам: Утечка в LLM-eval: почему перефразы одного вопроса нельзя считать независимыми тестами, Тайм-ауты в LLM-eval: как не улучшить метрику удалением неудачных ответов.
