SOC 2 AI API gateway 审查应在买家索取安全资料包之前就开始。采购问题不是“你有徽章吗？”而是该网关、模型路由、日志、密钥、计费记录、支持流程以及下游提供商是否能够对应到一名安全审查员 वास्तव能检查的证据。
本指南面向在生产流量之前评估 AI API 网关的采购、安全、平台、合规和供应商风险团队。它不是法律或审计建议。请将其用作一份实用的证据清单：需要索取什么、在 SOC 2 报告中核实什么、在网关中测试什么，以及在你们自己的买方文件中保留什么。
Flatkey 之所以相关，是因为 flatkey.ai 公开将该产品定位为面向生产 AI 团队的单一 API 网关，具备模型访问、路由、计费、使用分析、运营控制、仪表板以及针对多个提供商的一把密钥。Flatkey 的公开页脚还链接到 VOC AI Inc. 的证书查询页面，其中显示有 SOC 2 Type II 条目和 ISO 27001:2022 条目，而截至 2026 年 6 月 19 日核查的当前定价 API 快照返回了 23 家供应商的 638 条模型记录。请将这些视为有日期的公开证据，而不是私有 SOC 2 报告、已签署协议、DPA、账户设置或生产日志验证的替代品。
SOC 2 AI API 网关证据应证明什么：快速答案
SOC 2 AI API 网关审查应证明三件事：供应商的控制报告覆盖相关服务、网关能够为你的 AI 流量生成运行证据，以及你的团队已针对供应商报告留给客户承担的职责建立控制措施。
| 审查领域 | 需要请求的证据 | 需要验证的内容 |
|---|---|---|
| SOC 2 报告范围 | 最新的 SOC 2 Type II 报告、报告期间、审计师、系统描述，以及如果报告期间已过时则提供桥接函。 | AI 网关、API 路由、日志记录、支持、计费以及相关基础设施都在系统边界之内。 |
| 信任服务准则 | 报告涵盖的类别，通常是安全性，以及可用性、保密性、处理完整性或隐私中的任何适用类别。 | 所涵盖的类别与买方风险相匹配。除非报告明确说明，否则不要假设已涵盖隐私或可用性。 |
| 互补的用户控制 | SOC 2 报告中列出的 CUEC 和买方责任。 | 你的团队能够满足密钥管理、路由审批、数据分类、用户访问、保留和事件响应责任。 |
| 分包服务组织 | 剥离型或纳入型分包服务组织描述、提供商列表和监控控制。 | 下游模型提供商、云服务、支持工具、可观测性和计费供应商都按照报告模型一致地处理。 |
| AI 网关运营 | 样本日志、密钥所有权字段、路由变更历史、模型提供商路由清单和事件导出流程。 | 网关可以显示谁发送了流量、哪个模型/提供商接收了流量、发生了什么变更，以及保留了哪些证据。 |
| 数据和隐私 | 隐私政策、DPA 路径、数据处理位置、保留政策、载荷日志策略和提供商数据使用条款。 | 提示词、输出、元数据、支持材料和计费记录都有明确的处理规则。 |
| 买方侧证据 | 你自己的上线记录、已批准的用例、密钥分类体系、路由策略、日志模式和审查节奏。 | 供应商证据与你的团队实际使用网关的方式相对应。 |
从 SOC 2 范围入手，而不是看徽章
公开徽章可用于初步筛选，但采购仍应根据供应商的信任流程索取实际的 SOC 2 报告。AICPA 将 SOC 2 报告描述为对服务组织中与安全性、可用性、处理完整性、保密性或隐私相关控制的审查。这意味着采购时真正有用的问题是范围：涵盖了哪个系统、服务、日期范围、标准、控制、例外以及管理层认定？
对于 SOC 2 AI API 网关，范围审查应回答：
| 范围字段 | 买方问题 | 为何这对 AI API 流量很重要 |
|---|---|---|
| 法律实体 | 报告和合同中列的是哪家实体？ | Flatkey 的公开证书查询指向 VOC AI Inc.；你的采购文件应与签约实体和服务所有者一致。 |
| 系统边界 | 报告是否涵盖 AI 网关、API 路由、仪表板、密钥、计费、使用记录和支持流程？ | 一份针对更广泛的数据或分析平台的报告，可能无法证明你计划使用的特定网关工作流。 |
| 报告期间 | Type II 报告测试的是哪个日期范围，是否需要过渡函？ | 采购通常需要当前的运营证据，而不只是历史上的某个时点声明。 |
| 信任类别 | 涵盖了哪些信任服务标准？ | 安全性覆盖并不自动意味着可用性、保密性、处理完整性或隐私也被覆盖。 |
| 例外 | 是否有任何控制被限定、列为例外或已整改？ | 例外可能影响密钥管理、日志记录、变更控制、事件响应或供应商监控。 |
| 分包服务组织 | 哪些云、提供商、支持、可观测性和支付服务被排除在外或包含在内？ | AI 网关风险往往取决于下游模型和基础设施提供商。 |
实用规则很简单：如果买方无法将 SOC 2 报告与确切的网关服务和流量路径对应起来，那么该报告只是筛选证据，而不是最终的采购证据。
将 SOC 2 标准映射到 AI Gateway 控制项
AICPA Trust Services Criteria 涵盖安全性、可用性、处理完整性、保密性和隐私。SOC 2 AI API gateway 证据包应将这些宽泛类别转化为具体的 gateway 检查项。
| 控制主题 | 需验证的证据 | 相关的 SOC 2 关注点 |
|---|---|---|
| API key 所有权 | Key 与所有者、环境、应用和工作流绑定；key 的创建和吊销可审计。 | 逻辑访问、责任归属、变更控制和事件遏制。 |
| 路由和模型审批 | 已批准的提供商、端点族、模型行、回退规则和变更记录可供审查。 | 变更管理、供应商监控、处理完整性和保密性。 |
| 审计日志 | 日志显示时间戳、key 或项目、路由、提供商、模型、端点族、状态、错误类别、使用单位以及管理变更。 | 监控、事件响应、访问审查和运营证据。 |
| 载荷处理 | Prompt/output 日志记录模式、脱敏、访问限制、保留期限和删除路径均有文档说明。 | 保密性、隐私和数据最小化。 |
| 使用与计费 | 使用记录和计费记录与原始载荷分离，并与所有者、模型、路由和成本中心关联。 | 处理完整性、责任归属和财务审查支持。 |
| 事件审查 | 安全事件、提供商故障、可疑使用、key 泄露、回退循环和超限事件都有运行手册和导出路径。 | 安全监控、响应和修复。 |
| 供应商和提供商变更 | 提供商新增、移除、区域变更和数据使用政策变更都会触发重新审查。 | 子服务组织监控和风险评估。 |
这正是 AI gateways 与通用 API gateways 的不同之处。路由不只是主机/路径决策。它还会决定哪个模型提供商可以看到 prompt、适用哪项数据政策、适用哪条保留规则、允许哪种回退路径，以及按哪个使用单位计费。
采购前需验证的 Flatkey 证据
Flatkey 具备足够有用的公开证据，可用于初步 SOC 2 AI API gateway 评估。公开网站说明，Flatkey 为交付 AI 产品的团队统一模型访问、路由、计费、使用分析和运营控制。页脚链接到 VOC AI Inc. 的 Cert Assure SOC 2 Type II 查询，证书 `USA-SOC2-220513`，列出的有效期为 2025 年 7 月 15 日至 2026 年 7 月 14 日，且在检查时状态为有效。相同页脚还链接到 VOC AI Inc. 的 ISO 27001:2022 查询，证书 `USA-I-270513`，列出的有效期为 2024 年 5 月 1 日至 2027 年 4 月 30 日，且在检查时状态为有效。
先将这些公开页面作为档案起点，然后在采购前直接向 Flatkey 核实以下细节：
| Flatkey 检查项 | 需要收集的内容 | 防线 |
|---|---|---|
| SOC 2 报告请求 | 当前报告、审计机构、期间、范围、覆盖控制项、例外情况、分包服务机构，以及如有需要的桥接函。 | 不要仅依赖公开徽章或证书查询结果。 |
| ISO 27001:2022 交叉核对 | 证书主体、活动范围、日期，以及在信任审查下可获得的适用性声明或安全概述。 | ISO 认证可支持 ISMS 审查，但不能替代 SOC 2 报告或 AI 路由验证。 |
| 目录和端点支持 | 当前模型行、提供商、端点系列、可用性状态，以及来自 Flatkey pricing 的计价单位。 | 模型数量、供应商数量和可用性可能变化；请在批准路由当天核实。 |
| 仪表盘证据 | 当前 Flatkey dashboard 中的关键负责人、路由、模型、提供商、状态、使用单位、计费记录，以及任何导出路径。 | 不要假定公开营销文案中的仪表盘标签与实际完全一致。 |
| 日志和保留 | 元数据字段、载荷日志行为、保留期限、查看权限、支持数据处理，以及删除/导出流程。 | Flatkey 的公开隐私政策提到请求元数据、错误记录、使用记录、必要日志和支持材料，但买方需要账户级条款。 |
| 提供商路由政策 | 已批准的提供商、故障切换约束、提供商数据使用条款，以及谁可以更改路由。 | 如果下游提供商发生变化，可靠性故障切换可能演变为供应商风险变更。 |
如何在安全放行前测试网关
不要等到真实客户流量来了，才发现你的SOC 2 AI API 网关证据是否完整。针对每条路由执行一次受控的烟雾测试，并保存审查材料。
- 创建非保密路由标识：为预生产、生产、批处理、面向客户和评估流量分别使用独立的密钥或项目。
- 选择一条低风险模型路由：记录提供商、模型行、端点族、计价单位和预期数据类别。
- 发送一个无害的测试请求：避免使用真实客户数据、个人数据、机密信息或受监管内容。
- 检查日志记录：确认时间戳、密钥/项目、所有者、路由、提供商、模型、状态、使用单位、错误类别和成本可见性。
- 检查管理证据：确认是谁创建了密钥、谁批准了路由、谁可以更改回退，以及更改记录存放在哪里。
- 测试拒绝路径：尝试不允许的模型、被阻止的数据类别、已过期的密钥或配额边界，并保存结果。
- 记录保留情况：明确元数据、载荷（如有）、支持工单、计费记录和安全日志的保留位置。
- 附上采购文件：SOC 2 报告、过渡证明函、ISO 证据、隐私政策、条款、DPA 路径、提供商审查以及你的上线说明。
- 在变更后重复执行：当提供商、模型、端点族、回退、数据类别、日志模式或合同条款发生变化时，重新运行该材料包。
- 区分公开和私有证据：公开页面有助于初步筛查；私有报告和账户级验证可完成采购流程。
SOC 2 只是 AI 网关审查的一层
SOC 2 AI API 网关审查应与 ISO 27001、GDPR、应用安全和供应商风险检查并列。 这些框架彼此相关，但回答的是不同的问题。
| 框架或来源 | 它有助于验证什么 | 它本身不能证明什么 |
|---|---|---|
| SOC 2 | 在报告期间，对所描述系统及所覆盖的信任服务准则下控制措施的独立审查。 | 它不能证明每一项 Flatkey 功能、客户账户设置、下游模型路由或买方工作流都已覆盖。 |
| ISO/IEC 27001:2022 | 信息安全管理体系范围、风险管理和认证状态。 | 它不能替代 SOC 2 报告，也不能证明某个特定的 AI 请求日志模式。 |
| GDPR | 处理者审查、处理安全、数据最小化、保留、传输保障以及个人数据的角色映射。 | 仅仅因为网关经过 SOC 2 审查，并不意味着它就自动满足 GDPR。 |
| OWASP logging guidance | 实用的日志设计、事件属性、应排除的数据、日志保护以及监控方面的关注点。 | 它不能定义你供应商的保留政策，也不能证明你对 prompt/output 的处理是可接受的。 |
| Buyer controls | 你的密钥分类法、用户访问、路由审批、数据分类、模型回退、保留和事件审查。 | 它们不能替代供应商控制；它们让供应商证据在你的环境中可用。 |
请使用 Flatkey 邻近的 企业 AI API 网关清单来覆盖更广泛的采购栈，并参考 AI API 使用审计日志，获取安全团队通常会要求的证据字段。
采购证据包模板
来自 SOC 2 AI API 网关 审查的最有用输出，是一个精简的资料包，销售工程、安全、法务和平台团队都能读懂。
| 资料包部分 | 应包含的字段 | 负责人 |
|---|---|---|
| 供应商身份 | 法律实体、签约实体、支持联系人、信任门户路径、证书查询链接以及当前状态。 | 采购 |
| SOC 2 文件 | 报告类型、期间、审计师、系统边界、信任服务准则、例外情况、分包服务组织、CUECs 以及桥接函。 | 安全 |
| 网关路由文件 | 已批准的提供商、模型、端点系列、回退规则、数据类别、路由负责人以及变更审批人。 | 平台工程 |
| 日志和证据文件 | 请求元数据字段、管理日志、负载策略、保留类别、导出方法以及查看者访问列表。 | 安全运营 |
| 数据保护文件 | DPA 路径、隐私政策、条款、提供商数据使用审查、处理地点、子处理方列表以及 GDPR 角色说明。 | 法务与隐私 |
| 买方侧控制 | 密钥分类法、访问审查频率、路由变更流程、配额策略、事件处置手册以及重新审查触发条件。 | 平台与治理 |
| 上线批准 | 最终批准人、已批准用例、受阻数据类别、上线日期、审查日期以及残余风险。 | 安全与产品 |
审查期间的红旗
如果 SOC 2 AI API 网关 证据存在以下未解决的缺口，请暂停采购：
- 仅靠徽章作答： 供应商指向一个徽章，但无法在 NDA 或信任访问下提供当前的 SOC 2 报告。
- 范围不匹配： 报告涵盖的是与正在采购的网关不同的产品、实体、基础设施边界或时间段。
- 没有 CUEC 计划： 报告列出了客户责任，但买方尚未在内部分配这些责任。
- 子服务组织不透明： 下游模型提供商、支持工具、日志工具或云提供商未被清晰处理。
- 没有变更路线证据： 团队无法证明是谁添加了提供商、修改了模型，或启用了回退机制。
- 负载日志记录含糊不清： 提示和输出可能会被存储，但保留、访问和删除规则不明确。
- 仅有仪表板证明： 虽然有截图，但没有可导出或可审查的证据文件供安全审查使用。
- 没有重新审查触发条件： 新模型、地区、端点家族以及提供商政策变更可能在无需采购/安全审查的情况下发生。
常见问题
什么是 SOC 2 AI API 网关证据？
SOC 2 AI API 网关证据是一组文档、日志、路由记录、控制映射以及买方侧注释，用于展示 AI 网关的控制如何支持采购审查。它包括供应商的 SOC 2 报告、范围审查、子服务组织处理、审计日志、密钥所有权、路由审批、保留政策和客户责任。
SOC 2 徽章是否足以批准 AI API 网关？
不行。徽章可以帮助初步筛选，但采购方应核实当前的 SOC 2 报告、覆盖的系统、报告期间、标准、例外项、子服务组织以及互补用户实体控制。私有报告和买方的路由测试比徽章本身更重要。
SOC 2 是否应覆盖网关背后的每个模型提供商？
不一定。SOC 2 报告描述的是服务组织的系统以及如何处理子服务组织，通常通过剔除法或纳入法来说明。买方应核实模型提供商、云服务、支持工具和可观测性服务是如何被呈现的，然后审查每个提供商各自的数据和安全条款。
SOC 2 与 GDPR 如何与 AI API 网关关联？
SOC 2 可支持安全控制证据，而 GDPR 审查关注处理角色、合法依据、数据最小化、处理者条款、传输、保留以及数据主体权利。SOC 2 AI API 网关可以集中管理有用证据，但它不会自动解决 GDPR 义务。
购买前我应该在 Flatkey 中核实什么？
核实 Flatkey 当前的 SOC 2 报告、ISO 27001 证书详情、法律实体、已签署条款、DPA 路径、模型/提供商路由、端点系列、仪表板证据字段、日志保留、有效载荷处理、支持数据处理以及回退行为。还要在批准生产使用当天确认当前的模型行和定价单位。
最终采购步骤
在你批准一个SOC 2 AI API gateway之前，请像审计员或企业买家审查它一样来构建证据包：实体、报告范围、准则、期间、例外、子服务组织、日志、访问控制、路由变更、数据处理以及客户责任。Flatkey 可以集中管理模型访问、路由、使用可见性和运营控制，但你的采购文件仍应核实最新报告以及你将实际运行的确切路由。
获取密钥，当你准备好将模型访问、路由、使用可见性以及供买家审核的证据统一集中到一个 AI API gateway 中时。
