# 11.5 大语言模型安全成熟度模型

安全成熟度模型用于回答两个问题：**我们现在在哪里？下一步该做什么？** 它把零散的控制项组织成可评估、可对标、可规划的能力阶梯，帮助组织把“安全愿景”变成“落地路线图”。

> **为什么需要成熟度模型，而不是只看一个分数**
>
> AI 安全领域目前还没有一把可信的“安全计量器”：单纯优化某个安全/隐私基准分数（例如 SECURE、Priv-IQ、CAIBench 等），衡量的是模型在特定场景题目上的**表现（performance）**，并不等同于系统真实的**安全能力（competence）**。基准一旦公开就会污染到训练语料，分数会进一步失真。成熟度模型借鉴软件安全领域 BSIMM 的“二阶度量”思路——不直接给安全打分，而是评估**过程证据**：组织是否在合适的环节做了合适的保障活动。这种角度更能反映真实风险水位，也更难被单一分数误导。

## 11.5.1 成熟度维度（能力域）

建议至少从以下能力域评估 LLM 安全（这是作者定义的示例性成熟度模型，可映射到 `OWASP SAMM`、`NIST AI RMF` 等外部框架）：

| 能力域     | 关注点（示例）                |
| ------- | ---------------------- |
| 治理与合规   | 责任划分、审批流程、法规映射、证据留存    |
| 风险管理    | 威胁建模、风险评估、例外管理、变更评审    |
| 数据与隐私   | 数据分级、最小化、脱敏、日志策略、保留期   |
| 模型与供应链  | 模型来源验证、SBOM、依赖扫描、版本治理  |
| 应用与提示安全 | 系统提示基线、注入防护、上下文隔离、越权防护 |
| 工具与权限   | 最小权限、参数校验、操作确认、回滚与审计   |
| 监控与响应   | 监控指标、告警分级、事件响应、复盘改进    |
| 评估与红队   | 基准测试、回归门禁、红队演练、对抗样本库   |

## 11.5.2 五级成熟度（示例定义）

下面给出一个可直接落地的五级模型示例（L0-L4）。组织可把它映射到自身 OKR 与发布门禁，但不应把它误解为行业统一成熟度标准。第 11.8 节会补充 Agent 场景下的生产检查点，而不是再定义一套平行的成熟度等级。

| 等级     | 定义     | 典型特征                     |
| ------ | ------ | ------------------------ |
| L0 初始  | 基本无体系  | 依赖个人经验，缺少流程与证据           |
| L1 基线  | 有基本控制  | 有最小可行防线与准入，但不成体系         |
| L2 可重复 | 流程可执行  | 控制项可重复执行，有回归评测与审计留痕      |
| L3 可度量 | 指标驱动   | 有量化指标与门禁，能持续优化误报/漏报与体验成本 |
| L4 自适应 | 威胁驱动演进 | 结合威胁情报与红队持续演进，跨团队协同高效    |

**各等级能力域详细对照**

以“应用与提示安全”为例，展示从 L0 到 L4 的递进路径：

| 等级 | 能力特征                                | 典型工件              |
| -- | ----------------------------------- | ----------------- |
| L0 | 系统提示硬编码在代码中，无审核流程                   | 无                 |
| L1 | 有标准化系统提示模板；基础输入过滤（关键词黑名单）           | 提示模板文档、过滤规则清单     |
| L2 | 系统提示变更需审批；提示注入测试集可回归执行；有上下文隔离机制     | 变更审批记录、回归测试报告     |
| L3 | 注入成功率 < 5%（可量化）；误拒率 < 2%；指标异动触发自动告警 | 监控仪表盘、SLO 定义、告警记录 |
| L4 | 结合最新攻击情报自动补充测试集；多模态注入防护覆盖；跨团队持续红队   | 情报整合记录、红队闭环报告     |

**量化阈值说明**

上述表格中出现的量化阈值（如“注入成功率 < 5%”等）为建议性指标，基于行业最佳实践和作者经验，而非硬性标准。以下几点应当特别说明：

* **风险容忍度差异**：不同行业和应用场景的风险容忍度不同。例如，医疗诊断辅助系统和客服机器人对安全性的要求可能相差数个数量级。企业应根据自身业务需求、法规要求和风险评估结果调整这些指标。
* **起始基线和持续校准**：建议将这些指标作为起始基线，通过持续的红队测试和安全运营数据不断校准。即使初期无法达到目标阈值，建立“基准-监测-改进”的反馈循环同样重要。
* **多维度评估**：安全成熟度的评估不应仅依赖单一量化指标。应结合漏报率、误报率、响应时间、修复周期等多维度指标，形成更全面的安全画像。

## 11.5.3 各等级的“最小证据集”

成熟度评估要避免变成“写文档比赛”。建议为每个等级定义最小证据集：

**L1 基线**

* 输入输出过滤与脱敏策略文档
* 工具最小权限清单
* 最基本审计日志字段定义
* 系统提示模板及更新记录

**L2 可重复**

