11.6 企业级合规与审计

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

11.6.1 数据脱敏

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

常见 PII 类型

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

脱敏方案

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

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

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

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

方案二：Presidio（企业级）

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

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 处理完毕后还原真实数据的场景，使用映射表进行可逆替换：

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	输出内容的摘要或哈希	内容合规检查

日志存储架构

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

• 热存储：最近 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 服务中断或数据泄露的应急方案	☐