4、事件分类与定级：给AI安全事故“画像”

说实话，接到告警的第一时间，你脑子里最该想的问题不是“怎么修”，而是“这到底是个什么事儿？有多严重？”

我个人的习惯是，先花30秒做个快速分类定级。别小看这30秒，它决定了你后续调多少人、用多大权限、要不要惊动老板。今天我们就聊聊这个“画像”的过程。

4.1 事件分类标准：先搞清楚“敌人”是谁

AI安全事件，说白了就三大类。我在项目中遇到过不少次，一开始看着像数据泄露，查到最后发现是模型被篡改——所以分类这事，得有点经验才能分得准。

4.1.1 数据泄露

这是最常见的一类。训练数据、用户隐私、模型参数被偷了。嗯，这里要注意：数据泄露不光是数据库被拖库，还包括通过模型推理接口“套取”训练样本。

• 典型场景：API返回了不该返回的原始数据、日志里出现了明文密码、模型被成员推断攻击
• 我踩过的坑：有一次，一个同事把带标签的训练集直接传到了公开的GitHub仓库，半小时内就被爬虫抓走了。从那以后，我要求所有训练数据必须走内部Artifact Registry。

4.1.2 模型篡改

这类事件更隐蔽，也更危险。攻击者改了你的模型权重、推理逻辑或者后处理代码。

• 典型场景：模型在特定输入下输出恶意结果、模型精度突然下降、模型文件哈希值对不上
• 避坑指南：我曾经遇到过模型被植入后门的情况——输入一个特定图案的图片，模型就输出“通过”。查了三天才发现是训练流水线被污染了。所以，模型签名验证一定要做。

4.1.3 服务中断

模型推理服务挂了、API超时、GPU集群被挖矿程序占满。这类事件影响最直接，用户马上就能感知到。

• 典型场景：推理服务OOM、GPU被恶意占用、模型加载失败
• 个人经验：有一次半夜三点，线上推理服务突然全部超时。查了半天，发现是某个开发把测试用的死循环代码部署到了生产环境。你想想看，一个for循环就能让整个集群瘫痪——所以代码审查和资源隔离真的很重要。

4.2 严重等级划分：P0到P4，别什么都喊“紧急”

我见过最夸张的情况，有人把UI按钮颜色不对也报成P0。结果真正出大事的时候，大家反而麻木了。所以，定级这事得有标准。

等级	定义	响应时间	举例
P0	核心服务完全不可用，或敏感数据大规模泄露	立即响应，15分钟内拉起应急小组	模型推理服务全挂、训练数据被公开泄露
P1	核心服务部分不可用，或少量敏感数据泄露	1小时内响应	某个模型接口返回异常、单个用户数据泄露
P2	非核心服务中断，或非敏感数据泄露	4小时内响应	模型监控面板挂了、测试环境数据泄露
P3	轻微影响，有临时解决方案	24小时内响应	模型推理速度变慢、日志告警误报
P4	不影响业务，可后续修复	下一个迭代修复	文档错误、非关键告警优化

4.3 影响范围评估：别只看表面

定完级之后，得评估影响范围。说白了，就是搞清楚“这事儿波及了谁、波及了多大面积”。

4.3.1 用户影响

• 多少用户受影响？是全部用户还是特定群体？
• 用户数据是否被泄露？泄露了哪些字段？
• 用户能否正常使用服务？有没有替代方案？

4.3.2 业务影响

• 核心业务指标（如推理成功率、响应延迟）下降了多少？
• 是否触发了合规要求？比如GDPR要求在72小时内报告数据泄露
• 有没有经济损失？比如广告收入、付费用户流失

4.3.3 技术影响

• 事件是否扩散到了其他系统？比如模型被篡改后，下游推荐系统是否也受影响？
• 是否需要回滚？回滚的代价有多大？
• 日志和证据是否完整？能不能支撑后续溯源？

4.4 实战小贴士：分类定级的“黄金30秒”

最后分享一个我自己的快速判断流程。收到告警后，问自己三个问题：

1. 数据有没有出去？——有，就是数据泄露类；没有，继续问
2. 模型行为有没有异常？——有，就是模型篡改类；没有，继续问
3. 服务还能不能用？——不能，就是服务中断类；能，那可能是个P3或P4的告警

定级的话，我习惯用“用户+数据+业务”三维打分。用户影响大、数据敏感、业务关键——三个维度里有两个高，基本就是P0或P1了。

嗯，分类定级这事，说白了就是给事件“画像”。画得准，后续响应就顺；画得偏，后面全是坑。多练几次，你也能做到30秒内给出初步判断。