ai 合规管理

公司里用 AI 的部门越来越多，工具是各人自己开的，数据发了什么没人说得清，真出事又找不到责任人——这是多数中小企业管理者卡住的地方。这篇不讲法条原文，只给一套从零起步的框架：先盘清用了什么、再划数据边界、然后定审批与留痕、最后安排复检节奏，每一步都附可照着做的动作。

公司里用 AI 的部门越来越多，工具是各人自己开的，数据发了什么没人说得清，真出事又找不到责任人——这是多数中小企业管理者卡住的地方。这篇不讲法条原文，只给一套从零起步的框架：先盘清用了什么、再划数据边界、然后定审批与留痕、最后安排复检节奏，每一步都附可照着做的动作。

注意，这套框架是通用管理口径，不是法律意见。涉及金融、医疗等强监管行业时，具体条款还得找专业顾问对照。

先分清：你要管的是哪一层合规

动手之前先搞清楚，你是因为什么开始管 AI 的。监管来查、大客户在合同里加了条款、还是内部已经出过一次数据发错的事故——这三种起点，工作重点完全不一样。监管压力下，优先补文档和日志；客户问询，优先能证明数据流向；内部出事，优先堵住具体那个口子。

监管压力型

先确认行业有没有明确条文，没有的话按通用数据安全框架准备材料，重点在可举证

客户问询型

把「哪些数据不进外部模型、供应商怎么选」写成两页说明，能直接发给客户

内部事故型

先复盘那一次怎么发生的，把同类场景列出来，逐个定规则，别急着发大制度

管理层要盯的只有三件事：谁能用、能发什么、出事谁负责。至于选哪个模型、是不是最新版本，那是技术执行层面的决定，不用占用管理会议的时间。如果团队完全离线内网跑，不接触任何外部数据，那这套框架里大部分环节可以省略——但前提是真的完全离线，不是「以为离线」。

第一步：把「用了什么 AI」盘出来

这是最容易跳过、也最不能跳过的一步。盘点的目的不是抓人，是搞清楚现状。开始之前，先在全员会上明确说一句：这次只登记、不追责，用私人账号干活的也照实说。否则你收到的表格一定是残缺的，漏掉的那几行往往就是风险最大的。

• 分三张表：官方订阅类（买了席位的那种）、API 接口类（技术团队调的）、内嵌功能类（藏在别的 SaaS 里的 AI 按钮）
• 每行至少记四项：谁在用、用来做什么、数据从哪来、付款方是谁
• 内嵌功能类最容易被忽略，让各部门翻一遍自己常用工具的更新日志
• 盘点结果放进一张共享表格，指定一个负责人，按季度更新
• 表格里留一列「不确定」，允许填不清楚，后续再补

第二步：划出数据分级与可用边界

数据分级最怕做成十几档，没人记得住。对中小企业来说，按「能不能出内网」分三档就够用：可以出、脱敏后可出、绝对不出。这种分法比按敏感词分类好执行，因为员工做判断时只需要问一句：这个内容能不能离开公司网络。

对外部模型的原则写三句话贴在群里：脱敏后可用、原文不出、能本地跑的不走接口。站内 /safety 和 /ai-dict/category/safety 两个页面有术语口径，建议让各部门先对一遍，避免市场部说的「敏感数据」和技术部说的不是一回事。

1. 定档位和各部门负责人开一次会，把三档定义写死，举五六个具体例子，别用抽象描述
2. 写例外流程确实需要发原文时，谁批、批完留什么记录、多久有效，一条条写清楚
3. 贴到日常工具旁把三档判断做成一张图，放在常用工具的收藏夹或群公告里

第三步：工具与供应商的准入怎么定

准入看的不是名气，而是三件事：数据用途条款怎么写、留存策略是什么、有没有企业级管理后台。没有管理后台的工具，员工离职后账号还在，出了问题查不到记录。具体条款怎么读，站内 /guides 里有解读方法，价格和额度到 /price-watch 核对当时的数字，别凭记忆决策。

