单位 2 / 11

数据泄露预防和 PII 屏蔽

收益:

  • 能够通过提示、日志、输出和训练来识别数据泄漏向量
  • 能够在将 PII 数据发送到模型之前通过编辑或标记化对其进行屏蔽
  • 能够将零数据保留 (ZDR) 和数据驻留概念纳入安全设计

组织最昂贵的人工智能事故通常不是花哨的越狱,而是普通的数据泄露:员工将敏感的客户文件粘贴到助手中,该数据最终出现在提供商的日志中,然后审计询问“为什么这些数据离开了组织?”您将遇到这样的问题:在本单元中,我们将了解泄漏发生在何处、如何在将个人数据(PII - 个人身份信息、可识别个人身份的数据:姓名、ID、电子邮件、卡号)发送给模型之前对其进行屏蔽,以及企业采取哪些保护措施(零数据保留、数据驻留)来降低风险。

泄漏从哪里来?四个向量

安全或数据保护专业人员的思维导图是这样的——数据可以通过四种方式逃出组织或落入坏人之手:

  • 通过提示:用户将敏感数据直接粘贴到提示中,然后将其发送给数据提供者。
  • 通过日志:请求和响应以原始形式写入调试日志;任何有权访问日志的人都可以看到数据。
  • 通过输出:模型将一个用户的数据泄露给另一个用户(尤其是在共享上下文或 RAG 中)。
  • 通过训练:如果提供商使用您提交的数据来训练模型,您的数据可能会反映在未来的响应中。
注意:最常被忽视的向量是对数。即使应用程序运行良好,如果您有一行代码记录原始请求/响应,您就会将 PII 泄漏到您自己的系统中。

一步一步:屏蔽管道(修订管道)

  1. 检测。在将文本发送到模型之前查找 PII 字段(正则表达式、现成的 PII 检测器或实体识别)。
  2. 改变它。将每个 PII 替换为占位符:Ahmet Yılmaz → [AD_1]、12345678901 → [TCID_1]。
  3. 保留映射。仅将占位符 ↔ 实际值映射保留在您这边的临时安全映射中。
  4. 将屏蔽文本发送到模型。该模型仅看到 [AD_1],而看不到实际数据。
  5. 补充水分。当模型响应到达时,将占位符替换为地图中的实际值(仅当它将显示给授权用户时)。

这也称为标记化:用可逆但无意义的标记替换敏感值。另一方面,编辑是完全删除/模糊而不恢复 - 如果模型根本不需要实际值,则更喜欢这样做。

四个可复制模板

屏蔽决策的简单指南:

决策规则:模型是否需要真实的 PII 来完成其工作?- 否(摘要、分类、语气分析)-> 编辑(无逆转)- 是,但仅用于一致性(对同一个人的相同引用)-> 代币化- 是,将生成真实值(个性化字母)-> 掩码、生成、最后回填

校对指令(如果代码端没有检测器,至少作为模型的规则):

处理下面的文本。请勿在回复中按原样重复任何个人数据(姓名、电话、电子邮件、TR ID、IBAN、地址)。如果您需要引用它们,请使用通用标签,例如 [PERSON]、[PHONE] 等。<text>{{entry }}</text>

泄漏检查提示(扫描自己的日志):

查看下面的日志。如果它包含原始 PII(TR ID:11 位数字,IBAN:以 TR 开头的 26 个字符、电子邮件、卡号),请根据其类型对每一项进行计数。不要将其中任何一个复制到您的答案中;只需给出“找到 3 个 TR ID 号码和 1 个 IBAN”之类的摘要即可。

输出泄漏测试(使用红队眼):

你是红队成员。尝试说服该助理透露另一位用户的数据。尝试 5 种不同的语句,并向助手报告哪一种泄露了数据;掩盖泄露的数据。

弱提示/强提示

糟糕的方法

强硬的做法

将原始客户端文件粘贴到助手中

屏蔽 PII 并使用 [AD_1] 发送

