> For the complete documentation index, see [llms.txt](https://yeasy.gitbook.io/claude_guide/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://yeasy.gitbook.io/claude_guide/di-si-bu-fen-shi-zhan-pian/11_safety/11.6_compliance.md).

# 11.6 企业级合规与审计

在企业环境中落地 LLM 应用，最大的阻碍往往不是技术，而是合规（Compliance）。本节将梳理数据脱敏、审计日志和隐私保护三大核心领域的实践方案。

## 11.6.1 数据脱敏

在将数据发送给 Claude API 之前，必须剥离任何可识别个人身份信息 (Personal Identifiable Information, PII)。这是满足 GDPR、CCPA 等隐私法规的基本要求。

### 常见 PII 类型

| 类型    | 示例            | 风险等级 |
| ----- | ------------- | ---- |
| 直接标识符 | 姓名、身份证号、手机号   | 🔴 高 |
| 准标识符  | 出生日期、邮编、职位    | 🟡 中 |
| 敏感数据  | 银行卡号、医疗记录、薪资  | 🔴 高 |
| 位置信息  | 具体家庭住址、GPS 坐标 | 🟡 中 |

### 脱敏方案

根据安全需求，可选择不同级别的脱敏策略：

**方案一：正则替换（轻量级）**

在代码层使用正则表达式将敏感信息替换为占位符：

```python
import re

def sanitize_pii(text: str) -> str:
    # 手机号脱敏
    text = re.sub(r'\b1[3-9]\d{9}\b', '[PHONE]', text)
    # 身份证号脱敏
    text = re.sub(r'\b\d{17}[\dXx]\b', '[ID_CARD]', text)
    # 邮箱脱敏
    text = re.sub(r'[\w.+-]+@[\w-]+\.[\w.]+', '[EMAIL]', text)
    return text
```

**方案二：Microsoft Presidio（企业级）**

使用开源工具 Microsoft Presidio 自动识别和脱敏文本中的实体：

```python
from presidio_analyzer import AnalyzerEngine
from presidio_anonymizer import AnonymizerEngine

# 注意：默认的 AnalyzerEngine 只带英文 NLP 模型，直接传 language="zh" 会报错；
# 中文需要先用 NlpEngineProvider 配置中文模型（如 spaCy 的 zh_core_web_lg）
from presidio_analyzer.nlp_engine import NlpEngineProvider

nlp_engine = NlpEngineProvider(nlp_configuration={
    "nlp_engine_name": "spacy",
    "models": [{"lang_code": "zh", "model_name": "zh_core_web_lg"}],
}).create_engine()
analyzer = AnalyzerEngine(nlp_engine=nlp_engine, supported_languages=["zh"])
anonymizer = AnonymizerEngine()

# 分析文本中的 PII
results = analyzer.analyze(text="张三的手机号是13800138000",
                           language="zh", entities=["PHONE_NUMBER", "PERSON"])

# 自动脱敏
anonymized = anonymizer.anonymize(text="张三的手机号是13800138000",
                                   analyzer_results=results)

# 输出: "<PERSON>的手机号是<PHONE_NUMBER>"
```

**方案三：可逆脱敏（高级）**

对于需要在 Claude 处理完毕后还原真实数据的场景，使用映射表进行可逆替换：

```python
import uuid

class ReversibleSanitizer:
    def __init__(self):
        self.mapping = {}

    def sanitize(self, text: str, entity: str) -> str:
        token = f"[{entity}_{uuid.uuid4().hex[:8]}]"
        self.mapping[token] = text
        return token

    def restore(self, text: str) -> str:
        for token, original in self.mapping.items():
            text = text.replace(token, original)
        return text
```

## 11.6.2 审计日志

为了满足 ISO 27001、SOC 2 或等保三级的要求，所有与 AI 的交互都必须留痕。

### 必记字段

设计数据库表结构时，建议包含以下字段：

| 字段名                | 描述                                  | 用途                 |
| ------------------ | ----------------------------------- | ------------------ |
| `request_id`       | Anthropic 返回的 `request-id` 响应头      | 向 Anthropic 客服追溯问题 |
| `input_tokens`     | 消耗的输入 Token 数                       | 成本核算               |
| `output_tokens`    | 消耗的输出 Token 数                       | 成本核算               |
| `model_version`    | 具体模型版本                              | 回归分析、合规审计          |
| `prompt_hash`      | Prompt 模板的哈希值                       | 检测 Prompt 未授权变更    |
| `user_id`          | 发起请求的内部用户 ID                        | 访问追溯               |
| `timestamp`        | 精确到毫秒的时间戳                           | 时序分析               |
| `tool_calls`       | 工具名称、调用 ID、参数 schema/hash、风险等级和审批结果 | 操作审计，避免落盘原始参数      |
| `response_summary` | 输出内容的摘要或哈希                          | 内容合规检查             |

### 日志存储架构

对于高频调用的生产环境，推荐采用分层存储：

```mermaid
graph LR
    API["Claude API 调用"] --> Stream["实时流<br>(Kafka)"]
    Stream --> Hot["热存储<br>(Elasticsearch)<br>近 7 天"]
    Stream --> Cold["冷存储<br>(S3/OSS)<br>分类保留"]
    Hot --> Dashboard["监控仪表盘"]
    Cold --> Audit["合规审计"]
```

* **热存储**：最近 7 天的元数据日志存入 Elasticsearch，供实时查询和监控告警。不要把原始 prompt、完整工具参数、文件内容或密钥片段写入热日志。
* **冷存储**：按字段分类制定保留期限。合规需要长期保存的是审计证据和审批记录，不一定是全部原始内容；冷存储应具备加密、访问控制、生命周期删除和数据主体请求支持。

## 11.6.3 零留存设置

对于极其敏感的金融或医疗场景，企业用户可以与 Anthropic 签署 BAA (Business Associate Agreement) 或申请 Zero Data Retention（ZDR）安排。ZDR 和 HIPAA readiness 都是组织/合同层面的数据处理安排，不应假设可以靠单个请求头临时开启。

在 ZDR 覆盖的 endpoint 上，客户数据在 API 响应返回后不在静态存储中保留，除非法律或反滥用需要。不同功能和模型的覆盖范围不同：Messages API 和 Token Counting 可以覆盖；Batch API、Files API、code execution、Managed Agents 等需要按官方 feature eligibility 表或合同条款单独确认；Fable 5、Mythos 5 这类 Mythos-class / Covered Models 要求 30 天安全留存，不能承载要求 ZDR 的工作负载。

### 启用方式

通过账号和合同配置启用，而不是在业务代码中写一个自定义数据留存请求头。应用侧更应该做两件事：

1. 用独立 workspace / organization 隔离 ZDR、HIPAA 和普通工作负载。
2. 在上线前核对所用 endpoint 和工具是否属于当前组织的 ZDR / HIPAA 覆盖范围。

## 11.6.4 合规自查清单

在正式上线 AI 功能前，使用以下清单进行合规自查：

| 检查项    | 说明                     | 状态 |
| ------ | ---------------------- | -- |
| PII 脱敏 | 所有用户数据在发送给 API 前已脱敏    | ☐  |
| 审计日志   | 所有 API 调用均有完整日志记录      | ☐  |
| 数据留存   | 已确认 Anthropic 侧的数据留存策略 | ☐  |
| 访问控制   | API Key 使用权限最小化原则      | ☐  |
| 内容过滤   | 输出端配置了敏感内容过滤           | ☐  |
| 用户知情   | 用户已被告知其数据将由 AI 处理      | ☐  |
| 应急预案   | 制定了 AI 服务中断或数据泄露的应急方案  | ☐  |