跳到主要内容

你没定「哪些数据绝不能喂给外部 AI」，于是我把你的生产数据当普通上下文用了

阶段准备与协作角色项目经理 · 架构师 · 运维工程师严重度高适用版本通用 LLM证据安全报告

一句话摘要：为了让我帮上忙，你把真实数据贴给我——生产库 dump、客户资料、密钥、还没公开的源码。可你从没告诉我「哪些数据绝不能离开公司边界」，我只会把它当普通上下文处理。而数据一旦交给外部 AI，就等于送出了边界：收不回、可能被留存、可能被复述到别处。

现象​

你让我「分析下这份用户表」「照这段内部代码改」「用这个真实配置跑一下」，然后把东西直接贴进对话或让我读真实文件。里面可能有：客户的姓名手机号、生产数据库的导出、API 密钥和凭据、尚未公开的专有源码、受监管的财务/健康数据。

我照单全收，把它当成完成任务所需的上下文。我不会停下来问「这条数据能不能出公司」——因为在我这边，它和你贴的任何一段文本没有区别。于是这些数据被发往了一个外部模型，进了它的处理链路，也可能进了它的日志、缓存，甚至——取决于你用的是什么档位的服务——它的训练面。

为什么会这样​

因为数据敏感度是你的组织策略，不是我能从文本里看出来的属性。 一段字符串是「公开 README」还是「客户 PII」，差别不在字面，而在它属于谁、受什么监管、泄露了谁担责——这些信息不写进我的输入，我就无从判断。我默认把所有输入一视同仁地拿来用。

而把数据交给外部 AI，本质上是一次主动的对外传输。OWASP 把「敏感信息泄露」列为 LLM 应用的第二大风险（LLM02:2025）：模型可能泄露 PII、凭据、专有数据——既因为它会在输出里复述，也因为输入本身就离开了你的控制域。三星的工程师把内部源码粘进 ChatGPT 求助，正是这个机制的现实版（站内已收为案例）：没有恶意，只是缺一条「这类数据不进外部 AI」的边界。

关键在于：这是写码时埋漏洞 / 泄露敏感数据的上游。那条讲的是实现层——代码把密钥写进日志、把数据返回给不该看的人；而本条更靠前：在你决定要不要把数据喂给我的那一刻，就该有一条策略拦住你。等数据已经发出去，再谈实现层的防护已经晚了。

后果​

  • 出了边界就收不回。 缓存、日志、人工标注、训练——你无法保证一段已发送的数据没有任何副本留存。删除对话不等于删除它经过的每一处。
  • 合规与法律风险。 客户 PII、受监管数据（GDPR / HIPAA / 金融）、商业秘密一旦离境或离开授权处理方，可能直接构成违约或违规，代价远超技术故障。
  • Samsung 级泄密。 把未公开源码、战略文档喂给外部 AI，等于把核心资产交到了你无法审计的第三方手里。

最佳实践​

先定一张数据分级表，明确哪些类别绝不进外部 AI；再在边界处用机制把关，而不是靠我自觉。

  • 做数据分级，把红线写死。 至少分三档：绝不外发（密钥/凭据、客户 PII、未公开 IP、受监管数据）、脱敏后可（用合成/占位替换真实标识再给我）、公开可（已公开文档/示例）。第一档对任何外部 AI 一律不给。
  • 用占位 / 合成数据喂我。 需要我处理「像生产那样」的数据时，给我结构相同、内容假的样本——这恰是用假占位顶替真实输入的反向用法：那条里「造假数据」是我糊弄你的反模式，这里「用假数据」是你保护真实敏感数据的正解。
  • 在边界处加机制，别靠人自律。 在数据进入外部 AI 的通道上加 DLP / 正则过滤 / 密钥扫描，把「不该外发的」在出门前拦下——人会忘，机制不会。
  • 必须用真实数据时，换处理方。 用自托管 / 本地模型，或带「不训练、不留存、可审计」合同承诺的企业版服务，把数据留在你能审计的控制域内，而不是发给一个公开端点。

示例​

改之前：

你：帮我看看这条线上报错，这是出错时的完整请求日志。
   （直接贴上日志，里面含真实用户手机号、身份证号、和一个内部 API token）
我：（照单分析，这些数据已随请求发往外部模型）
后果：一次"求助"把一批客户 PII 和一个有效凭据送出了公司边界，且无法收回。

改之后：

你：帮我看看这条线上报错。（先把日志里的手机号/证件号替换成假值、token 打码）
   "phone": "138****", "id": "PLACEHOLDER", "token": "<redacted>"
我：（基于结构和报错堆栈定位问题，不需要真实 PII 也能分析）
你：（敏感数据从没离开边界，问题照样解决了）

同一条日志，直接贴是把客户数据和凭据送出门，脱敏后贴是只把「我诊断所需的结构」给我——任务没打折，边界没被破。

什么时候例外​

「数据不外发」针对的是把数据交给你无法审计的外部端点；边界内的处理不受此限：

  • 自托管 / 本地模型：数据全程留在你自己的基础设施里、不出网，那么用真实数据是安全的——此时约束来自你的内网治理，而非「别给外部 AI」。
  • 有合同保证的企业部署：服务方以合同明确「不训练、不留存、可审计、数据驻留在指定区域」，且满足你的合规要求时，相应档位的数据可按约定使用。
  • 数据本就公开：开源代码、已发布文档、公开数据集——没有「出边界」的问题，正常喂我即可。

判据：例外成立的前提是数据没有离开你能审计、能担责的控制域（自托管、合同锁定、或本就公开）。只要它会流向一个你无法审计的第三方端点，就回到默认——按分级把红线类数据挡在门外。

与相邻误区的区别​

  • 默认埋漏洞 / 泄露敏感数据：那条是实现层——我写的代码把密钥写进日志、把数据返回给不该看的人；本条是策略层——在你决定「要不要把这类数据交给外部 AI」之前就该立的边界。一个管「代码怎么处理数据」，一个管「数据该不该到我面前」。
  • 三星源码泄密给 ChatGPT（案例）：那是这条策略缺失时的真实事故；本条是从该类事故提炼出的通用策略。
  • 用假占位顶替真实输入：那条里「用假数据」是我蒙混过关的反模式；本条里「用假 / 脱敏数据」是你保护真实敏感数据的正解——同一个动作，目的相反。

版本说明​

适用版本

「先定哪些数据不能给外部 AI」是与具体模型无关的数据治理策略，对所有外部 LLM / AI 服务适用——无论是聊天窗口还是 agent。模型越强、越好用，你越想把真实数据喂进来，这条边界就越值钱：能力提升不会让「数据出了边界收不回」这件事改变。

延伸阅读与出处​