误解一：开源等于可控
权重可见不等于链路可控：依赖库、加载脚本、插件与遥测都可能带来风险，许可证还可能限制商用。可控的前提是来源可核、制品可管、运行环境隔离。三者缺一，所谓「可控」就只是对权重文件的心理安慰。
误解二：备案等于安全
备案是服务准入，证明你按要求提交了材料，不证明模型在真实攻击下稳。上线后的版本管理、评测与事件响应才是安全的主体，也是检查时最容易被追问的部分，更不是一次性的验收动作，要在评审时说清。
误解三：本地部署等于不泄露
本地部署解决数据不出域的问题，但解决不了内部越权、日志外带与人为导出。数据在本地被批量拉走，比出境更难被发现，因为没人会去查一条从未出过内网的流量，内部导出审计往往最缺，实际影响往往更大。
误解四：测过一次就够
模型换版、数据更新、工具增减都会改变行为。没有回归机制，一次测评的结论很快过期，而团队往往还以为在保护期内。这种认知差比没有测评更危险，评测用例必须跟着模型版本一起更新，否则形同虚设。
边界：安全是概率与成本的平衡
不存在绝对安全的模型，只有可接受的风险水平与可发现、可止损的机制。把这句话写进评审材料，比给一个「已达标」的结论更经得起追问。机制写清楚，后来接手的人才知道边界在哪，也才知道出了事该找谁。
适用与不适用
适合谁
- 对模型安全理解偏乐观的管理层与业务方
- 准备上线自建模型的项目团队，要有评测计划
- 需要向客户解释安全能力的售前与法务
不适合谁
- 完全不使用模型的传统系统项目，无模型资产
- 希望得到绝对安全承诺的采购方，不愿共担风险
典型场景
某公司在投标答辩时被问到模型安全措施，回答是「我们用开源模型，本地部署，很安全」。评委追问许可证、版本管理与越狱测试，三项都答不上来。会后团队补了台账与评测记录，下一次答辩改为按来源、运行、评测、响应四段说明。
可执行步骤
- 收集内部常见的四条判断，逐条写清成立条件与失效场景，由法务确认口径。
- 核对开源许可证与依赖清单，确认商用、分发与署名条件，写进岗位交接单。
- 检查本地部署下的导出通道、日志外带与内部越权风险，按任务逐个授权。
- 建立版本或数据变更即触发复测的回归机制，复测结论统一归档，归档到模型台账。
- 把可接受风险水平与止损机制写进对外说明与答辩材料，列入上线检查表。
常见坑
- 把开源当成免检理由，依赖库与加载脚本的风险完全没有查过，出了事只能临时补救，跨部门协调成本很高。
- 以为备案完成就万事大吉，上线后既没有评测也没有版本记录，问到细节就答不上来，检查时很难解释清楚。
- 本地部署后放松了内部权限，数据被批量导出很久都没人察觉，日志也没开，等发现时已经晚了，日志也没留。
- 对外承诺绝对安全，一旦出事，解释成本远高于技术问题本身；客户会拿这句话质疑全部材料，后续很难补救。
自检与验收清单
- 是否逐项核对过模型的许可证、依赖来源与商用限制
- 本地部署下的导出通道与日志是否受控，含导出审计
- 是否有版本或数据变更即复测的机制，含复测范围
- 对外表述是否说明风险水平，而非承诺绝对安全
- 是否有止损开关并做过一次演练，含演练记录与结论
常见问题
开源模型能通过安全测评吗？
能不能通过取决于测评标准与使用场景，开源与否不是决定因素。开源的好处是可核查、可改造，代价是要自己承担依赖、许可与运行环境的全部责任，测评范围要写清，别等上线再讨论。
客户要求提供安全证明怎么办？
提供可核查的材料：模型台账、评测报告、隔离部署说明、日志与应急方案。比一纸承诺更有说服力，也便于对方判断是否满足其场景要求，谈起来也更有底气，材料要能对应版本。
内部模型也要做越狱测试吗？
建议做。内部用户同样会试探边界，且内部权限更大，一次越狱可能读到跨部门数据。测试重点应放在数据范围与工具权限，而不只是内容合规，重点看检索范围与工具，值得单独写一条。