• 谁能申请：部门负责人提名，技术或合规岗复核
• 谁审批：两级以内，超过两级就会有人绕开
• 试用期多长：建议设一个明确期限，到期必须重新评估
• 到期怎么复评：看调用量、看有没有出过异常、看条款有没有变
• 中转站类渠道单独一类处理，先按 /sites 的检测口径做可信度核验再谈接入

不确定的渠道先小范围试用，别一上来就全公司铺开。试用期里重点观察两件事：它会不会在非工作时间产生调用、额度消耗和实际使用量对不对得上。这两条能筛掉相当一部分不靠谱的渠道。

第四步：审批流与留痕怎么设计

审批要短。流程一长，员工就会想别的办法，私下用私人账号反而更不可控。两级以内是实践里比较舒服的节奏：直属主管确认业务必要性，技术或合规岗确认数据边界。两个环节都在线完成，别做成纸质单子。

留痕记三样：提交了什么、谁批的、结果怎么回传。日志本身也有敏感性，处理思路可以参考站内关于日志脱敏的做法，别把完整请求内容原样存下来。账号与密钥归属公司而非个人，人员离职时按轮换流程交接，这一条最容易漏，也最容易出事。

• 给团队一份「什么要先问」的短清单，控制在五条以内
• 清单里写清楚：不确定时问谁，多久内回复
• 审批记录统一放在一个地方，不要散在邮件和聊天记录里
• 每季度抽查几条记录，看流程有没有被架空

第五步：责任分工与培训怎么落地

至少三个角色：业务侧负责人、数据或合规把关人、技术执行人。不要全压在一个人身上，尤其是小团队里让某个技术同事兼职，最后往往是既没时间也没权限。业务侧负责人管「用不用、用来干什么」，把关人管「数据能不能发」，技术执行人管「怎么接、怎么记日志」。

培训只讲三件事：哪些数据不能发、遇到可疑输出怎么办、出问题找谁。新人入职和工具上线两个时点各做一次，比年度大课有用得多。团队人数极少时，角色可以合并，但保留书面记录，写清楚谁兼了哪些职责。

第六步：日常监测与定期复检

日常盯三个信号：异常调用量、非工作时间的大量使用、突然新增的外部渠道。前两个能提示账号共享或数据外发，第三个说明有人绕过了准入流程。信号不用做成实时大屏，每周看一眼账单和管理后台就够。

每季度做一次小复检：盘点表是否更新、离职交接是否完成、准入表是否过期。出过事的场景单独列出来，在下一次复检里重点看。复检结论写成半页纸，别做成没人看的厚报告——报告越厚，越没人翻。

• 复检前先确认上次的整改项有没有落地
• 盘点表里标出新增和停用的工具
• 抽查三条审批记录，看留痕是否完整
• 把结论同步给业务侧负责人，而不是只发给技术团队

容易踩的坑与不适用边界

最常见的坑是只发一份制度文档就算完事，没有对应动作和负责人。其次是用户一刀切禁用，结果大家用私人账号，反而更不可控。还有一种是把合规全交给技术团队，业务侧不参与，边界永远划不清——因为数据的来源和用途，技术团队根本不知道。

• 制度没有配套动作：写完放文件夹，没人执行
• 一刀切禁用：逼出私人账号，数据风险不降反升
• 责任全压技术团队：业务不参与，边界划不清
• 盘点搞成追责：表格失真，后续全是无效劳动
• 忽视员工离职：账号密钥还在，人已经走了

最后说清楚适用范围。这套框架是通用管理口径，偏流程和组织。涉及具体行业监管要求时，比如金融、医疗、教育，需另行对照专业意见，不能直接照搬。另外，如果公司业务完全不涉及外部数据处理，框架里很多环节可以简化，但「谁负责」这一条不能省。