Enterprise Controls and Trust2026年6月22日Big Y

AI API 审计日志：安全审查员会要求了解什么

使用这份 AI API 审计日志清单，向审查员展示谁使用了每条模型路由、记录了什么、哪些内容被脱敏，以及证据如何留存。

AI API 审计日志是安全审查背后的证据层。审查者不仅在问应用是否调用了模型。他们还想知道是谁发起了请求、使用了哪个密钥或项目、由哪个模型和提供商处理、是否存储了敏感载荷、记录保留多长时间，以及团队是否能够在不暴露提示、补全、密钥或个人数据的情况下重建一次事件。

这使得AI API 审计日志不同于普通 API 日志。一次 LLM 请求可能在一个调用中跨越应用所有者、网关密钥、上游提供商、模型路由、令牌计量、回退路径、成本中心和数据处理策略。审计轨迹必须把这些层连接起来，同时又不能把日志存储变成第二个敏感数据仓库。

Flatkey 之所以相关，是因为 flatkey.ai 对外将该产品定位为面向生产 AI 团队的单一 API 网关，提供模型访问、路由、计费、使用分析、运营控制、仪表盘，以及路由器基础 URL https://router.flatkey.ai/v1。集中式网关可以成为 AI API 日志记录和审查证据的控制点，但本文不假定 Flatkey 有特定的审计日志导出架构、保留期限或合规范围。在向买方提供证据之前，请先在你当前的控制台中核实这些细节。

安全审查人员会问什么：快速答案

一套好的AI API 审计日志应当回答七个反复出现的问题。如果你能用记录而不是截图和 Slack 消息来回答它们，供应商审查就会容易得多。

审查人员问题	需要展示的证据	常见失败点
谁使用了 AI API？	调用者、服务账户、密钥拥有者、应用拥有者、项目、团队、环境和请求标识符。	只看到一个共享的供应商密钥，因此只能靠猜测来确定归属。
使用了什么模型路径？	网关路由、供应商、模型、端点系列、回退决策、状态、延迟和错误类别。	应用日志知道用户操作，而供应商日志知道模型调用，但两者之间没有任何关联。
存储了哪些数据？	载荷日志模式、脱敏策略、提示/完成内容存储设置，以及敏感数据处理说明。	原始提示和响应默认被存储，没有业务理由或屏蔽方案。
你能重建一次事故吗？	请求 ID、时间戳、应用跟踪 ID、网关请求 ID、供应商请求 ID（如有）以及可导出的事件历史。	日志可以在一个仪表板里搜索，但无法导出，也不能与应用事件关联。
你如何防止失控支出？	按密钥、项目、模型、拥有者和时间桶统计的使用量与成本报告，以及配额或预算审查证据。	审计日志显示了变更，但证据集中缺少使用量和成本报告。
日志会保留多久？	保留期限、删除行为、归档/导出流程，以及谁可以批准访问日志摘录。	团队把日志永久保留，因为没人决定保留期限。
谁可以查看这些日志？	角色或组列表、访问审批、日志访问监控，以及元数据日志与载荷日志之间的隔离。	所有拥有仪表板访问权限的人都可以检查敏感请求正文。

AI API 审计日志并不等同于使用报告

安全审查人员常说“日志”，但他们往往指的是三种不同的证据类型：审计事件、请求可观测性，以及使用或成本报告。将它们视为分层的独立内容，可以避免给出混乱的答案。

证据类型	主要问题	典型字段	单独无法证明什么
提供商审计日志	谁更改了组织、项目、密钥、角色或配置设置？	执行者、执行者邮箱或 ID、事件类型、目标资源、时间戳、IP/会话详情，以及配置更改详情。	是哪一个应用请求消耗了 token，或者是哪一个客户工作流触发了模型流量。
网关请求日志	每个 AI API 请求发生了什么？	请求 ID、网关密钥、应用所有者、提供商、模型、端点、状态、延迟、路由/回退、token 数量、成本和元数据。	请求之前，提供商侧的角色或密钥设置是否发生了变更。
使用和成本报告	按所有者、密钥、项目、模型和时间桶统计了多少流量、token 量和支出？	输入 token、输出 token、缓存 token、请求次数、项目、用户、API 密钥、模型、明细项、金额和货币。	谁批准了访问、谁更改了密钥，或者在事故期间哪一个具体请求失败了。

OpenAI 的 Admin API 是这种划分方式的一个有用公开示例。其 Audit Logs 端点被描述为列出最近的用户操作和组织配置更改，而其 usage 和 costs 端点则公开使用/成本字段，以及按项目、用户、API 密钥、模型、服务等级、明细项和时间桶等进行分组的选项。这种分离方式是任何 AI API 审计日志 项目的良好心智模型：审计事件、请求日志和使用/成本报告应该彼此关联，但它们并不能互相替代。

