定级对象是系统
AI 功能通常作为既有系统的一部分参与定级，而不是单独定级。要判断的是加了模型之后，系统被破坏的影响是否变化：如果开始处理更多个人信息或对外提供生成服务，影响面可能上升，级别与边界都要重新评估并留档。
推理集群的边界
推理服务常以容器或独享实例部署，容易被当成开发环境而漏掉边界控制。清单要写到网络分区、访问白名单、管理端口不对外、镜像来源可溯；训练环境与生产环境分开，避免一次调试把未加固的服务暴露出去。
模型后台的身份
模型管理后台能改提示词、开关功能、导出日志，权限比普通业务账号更高。要求强认证、按角色分权、操作留痕，密钥与令牌单独保管；把后台当普通管理系统对待，是这类项目最常见的权限缺口。处置也快得多。
审计与管理中心
调用日志、管理操作日志、训练任务日志要接入统一审计，时间同步、留存达标、可检索。等保看的是能不能还原一次操作，而不是日志量；训练任务的启动人、数据集版本与产物去向同样要记录，否则无法追溯。
供应链与变更
模型、推理框架与依赖组件要进软件物料清单，漏洞有跟踪与响应时限；模型版本更新走变更流程，更新前评估对输出与安全控制的影响。测评关注的是有没有机制，而不是某一次升级做得多规范。
适用与不适用
适合谁
- 正准备把大模型接入业务系统的项目组
- 自建推理集群或向量库、需要定级的企业
- 需要把 AI 功能并入既有等保范围的团队
不适合谁
- 仅做离线试验、不接业务数据的项目
- 完全使用外部服务且不承担系统运维的团队
典型场景
某企业的知识助手要接入内网门户，最初被当成一个新应用单独定级。安全负责人改为并入门户系统统一评估，补上推理集群的网络分区、模型后台的角色分权与调用日志接入，训练环境与生产环境分开。测评时 AI 部分只被提了两处整改，都在两周内关闭。
可执行步骤
- 判断 AI 功能是否改变既有系统的定级影响面与边界，先做一次完整的影响分析
- 给推理集群划网络分区，管理端口不对外，镜像来源可溯，日志单独留存并脱敏
- 模型后台按角色分权、按最小权限授予，操作留痕并接入统一审计，定期复核角色
- 把模型、推理框架与依赖组件纳入软件物料清单，并随每次版本更新清单
- 模型版本更新走变更流程，更新前做影响评估与回滚预案，回滚演练一次
常见坑
- 把推理服务当开发环境，安全组开放过大，管理端口对公网可见，成了最薄弱的入口，也是最容易被忽视的。
- 模型后台与业务系统共用账号，谁改了提示词说不清，出问题只能整体回滚，事后排查要花很久，只能先整体停用。
- 训练数据与生产数据放在同一存储桶、权限一致，一次误操作就可能污染训练集，恢复也很麻烦，清理成本很高。
- 模型升级不走变更流程，输出风格突变引发业务投诉，却查不到是哪次更新导致的，只能事后猜测。
自检与验收清单
- AI 功能是否纳入既有系统定级评估，并把边界写清楚
- 推理集群是否做网络分区与端口收敛，无公网入口
- 模型后台是否角色分权并留操作日志，可追溯到人
- 模型与依赖是否进物料清单并跟踪漏洞，有响应时限
- 模型更新是否走变更流程，有回滚预案，演练过回滚
常见问题
只调用外部模型接口，也要纳入等保吗？
要看你承担的控制项。系统整体仍要定级，调用外部接口属于供应链与边界管理的一部分，需要评估供应商资质、数据传输与接口鉴权。把外部调用排除在系统边界外，往往在测评时被要求补充说明。
向量库需要单独定级吗？
通常作为系统组件纳入同一定级对象，除非它独立对外提供服务、影响面明显不同。关键是边界要画清：向量库存储的往往是切片后的业务文本，敏感度可能不低于原系统，访问控制与审计不能省。
模型效果不好算不算等保问题？
不算。等保关注的是安全控制项，不评价模型准确率。但如果输出错误导致越权信息展示或数据泄露，就落入访问控制与数据保护的范畴；建议把输出过滤与权限校验分开设计，别用效果优化替代安全控制。