为什么你的 LLM 可能存在 PII 问题(以及如何解决)

发布: (2026年4月24日 GMT+8 17:21)
6 分钟阅读
原文: Dev.to

Source: Dev.to

(请提供您希望翻译的正文内容,我将按照您的要求保留链接并翻译文本。)

朴素正则表达式的问题

一个匹配信用卡模式的简单正则表达式会产生大量误报。例如,16 位数字 1234567890123456 能匹配所有信用卡正则,但它并不是有效的卡号。真实的 Visa、Mastercard 或 Amex 号码满足 Luhn 算法,该算法可以消除绝大多数随机数字序列。

def luhn_valid(number: str) -> bool:
    digits = [int(d) for d in number if d.isdigit()]
    digits.reverse()
    total = 0
    for i, d in enumerate(digits):
        if i % 2 == 1:
            d *= 2
            if d > 9:
                d -= 9
        total += d
    return total % 10 == 0

SSN(社会安全号码)也存在同样的问题。模式 \d{3}-\d{2}-\d{4} 能匹配数百万并非有效社会安全号码的字符串。一个健全的验证器还必须拒绝:

无效模式原因
000-XX-XXXX地区 000 从未发放
666-XX-XXXX地区 666 从未发放
900-999-XX-XXXX地区 900–999 为保留
XXX-00-XXXX组 00 从未发放
XXX-XX-0000序列号 0000 从未发放

没有这些检查,你的过滤器会把订单号、发票 ID、时间戳等标记为匹配,从而导致不可接受的高误报率。

实用的推出策略

1. 在 标记模式 下启动

检测潜在的 PII,记录命中,但让内容保持不变。这样可以在任何内容被修改之前,获取真实流量数据以验证检测准确性。

# Flag mode — detect and log, content unchanged
result = requests.post(
    "https://your-sentinel-endpoint/v1/scrub",
    headers={"X-Sentinel-Key": "sk_live_your_key"},
    json={"content": user_message, "tier": "standard"},
).json()

# pii_hits: number of PII matches found
# pii_types: categories detected (CREDIT_CARD, SSN, EMAIL, PHONE)
print(result["security"]["pii_hits"])   # e.g. 2
print(result["security"]["pii_types"])  # e.g. ["EMAIL", "PHONE"]
# safe_payload is unchanged in flag mode — content passed through

2. 在信心足够时切换到 脱敏模式

在文本到达你的 LLM 之前,用已定义的占位符替换检测到的 PII。

# Redact mode — PII replaced with placeholders
# Input:  "My card is 4532015112830366 and email is john@example.com"
# Output: "My card is [CREDIT_CARD] and email is [EMAIL]"

脱敏后的文本随后会流经安全管道的其余部分——注入检测、语义相似度等——此时敏感值已经被剥离。

合规考虑

法规为什么 PII 过滤很重要
PCI‑DSS任何处理、存储或传输持卡人数据的系统都在范围内。如果你的 LLM 读取信用卡号,你就属于范围内。在模型看到数据之前进行脱敏可以限制该范围。
HIPAA患者数据,即使是自由文本形式,也属于 PHI。处理医疗支持工单的 LLM 需要 PII 控制。
SOC 2审计员会询问关于在 AI 堆栈中流动的敏感数据的控制措施。“我们在模型看到之前进行过滤”比“我们依赖模型不记录它”是更有力的答案。

这些控制措施往往决定了能否赢得企业合作,而不是在合规问卷中失去机会。

第 1 阶段:高价值模式

类型模式验证
信用卡13–19 位数字序列Luhn 算法
社会安全号码\d{3}-\d{2}-\d{4}段有效性检查
电子邮件地址标准 RFC 模式
美国电话号码E.164 + 常见格式

第2阶段:扩展覆盖范围

  • IBAN(对欧洲金融科技至关重要)
  • 护照号码
  • 每个租户的自定义正则表达式模式——允许企业自行定义个人身份信息(PII)定义。

端到端流程

User message
   → PII pre‑pass (flag or redact)
       → HTML injection detection
           → Fast‑path regex (prompt injection patterns)
               → Deep‑path vector similarity
                   → LLM

PII 过滤首先运行,在任何其他处理之前进行。 在脱敏模式下,已清理的文本——例如 [CREDIT_CARD][EMAIL]——会流经管道的其余部分,确保注入检测和 LLM 永远不会看到原始的 PII。

Sentinel integration

PII 过滤已内置于 Sentinel,作为 scrub 流水线的预处理步骤,可在 Teams 和 Enterprise 计划中使用。flag → redact rollout 方法、Luhn 校验以及 SSN 段检查已全部上线。

0 浏览
Back to Blog

相关文章

阅读更多 »