* 威胁建模记录（参照 STRIDE 或 AI-STRIDE）
* 发布前安全测试报告
* 例外审批记录（哪些风险被接受、由谁审批、有效期）
* 可回归的安全测试集（参见 [10.4 节](/ai_security_guide/di-san-bu-fen-fang-yu-pian/10_operations/10.4_red_teaming.md)）

**L3 可度量**

* 关键安全指标仪表盘（注入成功率 / PII 泄露率 / 系统提示泄露率 / 误拒率）
* SLO 定义与阈值告警记录
* 月度安全复盘报告
* 误报/漏报趋势分析

**L4 自适应**

* 红队演练报告与修复闭环证据
* 威胁情报订阅与策略更新联动记录
* 跨法域合规映射矩阵（如同时满足 GDPR + PIPL）
* 多团队协同安全评审机制文档

## 11.5.4 案例：从 L0 到 L2 的升级路径

**案例一：SaaS 创业公司的智能客服**

该公司将 LLM 集成到客户支持流程中，初始状态为 L0。

```
起点（L0）：
├── 系统提示直接 hardcode 在代码中，包含 API 密钥
├── 无输入过滤，用户可直接注入指令
├── 无日志记录，出问题后无法追溯
└── 开发者兼任安全审核

第一阶段（→ L1，2 周）：
├── 将 API 密钥移出系统提示，改用环境变量
├── 编写标准化系统提示模板，明确角色边界和拒绝规则
├── 部署基础关键词过滤（提示注入常见 Payload）
├── 添加请求/响应审计日志（trace_id, timestamp, user_id）
└── 产出：提示模板文档、过滤规则清单、日志字段定义

第二阶段（→ L2，1-2 个月）：
├── 引入提示注入检测模型（Meta Prompt Guard 或 LLM-as-Judge）
├── 构建 30+ 条安全回归测试集，纳入 CI 流程
├── 系统提示变更需经技术负责人审批
├── 建立安全事件响应流程（发现→评估→修复→验证）
└── 产出：回归测试报告、变更审批记录、事件响应 SOP
```

**案例二：金融科技公司的投研助手**

该公司为基金经理提供 LLM 驱动的研究报告分析工具，数据敏感度高。

```
起点（L1）：
├── 有基础的输入过滤，但只针对英文 Payload
├── RAG 知识库无内容审核流程
├── 工具调用权限按角色粗粒度划分
└── 安全测试依赖人工抽检

升级路径（→ L3，3-6 个月）：
├── 多语言注入防护（覆盖中英文 + 小语种绕过）
├── RAG 文档入库前增加安全扫描与来源标记
├── 工具权限细化到"操作 × 数据范围 × 时间窗口"
├── 部署安全指标仪表盘：
│   ├── 注入成功率 < 3%（SLO）
│   ├── PII 泄露率 = 0（硬性要求）
│   ├── 误拒率 < 1.5%
│   └── 指标异动 5 分钟内触发告警
├── 季度红队演练 + 自动化回归
└── 产出：指标仪表盘、SLO 定义、红队报告、审计矩阵
```

## 11.5.5 自评检查表

组织可使用以下快速检查表进行粗粒度自评：

```
L1 基线检查：
□ 系统提示中不包含任何密钥或内部 URL
□ 有基础的输入过滤机制
□ 有审计日志记录关键操作
□ 工具调用有权限控制

L2 可重复检查：
□ 系统提示变更需审批
□ 有可自动执行的安全回归测试集
□ 有威胁建模文档
□ 有安全事件响应流程

L3 可度量检查：
□ 有安全指标仪表盘且定期查看
□ 关键指标有 SLO 和告警
□ 定期进行安全复盘
□ 误报/漏报趋势可追踪

L4 自适应检查：
□ 威胁情报驱动策略更新
□ 定期红队演练且闭环修复
□ 多团队协同安全评审
□ 跨法域合规持续映射
```

## 11.5.6 评分与落地方式（建议）

**评估频率**：可按季度评估一次；对高风险业务线，也可以采用更高频率。这些都应视组织风险与资源情况而定。

**评分方式**：按“能力域 × 等级”给出达标/部分达标/不达标，并附证据链接或工单编号。

```mermaid
quadrantChart
    title 成熟度评估结果示例
    x-axis "低优先级" --> "高优先级"
    y-axis "低成熟度" --> "高成熟度"
    quadrant-1 "保持领先"
    quadrant-2 "持续提升"
    quadrant-3 "风险容忍"
    quadrant-4 "优先补齐"
    "治理与合规": [0.6, 0.7]
    "数据与隐私": [0.8, 0.5]
    "应用与提示安全": [0.9, 0.4]
    "工具与权限": [0.7, 0.6]
    "监控与响应": [0.5, 0.3]
    "评估与红队": [0.4, 0.2]
```

图 11-9：成熟度评估结果象限图（示例）

**落地策略**：优先补齐“高优先级 + 低成熟度”象限的能力域（右下角），先达 L1-L2，再追求全面的 L3-L4。

成熟度模型的价值在于形成共识：安全不是“做没做”，而是“做到什么程度、是否可验证、能否持续改进”。


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://yeasy.gitbook.io/ai_security_guide/di-si-bu-fen-zhi-li-yu-zhan-wang/11_governance/11.5_maturity_model.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.