每8个AI支持提示中就有1个包含个人数据。我认为我们在以错误的方式保护LLM。

TL;DR：AI社区花费大量时间讨论提示注入、越狱和幻觉。我分析了来自生产环境AI支持系统的10,000条匿名客户提示，发现近12.4%包含直接转发给LLM的个人身份信息（PII）。这彻底改变了我对AI安全的看法。 过去几年，我一直在构建由AI驱动的客户支持系统。和许多工程团队一样，我们大部分精力都花在改进检索质量、评估指标、幻觉、延迟以及整体回答准确性上。然而最近，我想回答一个更简单的问题：用户究竟有多频繁地向AI系统发送敏感信息？在构建复杂的防护措施之前，我需要知道这到底是真实的生产问题，还是仅仅是我的直觉。于是我分析了来自生产环境企业RAG系统的10,000条匿名提示，结果确实让我们感到惊讶。 | 类别 | 数值 | |---|---| | 分析的提示总数 | 10,000 | | 包含至少一个敏感实体的提示 | 12.4% | | 电话号码 | 620 | | 姓名 | 410 | | 邮箱地址 | 180 | | 客户/合同ID | 95 | | 护照/国民身份证 | 12 | | 其他敏感实体（API密钥、支付信息、内部代码） | 23 | 这意味着大约每八个提示中就有一个包含敏感信息，而这些信息可能从一开始就没有必要离开应用边界。 正常用户行为，而非安全攻击 最让我惊讶的是，我们所看到的并不是安全事件——我们衡量的是正常、日常的用户行为。没有提示注入，没有越狱，也没有试图破坏系统的恶意用户。只是普通人在尝试解决普通的支持问题。 最常见的例子并不是被盗的信用卡或护照，而是粘贴在典型支持请求旁边的简单电话号码和姓名： “我的电话号码是 +1 415 XXX XXXX。为什么我收不到短信？” “我昨天换了手机号码。现在无法登录我的账户。” “我的名字是John Smith。你能帮我查一下我的账户为什么被封锁吗？” 检测到的大多数实体都是标准标识符： 电话号码 姓名 邮箱地址 但我们还经常遇到合同编号、护照信息、支付信息片段、直接从错误日志中复制的API密钥，甚至企业内部文档的片段。 从用户的角度来看，这种行为完全合乎逻辑——他们只是希望尽快解决自己的问题。 数据到底去了哪里？ 核心问题从他们按下回车键的那一刻就开始了。那条原始提示会立即被保存到以下各处： 应用日志 追踪系统 分析平台 监控工具 调试会话 内部支持接口 而在大多数现代LLM架构中，它会作为原始请求被转发给外部模型提供商（无论是OpenAI、Anthropic、Google、DeepSeek还是其他公司）。 我们在不知不觉中创建了额外的数据处理管道——通常位于我们自己的基础设施之外——以完全不受保护的方式处理敏感个人数据。 这不仅仅是理论上的架构疏忽；它正迅速成为一项重大的合规风险。 部署生成式AI的组织现在必须遵守严格的数据法规，如CCPA/CPRA、HIPAA和GLBA，以及NIST、OWASP、SOC 2和ISO 27001等安全框架。 虽然它们的具体规则各不相同，但都有一个基本要求：只收集、处理、保留和披露严格必要的信息。 然而，大多数现代AI管道仍然将原始、未净化的提示直接转发给外部API，从不问一句：模型真的需要这些个人信息来解决用户的问题吗？ 企业安全悖论 在一次内部安全审查中，我注意到一个奇怪的矛盾。在任何企业环境中，要获得生产版本发布批准，都必须回答严格的安全问题：个人数据存储在哪里？保留多长时间？谁有权访问？是否加密？能否删除？是否出现在备份中？整个发布版本都会被推迟，直到这些答案清晰明确。 然而，当我们集成LLM时，充满电话号码、客户ID、API令牌和私有文件的提示开始自由地流过外部API，使AI集成成为整个系统中保护最薄弱的部分之一。 这一认识让我得出一个简单的原则：也许最安全的个人数据不是加密的数据——而是从一开始就永远不会进入外部LLM管道的数据。 多年来，行业一直在优化如何安全地存储敏感信息。也许AI系统需要更早地优化一件事：完全避免传输不必要的敏感数据。 二十年安全工程，唯独漏了LLM 几十年的软件工程为我们带来了专门的安全层： 身份认证 授权 API网关 反向代理 Web应用防火墙（WAF） 速率限制器 DLP（数据防泄漏） 审计日志 每个后端请求在触及内部服务之前都要经过多个边界。唯独LLM层是个例外，原始用户输入通常被直接发送到第三方端点。 感觉我们就像是在用户最有可能分享敏感细节的地方，意外地剥掉了二十年来的基础设施安全防护。 与其问“模型能回答这条提示吗？”，我们应该问：“这条提示应该以当前形式到达模型吗？” 介绍SafeGate：网关层的数据最小化 为了弥补这一缺口，我开始构建一个名为SafeGate的开源项目——一个位于应用和模型提供商之间的AI安全网关。在提示离开你的环境之前，SafeGate会自动检测敏感实体，并允许你动态地： - 用逼真的替代值替换它们（为LLM保留语义上下文） - 完全屏蔽它们 - 根据策略完全阻止请求 目标很简单：在数据离开你的应用之前，在网关层实施严格的数据最小化。 一起构建开源AI基础设施 由于PII模式、文档格式和监管要求在不同国家和行业之间存在巨大差异，我相信AI安全基础设施不应由单个团队孤立地构建。我正在积极寻求社区的贡献、边缘案例测试和反馈，以使这一网关层尽可能健壮。 我已经在下方评论中放上了GitHub仓库和PyPI包的详细信息，任何有兴趣查看代码、提交issue或为架构做贡献的人都可以查看。我很想听听其他工程团队是如何处理这个问题的： - 你是否曾经分析或量化过实际到达第三方LLM端点的敏感数据有多少？ - 你们目前在生产环境中如何管理PII——是客户端屏蔽、正则表达式管道，还是使用本地小型模型进行预过滤？ - 在尝试提示净化时，哪些边缘案例或实体类型给你的团队带来了最多的麻烦？