企业使用 AI 时的数据安全

越来越多的公司把 AI 接入 CRM、客服、营销、分析和内部知识库。价值越大，风险也越大: prompt 里很快就会出现 个人数据、商业条款、客户沟通内容、合同和内部文档。问题通常并不是来自“危险的 AI”，而是来自薄弱的访问控制、日志管理不当、集成方式粗糙，以及员工缺少明确规则。下面用实务角度说明，企业如何在避免不必要泄露和法律风险的前提下使用 AI。

• 最大风险不在模型本身，而在于发送给它的 数据内容;
• 风险不仅来自外部攻击，也来自 员工和外包方的操作失误;
• 公共 AI 服务并不总适合处理敏感信息;
• 企业需要的不只是 NDA，还包括 访问规则、脱敏和审计;
• 安全使用 AI 依赖技术、流程和供应商合同的共同配合。

为什么这个话题已经变得关键

当企业只是“顺手”使用 AI 时，风险看起来并不大: 员工让模型写一封邮件草稿，经理拿到一份回复模板，市场人员生成一段文案。但在实际工作里，prompt 很快就会包含:

• 客户姓名、电话、邮箱和订单历史;
• 合同、发票、价格和折扣;
• 商业方案和内部制度;
• 代码片段、token、访问密钥和配置;
• 人事数据、简历和员工评估。

如果这些数据被发送到不合适的服务中，未经控制地保存在日志里，或被过多人员访问，那么企业面对的就不再是“AI 小实验”，而是真正的信息安全事件。

哪些数据尤其不适合发送给 AI

并不是所有数据的敏感度都一样。对企业来说，至少可以分成四类:

一个典型错误

员工为了“提高效率”，把客户请求、合同片段或销售表复制到公共聊天工具里。模型也许确实帮上了忙，但企业已经把数据交给了一个自己无法完全控制的外部系统。即使供应商承诺会保护数据，如果没有合同、日志保留政策和访问限制，这仍然是明显的薄弱点。

企业使用 AI 的主要风险

1. 通过 prompt 泄露

最常见的场景，就是敏感数据直接出现在请求文本中。这会发生在销售、客服、人事、财务和开发环节。没有明确规则时，员工往往会向 AI 发送超过任务所需的信息。

2. 日志和请求历史

即使模型的回答本身是安全的，请求日志 也可能完整保存原始数据。当这些历史记录能被多个团队、供应商访问，或者保存时间过长时，问题就出现了。

3. 访问权限过大

如果一个 AI 机器人同时连接 CRM、邮箱、知识库和 ERP，但权限没有被限制，那么一次故障或一次错误 prompt 就可能暴露过多信息。对 AI 来说，“先全部开放，之后再整理” 是特别危险的做法。

4. 供应商和跨境传输

许多模型和 API 运行在其他法域。这会影响个人数据、数据处理协议、日志保留期限以及 subprocessors。对某些场景来说，这不一定是禁止项，但必须有清晰的法律和技术方案。

5. 带来业务后果的幻觉

问题不只在泄露。如果 AI 很自信地编造合同条款、向客户承诺并不存在的折扣，或者错误分类客户请求，企业就会遭受直接损失。因此，AI 安全不仅是保护数据库，也是控制决策质量。

上线前企业该做什么

安全不是在第一次事故发生后才开始，而是在设计阶段就应建立。一个实用的最低标准包括:

1. 梳理使用场景。 谁会把什么数据发送给 AI，目的是什么，数据来自哪里，结果回到哪里。
2. 按敏感度划分数据。 哪些可以发送到公共模型，哪些只能发到企业环境，哪些完全不能发送。
3. 限制访问。 机器人和员工都只能看到完成当前任务所需的数据。
4. 做好脱敏。 从 prompt 中移除姓名、证件号、支付信息、token 和其他不必要标识符。
5. 检查供应商合同。 DPA、日志保留、是否用企业数据训练、处理区域以及 subprocessors 都很重要。

实际可落地的保护措施

员工规则

企业需要的是简短清晰的操作规则，而不是 40 页抽象文件。员工应该明确知道:

