AI 模型审批工作流是一个发布门禁，用于决定是否允许某个模型路由处理生产流量。路由不仅仅是模型名称，它还包括将在产品功能背后运行的提供商、端点族、提示词版本、工具权限、回退行为、日志记录设置、成本护栏、所有者和回滚路径。
这就是为什么审批应该在新路由上线之前进行。一个模型在演示中可能看起来很安全，但在生产中仍然可能失败，原因可能是发布了错误的提示词版本、回退将流量发送到未经审查的提供商、工具调用获得了过多权限、日志记录设置存储负载的时间超过预期，或者财务部门在推出后无法核对支出。
使用此 AI 模型审批工作流，将模型变更转化为一份由购买方拥有的证据文件。输出应足够清晰，以便工程、安全、采购、财务和产品部门日后能回答同样的问题：批准了什么，为什么批准，审查了什么证据，以及什么会触发新的审查？
对于 Flatkey 购买方来说，此审查应围绕网关路由进行。Flatkey 当前的公共网站将产品定位为一个 AI API 网关，用于模型访问、路由、计费、使用分析和运营控制，提供一个 API 密钥、一个基础 URL 和一个仪表板。这使得网关成为集中路由证据的有用场所。但这并不能免除在生产发布前验证特定于账户的日志记录、提供商条款、模型行为、数据处理和审批责任的需要。
工作流批准的内容
AI 模型审批工作流应批准的是一个路由，而不是供应商的口号。审批记录应明确指出发布后将存在的确切生产行为。
| 路由层面 | 审批问题 | 要保留的证据 | 发布阻碍因素 |
|---|---|---|---|
| 用例 | 此路由将执行什么用户或系统任务？ | 产品简报、数据分类、用户影响、滥用案例 | 任务模糊或所有权不明确 |
| 模型和提供商 | 哪个模型、提供商、端点、区域和账户路径将为流量提供服务？ | 提供商文档、模型/版本状态、路由配置、回退列表 | 回退可以选择未经批准的模型 |
| 提示词和工具策略 | 允许哪些指令、工具、模式和权限？ | 提示词版本、工具清单、类型化模式、代码审查 | 工具可以在没有控制措施的情况下采取不可逆转的操作 |
| 评估包 | 哪些测试证明该路由对于此用例足够好？ | 评估数据集、指标、阈值、审查员笔记、失败示例 | 没有针对特定任务的通过/失败阈值 |
| 安全和滥用控制 | 如何处理提示词注入、不安全输出、数据泄露和策略绕过？ | 红队案例、过滤器设置、拒绝测试、监控警报 | 已知故障没有缓解措施或所有者 |
| 数据和日志记录 | 存储哪些提示词、输出、元数据、跟踪和计费行？ | 数据流图、日志样本、保留类别、编辑测试 | 原始负载存储不明确或无限制 |
| 成本和容量 | 允许哪些支出、配额、速率限制、超时和回退行为？ | 预算限制、使用样本、压力测试、财务所有者 | 故障模式可能导致不受控制的支出 |
| 推出和回滚 | 流量将如何开始、扩展、暂停和恢复？ | 功能标志、金丝雀计划、回滚命令、事件联系人 | 回滚依赖于手动猜测 |
| 续订触发器 | 什么变化会强制重新审批？ | 审查日期、模型弃用观察、路由变更策略 | 发布后无人对漂移负责 |
关键点：审批不是一次会议。审批是一套证据包加上一个路由控制。
使用生命周期框架，而不是一次性清单
NIST 的 AI 风险管理框架 是一个实用的框架，因为它围绕治理 (Govern)、映射 (Map)、测量 (Measure) 和管理 (Manage) 来组织工作。这可以清晰地映射到 AI 模型审批工作流：
| AI RMF 功能 | 路由审批转换 |
|---|---|
| 治理 (Govern) | 分配路由所有者、风险所有者、财务所有者、安全审查员、审批策略和停用规则 |
| 映射 (Map) | 描述用例、用户、数据、上游提供商、模型限制、路由依赖关系和业务影响 |
| 测量 (Measure) | 运行功能评估、对抗性测试、安全检查、成本测试、延迟测试和可观察性检查 |
| 管理 (Manage) | 根据证据批准、推出、监控、暂停、续订或停用路由 |
NIST 的 生成式 AI 概况 也很重要，因为生成式系统引入了普通 API 变更审查通常会忽略的风险：提示词注入、幻觉、数据暴露、不安全的能力扩展、模型漂移和下游滥用。应将该框架视为一种构建决策的方式，而不是替代你自己的证据。
AI 模型审批工作流清单
对每个新模型路由、实质性提示词变更、工具权限变更、提供商回退或端点迁移，都应使用此清单。
- 定义路由。
记录路由 ID、所有者、产品功能、环境、端点族、主模型、允许的回退模型、提供商账户、提示词版本、工具清单、数据类别和预期流量模式。
- 对用例进行分类。
确定路由是否涉及客户数据、员工数据、受监管的工作流、财务决策、支持决策、法律审查、代码执行、外部操作或安全敏感内容。摘要路由和自主退款代理不应共享相同的审批深度。
- 收集模型和提供商证据。
保留提供商模型文档、模型卡或系统卡（如果可用）、弃用状态、内容过滤文档、数据处理条款、区域限制和帐户级设置。Google 的 模型版本指南 提醒我们要记录模型是稳定版、预览版、实验版、已弃用还是已停用。不要只批准一个友好的显示名称。
- 对提示和工具进行版本控制。
OpenAI 的 提示指南 建议使用代码管理的生产提示、类型化输入、代码审查、测试、评估检查和分阶段推出。这对于买方自有的 AI 模型审批工作流来说是正确的模式：提示行为应与代码行为属于同一发布流程。
- 构建特定于任务的评估。
OpenAI 的 评估最佳实践 将评估定义为针对可变 AI 系统的准确性、性能和可靠性的结构化测试。审批应要求提供特定于任务的评估包，而不仅仅是通用的基准测试截图。包括典型案例、边缘案例、对抗性案例、多语言案例、工具案例和已知失败示例。
- 运行安全和滥用测试。
OWASP 的 LLM01 提示注入指南 区分了直接和间接提示注入。为两者都添加测试。如果路由可以调用工具、检索文档、写入记录、发送消息或运行代码，请测试权限过大、工具参数操纵、系统提示冲突以及检索内容中的隐藏指令等问题。
- 验证数据保留和日志记录。
确定是否存储提示、输出、工具参数、文件、检索到的块、跟踪、请求元数据、审计事件和计费行。使用 AI API 数据保留清单 将有效负载内容与元数据分开，并使用 AI API 使用情况的审计日志 来证明谁更改了密钥、路由、日志记录、配额和模型策略。
- 设置成本、可靠性和回退限制。
记录令牌预算、请求预算、配额限制、超时策略、重试策略、回退模型列表、熔断器和警报阈值。即使在用户体验看起来不错的情况下，将流量悄悄转移到更强大、更昂贵或审查更少的模型的回退机制也是一种治理失败。
- 批准分阶段推出和续订。
通过金丝雀发布、功能标志、路由权重或租户允许列表进行发布。定义第一个小时检查、第一天检查、第一周检查和续订触发器。当模型版本更改、提供商条款更改、提示行为更改、工具权限更改、日志记录更改、成本概况更改或用户群体更改时，需要重新审批。
构建审批包
最强大的 AI 模型审批工作流会留下一个紧凑的审批包。它应该足够简短以便审查，但又足够具体以便审计。
| 数据包字段 | 必需的答案 | 证明工件 | 续订触发器 |
|---|---|---|---|
| 路由 ID | 此生产路由的稳定 ID | 网关路由配置或变更请求 | 路由重命名、合并或拆分 |
| 业务负责人 | 谁承担产品风险？ | 审批记录 | 负责人变更 |
| 技术负责人 | 谁可以暂停或回滚？ | On-call 文档、运行手册 | 团队或 on-call 变更 |
| 数据类别 | 哪些数据可以进入提示、工具、文件和检索？ | 数据流图、示例负载类别 | 新数据源或客户细分 |
| 模型列表 | 主模型、备用模型、端点系列、提供商账户 | 模型/版本文档、路由回读 | 新模型、备用模型、端点或提供商 |
| 提示版本 | 当前提示构建器、模式和系统指令源 | Git 提交或已审查的配置 | 提示、模式或工具变更 |
| 评估包 | 数据集、指标、阈值、失败案例、审查者签核 | 评估报告 | 模型、提示、数据或用户分布变更 |
| 安全控制 | 内容过滤器、拒绝策略、提示注入测试、人工上报 | 测试报告和过滤器设置 | 过滤器、策略或风险分类变更 |
| 工具控制 | 允许的工具、范围、参数、审批要求 | 工具清单和权限测试 | 工具权限或副作用变更 |
| 日志和保留 | 元数据字段、负载策略、保留类别、编辑行为 | 日志样本和保留回读 | 导出、可观察性或保留变更 |
| 成本控制 | 预算、配额、速率限制、警报、发票负责人 | 使用样本和成本阈值 | 定价、流量或模型组合变更 |
| 推出计划 | 金丝雀规模、回滚方法、停止条件 | 功能标志或路由权重记录 | 推出队列扩展 |
| 上线后监控 | 指标、警报、审查节奏、事件路径 | 仪表板截图或 API 回读 | 警报遗漏、事件或漂移 |
这个数据包也是一项采购资产。它使供应商审查具体化：购买者不再询问供应商是否“企业就绪”，而是询问哪些证据证明此路由已准备就绪。
路由上线前的预生产测试
测试集应与批准的用例相匹配。一个只标记支持工单的路由与一个编写 SQL、处理退款、编辑代码或总结医疗记录的路由需要不同的测试。
| 测试通道 | 测试内容 | 要保留的证据 | 停止条件 |
|---|---|---|---|
| 功能正确性 | 正常任务的预期输出 | 评估分数、失败示例、审查者笔记 | 通过率低于阈值 |
| 指令层次结构 | 系统提示与冲突的用户提示 | 对抗性案例 | 用户提示覆盖系统策略 |
| 提示注入 | 用户文本、检索到的文档、文件和工具输出中的直接和间接注入 | 红队演练记录 | 隐藏指令改变任务 |
| 工具权限 | 工具选择、参数提取、范围和副作用 | 工具调用日志和拒绝案例 | 工具可以执行未经批准的操作 |
| 数据泄露 | 秘密、私有数据、客户标识符和检索到的上下文暴露 | 固定数据测试 | 敏感的固定数据出现在输出或日志中 |
| 内容过滤 | 输入/输出策略类别和严重性阈值 | 过滤器配置和被阻止的案例 | 所需类别未被监控或阻止 |
| 成本和配额 | 令牌预算、速率限制、备用支出、滥用突发 | 使用行和警报测试 | 支出可以在没有负责人警报的情况下增长 |
| 可靠性 | 超时、重试、流式传输、备用、提供商中断、断路器 | 故障演练 | 用户流量持续重试直至失败 |
| 可审计性 | 密钥变更、路由变更、提示变更、日志访问、配额变更 | 审计事件样本 | 变更无法与执行者和时间关联 |
| 回滚 | 禁用路由、恢复提示、移除备用、恢复先前模型 | 回滚演练 | 回滚无法快速完成 |
微软的 Azure OpenAI 内容过滤文档很有用，它提醒我们过滤器有类别、严重性、配置选项和可选行为。您的审批记录应捕获用于该路由的实际设置，而不仅仅是堆栈中某个地方存在安全功能。
路由策略示例
审批应生成一个工程师可以实施、审查者可以检查的路由策略。确切的模式取决于您的网关，但其结构应明确。
route_id: support-summary-prod
owner:
product: support_ops
engineering: ai_platform
security: appsec
finance: finops
use_case:
task: summarize_support_threads
data_class: customer_support_confidential
allowed_environments: [production]
models:
primary: approved_summary_model_2026_07
fallbacks:
- approved_summary_backup_2026_07
denied:
- any_preview_model_without_reapproval
prompt:
source: app/prompts/support_summary.ts
reviewed_commit: 8f3c2d1
schema_required: true
tools:
allowed:
- read_ticket_metadata
denied:
- refund_customer
- send_email
logging:
payload_storage: disabled
metadata_retention_class: ops_metadata_90d
audit_events:
- route_change
- model_change
- prompt_change
- key_rotation
controls:
max_input_tokens: 8000
max_output_tokens: 700
monthly_budget_usd: 500
fallback_requires_same_data_policy: true
evals:
pack: support_summary_eval_2026_07
min_pass_rate: 0.95
required_tests:
- prompt_injection
- sensitive_data_fixture
- tool_scope
rollout:
canary_percent: 5
expand_after_hours: 24
rollback: disable_route_weight
renewal:
review_by: 2026-10-04
triggers:
- model_version_change
- prompt_change
- new_tool
- logging_change
- provider_terms_change这就是 AI 模型审批工作流开始运作的地方。如果路由配置无法表达决策，那么审批就过于抽象了。
这如何与 Flatkey 结合
Flatkey 可以作为此工作流的操作平台，因为其公共产品界面以统一模型访问、路由、计费、使用分析、配额限制以及用于密钥和路由的单一仪表板为中心。当前主页还展示了使用 https://router.flatkey.ai/v1/chat/completions 的 OpenAI 兼容请求模式，而定价和模型页面则描述了预付余额、使用分析、模型定价和提供商覆盖范围。
使用 Flatkey 作为网关证据平台，然后在审批前验证以下特定于账户的详细信息：
- 为该路由启用了哪些模型和提供商。
- 每个路由使用哪个端点系列。
- 允许和拒绝了哪些备用模型。
- 哪些 API 密钥、团队、项目和环境可以调用该路由。
- 购买者账户有哪些可用的使用、成本和配额控制。
- 哪些请求元数据、审计事件和计费记录是可见的。
- 是否存储原始提示、输出、工具参数、文件或跟踪信息。
- 路由变更、密钥变更、配额变更和日志记录变更是否会产生可供审查的证据。
不要将其变成一个通用的信任声明。网关可以减少提供商的无序扩张并集中证据，但购买者仍然拥有 AI 模型审批工作流的所有权。
要问的采购问题
采购和安全团队应要求提供与路由匹配的证据，而不仅仅是平台概述。
| 问题 | 好的证据 | 薄弱的证据 |
|---|---|---|
| 哪个模型将为该路由提供服务？ | 包含主模型和备用模型的路由回读信息 | “我们使用一流的模型” |
| 如果模型失败会怎样？ | 超时、重试、备用和回滚策略 | “网关会处理” |
| 记录了哪些数据？ | 元数据事件示例和有效负载策略 | “我们有日志” |
| 谁可以更改路由？ | 角色列表和审计事件示例 | “管理员可以管理” |
| 通过了哪些评估？ | 数据集、阈值、失败案例和审查员说明 | “在测试中是可行的” |
| 激活了哪些安全控制？ | 过滤器设置、拒绝测试、提示注入案例 | “安全功能已启用” |
| 财务部门审查什么？ | 使用量行项目、定价快照、预算警报、发票路径 | “有一个仪表板” |
| 什么情况会强制重新审批？ | 书面触发器列表和所有者 | “我们在需要时进行审查” |
将此审查与企业 AI API 网关清单（用于网关级控制）、AI API 供应商风险评估（用于上游提供商边界）以及AI API 使用情况的审计日志（用于持久的变更证据）联系起来。
续订和停用
最大的审批失败是漂移。7 月份批准的路由可能不是 10 月份运行的路由。
在上线前设置续订触发器：
- 模型版本被弃用、停用、仅供预览或被替换。
- 提供商更改了数据处理、内容过滤、定价、区域或功能支持。
- 备用模型、路由权重、端点系列或提供商账户发生变化。
- 提示、模式、检索源、系统指令或工具权限发生变化。
- 新的用户组、客户层级、地理位置或数据类别开始使用该路由。
- 监控警报显示质量、安全、延迟、成本或滥用情况出现漂移。
- 事件、支持升级、客户投诉或采购发现涉及该路由。
停用应是同一 AI 模型审批工作流的一部分。当路由停用时，记录替换路由、流量排空日期、禁用的密钥、删除的机密、保留的日志、计费结算以及最终所有者的签核。
常见问题解答
什么是 AI 模型审批工作流？
AI 模型审批工作流是一个治理流程，用于决定模型路由是否可以处理生产流量。它记录用例、模型/提供商路径、提示和工具策略、评估结果、安全控制、日志记录行为、成本护栏、推出计划和续订触发器。
谁应该批准新的 AI 模型路由？
审批至少应包括产品负责人、技术负责人、安全或风险审查员以及财务或运营负责人。风险较高的路由可能还需要法律、采购、隐私、支持或高管审查。
模型卡足以获得批准吗？
不可以。模型卡或系统卡是有用的证据，但它并不能证明您的提示、工具、回退、日志记录、数据流、成本控制和推出行为对于您的用例是安全的。路由仍然需要自己的审批包。
模型审批应该多久审查一次？
审查频率取决于风险，但每条路由都应有续订触发器。当模型版本、提供商、提示、工具权限、日志记录、数据类别、回退、成本概况或用户群体发生变化时，需要重新审批。
AI 网关如何帮助进行模型审批？
AI 网关可以集中管理模型访问、路由策略、密钥、使用情况、成本、配额和审计证据。它不能取代购买方的治理。使用网关作为控制和证据层面，然后验证特定于账户的行为。
结论
AI 模型审批工作流应确保生产模型的变更在成为事故之前是可审查的。批准路由，而不是模糊的模型名称。将证据文件放在网关附近，要求进行特定于任务的评估，测试提示注入和工具权限，验证日志记录和成本控制，并在第一个请求上线前设置续订触发器。当您准备好将模型访问、路由、使用和计费集中到一个网关后面时，请查看 Flatkey 当前的定价和模型目录，然后获取密钥。