AI API 审计日志字段清单

将此清单用作 AI 网关审查的证据矩阵。并非每个字段都适合进入每个日志存储。关键在于决定哪些内容应放入元数据日志，哪些应放入受限的负载日志，哪些应放入提供商管理日志，以及哪些内容根本不应保留。

字段组	推荐字段	审查价值	处理说明
时间与关联	事件时间、网关请求 ID、应用跟踪 ID、提供商请求 ID（如可用）以及导出批次 ID。	帮助团队重建顺序，并关联应用、网关和提供商记录。	为相关事件使用稳定的交互标识符。
身份与所有权	网关密钥所有者、服务账号、项目、应用、团队、成本中心、环境，以及在需要时的客户租户 ID。	显示责任归属，并支持关于共享密钥的供应商风险问题。	在可能的情况下，优先使用内部 ID 或哈希标识符，而不是原始个人数据。
请求路径	端点族、提供商、模型、路由组、回退决策、缓存状态、重试次数和状态码。	说明由哪条模型路径处理了请求，以及为何发生回退。	不要存储请求头中的密钥。
运行指标	持续时间、首次 token 时间（如可用）、错误类别、限流事件、配额决策和策略决策。	支持事件分诊和可靠性审查。	保留有用的错误详情，但要清理不受信任的输入。
使用与成本	输入 token、输出 token、缓存 token、请求次数、估算成本、应计账单条目以及货币。	支持预算审查、成本分摊和异常支出调查。	用于汇总时，使用团队成本归因和按密钥使用跟踪。
负载策略	负载日志模式、脱敏结果、DLP 决策、提示词哈希、响应哈希，以及附件/文件指示符。	显示敏感内容是被存储、抑制还是转换。	仅记录元数据通常已足以满足安全审查和事件分诊需求。
保留与访问	保留类别、删除日期、归档位置、导出权限、查看者角色和日志访问事件。	回应数据最小化、存储限制和审查者访问控制方面的问题。	记录对敏感日志的访问，并限制负载视图。

OWASP 的日志记录指南在这里是一个很好的基准：应用日志应记录何时、何地、谁以及什么；来自其他信任域的事件数据应视为不可信；在进入日志之前，应先移除、屏蔽、清理、哈希化或加密敏感数据。对于 AI API 审计日志，最后这一点尤为重要，因为提示词和补全内容可能包含密钥、受监管数据、客户内容以及内部策略。

下表并不是法律控制项映射，而是一种将安全审查语言转化为平台团队实际能够提供的证据的实用方式。

审查领域	审查者通常会问什么	来自 AI API 审计日志的证据	证据负责人
访问控制	谁可以创建、查看、更新或撤销 AI API 密钥和网关设置？	提供商管理员审计事件、网关密钥清单、角色/组列表以及访问审查记录。	安全或平台
变更控制	你如何证明某个模型路由、配额、密钥或策略是在经过批准的流程中变更的？	变更工单、批准人、审计事件、变更前/后设置、部署记录以及回滚说明。	平台工程
事件响应	你能否重建指定时间段内的可疑使用或提供商错误？	请求 ID、时间戳、主体/项目/密钥元数据、路由决策、状态码、令牌计数以及导出的事件包。	安全运营
数据最小化	你是否存储原始提示和响应？如果是，为什么、谁可以查看？	载荷日志模式、脱敏策略、受限的载荷查看者列表，以及在使用的场景下可证明存在仅元数据模式。	安全、隐私和应用负责人
保留期限	日志保留多久，过期日志如何删除？	保留策略、存储上限、删除规则、归档规则以及日志访问监控记录。	安全和数据治理
成本治理	你能检测到异常模型支出，或将其归属到某个团队吗？	按密钥、项目、模型、团队、时间桶和配额事件分组的用量/成本导出。	FinOps 或平台
供应商风险	你能向审查者展示一套具体、可重复的证据工作流吗？	包含源系统、导出日期、时间范围、负责人、脱敏说明和证据索引的审查包。	安全和采购

对于 GDPR 风格的审查，官方法规第 5 条原则包括数据最小化和存储限制。应用到AI API 审计日志时，这意味着你应说明每个已存字段为何是必要的，默认避免保留原始载荷，并设置与日志用途相匹配的保留期限。

LLM 审计日志中不要放什么

在日志审查中最快失败的方式，就是创建比生产应用本身所需更多的敏感数据。LLM 审计日志应当在不成为客户对话的失控副本的前提下，帮助回答安全问题。

