大模型安全评估若等到合同签订、应用接近上线时才开始，常见结果是风险发现了，却没有人能确认由谁修复、谁给予证据、修复后谁复测。采购门槛应在候选范围确定时就写清测试对象、风险分级和责任关系，让安全结论能够影响选型与交付，而不是成为项目末期的一份附加报告。

边界说明：本文讨论模型、数据、工具和平台相关的安全采购证据，不把一次技术测试写成法律或行业合规结论。

采购前先定义安全评估到底覆盖什么

“大模型安全”可能指模型输出风险，也可能包含数据访问、提示攻击、工具调用、接口滥用、运行环境和审计能力。若招采文件只写“顺利获得安全评测”，供应方、集成方和企业会按各自理解准备，最终报告很难比较。

可以按四类对象拆范围。模型输出关注不当内容、无依据回答、拒答和边界行为；数据层关注输入、知识和日志的授权、隔离与最小化；工具层关注参数、权限、副作用与人工确认；平台层关注身份、接口、策略、日志和运行控制。每一类都要说明本次测试包含什么、排除什么。

范围还应绑定应用场景。通用对话、内部知识问答、代码辅助和可执行Agent面对的风险不同。没有工具权限的问答应用，不需要假设它能执行写操作；能够调用业务系统的Agent，则不能只测试输出文本。场景决定攻击面，也决定哪些证据必须由企业给予。

采购方应准备业务风险说明、允许使用的数据和测试环境；供应方说明交付版本、可配置控制和已知限制；集成方说明提示、检索、网关与工具链改造。三方输入明确后，测试才能真正对准交付对象。

风险分级要直接对应采购动作

评测结果不能只按高、中、低列问题，还应规定每一级对应什么动作。阻断类风险要求修复并复测，未完成前不得进入下一阶段；限制类风险可以顺利获得关闭能力、缩小用户范围或增加人工确认控制；观察类问题进入监控和后续复盘。

分级依据应结合影响、可利用条件、暴露范围和现有控制。一个需要内部高权限且只能在隔离环境触发的问题，与普通用户可重复触发的数据越权不能采用同一处理方式。评分可以辅助排序，但不能让多个低风险项平均掉一个明确的阻断项。

以下字段适合进入风险记录：

• 受影响的场景、版本和功能范围
• 复现前提、步骤与必要的受控证据
• 可能影响的数据、系统或用户角色
• 已有控制、临时缓解与剩余风险
• 修复责任人、目标状态和复测条件
• 未验证区域与结论有效期

风险记录不得包含不必要的敏感攻击数据、真实凭证或生产细节。需要保密的复现材料可放在受控系统中，采购附件只保留标识、责任和结论。

责任矩阵要覆盖发现、修复与复测

风险责任不是简单地分给“模型厂商”。基础模型行为、私有部署环境、检索数据、提示设计、网关策略和工具权限可能由不同主体控制。责任矩阵应沿着“谁能改变该对象”来划分，并说明谁负责给予证据和验证效果。

供应方通常需要对交付版本、产品配置、已知限制和其控制范围内的修复负责；集成方对自建提示、检索、接口转换和工具编排负责；企业对数据授权、用户权限、业务规则、风险接受和运行流程负责。具体项目可以不同，但不能出现三方都认为对方负责的空白区。

责任还要覆盖复测。修复由一方完成，不应默认由同一方单方面宣布顺利获得。采购方或约定的独立评审角色应根据原始问题、修复版本和测试条件复验。若风险顺利获得限制功能缓解，复测需要确认限制确实生效，并且用户无法绕过。

平台能力可以降低风险，却不能替代企业的数据和业务责任。 采购决策应关注控制是否可配置、可验证和可审计，而不是要求供应方承诺消除所有风险。

安全证据要能对应到具体版本和控制

一份安全报告若没有版本、环境和配置范围，很快就会失效。模型服务升级、系统提示变化、知识库接入、新工具上线或网关策略调整，都可能改变攻击面。每条结论应关联被测版本和关键配置，并记录哪些外部依赖没有进入范围。

证据可以包括测试样本标识、请求与结果、策略命中记录、权限判断、审计事件和复测结论。原始内容的保存要遵守数据最小化；采购评审需要确认的是风险可复现、控制可验证、责任可追踪，并非复制所有敏感文本。

对于自动化安全扫描，应保留规则版本、覆盖对象和误报处理。人工红队或场景测试则要记录测试角色、授权范围、停止条件和异常上报路径。未经授权的生产测试不应成为采购评估手段。

