AI API 供应商安全评估完整指南：SOC 2、ISO 27001 之外还要查什么

企业在接入 GPT-5.5、Claude Opus 4.8 或 DeepSeek V3 之前，安全团队往往先要一份 SOC 2 Type II 报告，再核一下 ISO 27001 证书，打个钩就算过了。这种做法的问题在于：这两份证书描述的是供应商自身的信息安全管理体系，而不是你的数据在模型推理过程中的具体命运。AI API 供应商安全评估的真正难点，恰恰藏在证书覆盖不到的地方。

证书之外，先问三个"数据去哪了"

SOC 2 和 ISO 27001 的审计范围通常是供应商的基础设施和内控流程。它们不会告诉你：你发送的 prompt 是否会被用于下一轮模型训练、推理时数据在哪个地区的节点上处理、员工能不能看到你的请求内容。

评估时要逐条对照供应商的 Data Processing Agreement（DPA） 和 Terms of Service（ToS），重点盯住以下条款：

• 训练数据使用条款（Training Data Opt-out）：OpenAI 的 API ToS 默认不将 API 调用数据用于训练，但需要企业主动确认未开启零数据保留（Zero Data Retention）以外的选项；Anthropic 对 API 客户同样承诺不用于训练，但这一承诺要在 DPA 签署后才具合同约束力。国产供应商如 DeepSeek、Qwen 3 的中文 ToS 里，训练数据条款往往描述模糊，必须要求对方出具书面澄清。
• 数据驻留（Data Residency）：欧盟 GDPR 要求个人数据不得在未经适当保护机制的前提下跨境传输。询问供应商是否支持指定推理节点在特定地区（如 EU-West），并要求在合同中固定，而不是仅依赖控制台里的一个下拉菜单。
• 数据保留期限（Retention Period）：请求日志、推理请求本体、模型输出，分别保留多久？大多数主流供应商默认保留 30 天，但部分供应商对企业客户可协商至 0 天即时删除。把这个数字写进合同附件。

审计日志：你能看到多少，决定你能查到多少

供应商提供审计日志（Audit Logs）是标配，但日志的质量差距极大。评估时要求供应商提供一份样本日志，核查以下字段是否存在：

| 字段 | 最低要求 | 推荐级别 | |------|----------|----------| | 请求时间戳 | 秒级精度 | 毫秒级，含时区 | | 调用方身份 | API Key ID | API Key ID + IP + User-Agent | | 模型版本 | 模型名称 | 模型名称 + 版本哈希 | | Token 消耗 | 总量 | input/output 分拆 | | 响应状态码 | 有 | 有，含错误分类 | | 请求内容 | 不记录（隐私） | 可选记录，加密存储 |

关键问题：日志能否导出到你自己的 SIEM？ 支持 webhook 推送或 S3 导出的供应商，比只提供控制台查询的供应商安全性高一个档次。同时确认日志的不可篡改性——理想状态是日志写入后供应商员工也无法删除，部分供应商会提供日志签名（Log Signing）来证明完整性。

访问控制与员工访问政策

很多企业忽略了一个问题：供应商的工程师能否访问你的推理请求？这不是假设场景，而是真实发生过的内部数据泄露路径。

评估时要求供应商提供以下书面说明：

1. 人工访问政策：员工访问生产数据是否需要工单审批？审批记录是否纳入 SOC 2 审计范围？ 2. 特权访问管理（PAM）：是否使用 Just-in-Time（JIT）访问，即临时授权而非长期权限？ 3. 背景调查：接触生产系统的员工是否经过背景调查？适用哪个标准（BPSS、SC Clearance 还是自定义）？

OpenAI 和 Anthropic 的企业合同中通常包含一份 Trust & Safety Addendum，明确列出员工访问限制。国内供应商如 GLM-5.2 所在的智谱 AI，可以要求其提供等保三级（GB/T 22239）认证，这是国内等效的访问控制合规基准。

模型完整性与供应链风险

这是 2026 年新出现的评估维度：你调用的模型权重，是否有被投毒（Model Poisoning）或被替换的风险？

具体可操作的检查步骤：

• 模型版本锁定：API 调用时是否支持指定精确版本（如 claude-opus-4-8-20260501）而非浮动别名（如 claude-latest）？浮动别名意味着供应商可以在你不知情的情况下切换底层模型。
• 模型版本公告：供应商是否维护一个公开的 Changelog，记录每次模型更新的时间和变更内容？Anthropic 的模型版本页面做得相对规范，GPT 系列则可通过 OpenAI 的 API 返回头中的 openai-model 字段核验实际使用版本。
• 第三方模型来源：如果供应商是转售/聚合平台而非原始模型提供商，需要额外确认其上游来源链——权重是否来自官方渠道，是否经过完整性校验（如哈希比对）。

实操清单：采购前必问的 12 个问题

以下清单可直接用于与供应商的安全评估会议：

1. API 调用数据是否用于模型训练？默认状态是什么？如何关闭？ 2. DPA 是否可签，且受哪个司法管辖区法律约束？ 3. 推理请求的数据驻留地区是否可指定并固化在合同中？ 4. 请求日志保留多久？能否设置为 0 天或按需删除？ 5. 审计日志是否支持导出到 SIEM（如 Splunk、Datadog）？ 6. 供应商员工访问生产数据是否需要审批？审批记录在哪里？ 7. 是否支持精确模型版本锁定（而非浮动别名）？ 8. SOC 2 Type II 报告的审计期间是哪段？最近一次完成时间？ 9. 是否有漏洞赏金计划（Bug Bounty）？范围覆盖 API 端点吗？ 10. 发生数据泄露时，通知企业客户的 SLA 是多少小时？ 11. 是否支持 IP 白名单或 VPC Peering 以减少网络暴露面？ 12. 如果供应商是聚合平台，上游模型权重的来源和完整性如何验证？

---

作为在这个领域写了很长时间的人，我观察到企业在 AI API 安全评估上最常犯的错误，是把"持有证书"等同于"足够安全"。实际上，证书是必要条件，不是充分条件。

如果你正在寻找一个在合规层面已经做了基础功课的聚合接入平台，我目前用的是 XycAi 词元平台（https://www.xyc.ai）。它持有大模型算法备案号、支持企业合规开票，同时能一键接入 Claude Code、Codex、Gemini CLI 等编码 CLI，覆盖 200+ 全球模型。对于需要同时评估多家供应商行为的安全团队来说，通过一个有备案资质的中间层做统一审计，比分散管理十几个 API Key 要省力得多。