北京
旧供应商通过了安全审查，换新供应商似乎只是走个流程。但它不是，原因是结构性的：安全团队当初批准的是一套具体系统、一份具体报告所描述的状态、一个具体时间段内的运行情况。这三个要素，一项都不会自动延续到新供应商身上。
审批绑定的是系统，不是类别。供应商风险评估，本质上是对“一个供应商在一种架构中处理你的一类数据”所做的决策。“LLM推理”不是审批单位——“这家供应商、接收这些字段、保留这么长时间、在这些区域存储”才是。一旦更换供应商，这个决策的每一个输入都要重新评估。有些细节在两家公司之间看似相同，实则完全不同：数据保留默认值、提示词和生成结果是否可用于训练、端点后面还有哪些子处理商、请求可能从哪些区域被服务。
还有第二个容易踩坑的原因。大多数供应商登记册按“用途”记录审批，而用途往往和供应商同时改变——你迁移，正是因为旧供应商没有你想要的新能力。如果迁移同时新增了文件上传、能抓取URL的托管工具、或用客户对话记录训练的微调模型，那这已经不是同一条数据流了。即使供应商不变，这种变化也需要重新审查。
那么，SOC 2报告到底覆盖了什么？SOC 2报告是根据AICPA的信任服务标准（Trust Services Criteria）执行的鉴证。读报告，主要是读它的边界，而边界恰恰是审查最容易卡住的地方。下面五个边界，比控制清单本身更重要。
第一，Type I和Type II的区别。Type I报告只对“某一时点的控制设计是否恰当”发表意见；Type II则对“一段时间内控制是否有效运行”发表意见。只有第二种才能告诉你，这家供应商在普通工作日里实际表现如何。
第二，观察期以及报告日至今的间隔。Type II覆盖的是一个已经结束的时间窗口。窗口结束到今天的这段空白，报告一个字都没有说。
第三，系统边界。报告只覆盖它明确列出的系统和服务，没列出的不在鉴证范围内。
第四，子处理商。很多SOC 2报告并不覆盖所有子处理商，而你请求的数据可能恰恰经过某个未覆盖的子处理商。
第五，例外事项。报告中的例外情况往往比控制描述更有信息量——它告诉你控制在哪里失效过、如何补救、以及是否已整改。
结论是：切换AI供应商时，过去的审查结论不能结转。重新做一次彻底的、针对具体系统和具体用途的评估，不是流程冗余，而是唯一正确的做法。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
