# 3.3 行业安全标准与最佳实践

不同行业对 LLM 安全有着各自的要求和最佳实践。本节将汇总主要行业的安全标准，并介绍跨行业通用的安全实践。

## 3.3.1 金融行业

金融行业对 AI/LLM 的使用有严格的风险治理要求，主要关注模型风险、数据隐私、投资者与消费者保护。

**代表性参考文本（非穷尽）**

| 地区/机构         | 监管文件                                                             | 核心要求                               |
| ------------- | ---------------------------------------------------------------- | ---------------------------------- |
| 美国 SEC        | 2023 Predictive Data Analytics 提案（2025 已撤回） / 2025 AI roundtable | 投资者保护、利益冲突与 AI 风险讨论，但当前并非统一生效规则    |
| 美联储           | SR 11-7                                                          | 模型风险管理                             |
| 欧盟 EBA        | ML for IRB follow-up report                                      | 机器学习模型风险治理，以及与 GDPR / AI Act 的衔接讨论 |
| 中国国家金融监督管理总局等 | 金融数据与消费者保护相关规范                                                   | 数据安全、消费者保护、审慎治理                    |

**金融行业 LLM 安全要点**

* **模型验证**：在信贷、投顾、反欺诈等高影响场景，通常需要更严格的验证和独立审查
* **审计追踪**：保留足够的决策、数据和人工干预记录，满足审计与争议处理需要
* **偏见检测**：确保信贷决策等场景无歧视
* **人工监督**：对高风险自动化建议建立复核和申诉机制
* **数据隔离**：严格保护客户金融数据

```mermaid
flowchart TB
    subgraph "金融 LLM 安全架构"
    A["客户请求"] --> B["身份验证"]
    B --> C["权限检查"]
    C --> D["输入审核"]
    D --> E["LLM 处理"]
    E --> F["输出审核"]
    F --> G["合规检查"]
    G --> H["审计记录"]
    H --> I["响应返回"]
    end
```

图 3-3：金融行业流程图

## 3.3.2 医疗健康行业

医疗行业 LLM 应用涉及患者安全和隐私保护，但不同规则覆盖范围并不相同：HIPAA 面向 covered entities / business associates，FDA 的 AI/ML 与 CDS 指南主要针对医疗器械与特定软件功能。

**主要合规要求**

* **HIPAA（美国）**：保护患者健康信息
* **GDPR（欧盟）**：数据保护和隐私权
* **FDA 指南**：AI/ML 医疗设备与临床决策支持软件功能监管
* **中国数据安全法**：医疗数据分类保护

**医疗 LLM 安全要点**

* **临床验证**：涉及诊疗决策的高风险场景通常需要更严格的临床评估和验证
* **免责声明**：明确 AI 不能替代专业医疗建议
* **数据脱敏**：严格保护患者隐私信息
* **回答边界**：明确区分信息辅助、临床决策支持与直接诊疗建议
* **错误追溯**：可追踪错误信息的传播

**高风险场景的常见内控做法**

```
高风险场景：
├── 诊断建议 → 通常需要人工复核
├── 用药指导 → 高风险场景下仅提供参考，并引导就医
├── 心理健康 → 检测危机信号，提供热线
└── 急症处理 → 立即引导拨打急救电话
```

## 3.3.3 政府与公共服务

政府部门使用 LLM 需考虑公众信任、透明度、公平性，以及采购、部署和持续监控责任。

**代表性关注点**

* **透明与问责**：明确 AI 用途、责任主体和申诉路径
* **公平无歧视**：确保公共服务公平可及
* **影响评估**：对高影响用途进行评估、测试和持续监控
* **安全审计**：建立独立评估、事件记录和持续改进机制

**政务 LLM 的常见治理做法**

1. **分级管理**：根据敏感程度划分 LLM 应用等级
2. **采购与评估**：把模型能力、风险、监控和供应商责任纳入采购流程
3. **运行时监控**：对高影响系统实施持续测试、事件记录与独立评估
4. **人工兜底**：关键服务保留人工通道和申诉机制

## 3.3.4 教育行业

教育场景下的 LLM 使用涉及学术诚信、未成年人保护和学生数据隐私。美国语境下常见基线包括 FERPA / PPRA，英国教育部门近期 guidance 还特别强调 safeguarding、年龄限制、隐私与监控要求。

**核心关注点**

* **学术诚信**：防止滥用 LLM 进行作弊
* **内容适龄**：确保内容适合学生年龄
* **隐私保护**：保护学生个人信息
* **辅助而非替代**：LLM 作为学习辅助工具

**常见安全措施**

| 场景   | 风险        | 防护措施             |
| ---- | --------- | ---------------- |
| 作业辅导 | 过度代写与学术不端 | 引导式提问、过程性反馈与教师监督 |
| 内容生成 | 不适当内容     | 严格内容过滤           |
| 对话交互 | 隐私收集      | 最小化数据收集          |
| 评估反馈 | 偏见歧视      | 定期公平性审计          |

