Jacky CaiAI安全的"执行断层"：为什么70%的公司知道该做什么，但只有26%能做到
上周在内部讨论会上，我提了一个问题：“你们的AI安全策略是什么？”
在场12个安全负责人，10个能说清楚。再问第二个问题：“你们的架构能执行这个策略吗？”
沉默。
这不是他们的问题。这是2026年整个行业的通病。
一组让人不舒服的数据
Check Point 今年的[[checkpoint-2026-cloud-security-report|云安全报告]]给了几组数字，我反复看了好几遍：
- 70% 的组织在生产环境跑了GenAI
- 64% 已经部署了AI Agent
- 77% 更新了安全策略应对AI风险
- 但只有26% 的架构有能力执行这些策略
51个百分点的差距。策略写了，架构接不住。
Okta 的调查补了另一刀：
- 90% 的高管对AI可见性充满信心
- 95% 相信员工在用AI时是负责任的
- 但52% 的员工承认在用未授权的AI工具
- 58% 的组织在过去一年经历过AI安全事故
高管觉得没问题，员工在偷偷干，安全团队夹在中间。
这不是"安全意识不够"的问题。这是执行断层（Execution Gap）。
执行断层是怎么形成的？
我拆了三层原因：
第一层：策略是文本，架构是代码
安全策略写起来太容易了。“所有AI应用必须经过安全评审”——一行字。
但架构上要做到"所有AI应用必须经过安全评审"，你需要：资产台账 → 自动发现 → CI/CD 卡点 → 运行时监控 → 异常阻断。每一环都要工具、要流程、要人。
策略是一维的，架构是多维的。用一维的文本去指挥多维的系统，必然漏。
第二层：工具采购和架构能力不是一回事
很多公司遇到AI安全问题的第一反应是"买工具"。买了个AI安全网关，买了个模型扫描器，买了个数据防泄露。
但工具是单点的。架构能力是工具之间的连接和编排。
你能识别敏感数据（工具），但你能不能阻止Agent把它发出去（架构）？[[AgentScope|AgentScope]] 的权限上下文机制做了一件有意思的事——它不是加一个"安全开关"，而是在Agent框架层面嵌入权限层，每个操作都走权限判断。这是架构思维，不是工具思维。
[[Microsoft RAMPART]] 也是这个路子：把安全测试嵌入CI，变成工程流程的一部分，而不是一个单独的"安全扫描阶段"。
单点工具堆不出架构能力。
第三层：管理层和干活的人看到的是两张图
Okta的数据很典型：90%的高管觉得"我掌控了"，但52%的员工在用未授权的工具。
高管看到的是PPT上的策略框架。一线看到的是"用ChatGPT干活快，IT没说不让用"。
这不是谁对谁错的问题。这是信息不对称导致的两张图。高管不知道员工在用什么，员工不知道公司的安全策略是什么（Okta：65%的高管觉得策略"非常清晰"，但57%的员工不同意）。
一个诊断框架：AI安全执行断层四维模型
既然问题出在"知道该做什么"和"能做到什么"之间的差距上，那我们需要一个能测量这个差距的工具。
我提一个自己的框架，AI安全执行断层四维模型（AI Security Execution Gap Quadrant），四个维度评估组织的架构就绪度：
维度一：可见性（Visibility）
能不能看清AI资产的全貌？
| 级别 | 状态 | 判断标准 |
|---|---|---|
| L0 | 盲区 | 不知道公司有多少AI应用 |
| L1 | 台账 | 有手工维护的AI应用清单 |
| L2 | 自动发现 | 有自动扫描发现AI资产的能力 |
| L3 | 持续监控 | 能实时感知AI资产的变更和新增 |
Check Point说只有5%有完整可见性，大部分在L0-L1之间。
维度二：控制力（Control）
策略能不能落到架构层面执行？
| 级别 | 状态 | 判断标准 |
|---|---|---|
| L0 | 无控制 | 没有AI安全策略 |
| L1 | 文本策略 | 有书面策略，但靠人工执行 |
| L2 | 工具辅助 | 买了安全工具，但未嵌入流程 |
| L3 | 架构嵌入 | 安全控制嵌入开发、部署、运行全流程 |
77%更新了策略，但只有26%有架构能力——大部分在L1-L2。
维度三：响应力（Response）
出了问题能不能快速发现和处置？
| 级别 | 状态 | 判断标准 |
|---|---|---|
| L0 | 无响应 | 出了事不知道 |
| L1 | 事后追溯 | 出事后能查日志找原因 |
| L2 | 实时告警 | 有实时监控和告警 |
| L3 | 自动阻断 | 能自动阻断异常行为并回滚 |
58%经历了安全事故——大部分连L1都没到。
维度四：治理闭环（Governance）
策略→执行→审计→改进，能不能转起来？
| 级别 | 状态 | 判断标准 |
|---|---|---|
| L0 | 无治理 | 什么都没有 |
| L1 | 一次性 | 做过一次风险评估，没有后续 |
| L2 | 周期性 | 定期安全评审和更新 |
| L3 | 持续改进 | 安全治理嵌入日常运营，有量化指标 |
只有14%在积极执行和审计AI安全策略。
怎么用？
每个维度打分（0-3），四维加总得一个AI安全执行断层指数：
- 0-4分：断层严重，先解决可见性问题
- 5-8分：有基础但控制力不足，重点做架构嵌入
- 9-11分：架构基本就绪，打磨治理闭环
- 12分：架构和能力匹配，保持
这个指数不一定精确，但比"我感觉还行"要靠谱。目标是让每个安全负责人能说清楚"我在哪"而不是"我觉得我在哪"。
三步缩窄断层
1. 先做资产盘点，别跳步
Check Point报告的5个行动建议，第一条就是"建立AI资产清单"。听起来简单，但大部分公司连这个都没做。
没有清单，后面的可见性、控制力、响应力全是空中楼阁。
2. 策略和架构一起写
策略负责人和架构负责人坐在一起。策略每写一条，架构就得回答"怎么落地"。落不了的就拆、改、或者暂缓。
不要等策略写完了再扔给架构团队。那时候发现的断层已经晚了。
3. 从"安全门禁"转向"安全流程"
传统的安全思维是"加一道门"——安全评审、安全扫描、安全审批。但AI的变化太快了，门根本不够用。
RAMPART的做法值得借鉴：把安全测试变成CI流程的一部分，每次部署自动跑。不是"上线前安全审一下"，而是"不安全就部署不上去"。
这不是工具的问题，是流程设计的思维转变。
AI安全的执行断层不是一个人的问题，是整个行业的结构性矛盾。你在哪一层？欢迎评论区聊聊。
数据来源：Check Point 2026 Cloud Security Report, Okta AI Agents at Work 2026 Survey, OWASP AI Security图谱, AgentScope权限架构分析