在模型、提示、工具和数据控制方面，可以结合 AI应用安全治理 梳理对象。采购门槛需要进一步把这些对象映射到候选交付版本、责任方和可复核证据。

把安全条款写成可验收交付物

合同或技术附件不宜只写“满足安全要求”。更可执行的表达包括：给予哪些版本和配置说明；完成哪些已确认场景的测试；交付哪些风险、修复和复测记录；重大变化如何通知；上线后发现问题如何分流和响应。

未覆盖项也要写入。某些第三方模型能力、外部数据源、企业自建工具或生产网络不在供应范围内，应明确由谁在后续阶段补测。范围排除不是免责口号，而是为了防止采购结论被错误外推。

长期服务边界可以参考 AI平台采购评估 的技术验证与运营责任框架。安全部分还应增加漏洞或重大风险通知、配置变更影响、复测触发条件和证据保留责任。

采购验收可以输出四类材料：范围与责任矩阵、风险清单、修复与缓解记录、复测和剩余风险确认。所有材料指向同一交付版本，后续版本变化时按约定触发差异评估，而不是永久沿用一次测试结论。

常见误区是把安全分数当成单一门票

统一分数便于比较，却可能掩盖风险性质。一个候选在大量普通样本中表现稳定，但在特定越权场景中存在明确问题，不能顺利获得平均分抵消。采购门槛应保留阻断项和场景限制，再把汇总分用于趋势或候选排序。

另一个误区是只测模型输出，不测集成后的权限和工具。生产应用的风险往往来自组合：模型提出动作、Agent代用户调用工具、工具使用过宽权限，最终造成副作用。每个单点看似正常，链路仍可能越权。

还有一种误区是把安全报告当成供应方承诺。企业对数据、账号、业务流程和风险接受仍负有责任。安全评估的作用是让责任和剩余风险透明，而不是创造“购买后天然安全”的结论。

如何开始第一轮采购安全评估

选一个实际应用，画出模型、数据、工具和平台四类对象，标出供应方、集成方和企业各自能改变什么。挑选正常、边界、越权和异常依赖场景，先确认授权和停止条件，再执行测试。完成后不要只给风险分数，要为每个问题确定动作、证据、责任与复测，并把未覆盖项写入采购附件。

常见问题

大模型安全评估能否直接证明满足合规要求？

不能。技术安全评估可以给予风险、控制和测试证据，但合规判断还取决于适用法律、行业要求、数据类型、处理目的、组织流程和责任安排。不同企业和场景适用边界不同，一次模型或平台测试无法替代完整的合规审查。

更准确的做法是让技术评估为合规审查给予事实：数据如何进入系统、谁能访问、哪些控制已验证、日志如何保留、哪些风险仍存在。合规和法务角色再结合实际制度做判断。报告中应避免“天然合规”“保证顺利获得”等表达，并清楚标注版本与范围；当用途、数据或部署方式改变时，还要重新确认原结论是否继续适用。采购附件应分别列出技术覆盖、未覆盖要求和专业审查责任；证据只对应某个版本或场景时，结论不得外推到其他用途。

采购方没有安全测试团队怎么办？

可以引入具备相应能力的内部安全团队、集成伙伴或独立服务方，但采购方仍要掌握范围、风险接受和最终放行责任。完全把测试目标交给供应方，容易只覆盖其熟悉或有利的场景；完全依赖通用扫描，也难以反映企业业务与数据风险。

第一轮可以从少量高风险场景开始，要求测试方法、证据和复测可交接。企业至少要指定业务、数据和技术责任人，确认哪些行为不可接受。外部团队负责执行并不意味着责任转移，合同中还应说明敏感材料处理、授权边界和问题披露方式。验收时让内部责任人独立复核一条问题，确认交付材料足以接管。最低证据应包括授权范围、测试版本、问题复现和整改复测；缺少任何一项，都不宜把外部报告直接作为采购放行依据。

模型或提示更新后是否要重新做完整安全评估？

不一定每次都完整重做，但需要差异评估。先判断变化涉及模型行为、系统提示、知识数据、工具权限、网关策略还是运行环境，再选择受影响场景回归。高风险工具、数据权限或重大模型版本变化通常需要更严格复测；低风险文案调整可采用较小范围验证。

差异评估应记录变化对象、影响假设、选取的测试集和未复测部分。若无法判断影响，宁可扩大验证范围，也不要无依据沿用旧结论。每次更新还应确认原有缓解措施仍然有效，尤其是依赖配置、规则或人工流程的控制。复测结论要绑定新版本，并明确旧报告从何时起不再适用。可以用变更影响矩阵决定深度；新增数据域、工具写权限或外部用户时，应直接升级为重点场景复测。