制度：资产与准入
模型台账写清来源、许可、版本、责任人与用途；供应商准入要有安全条款与配合义务。台账不是给检查看的，而是在出事时能立刻定位到具体版本与数据，这一点在真实事件里价值最大，台账要能回答版本与授权两个问题。
流程：评测与灰度
选型后先做安全评测，覆盖越狱、注入、数据泄露与偏见四类；通过后小流量灰度，观察真实请求下的异常比例。跳过灰度直接全量，是把未知风险一次性放大，出了问题连对比基线都没有，灰度指标要事先约定。
技术：隔离与制品管理
模型文件放制品库，带哈希与签名；加载在隔离环境，禁外网、限文件写入；推理服务单独部署，不与业务系统共用主机。这些措施成本不高，但能挡住大部分供应链问题，性价比很高，隔离环境要能随时重建。
技术：网关与可观测
统一网关做鉴权、配额、审计与熔断，记录模型版本与路由。输出侧接护栏与抽样复核，监控漂移与异常输出比例，异常升高时能自动降级或切换，而不是等到用户投诉才发现，护栏策略要按租户区分。
边界：控制要能停
再好的防护也需要一个能立刻停下来的开关：停用某版本、切回上一版、关闭某类工具。上线前应演练一次停机，确认影响范围与恢复时间，否则出事时只能边排查边找办法，代价翻倍，开关要能在十分钟内生效。
适用与不适用
适合谁
- 自建推理服务或微调模型的企业，有运维能力
- 需要给模型上线定流程的平台团队
- 负责供应商准入与安全评审的部门
不适合谁
- 只做提示词配置、无模型资产的业务方
- 没有运维能力、也不打算建流程的小团队
典型场景
某物流公司的路径优化模型要换新版本。团队先在制品库登记哈希，隔离环境跑完四类评测，再用百分之五流量灰度一周，发现某个线路类型的建议偏差偏高，回滚后重新训练。整个过程有记录，复盘时能定位到具体数据切片。
可执行步骤
- 建立模型台账与供应商准入清单，逐项明确必填字段与责任人，由业务方签字。
- 为每次上线准备越狱、注入、泄露与偏见四类评测用例及通过标准，在工单里关闭。
- 模型文件统一入制品库，附哈希与签名，保留版本与变更记录，记录处理经过。
- 推理服务隔离部署，默认禁外网、限制文件写入与进程权限，标注截止日期。
- 由统一网关承担鉴权、配额、审计与熔断，日志按会话关联，按租户统计调用量。
- 演练一次版本停用与回滚，记录影响范围与实际恢复时间，在例会上过一遍。
常见坑
- 台账建好之后就不再更新，换了三个版本还写着最初那一个，等于从来没有建过台账，复核时对不上账。
- 评测只测功能不测安全，越狱、注入与泄露类用例一条都没写，报告好看但没什么用，旧问题被固化下来。
- 推理服务与业务系统同机部署，一处被攻破就全线受影响，而隔离的投入其实很小，出事时找不到源头。
- 没有版本停用开关，出事时只能重启整台机器，影响面被无谓地放大了不止一倍，影响面会持续扩大。
自检与验收清单
- 模型台账是否字段完整并随版本更新，含版本号
- 每次上线是否有四类安全评测与明确的通过标准
- 模型文件是否入制品库并附哈希与签名，可验签
- 推理服务是否隔离部署并限制外网，默认禁外网
- 是否演练过版本停用与回滚并记录时间，含恢复时间
常见问题
护栏模型必须自建吗？
不一定。可以用供应商提供的内容审核能力，但要评估其覆盖范围、误拦率与调用延迟，并保留人工复核通道。完全依赖单一护栏，遇到新手法时容易集体失效，人工复核要保留。
灰度多久合适？
看请求量与风险等级，通常以覆盖足够样本、能观察到异常比例为准，而不是固定天数。灰度期间要有明确的观察指标与回滚条件，否则只是拉长了上线时间，看异常比例是否收敛。
开源模型也要做供应商准入吗？
要，只是对象变成托管源与镜像仓库。需要确认来源可信、文件未被替换、许可证允许使用，并记录下载时间与哈希，便于后续追溯，这些步骤通常半小时就能完成，下载记录也要留存。