# Телеметрия inference API без записи prompt по умолчанию

Как наблюдать inference API без prompt capture по умолчанию: allowlist metadata, nested tool arguments, ошибки, exported payload и проверка redaction.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/provider-telemetry-content-redaction/
Language: ru

Для диагностики inference API обычно нужны время, outcome, модель и безопасные идентификаторы. Полное содержание prompt не должно попадать в каждый технический канал просто потому, что SDK умеет его захватывать. При этом удаление поля в одном logger ещё не означает, что оно исчезло из trace, exception или exporter. Провайдеру нужна проверяемая политика телеметрии с явным набором разрешённых данных и тестом всей цепочки.

## Определите минимальную запись

[OpenTelemetry о sensitive data](https://opentelemetry.io/docs/security/handling-sensitive-data/) описывает минимизацию, фильтрацию и redaction как отдельные меры. Начните с allowlist: endpoint, согласованное имя модели, duration, outcome и ограниченные технические поля. Для каждого значения назовите цель и место хранения. «Может пригодиться» слишком широко для автоматического включения содержимого пользователя.

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

## Разведите metadata и content

[GenAI span conventions](https://raw.githubusercontent.com/open-telemetry/semantic-conventions-genai/main/docs/gen-ai/gen-ai-spans.md) отдельно рассматривают захват instructions, inputs и outputs. Такое содержимое может появляться в разных формах, включая вложенные структуры. Политика должна охватывать не только prompt string, но и messages, tool arguments, результаты инструментов и дополнительные поля ошибок.

Если content capture нужен для ограниченного диагностического сценария, он имеет собственные условия, права и срок хранения. Это не следует незаметно включать общей настройкой production exporter. Статья описывает архитектурную границу, а не объявляет конкретную политику обработки данных любого внешнего сервиса.

## Проверьте propagation

[OpenTelemetry context propagation](https://opentelemetry.io/docs/concepts/context-propagation/) связывает операции между компонентами. Однако baggage и headers могут переносить больше metadata, чем требуется. Сохраните allowlist передачи и точки удаления, особенно на границе внешнего запроса. Trace context не является разрешением копировать содержимое пользователя через всю инфраструктуру.

Для диагностики обычно достаточно связи безопасных IDs. Не создавайте новый секрет в имени span или metric label. Даже если основной payload очищен, такая строка способна оказаться в другой системе с иным доступом и retention. Проверка должна включать все наблюдаемые exported fields.

## Создайте marker fixture

Используйте синтетический маркер SYNTHETIC_SECRET в обычном message, вложенном tool argument и контролируемом error path. Затем соберите фактический вывод тестового exporter. Ожидаемый результат — разрешённая metadata присутствует, запрещённый маркер не обнаруживается на выбранных проверяемых выходах.

Не проверяйте только функцию redaction unit-тестом. Другой middleware может записать исходный body до фильтра либо добавить exception с фрагментом входа. Integration fixture должен наблюдать последовательность до конечного тестового приёмника, сохраняя конфигурацию и версию SDK вместе с результатом проверки.

## Сохраните границы доказательства

Отсутствие маркера на доступном выходе подтверждает именно этот путь и набор fixtures. Оно не доказывает отсутствие любых данных во всех внешних системах. Если часть exporter-chain недоступна наблюдению, отчёт честно сохраняет неизвестную область вместо универсальной формулировки «ничего не хранится».

Связанные темы — [DLP шлюза](/ru/journal/ai-gateway-dlp/) и [безопасность доступа](/ru/journal/hardware-security/). Здесь фокус на собственной telemetry pipeline: минимальный набор, проверка реального экспорта и ясная граница выводов без неподтверждённых обещаний приватности конкретной компании.