AI 模型提供商证据审核是介于“这个模型看起来有用”与“这个路由已获准投入生产”之间的证明步骤。它为平台、采购、安全和财务审核者提供同一份带日期的记录：正在新增哪个模型路由、它能做什么、成本多少、适用哪些数据条款、如何检查支持与状态，以及如果路由行为异常团队如何回滚。
跳过这项审核会造成一种安静的故障模式。开发者可能保存了一个模型别名，采购可能批准了一个供应商，财务可能依据不同的计费单位做预算，而安全团队可能阅读的是另一份保留策略页面。等到路由后来失败时，没有人能判断在批准当天哪一个来源才是权威。
Flatkey 在这个工作流中很有用，因为当前公开网站将 flatkey.ai 定位为围绕一个 API key、带实时定价的模型目录、可见的使用情况、成本控制，以及跨供应商的统一计费。可以把它视为集中管理 AI 访问审核的地方。不要把公开营销页面当作法律证明、路由冒烟测试，或特定账户的 DPA。AI 模型提供商证据审核仍然需要最新的供应商文档、买方账户证据、审批负责人，以及回滚证明。
AI 模型提供商证据审核：审批包
审批包应当足够小，能在路由上线前完成；同时又要足够具体，能在之后的事故复盘中回答问题。
| 证据领域 | 批准前保存内容 | 重要性 |
|---|---|---|
| 路由申请 | 工作负载、负责人、环境、端点族、模型别名、预期数据类别 | 防止含糊的“我们加了 Claude/GPT/Gemini”式批准 |
| 模型文档 | 官方模型页面、API 模型 ID、模态、上下文、工具/流式支持、弃用说明 | 确认路由与工作负载及客户端集成相匹配 |
| 定价 | 供应商定价页面、网关定价页面、计量单位、缓存/批处理折扣、货币、检查日期 | 避免财务把 token、图像、视频和请求单位混为一谈 |
| 速率限制 | 官方配额/速率限制页面，以及在可用时的账户层级证据 | 设定并发、重试和回退预期 |
| 数据条款 | API 数据控制、保留页面、DPA 或安全审核、子处理方范围、加入/退出设置 | 定义哪些内容可以通过该路由，哪些必须留在外部 |
| 状态与支持 | 状态页面、支持方案、升级渠道、SLA 或无 SLA 说明 | 使事故归属明确 |
| 路由测试 | 最小请求、错误处理、用量/成本行、日志行为、回滚命令 | 证明该路由在目标环境中可用 |
| 审批记录 | 审核人姓名、决定、例外情况、到期/复审日期 | 建立可续期的控制，而不是永久性假设 |
关键的纪律是保存源证据，而不仅仅是结论。一条写着“定价已批准”的 Slack 备注，远不如同一份审批包中的一张带日期的定价截图、定价 URL、路由 ID 和审核人决定来得有力。
可将此审批包用作窄路由的 AI 模型批准证据、用于采购的 AI 供应商证据审核，以及用于安全和平台负责人的模型提供商风险审核。
先冻结路由申请
应先冻结正在申请什么，再开始 AI 模型提供商证据审核。否则，审核者在收集证据时，证据包本身会不断漂移。
在任何批准会议之前，记录这些字段：
| 字段 | 需要捕获的内容 |
|---|---|
route_name |
人类可读的路由名称，例如 support-triage-sonnet-prod |
owner |
产品负责人、平台负责人和安全审核人 |
environment |
开发、预发布、生产、客户专用或仅内部 |
gateway_path |
端点族，例如 chat completions、responses、messages、image、video 或 embeddings |
provider_model_id |
来自官方文档的精确上游模型 ID 或版本 |
gateway_model_alias |
通过网关或 Flatkey 账户暴露的精确别名 |
data_class |
公开、内部、机密、个人数据、受监管数据或客户内容 |
expected_features |
流式、工具调用、视觉、结构化输出、长上下文、批处理、缓存或文件输入 |
budget_guardrail |
预期月用量、硬上限、负责人和告警阈值 |
rollback_plan |
上一个模型、回退路由、功能开关、负责人和回退命令 |
许多审批就败在这里。团队要求批准“一个更好的模型”，但证据实际上只适用于一个端点、一个模型别名、一个数据类别和一个环境。除非现有批准明确覆盖，否则应将每个新的供应商、模型系列、端点族或敏感数据范围都视为单独审核。
保存官方模型文档
模型文档是首先要保存的来源，因为它定义了这条路由应当是什么。应使用官方模型页面，而不是博客摘要或第三方表格。OpenAI 当前的 models documentation、Anthropic 的 models overview，以及 Google 的 Gemini API models documentation，都是应收入资料包的来源示例。
对于每条已批准的路由，保存：
| 模型证据 | 审核问题 |
|---|---|
| 官方 URL 和抓取日期 | 批准当日哪个来源是最新的？ |
| 精确的 API 模型 ID 和别名 | 客户端必须发送什么字符串？ |
| 模态和端点家族 | 这条路由支持文本、图像、音频、视频、嵌入，还是工具调用？ |
| 上下文限制和输出限制 | 工作负载是否能容纳而不会静默截断或失控增加成本？ |
| 支持的参数 | 是否支持 temperature、工具、结构化输出、流式传输或文件？ |
| 版本、预览、beta 或弃用状态 | 这条路由对该工作负载来说是否足够稳定？ |
| 区域或账户限制 | 买家账户是否有资格调用它？ |
不要凭记忆批准路由。模型名称、别名、预览状态和功能支持都会变化。证据包应包含所用的确切文档、检查日期，以及一条备注，说明团队在重大流量迁移前必须重新检查文档。
将定价和配额证据一并保存
如果定价证据只写“便宜”或“与提供商相同”，那就很薄弱。应将定价单位与配额/速率限制证据一起保存，因为路由行为和成本都取决于两者。
OpenAI 的 developer pricing page、Anthropic 的 pricing page，以及 Google 的 Gemini API pricing page，是检查提供商侧单位的官方来源。OpenAI、Anthropic 和 Google 也发布速率限制或配额文档，例如 OpenAI 的 rate limit guidance、Anthropic 的 rate limits，以及 Gemini API 的 rate limits。
在批准资料包中，将这些字段分开：
| 定价或配额字段 | 要保存的证据 |
|---|---|
| 输入单位 | Token、字符、秒、图像、请求，或其他单位 |
| 输出单位 | 输出 tokens、生成媒体秒数、图像数量、工具调用或响应单位 |
| 缓存/批处理条款 | 是否适用折扣或单独单位 |
| 免费层或预览条款 | 该路由是否依赖临时可用性 |
| 网关加价或计费单位 | 当前 Flatkey 或特定账户的定价页面/结账证据 |
| 货币和税费 | 可用时的货币、发票主体和税务处理 |
| 速率限制 | RPM、TPM、RPD、并发请求或账户层级配额 |
| 预算上限 | 内部负责人、上限、告警和停用行为 |
Flatkey 当前公开的定价/模型页面，对于审核时买家在 Flatkey 上可见的内容很有用。但它们本身不足以支撑生产批准。应保存当前的 Flatkey 定价或模型页面，再将其与官方提供商定价页面以及买家账户自身的计费/合同证据配对。
这正是 AI 模型提供商证据审核同时保护工程和财务的地方：模型路由、定价单位和配额预期都基于同一份带日期的资料包获批。
保存数据、法律和安全证据
数据审查应明确说明这条路由跨越的边界。提供商可能默认不会使用 API 数据进行训练，但这并不能自动回答保留、滥用监控、子处理方、支持访问、日志记录、删除、区域处理或合同 DPA 范围等问题。
OpenAI 的 API data controls、Anthropic 的 API and data retention documentation、Google 的 Gemini API terms，以及 NIST AI Risk Management Framework，都是审查者可用于构建证据审核的来源类别示例。重点不是把冗长的政策文本粘贴到工单里。重点是捕获确切来源、买家账户条款和批准决定。
保存这些法律和安全字段：
| 证据 | 审批决定 |
|---|---|
| 法律实体和签约路径 | 买方是与哪个实体签约？ |
| DPA 或数据处理条款 | 是否有已签署的 DPA，还是只有公开条款？ |
| 数据使用和训练设置 | API 数据默认用于训练、选择加入、选择退出，还是仅限账号特定使用？ |
| 保留和滥用监控 | 哪些内容可能被保留、保留多久，以及在什么例外情况下保留？ |
| 子处理方和区域 | 哪些子处理方或区域在范围内？ |
| 支持访问 | 提供商支持是否可以访问提示、输出、日志或附件？ |
| 日志和导出 | 您的网关或工具将存储哪些原始载荷、元数据和使用行？ |
| 受限数据 | 该路由上禁止哪些数据类别？ |
| 例外流程 | 谁可以批准原始载荷访问、事件保留或法律保全？ |
请清楚地写出决定。例如："批准用于内部排障提示，不包含受监管的个人数据；在附上 DPA 和保留证据之前，不批准用于生产环境客户文档。" 这才是有用的 AI 模型提供商证据审核结果。"提供商已审核"则不是。
保存状态、支持和事件证据
路由批准也是一项运营决策。如果某个模型路由变得不可用、受到速率限制、性能下降或成本意外升高，团队需要知道去哪里查看以及由谁负责。
对于每条提供商路由，保存：
| 运营证据 | 应包含内容 |
|---|---|
| 公开状态页 | OpenAI 状态、Anthropic 状态、Google Cloud 状态，或提供商的对应页面 |
| 支持路径 | 账号门户、支持邮箱、优先支持方案、工单严重级别以及升级负责人 |
| SLA 或无 SLA 说明 | 合同约定的可用性/补救证据，或清楚的“未发现承诺的 SLA”说明 |
| 事件角色 | 谁决定故障切换、暂停流量或通知客户？ |
| 客户影响阈值 | 触发回滚的错误率、延迟、成本或质量阈值 |
| 沟通模板 | 内部事件频道和面向客户的负责人 |
不要假设网关负责人也就是供应商升级负责人。平台团队可能负责路由，采购团队可能负责合同，安全团队可能负责例外审批，而产品团队可能负责客户影响。证据包应显示这些角色在事件期间如何协同。
运行技术路由验证
AI 模型提供商证据审核应以一次小型路由验证结束。这不是完整的负载测试，而是证明所选路由在预期环境中可用，并且失败可以被观察到的最低限度证据。
使用非敏感提示并保存：
| 验证工件 | 理想状态 |
|---|---|
| 请求 | 端点、模型别名、环境、请求 ID 和已脱敏载荷 |
| 响应 | 状态码、返回的模型、延迟、使用字段以及预期的内容形状 |
| 错误测试 | 一次无效模型或错误密钥测试，以及预期的错误处理 |
| 使用行 | 显示该请求出现在预期负责人名下的计费或使用证据 |
| 日志行 | 不包含原始敏感载荷的元数据证据，除非已明确批准 |
| 限流行为 | 与提供商/网关速率限制证据相绑定的退避或重试策略 |
| 回退测试 | 可恢复到之前的模型或替代路由 |
| 回滚负责人 | 可以关闭该路由的指定人员或值班角色 |
如果审核期间没有真实 API 密钥或账号路由可用，则将该路由标记为未获生产批准。仅基于文档的审核可以批准进一步测试，但不应批准客户流量。
在上线前构建回滚包
回滚证据应在新模型路由上线之前创建。否则团队可能会在事件中才发现旧的模型别名已被移除、旧密钥已过期，或者客户端无法快速切换端点族。
| 回滚字段 | 审批前保存此项 |
|---|---|
| 上一条路由 | 模型别名、端点族、提供商以及最近一次已知可用测试 |
| 切换机制 | 功能开关、配置键、网关规则、部署变量或手动运行手册 |
| 数据兼容性 | 提示格式、工具 schema、JSON 模式或文件输入是否不同 |
| 成本影响 | 回退时预计的成本差异 |
| 质量风险 | 已知的质量下降、缺失功能或需要人工复核的要求 |
| 负责人 | 获授权触发回滚的人员或值班角色 |
| 验证 | 团队如何确认流量已回到获批路由 |
回滚不是一个悲观的附加项。它是审批的一部分。即使模型在演示中表现良好，无法安全回滚的新路由也属于更高风险路由。
Flatkey 买家应如何使用审核
Flatkey 买家可以将证据审核作为工程与采购之间共享的检查清单。先从路由请求开始，然后保存所选模型的当前 Flatkey 证据、定价、密钥所有权、使用可见性和账单审核。再结合来自提供商的直接文档，涵盖模型行为、数据条款、定价单位、配额、状态和支持。
对于周边治理背景，请将此资料包连接到现有的 Flatkey 集群：
- 使用 AI 模型审批工作流 来定义谁可以请求、审核、批准、到期和重新批准某个模型。
- 当路由变更与供应商或网关采购相关时，使用 AI 网关采购证据资料包。
- 当提供商或处理方发生变化时，使用 AI API 供应商风险评估。
- 在批准前查看当前的 Flatkey 定价和模型目录，然后仅在路由证据和账户特定控制都清晰后再获取密钥。
实用的 Flatkey 模式很简单：集中访问，但不要集中假设。每一条新路由仍然需要自己带日期的证据。
证据审核模板
在批准新的模型路由之前，将此模板复制到你的工单或 GRC 系统中。
| Section | Required fields |
|---|---|
| Route summary | Route name, owner, environment, endpoint family, model alias, data class |
| Model proof | Official model docs URL, date checked, exact model ID, supported features, limitations |
| Pricing proof | Provider pricing URL, Flatkey/account pricing proof, unit, currency, budget cap |
| Quota proof | Provider rate-limit URL, account-tier evidence, retry/backoff policy |
| Data proof | API data controls, DPA/terms, retention, support access, restricted data classes |
| Operational proof | Status page, support path, SLA note, incident owner |
| Technical proof | Request/response sample, usage row, log row, error test, fallback test |
| Decision | Approved/not approved, exceptions, reviewer names, expiry date |
| Recheck trigger | Model version change, price change, provider incident, new data class, new customer scope |
保持资料包简短，但保留证据材料。截图、保存的 HTML、导出的 PDF、API 响应和带日期的备注都很重要，因为提供商页面和账户设置会变化。
常见问题
什么是 AI 模型提供商证据审核？
AI 模型提供商证据审核是团队在批准新的 AI 模型或提供商路由之前保存的带日期证据资料包。它涵盖模型文档、定价、配额、数据条款、支持、状态、路由测试、回滚以及审核决定。
在批准新路由之前我们应保存哪些证据？
保存准确的模型 ID、端点系列、提供商文档、定价单位、速率限制证据、数据保留和 DPA 证据、状态/支持路径、已脱敏的路由测试、使用/日志证据、回滚计划、审核人以及审核到期日期。
仅凭提供商定价页面就足以批准吗？
不够。提供商定价页面只是其中一个输入。批准还应包括网关/账户定价、预期使用量、预算上限、配额、货币、开票主体，以及负责在上线后审查使用情况的负责人。
采购能否在没有实时路由测试的情况下批准一条路由？
采购可以批准合同或评估工作，但生产路由批准应要求在目标账户和环境中进行一次实时冒烟测试。如果没有这项证据，资料包应注明仅进行文档审核。
Flatkey 在审核中处于什么位置？
Flatkey 可以作为模型路由、定价可见性、使用审核和基于密钥的分阶段上线的共享访问与审核界面。但在生产批准前，买家仍然需要官方提供商文档、账户特定的法律证据、技术路由证据以及回滚计划。
最终结论
最强的 AI 模型提供商证据审核不是一份冗长的政策，而是一份紧凑、带日期的资料包，使未来的审核者能够重建团队为何批准某条路由、当时哪些源事实是最新的、允许哪些数据、成本如何受限，以及团队如何回滚。在路由上线前保存这些证据，然后在模型、提供商、数据类别、价格或客户范围发生变化时重新检查。
