AI 供应商安全评估是一个结构化的评估流程,用于确定人工智能工具或平台在被授予访问组织数据的权限或被集成到业务工作流之前,是否符合组织的安全、合规和数据保护要求。它在采购流程中那个出错后果仍可控的时间点上,用证据取代假设。
大多数组织都有针对传统软件运作良好的供应商安全评估流程。供应商填写问卷。法务审查合同。IT 检查认证。工具被部署。但对于 AI 供应商,这一流程遗漏的内容足以造成重大影响。揭示 AI 供应商关系中最重大风险的问题,并不出现在标准的 IT 供应商问卷中。这些问题涉及模型训练数据的使用、推理基础设施所在的司法管辖区、对话结束后数据将如何处理,以及供应商所出示的安全认证是否涵盖正在部署的特定产品,或仅涵盖其基础设施的完全不同的部分。那些在签订合同之后、敏感数据已流经未经其妥善评估的系统之后才发现这些差距的组织,会在第二次评估时格外仔细。本指南阐述了如何开展一项能够发现关键问题的 AI 供应商安全评估,应当要求哪些证据而不是仅凭主张就予以接受,以及如何将评估流程构建为可重复的组织能力。

为何标准供应商评估对 AI 来说不够充分
通用问卷遗漏的差距
标准的 IT 供应商安全问卷是为这样一种软件环境而开发的:主要的安全关注点是数据存储安全、访问控制和网络保护。这些关注点同样适用于 AI 供应商。但 AI 系统引入了一系列额外的关注点,而通用问卷在设计时并未旨在揭示这些问题,且如果不被明确询问,供应商也不会主动提供这些信息。
模型训练数据的使用是第一个差距。供应商是否使用通过其产品提交的数据来训练或改进其 AI 模型,对于通过 AI 工具处理专有或敏感信息的组织而言,是最具影响的数据处理问题之一。这也是标准供应商问卷未包含的问题,因为它在传统软件采购中没有对应项。数据库供应商不会使用您的数据来训练其产品。AI 供应商可能会,而他们是否如此做,通常隐藏在服务条款语言中,而非显著披露。
推理基础设施的位置是第二个差距。AI 模型在何处物理处理您的数据,决定了哪些法律框架适用于该处理过程、是否需要跨境数据传输机制,以及哪个司法管辖区的法律程序可以强制披露这些数据。标准供应商评估询问数据存储在何处。AI 评估需要单独询问数据在推理期间在何处处理,这可能是位于不同地点的不同基础设施。
安全认证的范围边界是第三个差距。供应商可能出示涵盖其云基础设施的 SOC 2 Type 2 报告,而正在评估的特定 AI 产品却运行在审计范围之外的不同基础设施上。如果不核实所出示的认证是否涵盖与您的部署相关的特定产品和基础设施,认证审查可能会对一个从未被审查过的部署提供虚假的信心。
理解 AI security 评估要求与传统供应商安全评估的差异,可帮助组织构建针对实际 AI 风险格局的评估流程,而非针对这些流程最初所设计应对的传统软件风险格局。