• 哪些数据不能粘贴到公共 AI 中;
• 哪些场景必须使用企业内部工具;
• 哪些 AI 回答必须由人工复核;
• 出现错误或可疑回答时应联系谁。

技术措施

对大多数企业来说，以下基础措施很有价值:

• SSO 和基于角色的访问控制;
• 记录 AI 交互日志;
• 自动脱敏个人数据;
• 阻止发送密钥和敏感凭据;
• 在外部 API 前增加独立网关或 middleware;
• 限制从内部系统导出数据。

组织措施

再好的技术也离不开流程。建议明确责任人，负责:

• 审批 AI 使用场景;
• 为新员工和外包方开通访问权限;
• 定期复查角色和权限;
• 复盘安全事件并更新规则;
• 培训团队安全使用 AI。

什么时候应该使用企业级 AI 而不是公共 AI

公共服务并不适合所有任务。以下情况更适合企业级环境:

• 流程中包含客户或员工的个人数据;
• AI 会接触合同、财务数据或内部分析;
• 回答会影响价格、交易条款、招聘或法律上重要的流程;
• 需要控制日志、角色、存储区域，并关闭基于公司数据的训练。

对于敏感任务，很多公司会使用一个中间层: 它先清洗请求、隐藏多余字段、记录调用，再把去标识化后的数据发送给外部模型或内部 RAG 环境。

上线前检查清单

在生产环境上线前，建议确认:

• 是否有清晰的数据地图，说明哪些数据会进入 AI;
• 敏感字段是否已经脱敏;
• 角色和访问权限是否已被限制;
• 是否已签署所需的供应商协议;
• 日志保留期限是否明确;
• 是否存在人工升级处理路径;
• 是否指定了安全事件负责人;
• 员工是否了解基本规则。

总结

企业使用 AI 时的数据安全 不是禁止使用神经网络，而是管理风险。只有当企业清楚 哪些数据可以传输、谁能访问、日志存在哪里、谁对结果负责 时，AI 才真正带来价值。如果在没有这些规则的情况下上线 AI，速度提升很快就会变成泄露风险、罚款和运营错误。与其在事故之后补救，不如一开始就把访问控制、脱敏和人工复核纳入方案。

如果你需要为网站、机器人或内部流程设计安全的 AI 落地方案，可以联系我们。

常见问题

员工可以直接用普通版 ChatGPT 或 Claude 处理工作任务吗

只有在 不涉及敏感数据 且内部规则明确的情况下才可以。如果员工把客户请求、合同、价格信息或内部文档直接贴到公共 AI 中，就会带来泄露风险和法律问题。对于持续处理公司数据的工作，最好使用企业级环境或专门的中间层。

哪些数据不应该在未单独审查前发送给 AI

首先是 个人数据、合同、财务信息、API 密钥、密码、商业条款和内部通信内容。即使模型只是“帮忙起草”，如果没有脱敏和批准流程，发送这些数据也会带来不必要的风险。越容易据此识别个人、客户或系统，流程就越需要谨慎。

只和员工、外包方签 NDA 就够了吗

不够。NDA 有帮助，但不能替代技术防护。 如果员工能访问所有系统，而且没有限制将数据复制到 AI 中，那么纸面文件本身并不能解决问题。企业仍然需要角色权限、日志、数据导出限制和清晰的 AI 使用政策。

如果 AI 已经接入 CRM 和知识库，怎样降低泄露风险

先从最小必要权限原则开始: AI 只能拿到完成任务所需的字段和文档。然后增加个人数据脱敏、交互日志、角色限制，以及在关键场景下的人工作业复核。比较好的做法是在内部系统和模型之间放置独立中间层，用来过滤请求并阻止发送多余信息。

小公司也需要专门负责 AI 安全的人吗

需要，至少需要明确这个职责，而不一定非要单独设置一个岗位。必须有人负责访问规则、场景审批、供应商管理、日志审查和安全事件处理。在小公司里，这个人可以是项目负责人、CTO 或外部承包方，但责任必须明确指定。