# AI安全的"执行断层"：为什么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权限架构分析*