ChatGPT API: как скрывать PII в streaming-событиях до логирования

Сначала определите цель каждого журнала

У лога может быть только одна из трёх целей: эксплуатационная диагностика, аудит локальной операции или краткоживущий тест. Для каждой цели задайте допустимые поля до подключения streaming. Обычно достаточно request ID приложения, tenant, времени, размера фрагмента, версии адаптера и статуса обработки. Если поле не нужно для решения инцидента, его не должно быть в общем журнале.

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

Постройте allowlist и отдельный redactor

Не пытайтесь угадать все чувствительные значения регулярным выражением после отправки события в систему логов. Сначала соберите малый объект из разрешённых полей, затем пропустите текстовый фрагмент через локальный redactor, если текст вообще необходим. Redactor должен возвращать метку состояния, а не исходное значение: например, redacted, skipped или needs_review.

Отделите этот код от транспортного адаптера. Транспорт принимает поток и проверяет форму события; redactor работает с ограниченным буфером; логгер получает только безопасный результат. Так смена SDK не даёт случайно записать исходный payload, а правило маскирования можно покрыть отдельными тестами без подключения к реальному endpoint.

Учитывайте границы фрагментов и неполные данные

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

Не отправляйте сырой буфер в клиент, аналитическую систему или очередь ошибок. При превышении лимита сохраните только категорию truncation и локальный operation ID. Это не является доказательством, что все PII были найдены; для конкретной классификации данных нужны правила вашей организации и, где требуется, проверка специалиста по безопасности или праву.

Не маскируйте только пользовательский текст

Секрет может находиться и в заголовке, имени инструмента, URL, ошибке proxy или метаданных трассировки. Перед записью нормализуйте события и исключите Authorization, cookie, ключи, полный URL с параметрами и произвольные заголовки. Клиентский браузер не должен получать серверный trace, если он может раскрыть внутреннюю инфраструктуру.

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

Сделайте ошибку redaction наблюдаемой и безопасной

Если redactor не понимает тип события или превышает лимит, не подставляйте исходный текст «для диагностики». Запишите категорию redaction_failed, версию правила и безопасный request ID, затем отправьте операцию в ручную очередь. Такой путь помогает исправить схему без незаметного снижения защиты.

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

Проверьте правило на fixture до выпуска

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

Для следующего шага используйте статьи о логировании AI API без утечек, обезличивании данных перед LLM API и tracing без prompt. Они описывают инженерные контрольные точки; текущие правила и договор вашего проекта остаются источником решения.

Безопасный server-side пример

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

export function safeStreamLog(event, operationId) {
  const kind = typeof event?.type === 'string' ? event.type : 'unknown';
  const size = typeof event?.delta === 'string' ? event.delta.length : 0;
  if (size > 512 || !['delta', 'completed'].includes(kind)) {
    return { operationId, kind, state: 'needs_review' };
  }
  return { operationId, kind, size, state: 'redacted' }; // never returns event.delta
}

Критерий готовности

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

Граница ответственности и данных

Не передавайте в браузер, обычный журнал, тикет или статью API-ключи, заголовок Authorization, cookie, ключи поставщиков, полный prompt либо персональные данные. Для расследования используйте минимальные технические метаданные и синтетические fixtures.

Контроль перед выпуском

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

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

Полезные материалы

OWASP Logging Cheat Sheet · NIST Privacy Framework

FAQ

Достаточно ли одной regex для PII?

Нет. Поле может быть разрезано между чанками или оказаться в метаданных. Начинайте с allowlist, не передавайте сырой payload в общий лог и тестируйте redactor на синтетических фрагментах.

Можно ли хранить полный streaming-ответ для отладки?

Не по умолчанию. Сначала определите законную цель, доступ, срок и минимальный объём. В большинстве эксплуатационных журналов достаточно безопасного operation ID, категории, версии адаптера и счётчика размера.

Является ли redaction гарантией соответствия требованиям?

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

Следующий шаг

Продолжите с материалами: Логирование AI API без утечек · Обезличивание данных перед LLM API · Tracing LLM API без prompt. Затем протестируйте интеграцию на staging до production-трафика.