Срок хранения логов AI API: как сбалансировать приватность, диагностику и расходы

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

Разделите три типа записей

Не называйте всё одним словом «логи»:

Тип	Назначение	Нужен полный запрос
Технический лог	Тайм-ауты, 429, 5xx и сеть	Нет
Биллинг	Модель, Token, коэффициент и сумма	Обычно нет
Аудит	Изменения ключей, прав и маршрутов	Нет текста пользователя

Для технической записи обычно достаточно request ID, провайдера, ID модели, HTTP-статуса, задержки до первого байта, общей длительности и числа повторов. Для биллинга сохраняйте input/output Token, сумму, валюту и время расчёта, если эти данные возвращает провайдер. В аудите фиксируйте оператора, объект и результат, но не полный API Key.

Выберите срок по риску

Универсального числа дней нет. В качестве начальной схемы можно хранить технические логи 7–14 дней, биллинговые записи 30–90 дней, а аудит — дольше только при наличии обоснованной необходимости. По окончании срока записи нужно автоматически удалять или обезличивать.

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

Минимальный набор полей

{
  "request_id": "req_20260920_8f31",
  "provider": "example-relay",
  "model": "model-id",
  "status": 200,
  "first_byte_ms": 620,
  "duration_ms": 4830,
  "input_tokens": 1200,
  "output_tokens": 380,
  "retry_count": 0
}

Не записывайте Authorization, полный API Key, весь диалог, Cookie и необезличенные идентификаторы. Для связи с аккаунтом используйте внутренний необратимый ID. Ошибки от посредника также нужно фильтровать: иногда они случайно содержат секреты.

Доступ и удаление

Доступ к логам должен быть отделён от доступа к production-ключам. Сотруднику поддержки достаточно статуса и времени, разработчику — технических полей по request ID, а отладочные образцы должны видеть только уполномоченные люди. Экспортируйте только обезличенные данные и задавайте срок действия ссылок на скачивание.

Добавьте поиск по request ID, периоду и статусу, а также удаление или обезличивание. Удаление должно охватывать базу, резервные копии и кэш, где это возможно. Периодически проверяйте автоматическое истечение срока на тестовой записи.

Проверочный список перед запуском

Описать поля и сроки для технических, биллинговых и аудиторских записей;
По умолчанию не хранить полный prompt, ответ, изображения и Authorization;
Настроить роли, границы поиска и срок скачивания;
Проверить автоматическую очистку через 7/30/90 дней;
Протестировать маскирование, удаление, очистку резервных копий и кэша;
Указать в политике приватности данные, срок хранения и порядок удаления.

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

Дополнительно: ошибки 401, 403 и 404 · обработка ошибки 429

Срок хранения логов AI API: как сбалансировать приватность, диагностику и расходы