概述
在前面的章节中，我们讨论了如何通过模型回退保证服务高可用。现在我们要关注一个非常重要的安全问题：如何保护用户的敏感信息，确保个人身份信息（PII）不会被泄露或滥用。
在实际应用中，用户可能会在对话中输入各种敏感信息：邮箱地址、信用卡号、身份证号、手机号等。如果这些信息被直接发送给AI模型，或者记录在日志中，就可能存在泄露风险。
PII检测中间件就是为了解决这个问题而设计的。它可以在对话流程中自动检测敏感信息，并根据预设的策略进行处理：脱敏、掩码、哈希或直接阻断，确保敏感信息不会被泄露，同时满足合规要求。
使用场景
合规要求
在医疗、金融、政务等受监管的行业，必须符合GDPR、HIPAA、PCI-DSS等合规标准，防止PII泄露。这是硬性要求，必须满足。
日志脱敏
客服系统、对话日志系统需要记录对话内容用于分析和审计，但必须对敏感信息进行脱敏处理，才能安全存储或展示。
数据安全
任何处理用户敏感数据的应用，都需要在数据发送给模型前检测并处理PII，避免敏感信息被模型学习或泄露。
核心功能需求
检测范围
我们需要在哪些环节进行PII检测？
输入阶段检测
- 检测位置：用户消息发送给模型前
- 目的：防止敏感信息被发送给AI模型
- 必要性：这是最重要的检测点，必须配置
输出阶段检测
- 检测位置：AI模型返回结果后
- 目的：防止模型生成的响应中包含敏感信息（可能是从上下文中推断出来的）
- 必要性：如果模型可能生成PII，建议开启
工具结果检测
- 检测位置：工具执行返回结果后
- 目的：防止工具返回的数据中包含敏感信息（如数据库查询结果）
- 必要性：如果工具可能返回敏感数据，建议开启
产品建议：至少要在输入阶段检测，这是必须的。输出和工具结果阶段的检测可以根据实际场景决定是否需要。
处理策略
检测到PII后，我们需要决定如何处理。不同的策略适用于不同的场景。
脱敏（Redact）
- 处理方式：将敏感信息替换为占位符，如<code>[REDACTED_EMAIL]</code>
- 优点：保留了PII类型信息，便于审计和日志分析
- 适用场景：日志记录、审计场景
掩码（Mask）
- 处理方式：保留部分信息，掩码其他部分，如信用卡号显示为<code>****-****-****-1234</code>
- 优点：用户可以看到部分信息，便于识别
- 适用场景：需要用户识别自己信息的场景
哈希（Hash）
- 处理方式：将敏感信息替换为确定性哈希值，如<code><email_hash:a1b2c3d4></code>
- 优点：相同PII生成相同哈希，便于去重和关联分析
- 适用场景：需要去重或关联分析的场景
阻断（Block）
- 处理方式：检测到即抛出异常，停止执行
- 优点：最严格，确保没有任何PII通过
- 适用场景：严格合规场景，禁止任何PII通过
产品建议：根据业务场景和合规要求选择合适的策略。严格合规场景建议使用阻断，日志场景建议使用脱敏。
内置与自定义类型
内置PII类型
系统提供了一些常用的PII类型，可以直接使用：
- 邮箱地址（email）：标准邮箱格式
- 信用卡号（credit_card）：Luhn算法验证的信用卡号格式
- IP地址（ip）：IPv4/IPv6地址格式
- MAC地址（mac_address）：网络设备MAC地址格式
- URL链接（url）：标准URL格式
自定义PII类型
对于特殊的业务需求，我们可以自定义PII类型：
- 正则表达式：适用于简单模式匹配（如API Key）
- 自定义函数：适用于复杂验证逻辑（如身份证号、手机号验证）
产品建议：优先使用内置类型，对于特殊需求再考虑自定义。自定义时需要注意性能影响。
PRD需求描述
功能需求
FR-1: PII检测能力
- 描述：能够在对话流程中自动检测多种类型的PII
- 检测类型：支持内置类型和自定义类型
- 检测位置：支持在输入、输出、工具结果三个阶段检测
- 优先级：P0（核心功能）
FR-2: 多种处理策略
- 描述：支持脱敏、掩码、哈希、阻断四种处理策略
- 策略配置：可以为不同PII类型配置不同策略
- 优先级：P0（核心功能）
FR-3: 自定义PII类型
- 描述：支持通过正则表达式或自定义函数定义新的PII类型
- 配置方式：提供配置界面，支持自定义规则
- 优先级：P1
FR-4: 检测范围配置
- 描述：可以配置在哪些阶段进行PII检测
- 配置项：输入检测、输出检测、工具结果检测
- 优先级：P0（核心功能）
非功能需求
NFR-1: 性能要求
- 检测延迟：PII检测不应显著影响响应时间，建议检测延迟 < 50ms
- 性能优化：对于大量消息场景，需要优化检测性能
NFR-2: 准确性与误报率
- 检测准确性：确保高敏感PII（如信用卡号）的检测准确率高
- 误报率控制：误报率应控制在合理范围内（建议 < 1%）
- 白名单机制：支持白名单，排除特定内容（如测试邮箱）
NFR-3: 审计与监控
- 检测日志：记录每次PII检测事件，包括PII类型、处理策略、检测位置等
- 统计指标：监控PII检测率、阻断率、误报率等指标
- 告警机制：检测到高敏感PII且策略为阻断时，触发告警
产品设计要点
策略选择建议
严格合规场景（医疗、金融）：
- 建议使用<code>block</code>策略，检测到即阻断
- 确保没有任何PII通过系统
日志审计场景：
- 建议使用<code>redact</code>策略
- 保留PII类型信息，便于后续审计
用户识别场景：
- 建议使用<code>mask</code>策略
- 保留部分信息，便于用户识别
数据分析场景：
- 建议使用<code>hash</code>策略
- 便于去重和关联分析
检测范围建议
必须配置：
- <code>apply_to_input=True</code>：必须配置，防止用户输入中的PII被发送给模型
建议配置：
- <code>apply_to_output=True</code>：如果模型可能生成PII，建议开启
- <code>apply_to_tool_results=True</code>：如果工具可能返回PII，建议开启
性能与误报率平衡
性能优化：
- 对于大量消息场景，需要优化检测性能
- 可以考虑异步检测或批量检测
误报率控制：
- 正则匹配可能产生误报（如将非邮箱文本识别为邮箱）
- 需要设置合理的误报率阈值
- 支持白名单机制，排除特定内容
产品建议：在PRD中明确性能要求和误报率阈值，根据业务场景权衡。
使用建议
什么时候应该使用
- 合规要求：行业监管要求必须处理PII
- 敏感数据场景：处理用户敏感数据的任何场景
- 日志审计：需要记录对话日志但必须脱敏的场景
配置建议
- 检测范围：至少要在输入阶段检测，这是必须的
- 处理策略：根据业务场景和合规要求选择
- 自定义类型：对于特殊需求，可以自定义PII类型
注意事项
- 性能影响：PII检测会增加延迟，需要监控性能影响
- 误报处理：需要设置合理的误报率阈值，支持白名单机制
- 审计日志：必须记录检测日志，便于合规审计
与其他中间件的配合
PII检测可以与其他中间件配合使用：
- 与Human-in-the-loop配合：检测到高敏感PII时，可以触发人工审核
- 与SummarizationMiddleware配合：摘要前先脱敏PII，避免摘要中包含敏感信息
- 执行顺序：PII检测应该在模型调用前执行，确保模型不会接收到原始PII
后续优化方向
- 智能检测：基于机器学习提高检测准确性，降低误报率
- 上下文感知：结合上下文信息，更准确地识别PII
- 个性化配置：根据不同用户或场景，提供个性化的PII处理策略
- 实时监控：实时监控PII检测情况，及时发现问题