资料能不能上传给 AI？个人信息、商业秘密与政府文件安全指南

上传前，先问 5 个问题

只要有一个问题答不出来，就先不要把原文放进一般公开型 AI。

1. 内容是否含个人信息或敏感信息？ 只要资料可能识别个人，或涉及隐私风险，就不应直接贴原文；EDPB 文件正是围绕 LLM 系统的隐私风险与缓解方式展开讨论。
2. 服务会保留输入或输出吗？保留多久？ NIST 将数据留存列为生成式 AI 风险管理项目。
3. 资料会不会被商业使用、再处理或用于改进服务？是否有退出机制？ NIST 同时列出商业使用、数据保护、数据留存和退出选项等治理面向。
4. 谁可以使用这项工具，使用行为能否追踪？ NIST 提到使用者资格、避免匿名使用和监控；放到日常管理中，就是组织需要知道谁在用、为什么用、用了哪些资料。
5. 组织是否做过影响评估、事件响应和风险控制？ 这些都是 NIST 生成式 AI 风险管理文件列出的项目。

不要把提示词里一句请保密当成安全控制。真正需要确认的是：资料会怎样保存，谁能访问，是否可以退出再利用，出事时谁负责处理，以及你的组织是否允许这样做。

红黄绿清单：哪些可以，哪些先别上传？

下面的清单，是把数据保护、数据留存和基于风险的控制原则，转成日常可用的判断方式。它不是法律意见，仍应以你所在组织的网络安全、法务、个人信息保护和公文管理规则为准。

绿灯：可以考虑，但仍要看条款

• 已公开、低敏感，且你确认有权使用的资料。
• 已去标识化、删除敏感字段或改写成摘要后，无法合理回推到个人、客户、案件或内部机密的资料。
• 只保留必要背景的问题描述，而不是整份合同、公文、客户资料表或代码库。

公开不等于零风险。如果公开资料中仍含个人信息或敏感信息，仍要回到隐私风险和数据保护规则来处理。

黄灯：先改写、遮蔽，或走审批流程

• 含有客户、员工、供应商、案件当事人或公众信息的资料。
• 合同草稿、财务资料、内部汇报、会议纪要、法务意见或政策草案。
• 源代码、技术文档、系统架构图，尤其是可能包含密钥、凭证或漏洞信息的内容；NIST 将安全软件开发和基于风险的控制列为生成式 AI 治理项目。
• 政府机关内部文件、未公开公文、签报、评审资料或跨部门协作文件；公共部门使用生成式 AI 时，仍需处理个人或敏感信息风险。

这类资料不一定永远不能用 AI 处理，但不应在没有审批、没有留存规则、没有监控和事件响应机制时，直接丢进一般公开型 AI。

红灯：不应上传到一般公开型 AI

• 法律法规或内部制度禁止外传的资料。
• 涉密文件，或涉及国家安全、执法、调查、采购评审等高敏感资料。
• 账号密码、API key、私钥、证书、访问令牌，或任何可以用来进入系统的信息。
• 你无法确认来源、授权、留存、删除和再利用条件的资料。

去标识化，不只是删掉姓名

如果身份证号、手机号、邮箱、地址、账号、案号、罕见职务、日期地点组合仍能指向特定个人或案件，隐私风险可能依然存在。EDPB 文件的核心关切之一，就是 LLM 系统中的隐私风险与缓解；因此，上传前应把识别信息、可回推细节和非必要字段一并移除或改写。

更稳妥的做法是：用代称替代真实姓名和公司名；只提供任务所必需的片段；把原始文件改写成抽象场景；对名单、记录或表格先做汇总；如果确实需要处理原文，改走组织批准的工具和流程。

政府文件：公开资料和内部文件要分开

公共部门使用生成式 AI，不是简单的允许或禁止二选一。JRC 的生成式 AI Outlook 报告把公共部门应用列为专门讨论领域；欧洲议会附件中的案例摘要也提到，使用官方 Bundestag 数据时避免个人或敏感信息。

通常较可考虑的是已公开、低敏感、可依法使用的官方资料；需要特别保守处理的，是未公开公文、内部签报、政策草案、调查资料、执法资料、采购评审资料，以及任何含个人信息或敏感信息的文件。前者仍要检查使用条件；后者不应直接放进一般公开型 AI。

最简单的决策规则

如果资料外泄会伤害个人、组织、公共利益或合规状态，就不要把原文交给一般公开型 AI。先遮蔽、摘要、最小化；如果任务确实需要原文，改走审批流程和受控工具，并确认数据保护、数据留存、访问权限、监控和事件响应机制。