数据	风险	更安全的模式
原始提示词和补全内容	可能包含个人数据、机密、客户内容、特权内容或受监管数据。	默认仅记录元数据；仅在经批准的用例中存储载荷，并限制访问和保留期。
API 密钥、Bearer 令牌和提供商凭据	会在证据系统内造成凭据暴露。	切勿记录密钥。改为存储密钥 ID、密钥所有者或哈希指纹。
未脱敏的用户标识符	扩大隐私范围，并使导出更难共享。	除非需要并已获批准，否则使用内部用户 ID、租户 ID 或加盐哈希。
完整的请求和响应头	请求头可能携带 cookie、身份验证令牌、trace baggage 和内部基础设施名称。	仅保留允许列表中的请求头，例如请求 ID、用户代理类别或安全的网关元数据。
失败模型调用的调试跟踪	调试数据可能包含原始载荷、堆栈跟踪和内部实现细节。	在持久化之前先进行脱敏，并将扩展调试记录与标准审计日志分开存储。

Cloudflare 的公开 AI Gateway 文档展示了一个有用的区分：按请求的控制可以跳过原始请求和响应载荷的存储，同时保留诸如 token 数、模型、提供商、状态码、成本和时长之类的元数据。Vercel 的公开 AI Gateway 可观测性文档描述了按项目和 API 密钥汇总的请求摘要，以及包含 token 和成本字段的详细请求日志。这些都是通用模式的公开示例：让元数据保持广泛可用，并严格限制载荷可见性。

如何设计 AI 网关审计轨迹

当 ai gateway audit trail 在审查人员提出要求之前就已设计好时，效果最佳。使用这个工作流程，将分散的日志转化为审查证据。

选择控制点。 确定哪些请求必须经过 AI 网关，哪些提供商管理事件保留在提供商审计日志中，以及哪些应用事件保留在应用日志中。
定义安全的所有者元数据。 标准化项目、应用、团队、环境、成本中心、客户租户和关键所有者字段。避免会泄露个人数据的自由格式值。
决定负载日志模式。 将仅元数据日志与原始提示/响应日志分开。对负载存储要求明确批准。
映射请求 ID。 将请求或跟踪 ID 从应用传递到网关，并在可用时保留网关/提供商标识符。
将变更事件与请求事件分开。 密钥创建、路由变更、角色变更和配额变更应归入审计事件。模型调用应归入请求日志。
关联使用量和成本。 按密钥、项目、模型、团队和时间桶添加汇总，以便能从同一证据包中回答预算问题。
设置保留和导出规则。 决定谁可以导出日志、如何对提取内容进行脱敏、证据存放在哪里以及何时删除。
测试审查者证据包。 选择一段无害的时间范围，导出证据，并确认另一位工程师仅凭该证据包就能重建请求路径。
按季度审查访问权限。 记录对日志的访问，限制负载查看权限，并移除过期的仪表板/导出权限。

如果你已经通过 Flatkey 路由流量，请从中央路由器开始这个工作流程：验证当前的基础 URL、密钥、所有者、使用分析、计费上下文、路由控制、配额控制和仪表板标签。然后将这些记录与应用跟踪 ID 以及提供商侧审计事件连接起来。对于相邻的设置工作，请使用企业 AI API 网关检查清单、AI API 可观测性日志指南和网关密钥轮换运行手册。

审阅者资料包模板

当买家要求AI API 审计日志时，不要发送一份没有解释的原始导出。请发送一份能展示范围、数据处理和可追溯性的证据资料包。

资料包部分	内容	重要性
范围说明	系统、环境、日期范围、包含的应用、包含的网关密钥，以及排除的数据源。	防止审阅者误以为样本涵盖了每一条生产路径。
来源索引	提供商审计日志、网关请求日志、应用日志、使用/成本报告、变更工单以及访问审查记录。	展示追踪链条中的每一部分由哪个系统来证明。
字段字典	请求 ID、执行者、密钥所有者、项目、提供商、模型、状态、令牌、成本、路由和负载模式的含义。	让审阅者无需猜测即可解读导出内容。
脱敏说明	哪些内容被遮盖、哈希、移除，或有意未收集。	展示数据最小化的规范性。
保留说明	保留类别、删除计划、归档位置以及例外流程。	回答存储限制和证据可用性方面的问题。
访问说明	哪些角色可以查看元数据日志、哪些角色可以查看负载日志，以及如何监控日志访问。	展示围绕证据本身的最小权限审查。
样本追踪	一条安全、非敏感的请求，展示应用事件、网关请求、提供商路由、使用/成本汇总以及最终状态。	证明证据链路端到端可用。

Flatkey 实施说明

对于 Flatkey 团队，请将实施说明与当前产品证据保持一致，而不是基于假设。公开网站支持围绕模型访问、路由、计费、使用分析、运营控制、仪表板上下文、定价上下文以及路由器基础 URL 的单一网关定位叙事。这足以构建一个实用的证据工作流，但不足以声称某种特定的原生 AI API 审计日志 导出格式。