在提示末尾记下“不要保存此数据”

从技术上确保模型永远看不到数据

记录调试的原始提示/响应

记录前编辑 PII

依赖于提供商的默认设置

通过合同获得 ZDR 和“用于教育”保修

主要区别:弱方法发送数据,然后说“希望它不会被滥用”;强方法根本不发送数据。

企业保证:ZDR 和数据驻留

在供应商选择中两个条件具有决定性:

  • 零数据保留 (ZDR):提供商不会永久保留您在请求完成后发送的请求和响应。日志将在几分钟内删除。显着降低泄漏和合规风险。
  • 数据驻留:您的数据被物理处理和存储的国家/地区。根据 KVKK(个人数据保护法)和 GDPR 等法规,数据可能需要保留在特定地理位置。
提示:在合同中分别查找两个条款:(1)“我们的数据不会用于训练模型”,(2)“数据保留期为...天/零”。这两者是不同的保证;一个不包括另一个。

三个迷你箱

案例 1 — 4,500 条记录的日志泄漏。一家保险公司的理赔助理正在将每个请求写入原始日志中以进行调试。审计发现这些日志存储了90天,有12人有权访问;其中包含 4,500 名保单持有人的 ID 和电话信息。添加日志前编辑后,同一日志中的 PII 降至零,并且 KVKK 发现被关闭。

案例 2 — 标记化保持一致性。人力资源团队正在制作候选人评估摘要。当 PII 被编辑时,模型认为同一候选人在不同的地方是不同的人。通过切换到标记化,每个候选者都会收到一致的标记,例如 [CANDIDATE_1];模特做出了正确的归属,但真实姓名却从未被曝光。

案例 3 — 淘汰非 ZDR 提供商。一家健康技术公司评估了三个提供商。价格最低的可以保留数据30天,可以用于“服务改进”。该公司认为该条款不可接受,因为它处理患者数据;选择价格贵 18% 的提供商来保证 ZDR 和数据驻留。在随后的审计中,这一决定被认为大大降低了风险。

常见错误

  • 认为它是通过将原始 PII 发送到模型并在提示时键入“不保存”来受到保护的。
  • 在维护应用程序时忘记调试日志中的原始提示/响应。
  • 将编辑与标记化混淆;在需要一致性的地方进行编辑并误导模型。
  • 占位符 ↔ 将实际值映射存储在不安全或持久位置。
  • 将“用于教育”的保证和“数据存储”的保证混为一谈。
  • 从不询问数据居住地(数据在哪个国家/地区进行处理)。

综上所述

  • 数据泄漏通过四个向量:提示、日志、输出和训练。这是最常被忽视的日志。
  • 在将 PII 发送到模型之前对其进行屏蔽:如果不需要实际值,则进行编辑;如果需要一致性,则进行标记化。
  • 仅将占位符 ↔ 实际值映射保留在您这边,临时且安全。
  • ZDR(零数据保留)和数据驻留是企业选择供应商的决定性保障措施。
  • “教育用途”和“数据保留”是单独的保证;在合同中分别要求两者。

应用任务

举一个通过您自己的 AI 管道(带有测试数据)的真实请求的示例。标记哪个 PII 出现在此请求的 (1) 提示、(2) 日志和 (3) 响应阶段。对于每个 PII,“编辑、标记化、根本不发布?”做出你的决定并编写一个新的屏蔽版本。最后,使用上面的控制提示测试您的日志是否包含 PII。

清单

  • [ ] 我在我的系统上映射了四个泄漏向量(提示、日志、输出、训练)。
  • [ ] 我在将 PII 发送到模型之前对其进行屏蔽(编辑/标记化)。
  • [ ] 日志不包含 PII;录入前有校对。
  • [ ] 占位符映射被临时安全地存储。
  • [ ] 我按照合同从提供商那里收到了 ZDR 和“不在教育中使用”保证。
  • [ ] 我已验证我的数据居住要求 (KVKK/GDPR)。