## 3.3.5 跨行业 AI 风险与管理标准：ISO/IEC 23894 与 42001

ISO/IEC 在 AI 治理方向上形成了两条相互配套的标准线：

* **ISO/IEC 23894:2023**（**2023-02-06** 发布）：在 ISO 31000 通用风险管理框架基础上，针对 AI 系统特有的风险（如算法偏见、模型漂移、自动化决策影响）提供识别、分析、评估与处置指南，是 AI 风险**指南类**标准。
* **ISO/IEC 42001:2023**（**2023-12-18** 发布）：首个 AI **管理体系**国际标准（AIMS），从组织层面规定治理、目标、控制、绩效评估与持续改进的可审计框架。

两者关系类似 ISO 31000 / ISO 27005 与 ISO 27001 的“指南 + 管理体系”组合：23894 解决“如何识别和处置 AI 风险”，42001 解决“如何在组织内建立可持续运行的 AI 治理体系”。

**ISO/IEC 42001:2023** 是全球首个 AI 管理体系国际标准。

**标准概况**

ISO/IEC 42001 为组织提供了一套系统化的方法来管理 AI 系统的风险和机会，帮助组织在治理、透明度、监督和持续改进之间建立统一管理体系。

**公开资料可确认的主题**

标准的主要管理要求包括：

* **AI 管理体系（AIMS）**：用管理体系方式覆盖 AI 的开发、提供和使用
* **风险与机会管理**：识别、评估并处理 AI 相关风险与机会
* **透明度与信息提供**：向相关方说明 AI 系统的能力、局限性和使用边界
* **监督与绩效评估**：建立监控、审计和持续改进机制

**与 ISO 27001 的关系**

ISO/IEC 42001 与现有的信息安全管理标准 ISO 27001 形成互补关系，可以有机集成到现有的信息安全管理体系中：

* **兼容性设计**：ISO/IEC 42001 的结构与 ISO 27001 相似，都采用 PDCA（Plan-Do-Check-Act）循环
* **共同的基础**：两个标准都要求建立政策、流程、监控和持续改进机制
* **集成实施**：组织可以整合两套标准的审核人员、文档和流程，降低管理成本
* **互补覆盖**：ISO 27001 侧重信息安全（机密性、完整性、可用性），ISO/IEC 42001 额外覆盖 AI 治理、透明度、监督和相关风险管理

**实施建议**

组织可以按以下步骤逐步建立 ISO/IEC 42001 合规体系：

1. **评估现状**：识别现有 AI 系统，评估与标准要求的差距
2. **建立管理框架**：制定 AI 治理政策和流程，明确角色责任
3. **实施管理体系**：在各部门推行标准要求，建立控制措施
4. **监控与测量**：持续监控 AI 系统表现，评估管理体系有效性
5. **持续改进**：根据审计结果和新出现的风险持续优化体系

## 3.3.6 企业通用最佳实践

无论哪个行业，以下最佳实践具有普遍适用性：

**安全开发生命周期（SDL）**

```mermaid
flowchart LR
    A["需求分析"] --> B["安全设计"]
    B --> C["安全编码"]
    C --> D["安全测试"]
    D --> E["安全部署"]
    E --> F["安全运营"]
    F --> A
```

图 3-4：企业通用最佳实践流程图

* **需求阶段**：识别安全需求，定义安全目标
* **设计阶段**：威胁建模，安全架构设计
* **开发阶段**：安全编码规范，代码审查
* **测试阶段**：安全测试，红队评估
* **部署阶段**：安全配置，最小权限
* **运营阶段**：监控告警，事件响应

**数据安全基线**

1. **数据分类分级**：明确不同敏感级别数据的处理要求
2. **访问控制**：基于角色的最小权限访问
3. **加密传输存储**：敏感数据全程加密
4. **审计追踪**：完整的操作日志记录
5. **数据生命周期**：明确数据保留和销毁策略

**第三方风险管理**

* 对 LLM 供应商进行安全评估
* 审查数据处理协议
* 监控供应商安全状况
* 制定供应商退出计划

**员工安全意识**

* 定期安全培训
* LLM 安全使用指南
* 事件报告机制
* 安全文化建设

## 3.3.7 合规检查清单

以下是企业 LLM 合规的快速检查清单：

```
□ 已识别适用的法规和标准
□ 已进行数据保护影响评估
□ 已实施数据最小化原则
□ 已部署输入输出安全控制
□ 已建立模型监控机制
□ 已制定事件响应计划
□ 已进行员工安全培训
□ 已记录安全决策和措施
□ 已安排定期安全评估
□ 已建立持续改进流程
```

行业标准和最佳实践是 LLM 安全的重要参考，但不应机械照搬。组织需要根据自身业务特点、风险偏好和资源条件，制定适合的安全策略。


---

# 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-yi-bu-fen-ji-chu-pian/03_frameworks/3.3_industry_standards.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.