资产清单先补全
除了业务系统，还要登记推理服务、模型网关、向量库、微调环境与密钥保管位置。这些资产常由业务团队自行开通，不在运维台账里，漏洞扫描与补丁自然也漏掉。先把资产摸清，后面的边界与日志才有落点。
边界与身份
模型接口统一走网关，做鉴权、限流与来源控制；接口密钥按系统发放、定期轮换、离职即回收，禁止写进前端代码。把密钥当前端配置是这类项目最常见的事故来源，一旦泄露，调用量与数据暴露同时失控。
日志与可追溯
记录调用方、模型版本、输入输出摘要与耗时，管理后台操作单独留痕，留存不少于六个月。日志要注意脱敏，避免把敏感输入原样落盘；同时保留会话标识，事件发生时能串起一次完整交互，而不是只看到一堆计数。
应急与降级
预案里写清模型不可用、被滥用、输出违规三类情形的处置：切换备用模型、限流熔断、人工接管与对外告知。演练时至少跑一次切换，确认业务能在没有模型的情况下继续运行，否则预案只是文档，真出事时没人敢按它执行。
供应链与内容处置
采购云服务与模型服务时核查安全评估与数据处理条款，把响应时限写进合同；发现违法信息要能停止生成、阻断传播并保存记录。涉及面向公众提供生成式服务的，备案与标识要求另行核对，申报主体是客户方。
适用与不适用
适合谁
- 正在把大模型接入对外服务的团队
- 自建推理服务或向量库、需要向安全团队说明的企业
- 需要向安全与法务说明 AI 资产的组织
不适合谁
- 仅做内部演示、没有对外接口的验证性项目
- 完全依赖单一外部服务且不碰企业数据的团队
典型场景
某企业的智能客服上线前做安全检查，发现推理接口直接暴露公网、密钥写在前端、调用日志只记录成功次数。团队把接口收进网关做鉴权与限流，密钥改为按系统发放并轮换，日志补上会话标识与脱敏。上线后一次异常调用被限流挡住，溯源到具体密钥并当天下线。
可执行步骤
- 补全智能应用资产台账，登记推理服务、向量库、微调环境与密钥位置，指定归属人
- 所有模型接口统一走网关，落实鉴权、限流与来源控制，关闭公网直连入口
- 密钥按系统发放，设定轮换周期与离职回收流程，禁止写入前端代码，按季度核查
- 补齐调用日志与管理操作日志，完成脱敏与留存设置，保留会话标识，保存期限达标
- 把模型不可用与输出违规两类处置各演练一次，记录切换耗时与卡点并归档
常见坑
- 密钥写在前端或配置文件里，泄露后调用量暴涨，费用与数据一起失控，事后只能整体重置，业务也被迫中断。
- 推理服务由业务团队自行开通、不进资产台账，补丁与扫描长期漏管，成了没人看的角落，风险越积越多。
- 日志把输入原样落盘，敏感信息二次泄露，等于把风险从业务系统搬到了日志服务器，一处变两处。
- 应急预案只写模型不可用，没写输出违规与人工接管，真出事时没人敢下决策，处置被拖延，只能临时拍板。
自检与验收清单
- 智能应用资产是否全部登记在台账，并纳入扫描
- 接口是否统一鉴权、限流并限制来源地址，关闭匿名访问
- 密钥是否有轮换周期、离职回收与泄露处置流程
- 调用日志是否脱敏，并满足不少于六个月的留存
- 应急演练是否覆盖模型不可用与输出违规两类情形
常见问题
调用大模型也要做等保吗？
看系统是否承载对外服务以及被破坏后的影响。承载业务、对外提供服务的系统通常要定级，模型只是其中一部分；定级对象是系统整体，不是模型本身。建议把 AI 功能纳入既有系统的定级与测评范围，而不是另起一套。
供应商说数据不落地，还需要自己留日志吗？
需要。供应商的承诺解决的是它那一侧的处理，企业仍要能说明谁在什么时候调用了什么、是否含敏感数据。日志可以只记摘要与标识，但缺了它，事件发生时既无法界定影响范围，也无法向监管说明处置过程。
提示注入算网络安全事件吗？
造成未授权访问、数据泄露或服务中断的，按事件处置流程走；仅输出不当内容、未造成实际影响的，按内容安全流程处理。两类流程的触发条件、上报口径与责任人不同，建议在预案里分开写，避免现场判断混乱。