Чек-лист по хранению данных API ИИ должен отвечать на простой вопрос еще до запуска производственного трафика: какие записи будут существовать после вызова модели, кто сможет их читать, как долго они будут храниться и какие доказательства покупатель сможет просмотреть позже?
Этот вопрос быстро усложняется. Один-единственный запрос к ИИ может создать записи промптов, записи результатов, логи запросов шлюза, логи мониторинга злоупотреблений со стороны провайдера, события аудита, трассировки, записи в кэше, строки биллинга, тикеты поддержки, экспортированные данные, скриншоты и заметки об инцидентах. Некоторые записи помогают инженерам отлаживать сбои. Некоторые помогают финансовому отделу сверять расходы. Некоторые помогают отделу закупок доказать, что настройки поставщика были проверены. А некоторые вообще не должны существовать для чувствительных рабочих нагрузок.
Используйте этот чек-лист по хранению данных API ИИ, чтобы разделить эти записи до того, как вы направите реальные данные клиентов через шлюз. Цель не в том, чтобы бездумно хранить меньше записей. Цель — хранить нужные доказательства для операционной деятельности, безопасности, финансов и закупок, не превращая каждый промпт и результат в долгосрочное хранилище данных.
Для покупателей Flatkey эта проверка относится к файлу утверждения шлюза. Текущий публичный сайт Flatkey позиционирует продукт как шлюз API ИИ и платформу для операций с моделями, обеспечивающую доступ к моделям, маршрутизацию, биллинг, аналитику использования и операционный контроль. Это делает его естественным местом для централизации доказательств, касающихся маршрута, модели, владельца, использования и стоимости. Это не отменяет необходимости проверять специфичные для аккаунта правила хранения, контракты с провайдерами и поведение при хранении полезной нагрузки до утверждения.
Чек-лист по хранению данных API ИИ
Начинайте с класса записи, а не со слогана поставщика. «Нулевое хранение данных» для одной функции провайдера не описывает автоматически ваши логи шлюза, трассировки наблюдаемости, биллинговую книгу, экспортированные данные или рабочий процесс поддержки.
| Область хранения | Что нужно решить | Какие доказательства хранить | Позиция по умолчанию |
|---|---|---|---|
| Промпты | Хранятся ли необработанные сообщения пользователя/системы/разработчика, извлеченный контекст, файлы и входные данные инструментов | Диаграмма потоков данных, настройка полезной нагрузки, тест на редактирование, тест на удаление | Не хранить необработанные промпты по умолчанию |
| Результаты | Хранятся ли ответы модели, аргументы вызовов инструментов, сгенерированные файлы и потоковые фрагменты | Политика логирования результатов, настройка хранения, тест доступа | Не хранить необработанные результаты по умолчанию |
| Логи запросов | Какие поля метаданных сохраняются для отладки и операционной деятельности | Пример события в логе, словарь полей, период хранения | Хранить метаданные без тел полезной нагрузки |
| Логи аудита | Какие административные события и события политик являются достаточно неизменяемыми для проверки | Лог смены ролей, лог ключевых событий, лог изменения политики маршрутизации | Хранить дольше, чем отладочные полезные нагрузки |
| Данные биллинга | Какие записи об использовании, стоимости, счетах, пополнениях, налогах и возвратах платежей сохраняются | Пример счета, экспорт данных об использовании, поля для сверки | Хранить в соответствии с потребностями финансового отдела и условиями контракта |
| Записи провайдера | Что вышестоящие провайдеры моделей сохраняют для мониторинга злоупотреблений, состояния приложения, кэширования и хранения данных функций | Документация провайдера, условия контракта, скриншоты аккаунта | Проверять для каждого провайдера, эндпоинта и аккаунта |
| Экспорт данных наблюдаемости | Какие трассировки, оповещения, дашборды, тикеты и хранилища получают копии | Список назначений, конфигурация маскирования, пример экспорта | Минимизировать и редактировать перед экспортом |
| Записи поддержки | Включают ли заметки об инцидентах фрагменты промптов/результатов | Рабочий процесс поддержки, хранение тикетов, правило редактирования | Хранить очищенные доказательства, а не необработанные полезные нагрузки |
Это основной чек-лист по хранению данных API ИИ: определите каждый класс записей, назначьте ответственного за хранение, подтвердите настройку датированным отчетом и установите триггер обновления для каждого места, куда могут быть скопированы данные.
Отделяйте хранение от обучения
Политика обучения провайдера — это всего лишь одна строка в проверке. Отделы закупок часто спрашивают, используются ли данные API для обучения моделей. Это важно, но не отвечает на вопрос, хранятся ли промпты или результаты для мониторинга злоупотреблений, состояния приложения, функций продукта, поддержки, аналитики или биллинга.
В элементах управления данными платформы OpenAI различаются обучение моделей, хранение данных для мониторинга злоупотреблений и хранение данных о состоянии приложения. В той же документации говорится, что логи мониторинга злоупотреблений могут включать промпты и ответы и по умолчанию хранятся до 30 дней, в то время как соответствующие критериям клиенты могут подать заявку на такие элементы управления, как Modified Abuse Monitoring или Zero Data Retention. В ней также перечислены исключения для конкретных эндпоинтов, включая хранение состояния приложения для некоторых API и специфичное для функций поведение для файлов, разговоров, видео, кэширования, веб-поиска, размещенных контейнеров и других возможностей.
Документация по хранению данных API от Anthropic определяет Zero Data Retention как ситуацию, когда данные клиента не хранятся в состоянии покоя после возврата ответа API, за исключением случаев, связанных с юридическими требованиями, предотвращением неправомерного использования и хранением данных для конкретных функций. В ней также отмечается, что право на использование функции может различаться в зависимости от возможностей API.
В документации по ZDR для Gemini Developer API от Google говорится, что промпты и ответы платных сервисов не используются для улучшения продуктов Google, но при этом описывается ограниченное логирование промптов и ответов для мониторинга злоупотреблений и хранения данных для конкретных функций. Эта страница делает ZDR предметом проверки конфигурации и выбора функций, а не универсальным предположением.
Урок для покупателя практичен: храните доказательства политики провайдера, но не позволяйте им заменять вашу собственную политику хранения данных API ИИ. Провайдер может хранить одно, шлюз — другое, а ваш стек наблюдаемости может копировать и то, и другое.
Для промптов и результатов нужны свои правила
Промпты и результаты — это записи с самым высоким риском в чек-листе по хранению данных API ИИ, поскольку они часто содержат наиболее полезные данные для отладки и самые конфиденциальные бизнес-данные.
Рассматривайте хранение промптов и результатов как исключительный рабочий процесс:
- По умолчанию не хранить необработанные полезные данные для производственных маршрутов, если это не требуется для конкретной рабочей нагрузки.
- Разрешать хранение отредактированных полезных данных только после того, как фикстуры докажут, что маскирование работает для промптов, результатов, итогов работы инструментов, извлеченных фрагментов, ошибок и потоковых событий.
- Разрешать полное хранение полезных данных только для именованного инцидента, промежуточного теста, утвержденного клиентом рабочего процесса или эскалации поставщику.
- Устанавливать срок хранения до сбора данных, чтобы окно отладки не превратилось в постоянное хранилище.
- Логировать доступ к логам полезных данных, поскольку средство просмотра логов становится уязвимой системой.
- Сохранять очищенную сводку по инциденту после истечения срока хранения полезных данных, а не необработанный промпт или результат.
Здесь будет полезна шпаргалка по логированию от OWASP, поскольку она рассматривает конфиденциальные значения в логах как проблему проектирования, а не форматирования. Секреты, токены доступа, конфиденциальные персональные данные, платежные данные, строки подключения, ключи шифрования и данные высокой степени секретности обычно следует удалять, маскировать, очищать, хешировать или шифровать перед логированием. Промпты ИИ могут содержать все эти категории.
Что касается шаблонов редактирования, документация инструментов указывает в том же направлении. Маскирование в Langfuse может редактировать данные до того, как данные трассировки покинут приложение. Функция Helicone Omit Logs предназначена для сохранения операционных метрик при пропуске тел запросов и ответов. Элементы управления логированием запросов Portkey отделяют содержимое запросов/ответов от логирования, ориентированного на метрики. Даже если вы используете другой стек, принцип тот же: редактировать или пропускать данные перед хранением и экспортом.
Логи запросов должны в первую очередь содержать метаданные
Логи запросов обычно являются основной рабочей силой в операциях с API ИИ. Для того чтобы быть полезными, им не нужно содержать необработанные промпты.
Для большинства производственных маршрутов достаточно события, ориентированного на метаданные:
{
"request_id": "req_01jz4...",
"timestamp": "2026-07-04T04:00:00Z",
"environment": "production",
"owner_key_id": "support_summarizer_prod",
"route": "support-summary",
"endpoint_family": "chat_completions",
"requested_model": "approved-summary-route",
"served_provider": "selected_by_gateway",
"prompt_tokens": 1840,
"output_tokens": 312,
"status": "success",
"latency_ms": 1420,
"cost_usd": "0.0042",
"payload_storage": "none",
"retention_class": "ops_metadata_90d"
}
Такое событие поддерживает проверку биллинга, корреляцию инцидентов, проверку маршрутизации, проверку SLO, расследование злоупотреблений и возвратные платежи владельцу без сохранения тела промпта или ответа.
Логирование Cloudflare AI Gateway показывает, почему решения о логировании запросов должны быть явными. Логи шлюза могут включать провайдера, модель, статус, использование токенов, стоимость, продолжительность, промпты, ответы и действия политики, а элементы управления для каждого запроса могут влиять на то, сохраняются ли тела запросов и ответов. Чек-лист по хранению данных должен фиксировать как настройки шлюза по умолчанию, так и любые пути переопределения для отдельных запросов.
Используйте этот чек-лист для логов запросов:
| Группа полей | Сохранять по умолчанию? | Примечания |
|---|---|---|
| ID запроса, ID трассировки, временная метка | Да | Необходимо для поддержки и рассмотрения инцидентов |
| Ключ, проект, маршрут, среда | Да | Используйте стабильные внутренние ID; избегайте необработанных секретов |
| Провайдер, модель, семейство эндпоинтов | Да | Необходимо для маршрутизации и доказательств для поставщика |
| Статус, класс ошибки, причина повторной попытки/отката | Да | Необходимо для проверки надежности |
| Количество токенов, задержка, стоимость | Да | Необходимо для финансов и обнаружения аномалий |
| Результат проверки безопасности/DLP/политики | Обычно | Храните метаданные решения, а не конфиденциальный совпавший текст, если это не требуется |
| Тело промпта | Нет по умолчанию | Эскалировать через рабочий процесс отладки |
| Тело результата | Нет по умолчанию | Эскалировать через рабочий процесс отладки |
| Входные и выходные данные инструмента | Нет по умолчанию | Часто содержит частные системные данные |
| Извлеченные фрагменты и файлы | Нет по умолчанию | Часто содержит документы, контракты или данные клиентов |
Именно здесь хранение данных API ИИ становится операционной, а не теоретической задачей: инженеры по-прежнему получают необходимые им записи, в то время как владельцы, отвечающие за конфиденциальность и безопасность, могут видеть, что было намеренно опущено.
Логи аудита — это не логи полезных данных
Логи аудита отвечают на вопросы, кто, когда и что изменил, а также сработал ли путь контроля. Обычно они должны храниться дольше, чем полезные данные для отладки, но не должны становиться лазейкой для хранения полезных данных.
Чек-лист по хранению данных API ИИ должен включать события аудита для:
- Создание, ротация, отключение и удаление ключей API.
- Изменения в рабочих пространствах, проектах, маршрутах, провайдерах и политиках моделей.
- Изменения в квотах, бюджетах и контроле биллинга.
- Включение, отключение логирования полезной нагрузки и утверждение исключений.
- События доступа к конфиденциальным логам и экспортированным данным.
- Изменения ролей администраторов и предоставление разрешений.
- События экспорта, удаления данных и эскалации в службу поддержки.
Логи аудита должны содержать имя исполнителя, цель, действие, временную метку, исходную систему, ссылку на утверждение и состояние до/после. В них не следует хранить необработанные промпты, необработанные результаты, необработанные ключи API, токены носителя, данные платежных карт и неотредактированные клиентские данные.
Свяжите эту статью с руководством Flatkey по логам аудита использования API ИИ, когда отделу закупок требуется надежная модель событий для операций шлюза. Лог аудита должен подтверждать применение политики хранения; ему не нужно сохранять конфиденциальную полезную нагрузку, которая вызвала применение политики.
Данные биллинга требуют иного подхода к хранению
Данные биллинга легко упустить из виду в чек-листе по хранению данных API ИИ, потому что они не похожи на данные промптов. Тем не менее они важны.
Данные биллинга и финансовые записи могут включать:
- Идентификаторы ключа API, рабочего пространства, команды, проекта, клиента или среды.
- Модель, провайдер, семейство конечных точек и маршрут.
- Токены промпта, токены результата, кэшированные токены, единицы изображений/видео, продолжительность или количество запросов.
- Цена за единицу, фактическая цена, наценка, кредиты, налоги, строка счета, запись о пополнении, возврат и движение баланса.
- Временная метка, расчетный период, идентификатор счета, идентификатор платежного провайдера и ссылка на бухгалтерскую книгу.
Эти записи обычно должны храниться дольше, чем полезные нагрузки для отладки, поскольку финансовым, налоговым отделам, службе поддержки клиентов и отделу закупок требуются доказательства для сверки. Они все равно требуют минимизации. Бухгалтерской книге биллинга не требуются необработанные промпты или результаты для подтверждения расходов.
Используйте эту таблицу по хранению данных биллинга:
| Артефакт биллинга | Типичный владелец | Вопрос о хранении | Нужна ли полезная нагрузка? |
|---|---|---|---|
| Строка использования | Финансовые операции и платформа | Как долго нам нужны доказательства для возврата платежей? | Нет |
| Счет-фактура | Финансы | Какие правила налогообложения, аудита и клиентских договоров применяются? | Нет |
| Пополнение или движение предоплаченного баланса | Финансы | Может ли команда сверить изменения баланса с использованием? | Нет |
| Снимок цен | Закупки и финансы | Какая цена за единицу действовала во время выполнения запроса? | Нет |
| Запись о споре с клиентом | Поддержка и финансы | Какие очищенные доказательства объясняют списание? | Обычно нет |
| Счет-фактура от поставщика | Финансы и закупки | Можно ли связать расходы на вышестоящие сервисы с внутренним использованием? | Нет |
Текущая страница с ценами Flatkey описывает прозрачное ценообразование на модели, оплату по мере использования, лимиты квот, аналитику использования, контроль затрат и способы проверки счетов. Рассматривайте это как полезные публичные заявления для предварительной оценки, а затем проверьте действующую панель управления, условия учетной записи, счета и экспортированные данные для собственной записи покупателя.
Создайте файл доказательств, принадлежащий покупателю
Страницы доверия полезны, но долговечный артефакт должен принадлежать покупателю. Рецензент через шесть месяцев должен иметь возможность увидеть, что было проверено на дату утверждения и что изменилось позже.
Создайте папку или запись управления со следующей структурой:
| Элемент доказательства | Что фиксировать | Триггер для обновления |
|---|---|---|
| Карта потоков данных | Путь запроса от приложения к шлюзу, провайдеру, системам наблюдаемости, биллинга, поддержки и экспорта | Новый провайдер, инструмент, маршрут или экспортер |
| Настройки провайдера | Скриншоты или данные API о хранении, обучении, ZDR/MAM, регионе и поведении состояния приложения | Изменение контракта или функциональности провайдера |
| Настройки шлюза | Логирование запросов, логирование полезной нагрузки, редактирование, удаление, политика маршрутизации и контроль экспорта | Релиз или изменение конфигурации шлюза |
| Пример лога метаданных | Очищенное событие, подобное производственному, без тела полезной нагрузки | Новое семейство конечных точек или маршрут |
| Тест редактирования | Результаты тестов для промптов, результатов, данных инструментов, извлеченных фрагментов и фрагментов потока | Новый SDK, модель, инструмент или экспортер |
| Запись об исключении для полезной нагрузки | Кто утвердил полное логирование полезной нагрузки, почему, область действия, срок истечения и доказательства очистки | Каждый инцидент |
| Пример события аудита | События, связанные с ключами, маршрутами, квотами, ролями, логированием, экспортом и удалением | Изменение роли или рабочего процесса администратора |
| Пример данных биллинга | Строка использования, снимок цен, доказательства по счету/пополнению и сопоставление с владельцем | Изменение цен или рабочего процесса биллинга |
| Проверка доступа | Кто может просматривать логи, хранилища полезной нагрузки, экспортированные данные, счета и тикеты поддержки | Ежеквартально или при изменении роли |
| Тест удаления | Доказательство того, что логи, полезные нагрузки, экспортированные данные и тикеты могут истекать или быть очищены | Изменение политики хранения или процесса удаления клиента |
Этот файл доказательств превращает хранение данных API ИИ из заявления поставщика в повторяемый процесс проверки. Это также упрощает продление, поскольку рецензент может сравнить текущее состояние с предыдущим, а не начинать все с нуля, основываясь на маркетинговых материалах.
Определите классы хранения до запуска
Не позволяйте каждой системе изобретать свой собственный период хранения. Определите классы хранения и сопоставьте каждую запись с одним из них.
retention_classes:
ops_metadata_90d:
stores_payload: false
records:
- request_id
- route
- provider
- model
- status
- latency
- token_usage
- cost
access: engineering_ops_finance_security
debug_payload_72h:
stores_payload: true
approval_required: true
redaction_required: true
expiration_required_before_collection: true
access: named_incident_responders
audit_control_1y:
stores_payload: false
records:
- actor
- action
- target
- before_after_state
- approval_reference
access: security_procurement_admins
finance_ledger_contract_term:
stores_payload: false
records:
- usage
- pricing_snapshot
- invoice
- recharge
- balance_movement
access: finance_procurement
Точные сроки должны определяться вашими контрактами, политикой безопасности, налоговыми требованиями и обязательствами перед клиентами. Важно, чтобы класс существовал до начала трафика и чтобы хранение полезной нагрузки было видно как отдельное свойство.
Как это соотносится с Flatkey
Flatkey может поддерживать операционную модель, поскольку общедоступная поверхность продукта сосредоточена на одном API-шлюзе, маршрутизации моделей, видимости использования, биллинге, контроле квот и операционном обзоре. Проверка API цен в реальном времени от 4 июля 2026 года вернула success=true, 45 строк моделей, 48 записей поставщиков, версию цен a42d372ccf0b5dd13ecf71203521f9d2 и поддерживаемые пути конечных точек, включая /v1/chat/completions, /v1/messages, Gemini generateContent, конечные точки для генерации изображений и видео.
Используйте Flatkey как поверхность для сбора доказательств на уровне шлюза, а затем проверьте специфичные для аккаунта детали, которые публичные страницы не могут подтвердить:
- Какие метаданные запросов хранит Flatkey.
- Хранятся ли необработанные тела промптов и ответов.
- Можно ли отключить, ограничить по области видимости, отредактировать или ограничить по времени хранение полезной нагрузки.
- Какие события аудита доступны для ключей, маршрутов, квот, биллинга и доступа к логам.
- Какие экспортные данные биллинга доступны для финансовой сверки.
- Какие настройки хранения данных поставщика применяются за каждым маршрутом.
- Какие пути поддержки, экспорта и наблюдаемости могут копировать данные запросов.
Это различие имеет значение. Шлюз может упростить операции и сбор доказательств, но покупатель по-прежнему несет ответственность за итоговый чек-лист по хранению данных API ИИ.
Проведите предпроизводственный тест хранения данных
Прежде чем утверждать производственный маршрут, проверьте чек-лист на тестовой нагрузке.
- Отправьте обычный запрос и убедитесь, что лог метаданных появляется без тела промпта или ответа.
- Отправьте запрос, содержащий заранее подготовленные чувствительные данные, такие как электронные письма, строки, похожие на токены доступа, идентификаторы аккаунтов, значения, похожие на платежные данные, и маркеры проприетарного кода.
- Убедитесь, что эти данные не появляются в логах, трассировках, оповещениях, экспортных данных поддержки или записях биллинга, если только маршрут явно не был направлен по утвержденному пути отладки.
- Включите ограниченное по области видимости исключение для отладочной полезной нагрузки в непродуктивной среде и проверьте утверждение, логирование доступа, редактирование и истечение срока действия.
- Удалите или дождитесь окончания периода хранения отладочных данных и убедитесь, что при повторном чтении полезная нагрузка больше не возвращается.
- Получите событие аудита для изменения политики логирования и для удаления данных.
- Получите строку биллинга или использования и убедитесь, что она сверяется без содержимого полезной нагрузки.
- Запишите скриншоты, ответы API, временные метки, идентификаторы аккаунтов и имена проверяющих в файл с доказательствами.
Этот тест выявляет распространенную ошибку: команда отключает хранение полезной нагрузки в шлюзе, но текст промпта все равно утекает через экспортер трассировок, сообщение об ошибке, тикет в техподдержку или скриншот отладки.
Место этого в проверке на доверие
Хранение данных API ИИ — это одна из частей более широкой проверки шлюза. Используйте чек-лист по корпоративному шлюзу API ИИ, чтобы охватить доступ, маршрутизацию, биллинг, квоты и операционную ответственность. Используйте оценку рисков поставщика API ИИ для сравнения контрактов с вышестоящими поставщиками и сторонними обработчиками. Используйте руководство по логам аудита для использования API ИИ, когда отдел закупок спросит, как шлюз доказывает, кто изменял ключи, маршруты, квоты и политику логирования.
Эти проверки должны быть взаимосвязаны. Чек-лист по шлюзу показывает поверхность управления. Оценка рисков поставщика показывает вышестоящий контракт и границы данных. Руководство по логам аудита показывает надежные административные доказательства. Этот чек-лист по хранению данных API ИИ показывает, что остается после каждого запроса.
Часто задаваемые вопросы
Что такое хранение данных API ИИ?
Хранение данных API ИИ — это политика и поведение системы, которые определяют, как долго хранятся промпты, результаты, логи метаданных, события аудита, трассировки, строки биллинга, записи поддержки и записи на стороне поставщика после запроса к API ИИ.
Означает ли нулевое хранение данных отсутствие логов?
Нет. Нулевое хранение данных обычно описывает специфичный для поставщика или функции контроль над контентом клиента. Это может не распространяться на метаданные шлюза, логи аудита, записи биллинга, экспортные данные наблюдаемости, тикеты поддержки или все функции поставщика. Всегда проверяйте область действия и исключения.
Следует ли хранить промпты и результаты для отладки?
Только в виде исключения. Логи метаданных должны быть стандартом для производственного трафика. Храните отредактированные или полные полезные нагрузки только для утвержденных рабочих процессов, ограниченных инцидентов, промежуточных тестов или утвержденных клиентами каналов, и устанавливайте срок истечения до сбора данных.
Как долго следует хранить логи запросов к API ИИ?
Универсального срока не существует. Логам метаданных часто требуется достаточно времени для расследования инцидентов, сверки счетов и расследования злоупотреблений. Необработанные полезные нагрузки промптов и результатов обычно должны иметь гораздо более короткий срок хранения, чем метаданные, логи аудита или записи биллинга.
Какие данные биллинга важны для хранения данных API ИИ?
Храните строки использования, количество токенов, идентификаторы моделей/провайдеров, снимки цен, счета-фактуры, записи о пополнении, возвраты и сопоставления владельцев в качестве финансовых доказательств. Эти записи не должны требовать необработанных текстов промптов или результатов.
Что отдел закупок должен спросить у поставщика шлюза?
Запросите датированные подтверждения метаданных запросов, поведения при хранении полезной нагрузки, редактирования, удаления, журналов аудита, контроля доступа, экспорта данных биллинга, настроек хранения у провайдера и мест назначения экспорта третьим сторонам. Затем сравните эти подтверждения с вашей собственной политикой классификации данных и реагирования на инциденты.
Заключение
Чек-лист по хранению данных API ИИ превращает расплывчатые заявления о доверии в проверяемый рабочий файл. Отделяйте промпты от результатов, логи запросов от логов аудита и данные биллинга от отладочных данных. Храните метаданные по умолчанию, сохраняйте необработанные данные только в исключительных случаях, тестируйте редактирование перед сохранением и сохраняйте датированные подтверждения для продлений. Когда вы будете готовы централизовать доступ к моделям, их использование, биллинг и маршрутизацию через единый шлюз, ознакомьтесь с текущими ценами и каталогом моделей Flatkey, а затем получите ключ.
