Журналирование и хранение запросов

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

Что сохраняется

Для каждого запроса /v1/chat/completions шлюз может создать одну строку во внутренней таблице prompt_logs:

• Messages — точный массив messages, отправленный клиентом, после удаления секретов. Bearer tokens, значения sk-…, gw_… и JWT-подобные токены заменяются на [REDACTED]; части с изображениями сворачиваются в [redacted-image], исходные bytes не сохраняются.
• Response — тело ответа в OpenAI-формате для непотокового запроса. Для всех streaming-запросов, включая успешно завершённые, тело ответа не сохраняется.
• Metadata — request id, пользователь-владелец и timestamp expires_at.

Мы не сохраняем:

• API key. Секрет gw_ проверяется в auth store и никогда не попадает в prompt_logs.
• Исходные bytes изображений и base64 payloads. В журнале vision-запросов остаётся placeholder.
• Тела анонимных запросов и запросов к каталогу. Журналируются только аутентифицированные обращения к /v1/chat/completions.

Срок хранения

• Retention: 7 дней. Maintenance sweep каждые 15 минут безвозвратно удаляет строки, у которых expires_at уже в прошлом.
• Storage: тот же кластер Postgres, где хранится аккаунт. Данные не передаются третьим лицам и не используются для обучения.
• Access: через аутентифицированные пользовательские и операторские интерфейсы. Удаление оператором записывается в admin_audit_log; для чтения эта документация не обещает отдельную audit-запись.

Зачем это нужно

Три задачи журналирования запросов:

1. Отладка — при сообщении о некорректном ответе мы можем воспроизвести его по точным сообщениям, не прося отправить их повторно.
2. Разбор злоупотреблений — журнал помогает быстрее обнаружить неправомерное использование ключей, чем одни метрики.
3. Проверка биллинга — при споре можно сопоставить списанные AI-кредиты с токенами, которые фактически обработал upstream.

Как отказаться

Доступны три варианта:

• Self-service переключатель аккаунта. Откройте настройки приватности профиля и отключите журналирование запросов. Профиль отправит promptLoggingEnabled: false, после чего новые запросы не будут записываться в prompt_logs. Уже созданные строки остаются до конца семидневного срока либо до удаления.
• Удаление отдельной строки. Оператор может удалить конкретную запись prompt_logs по id через админ-консоль. Сам факт удаления аудируется, но payload исчезает.
• Удаление данных аккаунта. Вы можете запросить удаление данных аккаунта из личного кабинета. Пока запрос обрабатывается, аккаунт блокируется, а его сессии и API-ключи отзываются. По завершении удаляются все строки prompt_logs, принадлежащие аккаунту, а также задачи генераций и сгенерированные медиафайлы; строки журнала API-запросов обезличиваются. Полный объём удаления описан в Политике конфиденциальности.

Правовое основание

• Согласие фиксируется при регистрации в рамках Пользовательского соглашения: доступ предоставляется при понимании, что запросы хранятся 7 дней для перечисленных целей.
• Срок хранения задаётся на уровне платформы, а не отдельного запроса; увеличить TTL одной строки без изменения глобальной политики нельзя.
• Нет профилирования, автоматизированного принятия решений и передачи данных. Буфер хранения нужен только для операторского расследования на self-hosted single-tenant развёртывании.

Если ваши требования строже — нулевое хранение, audit controls уровня HIPAA или on-prem key management — обсудите их с поддержкой до передачи production-трафика через шлюз.