企业 AI 治理清单，是企业在同时接入多家 AI 服务时，用来逐项检查密钥发放、模型权限、数据边界与预算归账是否到位的检查工具，服务对象是平台团队、安全法务，以及所有要为 AI 费用签字的人。
先说结论：治理的最小单位是「项目」。密钥挂在项目上、预算挂在项目上、每一笔请求记录也挂在项目上——只要一项目一密钥成立，下面 12 个检查项就有一半会自动成立。清单分成四组，按「先止血、再上轨道」排序，可以直接带进落地会议逐条打勾；想先看费用端怎么读，可搭配怎么读懂 AI 账单的三层读法一起看。
一、密钥与身份
1. 一个项目一把密钥——密钥跟着项目走，不跟着人走
同事离职或转岗时，收回的是那个项目的权限，而不是急着更换全公司共用的钥匙。共用密钥是治理里最贵的技术债：出事时你只知道「有人」，不知道「是谁」。
2. 密钥只显示一次，并集中保管——可停用、可回查
发出去的密钥要能随时停用；停用之后，还要能从请求记录回头确认它曾经服务哪些系统、影响范围多大。
3. 区分生产与测试环境——测试额度低到烧完也不心疼
测试密钥的额度上限，应该低到任何人误用都不会变成月底的惊吓。生产密钥则走发放流程，留下审批记录。
二、模型与数据边界
4. 建立模型白名单——换模型是决策，不是改一行代码
不是每个项目都需要最强的模型。白名单让「换模型」成为需要说明理由的决策；平台上有哪些模型可选、各自的计价模式，可以先看模型目录。
5. 定义数据分级——工程师不该每次自行判断
哪些数据可以送进外部模型、哪些必须先脱敏，写成一页文档。参考架构可以对照 NIST 的 AI 风险管理框架，把分级落到字段层级。
6. 记录各家服务的数据保留政策——集中在同一份文档
法务与安全团队要查的时候，答案不应该躺在某个人的邮箱里。
三、预算与归账
7. 在项目层级设置预算上限——先告警、再截断
超标的第一次通知，不应该是月底的账单。
8. 保留逐请求记录——回答「这笔钱是谁、为了什么花的」
每一笔调用都对应到项目、密钥、模型与 token 数，费用才有办法审计。字段细节见用量与费用文档。
9. 每月以同一种单位对账——看趋势，不只看总额
把各家服务的用量换算成同一种单位（例如点数），趋势比绝对数字更早暴露问题。
四、流程与审计
10. 新服务的接入流程标准化——多一家服务只是多一行配置
评估、白名单、密钥、预算四步走完才上线，而不是谁先申请到账号谁先用。
11. 建立事件应急预案——密钥泄露时知道先关哪里
停用密钥、回查记录、换发密钥三步，写成预案并演练一次。
12. 每季度盘点与权限回收——治理是周期，不是一次性项目
每季度重跑一次盘点：哪些项目还活着、哪些密钥三十天没有流量、哪些权限可以收回。
按企业规模怎么套用
10 人以下：先做第 1、7、8 项
小团队不需要委员会，只需要项目密钥、预算上限与逐请求记录——三件事都是配置，不是流程。
50 到 200 人：补上白名单与数据分级
跨部门用量开始分化，第 4、5 项让「谁能用什么模型」有据可查。
500 人以上：流程与审计全上
第 10 到 12 项成为重点，治理从配置升级为周期性制度，并纳入内部审计范围。
按行业场景的三种落地情境
软件与互联网：速度优先，靠默认值治理
用测试环境低额度加上生产环境白名单，让实验跑得快、上线守得稳。
金融与强合规行业：数据边界先行
第 5、6 项先做满，再逐步放开模型使用范围；每笔请求可审计，是内外部审计的共同语言。
制造与客服现场：用量归账决定成败
大量重复性请求让成本归属特别重要，第 8、9 项直接决定 AI 预算能不能续批。
更现代的做法：把清单变成系统的默认值
以上 12 项，传统做法是写成制度、靠人执行；更现代的做法是让治理平台把它们变成默认值。以 ATP Token 为例：组织、工作区到项目的层级本身就是第 1 项；项目密钥天生带白名单与额度，覆盖第 4、7 项；每笔请求自动写入记录，第 8、9 项不需要任何人记得去做。接口兼容 OpenAI、Anthropic 与 Gemini 格式，接入只需更换 base_url 与密钥。
延伸阅读
治理做得好的样子是安静的：实验照跑、账单看得懂、审计有得查。从盘点开始，把密钥、白名单与预算收进同一个管理平面，剩下的交给默认值。