一家公司的备份服务器，每天凌晨3点都会产生大量流量。如果AI监控系统只看"流量突然增大"这一个指标，很可能把这个每天都会重复发生的正常动作，判定为异常。
正常业务也会产生"异常"数字
在真实的业务上下文中，凌晨3点的大流量其实是例行备份，是一件完全正常、甚至值得依赖的事情。如果系统因为这条判断触发了自动断网，反而会打断正常的备份任务，造成不必要的业务影响。这类"统计意义上的异常，业务意义上的正常"情况，在企业网络里其实相当常见。
反过来，真正的攻击可能毫不起眼
与"备份流量"相反的情况同样存在：一次真正的数据窃取行为，攻击者完全可以把数据拆分成很多次小额传输，每一次单独看都远低于会触发流量告警的阈值。如果安全系统只依赖"流量是否够大"这一个信号，这种缓慢、分散的攻击手法反而完全不会被察觉。
ANOMALY ≠ ATTACK
这两个例子共同说明一件事：统计上的异常（Anomaly）和真正的攻击（Attack）不是一回事。需要额外结合的判断维度包括：
- TIME 时间：这个行为发生的时间点，是否符合该业务/用户的历史规律。
- DEVICE 设备：发起行为的设备是否是已知的、常规使用的设备。
- USER 用户：涉及的账号身份，以及该账号是否有理由执行这类操作。
- HISTORY 历史：类似的行为模式此前是否反复出现过。
- DESTINATION 目标：数据或连接指向的目的地是否可信。
- PROCESS 关联进程：发起这次行为的具体程序是否是已知、合法的应用。
AI安全最容易犯的错
把"没见过"直接等同于"有攻击"，是AI安全系统最容易犯的一类错误——因为"没见过"在统计模型上很容易识别，而"这是不是攻击"需要更多业务上下文才能判断。设计告警规则和自动响应策略时，如果只依赖单一维度的异常检测，很容易在"漏掉真正的攻击"和"频繁误伤正常业务"这两个极端之间反复摇摆。更稳健的做法，是让异常检测的结果作为需要进一步核查的起点，而不是直接触发断网这类高影响力的自动操作，具体的响应层级设计见AI开始替安全人员执行响应以后。