把内部数据交给 AI 之前，企业至少要回答这七个问题

文章主旨：

企业不应制作静态的“可喂数据清单”，而应把每次 AI 数据使用当作有条件的数据处理，按业务目的、数据等级、处理环境和结果责任进行字段级、场景化判断。

关键要点：

• 单一文档标签无法覆盖混合数据，AI 数据治理的最小单元应从“文档”下沉到“字段、片段和权限”。
• 数据能否输入 AI 取决于处理条件，而非简单按等级一刀切；需结合使用目的、必要性、处理环境、保留期限和删除能力判断。
• 应区分公开消费级账号、企业级 SaaS/API、私有化或受控 VPC 三类环境，分别核对训练使用、日志留存、访问主体和处理地域等边界。
• 通过目的与权限、数据内容、服务边界、输出与责任四道闸门，落实字段删减、片段化、合同约束、人工复核和日志追踪。
• 执行层面需建立三档数据规则，并将身份、数据目录与标签、网关审批、知识库权限等控制嵌入系统，配合上线前七问检查。

内容结构：

1. 引子：采购合同是否机密

   采购人员希望用 AI 提取合同条款，但同一份合同可能同时包含公开产品说明、个人信息、敏感个人信息和商业秘密。作者据此提出，不应急于制作“可喂数据清单”，而应依次检查业务目的、数据等级、处理环境和结果责任。

2. 一份采购合同，为什么不能只贴一个标签

   公开产品资料通常风险较低；联系人姓名和手机号属于个人信息，银行账户属于敏感个人信息；采购价格、折扣底线、供应商评估和技术附件可能构成商业秘密。员工将文件复制到未经批准的外部工具，可能改变原有保密边界。因此治理应落到字段、片段和权限。

3. “可输入”是一组处理条件

   数据分类分级制度要求按重要程度和危害程度实施保护，但不能简单理解为“高等级数据一律禁用”。同一类数据因使用目的、必要性和环境不同，风险不同；企业需要判断 AI 任务是否落在原处理目的内，不存在脱离场景、账号和部署方式的永久白名单。

4. 先把三种 AI 环境分开

   公开消费级账号适合公开资料和已完成可靠脱敏的低风险材料；企业级 SaaS 或 API 可承载更多内部信息，但仍需核对是否用于训练、日志保存期限、功能级持久化、处理主体与地区及删除机制。以 OpenAI API 为例，官方文档说明 API 数据默认不用于训练，但默认滥用监控日志仍可能保留，部分端点还会保存应用状态，因此“不用于训练”不等于无留存风险。私有化、专有云或受控 VPC 可收紧边界，但仍需治理权限继承、向量库副本、日志内容、模型输出和管理员账号。

5. 四道闸门怎样落到项目里

   第一道检查目的和权限，明确 AI 任务及数据必要性；第二道检查数据内容，识别个人信息、敏感个人信息、商业秘密、重要数据等，并做字段级删除、替换、汇总或抽样；第三道检查服务边界，通过合同约定训练使用、保存期限、删除机制、访问主体、处理地域、分包方、事件通知和审计能力；第四道检查输出和责任，对高影响输出设置人工复核、引用来源、操作日志和纠错渠道。

6. 哪些数据通常可以用，哪些要停一下

   可直接进入已批准 AI 环境的包括已公开资料、允许内部广泛共享的制度与知识、不含个人信息和机密内容的模板、经验证的匿名化数据及合成数据；完成处理或审批后可使用含个人信息、内部合同、工单、源代码、经营分析明细等数据；账号口令、私钥、访问令牌、生产数据库连接信息、制度明确禁止外发的数据及国家秘密等应直接拦截。重要数据需结合行业目录、地区目录和企业分类分级结果识别，未完成识别审批的高敏数据应先阻断。

7. 规则要长进系统里

   生成式人工智能服务管理办法主要适用于向境内公众提供服务，不适用于未向公众提供服务的内部研发应用，但这不等于企业内部使用 AI 没有约束。员工承诺书不够，企业至少要把规则嵌入身份系统、数据目录和标签、网关或代理、知识库权限四个位置，并用七个问题做上线收口检查，覆盖业务目的、数据类型、最小化措施、环境类型、供应商数据处理、输出复核及终止后清理。

8. 结论

   企业内部数据能否输入 AI，最终取决于具体任务、具体字段和具体环境。放行条件是目的清楚、数据最小、边界可控、结果有人负责；无法说清时先不要发送，能够被系统验证和日志追踪，AI 才算真正进入企业流程。

文章总结：

文章建议以场景化、字段级、可审计的系统治理替代静态清单，在合规前提下建立可执行的企业 AI 数据使用边界。