Журналы аудита API ИИ — это слой доказательств, лежащий в основе проверки безопасности. Проверяющие спрашивают не только о том, вызывало ли приложение модель. Им нужно знать, кто сделал запрос, какой ключ или проект использовался, какая модель и провайдер обработали его, сохранялись ли конфиденциальные полезные данные, как долго хранятся записи и может ли команда восстановить инцидент, не раскрывая промпты, завершения, секреты или персональные данные.
Это делает журналы аудита API ИИ отличными от обычных журналов API. Запрос LLM может за один вызов проходить через владельцев приложения, ключи шлюза, upstream-провайдеров, маршруты моделей, счетчики токенов, резервные пути, центры затрат и политики работы с данными. Журнал аудита должен связывать эти уровни, не превращая хранилище журналов во второе хранилище чувствительных данных.
Flatkey здесь уместен, потому что flatkey.ai публично позиционирует продукт как единый API-шлюз для production-команд ИИ, с доступом к моделям, маршрутизацией, биллингом, аналитикой использования, операционными контролями, панелью управления и базовым URL роутера https://router.flatkey.ai/v1. Центральный шлюз может стать точкой контроля для ведения журналов API ИИ и предоставления доказательств для проверки, но эта статья не предполагает конкретную схему экспорта журналов аудита, срок хранения или объем соответствия требованиям, специфичные для Flatkey. Уточните эти детали в вашей текущей консоли, прежде чем передавать доказательства покупателю.
Краткий ответ: что спрашивают аудиторы безопасности
Хороший пакет журналов аудита AI API отвечает на семь повторяющихся вопросов. Если вы можете ответить на них записями, а не скриншотами и сообщениями из Slack, проверка поставщика становится намного проще.
| Вопрос проверяющего | Какие доказательства показать | Типичный провал |
|---|---|---|
| Кто использовал AI API? | Актор, служебная учетная запись, владелец ключа, владелец приложения, проект, команда, среда и идентификатор запроса. | Отображается только общий ключ провайдера, поэтому принадлежность приходится угадывать. |
| Какой путь модели был использован? | Маршрут шлюза, провайдер, модель, семейство конечных точек, решение о резервном переходе, статус, задержка и класс ошибки. | Журналы приложения знают действие пользователя, а журналы провайдера — вызов модели, но ничто их не связывает. |
| Какие данные были сохранены? | Режим логирования полезной нагрузки, политика редактирования, настройка хранения prompt/completion и примечания по обработке чувствительных данных. | Сырые промпты и ответы сохраняются по умолчанию без бизнес-обоснования или плана маскирования. |
| Можно ли восстановить инцидент? | Идентификаторы запросов, временные метки, идентификаторы трассировки приложения, идентификаторы запросов шлюза, идентификаторы запросов провайдера, где доступны, и экспортируемая история событий. | Журналы можно искать на одной панели, но их нельзя экспортировать или сопоставлять с событиями приложения. |
| Как вы предотвращаете неконтролируемые расходы? | Отчеты об использовании и расходах по ключу, проекту, модели, владельцу и временным интервалам, а также доказательства проверки квоты или бюджета. | Журналы аудита показывают изменения, но в наборе доказательств отсутствуют отчеты об использовании и расходах. |
| Как долго хранятся журналы? | Срок хранения, поведение при удалении, процесс архивации/экспорта и кто может утверждать доступ к выгрузкам журналов. | Команды хранят журналы вечно, потому что никто не выбрал срок хранения. |
| Кто может просматривать журналы? | Список ролей или групп, согласования доступа, мониторинг доступа к журналам и разделение между метаданными и журналами полезной нагрузки. | Любой, у кого есть доступ к панели, может просматривать чувствительные тела запросов. |
Журналы аудита AI API — это не то же самое, что отчёты об использовании
Специалисты по безопасности часто говорят «логи», имея в виду три разных типа доказательств: события аудита, наблюдаемость запросов и отчётность по использованию или затратам. Если рассматривать их как отдельные уровни, это помогает избежать путаных ответов.
| Тип доказательства | Основной вопрос | Типичные поля | Что это само по себе не доказывает |
|---|---|---|---|
| Журналы аудита провайдера | Кто изменил организацию, проект, ключ, роль или параметры конфигурации? | Субъект, email или ID субъекта, тип события, целевой ресурс, отметка времени, сведения об IP/сеансе и детали изменения конфигурации. | Какой запрос приложения потребил токены или какой рабочий процесс клиента инициировал трафик к модели. |
| Журналы запросов шлюза | Что произошло с каждым запросом AI API? | ID запроса, ключ шлюза, владелец приложения, провайдер, модель, endpoint, статус, задержка, маршрут/резервный вариант, количество токенов, стоимость и метаданные. | Изменились ли настройки роли или ключа на стороне провайдера до запроса. |
| Отчёты по использованию и затратам | Какой объём трафика, токенов и расходов был по владельцу, ключу, проекту, модели и временному интервалу? | Входные токены, выходные токены, кэшированные токены, количество запросов, проект, пользователь, API-ключ, модель, строка учёта, сумма и валюта. | Кто одобрил доступ, кто изменил ключ или какой именно запрос не удался во время инцидента. |
Admin API OpenAI — полезный публичный пример такого разделения. Его endpoint Audit Logs описывается как список недавних действий пользователей и изменений конфигурации организации, тогда как endpoints usage и costs предоставляют поля по использованию/затратам и варианты группировки, такие как project, user, API key, model, service tier, line item и time bucket. Такое разделение — хорошая мысленная модель для любой программы журналов аудита AI API: события аудита, журналы запросов и отчёты по использованию/затратам должны быть связаны, но они не взаимозаменяемы.
Чек-лист полей журналов аудита AI API
Используйте этот чек-лист как матрицу доказательств для ревизий AI gateway. Не каждое поле должно попадать в каждое хранилище логов. Суть в том, чтобы определить, что относится к метаданным логов, что — к ограниченным логам полезной нагрузки, что — к административным логам провайдера, а что не следует сохранять вообще.
| Группа полей | Рекомендуемые поля | Ценность для ревьюера | Примечание по обработке |
|---|---|---|---|
| Время и корреляция | Время события, ID запроса gateway, ID трассировки приложения, ID запроса провайдера, если доступен, и ID пакета экспорта. | Позволяет командам восстановить последовательность и связать записи приложения, gateway и провайдера. | Используйте устойчивый идентификатор взаимодействия для связанных событий. |
| Идентификация и владение | Владелец ключа gateway, сервисная учетная запись, проект, приложение, команда, центр затрат, окружение и ID тенанта клиента, если нужно. | Показывает ответственность и помогает отвечать на вопросы vendor-risk о совместно используемых ключах. | По возможности отдавайте предпочтение внутренним ID или хэшированным идентификаторам вместо сырых персональных данных. |
| Путь запроса | Семейство endpoint'ов, провайдер, модель, группа маршрутов, решение о fallback, статус кэша, число повторных попыток и код статуса. | Объясняет, какой путь модели обслужил запрос и почему произошел fallback. | Не храните секреты из заголовков запроса. |
| Операционные метрики | Длительность, время до первого токена, где доступно, класс ошибки, событие rate-limit, решение по квоте и решение по политике. | Поддерживает разбор инцидентов и проверку надежности. | Сохраняйте полезные детали ошибок, но очищайте недоверенный ввод. |
| Использование и стоимость | Входные токены, выходные токены, кэшированные токены, число запросов, оценочная стоимость, позиция для биллинга и валюта. | Поддерживает анализ бюджета, распределение затрат и расследование необычных расходов. | Используйте распределение затрат по командам и отслеживание использования по ключам для агрегаций. |
| Политика полезной нагрузки | Режим логирования полезной нагрузки, результат редактирования, решение DLP, хэш промпта, хэш ответа и индикаторы вложения/файла. | Показывает, были ли конфиденциальные данные сохранены, подавлены или преобразованы. | Для проверки безопасности и разбора инцидентов часто достаточно логирования только метаданных. |
| Хранение и доступ | Класс хранения, дата удаления, расположение архива, разрешение на экспорт, роль просмотрщика и событие доступа к логам. | Отвечает на вопросы о минимизации данных, ограничении хранения и контроле доступа ревьюеров. | Фиксируйте доступ к чувствительным логам и ограничивайте просмотр полезной нагрузки. |
Руководство OWASP по логированию — хорошая отправная точка: в логах приложений следует фиксировать когда, где, кто и что; данные событий из других зон доверия следует считать недоверенными; а чувствительные данные перед попаданием в логи нужно удалять, маскировать, санитизировать, хэшировать или шифровать. Для журналов аудита AI API последний пункт особенно важен, потому что промпты и completion'ы могут содержать секреты, регулируемые данные, контент клиентов и внутреннюю стратегию.
Матрица доказательств для SOC 2, ISO 27001, GDPR и проверки поставщиков
Приведённая ниже таблица — не сопоставление с правовыми контролями. Это практичный способ перевести язык проверки безопасности в доказательства, которые ваша платформа действительно может предоставить.
| Область проверки | Что обычно спрашивают проверяющие | Доказательства из аудиторских журналов AI API | Ответственный за доказательства |
|---|---|---|---|
| Контроль доступа | Кто может создавать, просматривать, обновлять или отзывать ключи AI API и настройки шлюза? | События аудита администратора провайдера, инвентарь ключей шлюза, список ролей/групп и запись проверки доступа. | Безопасность или платформа |
| Контроль изменений | Как вы доказываете, что маршрут модели, квота, ключ или политика были изменены через утверждённый процесс? | Заявка на изменение, согласующий, событие аудита, настройка до/после, запись развертывания и заметка об откате. | Инженерия платформы |
| Реагирование на инциденты | Можете ли вы восстановить подозрительное использование или ошибки провайдера за заданный период? | Идентификаторы запросов, метки времени, метаданные актор/проект/ключ, решения по маршрутизации, коды статуса, число токенов и экспортированный пакет событий. | Операции безопасности |
| Минимизация данных | Вы храните сырые промпты и ответы? Если да, то почему и кто может их видеть? | Режим логирования полезной нагрузки, политика редактирования, список пользователей с ограниченным доступом к просмотру полезной нагрузки и подтверждение того, что при использовании есть режим только с метаданными. | Безопасность, конфиденциальность и владелец приложения |
| Сроки хранения | Как долго хранятся журналы и как удаляются просроченные журналы? | Политика хранения, лимит хранилища, правило удаления, правило архивации и запись мониторинга доступа к журналам. | Безопасность и управление данными |
| Управление затратами | Можете ли вы обнаружить неожиданные расходы на модели или отнести их к команде? | Экспорты использования/затрат, сгруппированные по ключу, проекту, модели, команде, временному интервалу и событиям квот. | FinOps или платформа |
| Риск поставщика | Можете ли вы показать проверяющему конкретный, воспроизводимый процесс предоставления доказательств? | Пакет для проверяющего с исходными системами, датой экспорта, временным диапазоном, владельцем, заявлением о редактировании и индексом доказательств. | Безопасность и закупки |
Для проверок в стиле GDPR официальные принципы статьи 5 включают минимизацию данных и ограничение срока хранения. Применительно к аудиторским журналам AI API это означает, что вы должны документировать, почему каждое сохранённое поле необходимо, по умолчанию избегать хранения сырых полезных нагрузок и устанавливать срок хранения, соответствующий цели журналов.
Что не следует помещать в журналы аудита LLM
Самый быстрый способ провалить проверку логирования — создать больше чувствительных данных, чем нужно самому production-приложению. Журналы аудита LLM должны помогать отвечать на вопросы безопасности, не превращаясь в неконтролируемую копию разговоров с клиентами.
| Данные | Риск | Более безопасный подход |
|---|---|---|
| Сырые промпты и завершения | Могут содержать персональные данные, секреты, контент клиентов, привилегированный контент или регулируемые данные. | По умолчанию ведите только метаданные; сохраняйте полезные нагрузки только для одобренных сценариев с ограниченным доступом и сроком хранения. |
| API-ключи, bearer-токены и учетные данные поставщика | Создает риск раскрытия учетных данных внутри системы доказательств. | Никогда не логируйте секреты. Вместо этого храните ID ключа, владельца ключа или хешированный отпечаток. |
| Не обезличенные идентификаторы пользователей | Расширяет область приватности и усложняет обмен экспортами. | Используйте внутренние ID пользователей, ID арендаторов или salted-хеши, если только не требуются и не одобрены исходные значения. |
| Полные заголовки запроса и ответа | Заголовки могут содержать cookies, токены аутентификации, trace baggage и имена внутренней инфраструктуры. | Оставляйте только заголовки из allowlist, например request ID, класс user agent или безопасные метаданные шлюза. |
| Отладочные трассы из неудачных вызовов модели | Отладочные данные могут включать сырые полезные нагрузки, stack traces и детали внутренней реализации. | Перед сохранением выполняйте санитизацию и храните расширенные отладочные записи отдельно от стандартных журналов аудита. |
Публичная документация Cloudflare по AI Gateway показывает полезное различие: построчные настройки могут отключать хранение сырых полезных нагрузок запросов и ответов, сохраняя при этом метаданные, такие как количество токенов, модель, провайдер, код статуса, стоимость и длительность. Публичная документация Vercel по наблюдаемости AI Gateway описывает сводки запросов по проекту и API-ключу, а также подробные журналы запросов с полями токенов и стоимости. Это публичные примеры общего подхода: делайте метаданные широко полезными, а доступ к полезным нагрузкам жестко ограничивайте.
Как спроектировать журнал аудита AI Gateway
журнал аудита ai gateway работает лучше всего, когда он спроектирован до того, как его запросит проверяющий. Используйте этот рабочий процесс, чтобы превратить разрозненные логи в доказательства для проверки.
- Выберите контрольную точку. Определите, какие запросы должны проходить через AI gateway, какие административные события провайдера остаются в его аудит-логах, а какие события приложения — в логах приложения.
- Определите безопасные метаданные владельца. Стандартизируйте поля project, app, team, environment, cost center, customer tenant и key owner. Избегайте произвольных значений, которые раскрывают персональные данные.
- Определите режим логирования полезной нагрузки. Разделите логирование только метаданных и логирование сырого prompt/response. Требуйте явного одобрения для хранения полезной нагрузки.
- Сопоставляйте request ID. Передавайте request или trace ID из приложения в gateway и сохраняйте идентификаторы gateway/provider, где это возможно.
- Отделяйте события изменений от событий запросов. Создание ключей, изменения маршрутов, изменения ролей и изменения квот относятся к audit events. Вызовы модели относятся к request logs.
- Связывайте использование и стоимость. Добавляйте агрегации по key, project, model, team и time bucket, чтобы на вопросы о бюджете можно было ответить из одного и того же пакета доказательств.
- Задайте правила хранения и экспорта. Определите, кто может экспортировать логи, как редактируются выгрузки, где хранится доказательная база и когда она удаляется.
- Проверьте пакет для проверяющего. Выберите безопасный временной диапазон, экспортируйте доказательства и убедитесь, что другой инженер может восстановить путь запроса только по этому пакету.
- Проводите ежеквартальный обзор доступа. Логируйте доступ к логам, ограничивайте просмотр полезной нагрузки и удаляйте устаревшие права на дашборды и экспорт.
Если вы уже направляете трафик через Flatkey, начните рабочий процесс с центрального маршрутизатора: проверьте текущий base URL, keys, owners, usage analytics, billing context, routing controls, quota controls и метки dashboard. Затем свяжите эти записи с app trace IDs и аудиторскими событиями на стороне provider. Для смежных работ по настройке используйте enterprise AI API gateway checklist, AI API observability logs guide и gateway key rotation runbook.
Шаблон пакета для рецензента
Когда покупатель просит журналы аудита API ИИ, не отправляйте сырой экспорт без пояснений. Отправьте пакет доказательств, который показывает охват, обработку данных и трассируемость.
| Раздел пакета | Содержимое | Почему это важно |
|---|---|---|
| Заявление об охвате | Система, среда, диапазон дат, включенные приложения, включенные ключи шлюза и исключенные источники. | Не позволяет рецензентам предполагать, что выборка охватывает каждый производственный путь. |
| Индекс источников | Журналы аудита поставщика, журналы запросов шлюза, журналы приложения, отчеты об использовании/затратах, тикеты изменений и запись проверки доступа. | Показывает, какая система подтверждает каждую часть цепочки. |
| Словарь полей | Значение идентификатора запроса, актора, владельца ключа, проекта, поставщика, модели, статуса, токенов, стоимости, маршрута и режима полезной нагрузки. | Позволяет рецензентам интерпретировать экспорт без догадок. |
| Заявление о редактировании | Что было замаскировано, хэшировано, удалено или намеренно не собиралось. | Показывает дисциплину минимизации данных. |
| Заявление о хранении | Класс хранения, график удаления, расположение архива и процесс исключений. | Отвечает на вопросы об ограничении хранения и доступности доказательств. |
| Заявление о доступе | Роли, которые могут просматривать журналы метаданных, роли, которые могут просматривать журналы полезной нагрузки, и как контролируется доступ к журналам. | Показывает принцип наименьших привилегий при проверке самих доказательств. |
| Пример трассировки | Один безопасный, не содержащий конфиденциальных данных запрос, показывающий событие приложения, запрос шлюза, маршрут к поставщику, сводку по использованию/затратам и итоговый статус. | Доказывает, что путь доказательств работает от начала до конца. |
Примечания по внедрению Flatkey
Для команд Flatkey держите примечания по внедрению привязанными к текущему подтверждению продукта, а не к предположениям. Публичный сайт поддерживает позиционирование вокруг одного шлюза для доступа к моделям, маршрутизации, биллинга, аналитики использования, операционных контролей, контекста панели управления, контекста ценообразования и базового URL маршрутизатора. Этого достаточно, чтобы выстроить практический рабочий процесс подтверждения, но недостаточно, чтобы заявлять о конкретном нативном формате экспорта журналов аудита AI API.
- Используйте шлюз как границу ответственности. Свяжите ключи маршрутизатора и проекты с владельцами приложений, командами, средами и центрами затрат до того, как вырастет производственный трафик.
- Свяжите журналы с контролем расходов. Сопоставляйте наблюдаемость на уровне запросов с управлением квотами, атрибуцией затрат и актуальным каталогом цен.
- Разделяйте доказательства метаданных и полезной нагрузки. Проверяющий часто может подтвердить контроль доступа, маршрутизации, затрат и реконструкции инцидентов, не видя исходные промпты или ответы.
- Проверяйте панель управления в день ревью. Убедитесь в правильности меток, поведения экспорта, прав ролей, статуса маршрутов, доступности моделей и контролей хранения, прежде чем включать их в анкету покупателя.
- Держите CTA простым. Если вам нужна одна точка контроля шлюза для ведения логов AI API, маршрутизации, биллинга и анализа использования, Получить ключ.
Часто задаваемые вопросы: журналы аудита AI API
Что такое журналы аудита AI API?
Журналы аудита AI API — это записи, которые помогают командам доказать, кто изменил доступ к AI API или его конфигурацию, какие приложения и ключи генерировали трафик моделей, какой путь провайдера/модели обслуживал запросы, какой объем использования и затраты возникли, а также как обрабатывались чувствительные данные полезной нагрузки.
LLM-журналы аудита — это то же самое, что и журналы наблюдаемости?
Нет. LLM-журналы аудита обычно фокусируются на ответственности, доступе, изменениях конфигурации и доказательствах для проверяющих. Журналы наблюдаемости фокусируются на отладке запросов, задержке, использовании токенов, ошибках и поведении маршрутизации. Зрелые команды связывают оба представления через идентификаторы запросов и метаданные владельца.
Должно ли ведение логов AI API хранить промпты и ответы?
Не по умолчанию. Сначала храните метаданные: идентификаторы запросов, поля владельца, модель, провайдер, статус, количество токенов, стоимость, задержку, маршрут и режим логирования полезной нагрузки. Сохраняйте сырые промпты или ответы только тогда, когда есть четкая утвержденная цель, ограниченный доступ, редактирование и определенный срок хранения.
Какие поля должен включать журнал аудита ai gateway?
Журнал аудита ai gateway должен включать время запроса, идентификатор запроса, приложение или проект, владельца ключа, среду, провайдера, модель, конечную точку, решение по маршруту/резервному варианту, статус, задержку, количество токенов, стоимость, решение по квоте, режим логирования полезной нагрузки, класс хранения и элементы управления экспортом/доступом.
Как Flatkey помогает с журналами аудита AI API?
Flatkey предоставляет центральный контекст AI API gateway для доступа к моделям, маршрутизации, биллинга, аналитики использования, операционных контролей и просмотра на панели мониторинга. Используйте эту центральную точку, чтобы стандартизировать метаданные владельца и рабочие процессы с доказательствами, а затем проверьте текущее поведение консоли, прежде чем заявлять о конкретных возможностях экспорта журналов аудита, хранения или контроля доступа.
Когда покупатель спрашивает о журналах аудита AI API, лучший ответ — это не куча сырых записей. Это четкий пакет доказательств: что было залогировано, что намеренно не логировалось, кто это видит, как долго это хранится и как один запрос можно реконструировать от приложения к gateway, к провайдеру и к сводке по затратам. Если вы централизуете доступ к AI API и вам нужен этот путь доказательств, Получить ключ.
