企业数据安全管理制度

团队开始用 AI 工具、接第三方 API 之后，数据从哪出去、谁能看、留多久，往往没人说得清。等出事再补制度，成本高得多。这篇不聊概念，直接给一套能落地的框架：先划数据分级，再定使用与流转规则，然后落到账号权限和日志留存，最后给一份自查顺序。适合 5 到几百人、刚开始把 AI 接进日常工作的公司对照着改。

团队开始用 AI 工具、接第三方 API 之后，数据从哪出去、谁能看、留多久，往往没人说得清。等出了事再补制度，成本高得多：客户问起来答不上，审计要材料拿不出，内部也不知道该追谁的责。这篇不聊概念，直接给一套能落地的框架，适合 5 到几百人、刚开始把 AI 接进日常工作的公司对照着改。

框架顺序是：先划数据分级定边界，再定使用与流转规则，然后落到账号权限和日志留存，最后给一份自查顺序。制度写多长不重要，重要的是每条都能回答「谁在什么情况下该做什么」。下面每节都配了判断标准和可执行动作，你可以直接拿去改自己公司的文档。

先定边界：管什么数据、分几级

制度的第一件事不是写条款，而是划范围。范围不清，后面所有规则都会打架：业务觉得这条管不着，IT 觉得那条该业务管。建议先把公司数据按敏感度分档，每档写清能不能发到外部模型、能不能进第三方工具，让一线员工不用靠猜。

• 分级判断看泄露后果，不看文件大小或所属部门：影响钱和客户往敏感以上放，只影响内部效率放内部。
• 覆盖对象要写全：员工电脑之外，还包括 API Key、中转站账号、云盘、协作工具、日志与备份。
• 每档至少回答两个问题：能不能发到外部模型、能不能进第三方工具，答案要具体到动作。
• 不适用的情况：只有一两个人的极小团队不必写长篇制度，但至少把「哪类内容不许贴进外部工具」写成一句话贴在群里。

使用与流转规则：什么能发外部，怎么发

分级定完之后，规则要落到「怎么发」上。很多公司制度写了「敏感数据不得外泄」，但员工照样把整段内容贴进对话工具，因为没人告诉他什么算外泄、走哪个审批。规则要给出三档动作和明确入口，而不是一句禁止。

允许

对应档位的数据可直接用于外部服务，无需额外动作。

需审批

默认不允许，但可提交申请，写明用途、数据类别、接收方和保留方式。

禁止

任何情况下不得外发，替代方案是本地处理或脱敏改写。

1. 先脱敏再外发能去标识化的先去标识化，能本地跑的优先本地跑；验证方法是抽查一批调用记录，看是否还有原始敏感字段。
2. 管住 Key 与账号明确谁申请、谁持有、离职或换人怎么交接、多久轮换一次；验证方法是拉一份 Key 清单，核对是否还有离职人员名下的。
3. 设定审批入口和时限写清提交路径、需要谁批、多久内给答复，避免流程卡死业务；验证方法是跑一次真实申请，看是否在承诺时限内闭环。

不适用的情况：业务确实必须传原始数据时，不要一刀切禁止，而是走单独的评估与审批，并留下可追溯记录。一刀切的结果通常是员工绕开流程，反而更查不到。

谁负责：把责任落到岗位而不是「大家注意」

数据安全最容易失败的地方，是制度写了但没写谁执行。出事时找不到决策人，审批没人接，规则就会自然失效。做法是把责任拆到具体岗位，而不是笼统写「全体员工应遵守」。

• 把数据安全要求写进新员工入职和工具开通流程，而不是等培训会上提一句。
• 审批入口要固定一个人或一个邮箱，避免「找谁都行」等于「找谁都不行」。
• 例外要留痕：谁批的、为什么批、有效期多久，到期自动失效。
• 不适用的情况：小团队可以由一人兼多职，但职责条目仍要写下来，防止无人认领。

留痕与自查：怎么知道制度有没有在跑

制度上线不是终点，能不能查才是关键。留痕要有目的：不是为了存一堆日志，而是为了在出现问题时能还原「谁在什么时间把哪类数据发给了哪个外部服务」。记录类型、留存期限、访问权限三件事要一起定。

• 必须留的记录：外部服务调用记录、传输的数据类别、审批记录、Key 的发放与吊销记录。
• 日志本身也可能含敏感内容，脱敏和访问权限要一并管，不能谁都能导。
• 留存期限和删除方式提前写清，避免无限期堆积带来的合规风险。
• 自查节奏固定下来：每月看异常调用和权限清单，每季度做一次流程演练。

1. 第一步：核对账号与 Key拉全量清单，看有没有多余项、离职人员名下项、长期未轮换项。
2. 第二步：核对调用记录按数据档位抽查调用，看有没有越档外发、有没有绕过审批的路径。
3. 第三步：核对审批与留痕把审批记录和实际调用对上，缺审批、缺记录的要补流程而不是补文档。
4. 第四步：输出整改清单每条问题写清责任人和完成时间，下次自查先看这张清单。

如果你还想横向看看不同服务的调用与鉴权方式有什么差别，可以到站内的工具目录和价格追踪页面核对当时的对比信息，再决定哪些服务适合放进公司的白名单。