构建 AI 供应商安全评估框架
每项评估必须涵盖的五大领域
有效的 AI 供应商安全评估将其评估组织为五个领域,这五个领域共同构成了供应商在所考虑的具体部署中的安全态势的完整图景。每个领域都涉及其他领域未涵盖的风险维度,这就是为什么仅关注一两个领域而跳过其余领域的评估始终会遗漏实质性风险。
技术安全涵盖保护由供应商 AI 系统处理的数据的基础设施控制措施。这是与传统供应商安全评估重叠最多的领域,涵盖加密标准、网络安全架构、漏洞管理实践、事件检测和响应能力,以及运行 AI 工作负载的基础设施的物理安全。
数据治理涵盖供应商在其系统中对组织数据整个生命周期所做的处理。该领域包括训练数据使用政策、推理日志保留实践、数据删除能力和时限、次级处理方关系及其数据访问权限、跨境数据传输机制,以及管辖所有上述事项的合同保护。
合规与认证涵盖对供应商安全主张的独立验证以及其产品可支持的监管框架。该领域包括审查具体的认证文件而非接受供应商陈述、验证认证范围和时效性、评估所需数据协议的可用性,以及确认对您的组织适用的行业特定合规要求的支持。
AI 特有的安全涵盖 AI 系统所独有的、在传统软件供应商评估中没有对应项的风险。该领域包括提示注入的易感性和缓解控制、对抗性鲁棒性测试、模型提取保护、针对所部署特定用例的幻觉率和缓解方法,以及供应商对模型更新和行为变更管理的处理方式。
运营安全涵盖供应商作为一个组织的安全实践,而非其特定产品的技术控制措施。该领域包括安全团队的结构和专业知识、安全披露和漏洞管理实践、违规通知流程和历史事件记录,以及供应商对其 AI 产品所依赖的组件和服务的自身供应链安全。
| 评估领域 | 主要问题 | 所需证据 |
|---|---|---|
| 技术安全 | 加密标准、网络架构、漏洞管理 | SOC 2 Type 2 报告、渗透测试摘要 |
| 数据治理 | 训练数据使用、保留期限、删除能力、次级处理方 | 合同条款、数据处理协议、次级处理方清单 |
| 合规与认证 | 认证范围和时效性、数据协议可用性、监管支持 | 当前认证文件、已签署的 DPA 或 BAA |
| AI 特有的安全 | 提示注入控制、对抗性鲁棒性、模型更新实践 | 技术文档、安全测试结果 |
| 运营安全 | 安全团队、披露实践、事件历史、供应链 | 安全披露、事件通知历史 |
区分评估与接受的证据标准
AI 供应商安全评估中最重要的纪律是要求证据,而非接受主张。供应商在销售对话、营销材料,甚至供应商填写的问卷中所做的安全主张,并不是经过独立核实的事实陈述。它们是其准确性取决于供应商自身对其安全态势的评估,以及他们以有利方式呈现的商业动机的陈述。
基于证据的评估要求每项重大安全主张都必须由独立方已核实的文档支持,或者由组织可以直接核实的文档支持。声称符合 SOC 2 的供应商应出具实际的 SOC 2 报告,而非摘要或徽章。报告应被阅读,而不仅是接收,需关注其范围边界、审计期间、所测试的具体控制措施,以及所注明的任何例外或偏差。声称其产品不使用客户数据进行模型训练的供应商,应在管辖该关系的合同条款中记录这一禁止条款,而不仅仅在销售对话中陈述。
核实纪律同样延伸至认证本身。SOC 2 审计师在质量和严格性方面各有不同。来自具有经验证的技术行业专业知识的知名公司的审计报告,所提供的证据比来自不知名公司、技术审计历史有限的审计报告更为有力。报告期间也很重要,因为涵盖非常短审计期间的报告可能反映的是一次旨在快速获得认证的首次审计,而非一个成熟、持续的安全计划。
审查供应商 AI architecture 文档如何描述其安全控制措施,可帮助评估人员评判所呈现的技术架构是否连贯且可辩护,或者是否在某种抽象层面上描述安全性,从而掩盖了实质性差距。
最重要的 AI 特有问题
关于训练数据使用应当问什么
训练数据使用问题需要比是或否的回答更精确,因为产生重大风险的实践比一般性问题所能捕捉到的更为具体。回答其不使用客户数据进行训练的供应商,所表达的含义可能比该问题所暗示的更为狭窄。
询问对话内容(包括提示词和响应)是否在任何情况下用于模型训练或微调,包括通过服务条款获得的客户同意。询问聚合或匿名化的客户数据是否会为模型改进做出贡献。询问该禁止条款是否适用于所有产品层级,还是仅适用于正在评估的企业层级。询问该禁止条款是绝对的,还是可以通过客户协议加以放弃。询问该禁止条款是如何在技术上而非仅仅在合同上实施的,因为一项未在技术上实施的合同禁止条款,完全依赖于供应商的运营合规性,而非架构保证。
对这些具体后续问题的回答,往往会揭示训练数据使用实践比供应商最初陈述所暗示的更为微妙,以及组织所评估的企业层级所提供的保护可能与标准产品条款不同,而这些差异对于所评估的特定用例具有重要意义。
关于推理基础设施和数据驻留应当问什么
对于 AI 系统的基础设施问题,需要分别询问模型权重存储在何处、推理在计算上发生在何处、输入数据在何处处理、输出数据和日志存储在何处,以及这些情况在所部署的特定产品层级而非供应商总体基础设施的背景下分别发生在何处。
对于具有数据驻留义务的组织,推理位置问题往往比存储位置问题在直接影响上更为重要,因为在大多数司法管辖区中,驱动驻留要求的监管框架将处理司法管辖区视为等同于存储司法管辖区。存储基础设施位于所要求的司法管辖区,但推理处理发生在其他地方的供应商,即使存储控制措施完全合规,也未满足驻留要求。
要求供应商提供一份数据流图,从提交开始,经过推理、输出、日志记录,直到删除,追踪组织数据,并清楚标明每个阶段的物理位置。如果供应商无法提供这份文档,他们对自身数据流理解上的这一差距本身就是一项重大的安全发现。

关于模型更新和行为变化应当问什么
AI 供应商按照并不总是提前与客户沟通的时间表更新其底层模型。模型更新可能以影响其安全态势、其与客户可接受使用要求的合规性,或其在客户所部署特定用例下输出质量的方式,改变 AI 系统的行为。
询问供应商如何通知客户与安全或合规性相关的行为变化的模型更新。询问企业客户是否可以选择保留在特定模型版本上,而非接收自动更新。询问供应商如何在将模型更新部署到客户环境之前对其进行安全回归测试。并询问如果模型更新以影响客户部署中的合规性或安全性的方式改变行为,客户的救济措施是什么。
这些回答揭示了组织对其所部署 AI 系统核心组件将拥有的控制程度,以及供应商关于客户参与模型生命周期的理念。其所部署 AI 系统用于受监管环境或高风险决策支持的组织,在模型稳定性和更新通知方面比那些将 AI 用于低风险生产力应用的组织有更强的利益诉求。
评估必须建立的合同保护
数据流动之前必须就位的协议
AI 供应商安全评估的合同阶段,将技术和治理的发现转化为具有法律可执行性的保护。技术控制措施保护供应商基础设施上的数据。合同保护则定义了管辖该基础设施如何运作以及在未履行义务时组织拥有何种救济的法律义务。
涵盖正在部署的特定 AI 产品的数据处理协议,是任何处理受 GDPR、CCPA 或同等框架约束的个人数据的供应商的基本合同要求。DPA 需要明确处理训练数据禁止条款、按类别的数据保留限制、次级处理方管理义务、数据删除时限,以及违规通知要求。为通用云服务起草的供应商 DPA 模板,可能无法充分处理评估所确定为相关的 AI 特有考虑因素。
对于医疗保健组织而言,业务伙伴协议是任何可能构成受保护健康信息的数据流经供应商 AI 系统之前的法律前提。BAA 需要涵盖正在部署的特定产品,而非仅仅涵盖供应商的总体基础设施,并需要确认该 AI 产品的数据处理实践与 HIPAA 的技术保障要求一致。
理解企业 AI 平台中的 AI features 相对于正在协商的合同保护的结构,可帮助组织识别产品行为和合同条款一致的地方,以及产品技术现实需要额外合同明确性才能实现组织所需保护的地方。
| 所需协议 | 适用情形 | AI 关键条款 |
|---|---|---|
| 数据处理协议 | GDPR 或同等框架下的任何个人数据处理 | 训练数据禁止条款、保留限制、次级处理方清单 |
| 业务伙伴协议 | HIPAA 下的任何 PHI 处理 | 产品特定覆盖范围、技术保障确认 |
| 主服务协议 | 所有商业供应商关系 | 责任分配、违规救济、终止时数据返还 |
| 安全附录 | 高敏感性数据处理场景 | 超出标准条款的特定安全义务 |
| 模型风险文档 | 受监管金融活动中的 AI | 模型文档、验证权、更新通知 |
| 保密协议 | 评估流程本身及敏感发现 | 涵盖评估方法和组织要求的范围 |
超越标准条款的谈判
大多数企业 AI 供应商协议起始于有利于供应商起草的标准条款。评估流程应根据组织的安全发现和合规要求,确定需要修改的具体条款,而非未经优先级排序地针对整个标准条款进行谈判。
谈判优先级最高的条款是那些最直接影响评估所识别的安全和合规风险的条款。允许组织需要禁止的使用方式的训练数据使用条款。对所处理数据类别而言不足的责任限制。不满足监管要求的违规通知时限。赋予供应商更多变更其基础设施的灵活性,超出了组织合规要求所能容纳范围的次级处理方批准权。
具有显著采购影响力的组织——无论是通过交易规模、品牌价值还是市场地位——往往能够恰恰在这些点上对标准 AI 供应商条款获得有意义的改进,因为供应商对这种关系的重视程度足以满足超出其标准模板的要求。影响力有限的组织有时可以通过将要求构建为监管必要性而非偏好来达到同样的结果,因为供应商在支持合规部署方面具有商业利益,这种利益延伸超越任何单一客户关系。
关于如何为安全和合规构建 AI 供应商协议的全面 AI guide,可帮助组织构建优先考虑那些最影响其实际风险敞口的条款的谈判框架,而非试图以同等强度谈判每一条款。
将评估构建为可重复的流程
可扩展的评估工作流
将 AI 供应商安全评估作为每次重大 AI 采购的一次性项目进行的组织,所积累的机构知识无法有效地转移到后续评估中。将评估构建为可重复流程的组织,具有有据可查的方法论、标准证据模板和明确的决策标准,从而发展出一种能力,使每次评估都比上一次更快、更一致。
可重复的 AI 供应商安全评估流程包括:专门为 AI 供应商开发的、涵盖五个评估领域的标准化问卷;明确每项主要安全主张所需具体证据的文件请求清单;将评估发现转化为部署建议的评分或决策框架;让安全、法务、合规和业务职能中合适的利益相关者参与的审查流程;以及生成对内部治理和外部监管审查都有用的记录的文档标准。
问卷和文件请求清单应至少每年审查和更新一次,以纳入从供应商格局、监管环境以及组织自身部署经验中浮现的新 AI 特有安全考虑因素。十二个月前还很全面的评估工具,在 AI 安全威胁格局和围绕它的监管预期持续发展的今天,可能存在实质性差距。
超越初次采购的持续评估
在采购时进行的 AI 供应商安全评估提供了供应商安全态势的某一时间点评估。它无法持续保证,在供应商产品演进、其基础设施变化、其所有权或财务状况变化,或其技术栈中出现新的安全漏洞时,该态势仍然充分。
针对重要 AI 供应商的持续评估应包括:每年审查更新的认证和安全文档;审查来自供应商的任何安全事件披露或违规通知;评估对供应商服务条款或隐私政策的实质性变更,这些变更影响初次评估所审视的数据处理实践;以及审查对供应商 AI 产品、基础设施或所有权的任何重大变更,这些变更可能影响初次评估所基于的安全假设。
将 AI 供应商安全评估视为采购检查点而非持续关系管理实践的组织,会积累起其文档化的安全假设与供应商实际安全态势之间的渐进偏差,这使得事件发现相对于主动监控而言代价高昂。
需要了解的事项
随着组织计划的成熟,几个关于 AI 供应商安全评估的重要现实是它们持续遇到的:
评估范围需要与部署范围完全匹配。涵盖供应商企业 API 的安全评估,并不能为供应商的消费者产品提供保证。涵盖供应商文本生成产品的评估,并不涵盖其图像生成产品,即使两者都以同一品牌名称推出。明确定义所评估的特定产品、层级和部署配置,并确认所审查的每项认证和合同保护都涵盖该特定范围。
参考客户对话以文档审查无法复制的方式补充了文档审查。与已部署同一供应商 AI 产品的、规模、行业和监管概况相似的组织交谈,可提供有关供应商响应能力、实际数据处理实践与已记录实践对比,以及操作供应商关系的实际经验的定性洞察,这些都是文档审查无法捕捉的。
供应商财务稳定性是合法的安全评估维度。停止运营的 AI 供应商会造成数据可移植性、删除和审计跟踪挑战,这些挑战可能成为合规问题。评估供应商的财务健康状况、资金跑道和市场地位,对于正在考虑进行重大生产部署的 AI 供应商而言是恰当的,尤其是那些提取或训练的数据会创建持续依赖关系的供应商。
30% 原则适用于评估工作量分配。大约 30% 的评估工作量应用于技术安全领域,评估流程相对于其实际风险贡献而言最常对该领域过度投入。其余 70% 应涵盖数据治理、合同保护、AI 特有风险,以及揭示表面上认证看似相似的供应商之间最具意义的差异点的运营安全维度。
评估发现需要以风险术语而非技术语言传达给业务利益相关者。一项发现表明供应商的 SOC 2 审计范围不包括 AI 推理基础设施,在技术上是准确的,但若不转化为业务风险术语,对业务决策者而言并不可操作。供应商未独立核实将处理您最敏感数据的系统安全性这一发现,是以能够产生决策的语言表达的同一发现。
重新评估的触发条件需要事先定义。应在评估流程中定义、而非在事件发生时临时确定的、应触发新的或部分 AI 供应商安全评估的具体事件,包括重大供应商事件、服务条款的实质性变更、供应商收购或所有权变更,以及产品架构的重大变更。
AI 供应商安全评估作为竞争性选择工具
进行彻底 AI 供应商安全评估的组织持续发现,该流程不仅仅识别不可接受的供应商。它揭示了在认证和营销表面相似但在证据而非主张层面审视时实际安全实践存在显著差异的供应商之间的实质性差异化。
这种差异化在风险管理价值之外具有商业用途。投资于真正安全基础设施、维持当前且全面认证、运营透明数据处理实践,并支持受监管组织所需合同保护的供应商,已将安全打造为竞争性资产而非合规成本。通过严格评估识别这些供应商并与他们建立持久关系,所产生的采购成果在 AI 工具格局持续演进且安全要求持续收紧时,价值会复利增长。
AI 供应商安全评估是负责任的 AI 采用承诺与选择信任谁来处理最重要数据的运营现实相遇之处。彻底地、一致地、以其应有的证据标准开展这项工作的组织,所建立的供应商关系支持其 AI 抱负,而非创造不充分评估不可避免地遗留的未被发现的责任。
常见问题
如何评估 AI 供应商?
评估 AI 供应商需要在五个领域开展结构化评估:通过当前认证文件核实的技术安全控制措施;通过合同条款核实的、涵盖训练数据使用和保留的数据治理实践;通过实际报告而非供应商陈述核实的合规认证范围和时效性;包括提示注入控制和模型更新实践在内的 AI 特有安全考虑因素;以及涵盖供应商组织安全实践和事件历史的运营安全。 评估基于证据而非供应商主张产生部署决策,合同保护在任何组织数据流经供应商系统之前建立。
使用 AI 的安全评估是什么?
使用 AI 的安全评估是指应用人工智能工具来提高安全评估流程的效率和覆盖范围,包括使用 AI 分析供应商文档以查找与安全相关的条款,在多个供应商提交的文档中自动化问卷响应分析,持续监控供应商的安全披露和事件通知,以及识别人工审查流程会遗漏的供应商安全态势数据中的模式。 它与评估 AI 工具本身安全性的 AI 供应商安全评估有所不同,尽管具有成熟安全计划的组织越来越多地使用 AI 来增强其 AI 供应商评估流程和更广泛的安全评估能力。
什么是供应商安全评估?
供应商安全评估是在第三方技术提供商被授予访问组织数据的权限或被集成到业务系统之前,对其安全控制措施、数据处理实践、合规认证和合同保护进行的结构化评估。 具体到 AI 供应商,评估超越了传统供应商安全评估,以处理训练数据使用、推理基础设施司法管辖区、模型更新实践,以及标准 IT 供应商问卷在设计上未旨在揭示的 AI 特有攻击面等 AI 特有的风险。
可以采取哪些措施确保 AI 供应商是安全的?
确保 AI 供应商安全的五项最重要措施是:要求当前的 SOC 2 Type 2 或同等认证文件,涵盖正在部署的特定产品和基础设施;在任何组织数据被处理之前,获取已签署的、具有明确训练数据禁止条款和明确保留限制的数据处理协议;核实推理基础设施位于满足适用数据驻留要求的司法管辖区;通过合同条款和技术文档确认供应商的安全控制措施处理 AI 特有风险,包括提示注入和模型提取;以及建立持续的供应商监控流程,按已定义的年度周期审查认证续期、事件披露和服务条款的实质性变更。 这些措施共同建立了一种与 AI 供应商的安全关系,该关系建立在经核实的证据和可执行的义务基础上,而非未核实的主张和假定的善意基础上。
5 项安全措施有哪些?
适用于 AI 供应商关系的五项基础安全措施是:使用当前标准、具有有据可查的密钥管理实践,对传输中和静止状态的数据进行加密;限制供应商组织中谁可以在何种条件下访问组织数据的访问控制;对所有数据访问和处理事件的全面日志记录,保留期限支持事件调查;漏洞管理实践,包括定期安全测试和针对已识别漏洞的定义化的修复时限;以及违规通知流程,使供应商承诺及时披露,具有满足组织监管通知义务的具体时限。 这五项措施代表了技术安全基线,应通过证据为每个被评估承担重大数据处理责任的 AI 供应商进行核实,AI 特有的评估维度则叠加在此传统安全基础之上。
