先是那个所有 AI 已经跑起来的企业都会遇到的季度末场景：财务把上百万的模型调用账单推到运营负责人桌上，"这笔钱怎么花的、哪些团队花的、花在什么业务上"，会议室里静默三秒之后，回答永远是"大概有两个团队，有一个是测试环境，其他的回头查"。我见过不止一家公司在这个问题面前来回拉扯，最后发现最尴尬的不是费用高，而是连谁该背这个指标都说不清楚。企业级 AI 治理与 FinOps，几乎都是从这个尴尬的瞬间开始被认真对待的。
这篇文章想聊的，就是当 AI 从"几个工程师的试验品"变成"全公司都在跑的生成式 AI 应用"之后，治理与成本究竟怎么落地。具体来说三件事：第一，AI 成本分摊怎么做才不是走过场；第二，EU AI Act 这类合规要求如何从法律文本变成工程系统；第三，AI Platform Engineering 这门工程实践，怎么把治理能力直接长进平台里，而不是靠一堆审批流程贴在项目上。适合正在或即将负责企业 AI 平台、基础设施、FinOps 或合规工程的同学参考，尤其适合那些"AI 已经开始烧钱、但治理体系还是白纸一张"的团队。
我的核心观点先放在这里：AI 治理和 FinOps 不是两件事，而是同一套数据体系的两个输出口。成本分摊要求你回答"谁用了什么模型、花了多少钱、拿来干嘛"，EU AI Act 这类合规要求的审计证据也包含"哪些系统用了 AI、用于什么场景、由谁负责、出了事怎么追溯"。你需要的不是两套独立的系统，而是一套共享的"AI 资产登记 + 调用链路观测 + 归因数据"底座。下面按我的实操经验，拆开讲。
1. AI 上量之后，治理和成本为什么总是捆在一起
很多团队一开始把 AI 治理理解成"安全部门的事"，把 FinOps 理解成"财务和基础设施的事"，结果两边各做各的，平台工程建设出来一堆互相不通的管子。等到 AI 应用真上了量，你才发现这两个议题根本拆不开。
先说成本侧的变化。传统的软件成本是相对可预测的：服务器按需扩容，存储按量计费，工程师的人天也大致有谱。而生成式 AI 的成本模型换了玩法——一次 API 调用的价格取决于你提交了多少 token、模型生成了多少 token，而 token 数又取决于 prompt 写得多啰嗦、上下文塞了多少文档、模型回答得长不长。同一个业务需求，会写 prompt 的工程师和不会写的，成本能差 3 到 10 倍。这种"单次调用不贵、放大一亿倍就失控"的特性，导致 AI 成了近十年最需要 FinOps 盯防的支出项。
再说治理侧。一旦 AI 能力开放给全公司，你能看到什么荒唐事？销售团队把客户名单粘进免费网页版大模型，研发团队用个人账号调 API 跑数据，某部门自己申请了个云账号租显卡训练内部模型——这就是典型的影子 AI。它带来的问题远不止是账单上多了一笔"神秘支出"，更严重的是你完全不知道什么数据在什么模型里走了一遍。等你被合规审计问起来，连 AI 系统的清单都拿不出来。
1.1 影子 AI：治理缺口的第一张多米诺骨牌
影子 AI 之所以防不住，是因为大多数人只是"想把手头的活儿干完"。你禁止个人使用公共大模型，他们就用匿名邮箱注册；你封锁外部网站，他们就用自己的手机开热点。靠堵永远堵不完，而且堵得越狠，数据从你视野里消失得越快。
合理的解法是给一条"正门"：公司内部提供经过审批的模型网关、统一计费、带审计日志的 AI 工作台，让用 AI 的人可以自助开通、自助申请预算、三分钟跑起来。我见过最成功的做法是内部 AI 门户直接把模型调用做成"开箱即用"，比绕道外网还方便，用户自然就走正门了。影子 AI 不是说消灭就能消灭的，但你可以把新增流量引导到可控的管子里——一旦流量可控，治理和成本分摊才有数据基础。
1.2 成本数据其实就是治理的审计底稿
为什么说 FinOps 数据是治理的底稿？因为合规的本质就是回答四个问题：谁在用 AI、用在哪、数据去了哪、出了问题如何追溯。这恰好和成本分摊要回答的问题完全重叠。
打个比方，传统审计要查"这笔招待费是谁花的、请了谁、为什么请"，AI 合规要查的是"这次模型调用是谁发起的、带了什么上下文、回答被用在了哪里"。前者靠报销系统加发票，后者靠网关日志加调用链路追踪。你做 FinOps 成本分摊时建好的标签体系、请求级日志、归属关系，稍加扩展就是 EU AI Act 或其他合规审计最需要的证据链。所以我把话说死：不管你现在多忙，先把"每一次 AI 调用都能归因到人和应用"这件事做了，它既是 FinOps 的起点，也是治理的起点，一鱼两吃。
2. 成本分摊：让每笔 AI 花费都有责任人
成本分摊是所有 AI 治理里最容易被轻视、但最见功夫的一块。它的目标不是算出一个"绝对精确"的账单，而是让每一笔支出都能快速定位到责任主体，并且让责任主体无法推诿。
2.1 Showback 与 Chargeback：先让数据透明，再谈内部结算
FinOps 里有两种分摊模式：Showback 和 Chargeback。Showback 是只出报告不扣预算，让每个团队看到自己用了多少、花了多少，但实际不从他预算里扣钱；Chargeback 则直接把费用计入部门成本中心，跟部门预算硬挂钩。
我的建议是：第一年只做 Showback。原因很现实——AI 还在快速探索期，如果从一开始就搞内部结算，各部门会因为"怕被扣钱"而不敢用 AI，或者更糟，重新躲回影子 AI。先把账单透明化，让团队意识到成本，并主动开始优化 prompt、换更便宜的模型，这已经赢了一半。等大家的 AI 用量稳定下来、Cost Center 边界也理清了，再过渡到 Chargeback 也不迟。见过一上来就 Chargeback 的公司，结果发现分摊逻辑本身一堆争议，所有团队都在吵"凭什么这算我的"，治理反而瘫痪了。
2.2 分摊维度设计：越少越好，但必须能对上责任人
设计标签维度时最大的错误是贪多求全。我见过某团队一口气定了 30 多个标签，结果连基础设施的同学自己都填不齐，最后标签覆盖率不到 40%，等于白做。我的经验是：统一强制标签控制在 6 到 8 个，每个标签都必须有明确的枚举值，并且绑定到组织架构。
| 标签 | 必填 | 说明与建议枚举值 |
|---|---|---|
| cost_center | 是 | 对应财务口径的成本中心/部门编码 |
| app_id | 是 | 业务系统/应用标识，对应平台上的注册应用 |
| env | 是 | production、staging、test，至少三分 |
| owner | 是 | 该应用或系统的负责人邮箱 |
| model | 是 | 模型名称，网关自动补全，无需人工填 |
| feature | 否 | 功能入口标识，用于定位产品功能级成本 |
| user_group | 否 | 内部、外部客户、合作伙伴等 |
注意 model 这个标签可以由网关自动打，不用人填。feature 和 user_group 是可选的，因为粒度越细成本越高，先把必填项保证好，再逐步加维度。一个基础原则是：每个标签存在的意义必须能回答"这笔钱归谁、为什么归他"，答不上来的标签就是噪音。
2.3 从网关日志到分摊账单：一条完整的数据链路
有了标签还不够，你得把"一次模型调用"从发生到进入账单的链路打通。真实的链路是这样工作的：
- 所有模型请求统一经过内部模型网关（Model Gateway），网关强制校验必填标签，缺失的直接拒绝或丢进"未分摊池"。
- 网关记录每次调用的明细：用户、应用、模型、输入输出 token 数、是否命中缓存、耗时、错误码。
- 计费模块根据模型单价计算单次调用成本。单价表从模型供应商处同步，研发和财务能看到同一个口径。
- 每日定时任务把明细聚合到数据仓库，按 cost_center、app_id、env 等维度产出分摊报告。
这里要强调一点：云账单上的 AI 费用往往是"按资源汇总"的，比如某个模型部署实例的总费用，而网关日志是"按请求明细"的。两者的对账机制必须提前设计。你可以为每个模型部署实例打上唯一标识，在云账单和网关日志里都带上这个标识，每天做一次总额对账，差额超过 5% 就要告警。我见过因为没做对账，云厂商账单和网关统计差出 30%，最后连账本都不知道信谁的。
为了让你对数量级有感知，举个简化的成本计算例子：假设某个复杂 RAG 任务，系统提示词加检索上下文一共 2 万输入 token，模型输出 8 千 token，按某主流旗舰模型输入约 5 美元/百万 token、输出约 15 美元/百万 token 计算，单次成本是(20000 * 5 + 8000 * 15) / 1000000 = 0.22美元。单次看着不高，但如果这个功能一天被调用 50 万次，一天的模型成本就是 11 万美元。同样的功能，如果把系统提示词压缩 50%、引入 prompt 缓存，成本立刻可以降 40% 以上。这就是为什么 FinOps 工具必须落到 token 粒度，而不是只看总量。
2.4 最容易吵起来的三个分摊场景
实际分摊中，总有几类费用让各个团队互相扯皮。提前想清楚处理原则，能省掉大量沟通成本。
场景一：prompt 缓存命中。多轮对话和 RAG 里，缓存命中的 token 价格往往只有原始价格的 10% 甚至更低。节省下来的钱算谁的？有些团队认为是"第一个发起查询的人"的功劳，有些认为是"所有复用者"共享。我的建议很简单：统一按"谁发起的调用谁承担最终账单"来算，但缓存命中节省的部分单独一列展示，让主动设计复用模式的团队能被看见。不是每个团队都认这个理，但至少账算得清。
场景二：共享微调模型。公司微调了一个垂直领域模型，多个部门共用。推荐用"调用次数占比"来分摊，而不是按用户数或部门人头数平摊，因为不同团队的单次调用 token 量差异可能非常大。
场景三：平台基建费。网关、向量数据库、GPU 池、模型血缘服务这些"公共设施"的费用，很难直接归属于某个业务。我的经验是按各应用的实际 token 消耗占比来分摊，同时给平台基建一个固定的"平台税"比例（比如 10%），向所有业务方公开透明展示。
此外一定要设一个"未分摊池"：那些标签缺失、无法归因的调用，单独挂账，并生成报表直接发给各成本中心负责人和 CFO 看。让"无主成本"变得刺眼，往往比任何强制手段都有效。我们团队后来把未分摊率从最初的 25% 压到了 2% 以下，靠的就是这张让领导直皱眉头的"糊涂账清单"。
3. EU AI Act 合规：把法规要求翻译成工程动作
EU AI Act 是目前全球为数不多把"AI 系统"作为监管对象进行分级规范的法规，凡是向欧盟市场投放或提供 AI 服务的企业，包括欧盟境外供应商，基本都在适用范围内。它最核心的逻辑是"风险分级"：不同风险等级的系统，承担完全不同的义务。对工程师来说，这其实是个好消息——它给了你一个清晰的框架去判断"这套系统到底要做到什么程度才算合规"。
3.1 先做用例盘点，别急着给所有模型上全套保险
合规工作的起点不是买工具，而是盘点：你公司目前在生产环境跑的所有 AI 系统，逐一登记并做风险分类。这里最容易犯的错误是"把所有 AI 系统都当成高风险来对待"——那不是合规，那是自断手脚。
按照 EU AI Act 的基本分类框架，从企业的角度可以这么理解：
| 风险等级 | 典型场景举例 | 企业需要做的 |
|---|---|---|
| 不可接受风险 | 法规明确禁止的少数操纵性、利用弱势等做法 | 停止使用，没有商量余地 |
| 高风险 | 招聘筛人、信贷评估、教育评分、关键基础设施管理、司法等 | 全面义务：风险管理体系、数据治理、技术文档、日志留存、人工监督、注册登记 |
| 有限透明度风险 | 聊天机器人、AI 生成内容、深度合成 | 向用户披露"你在跟 AI 交互"、标注 AI 生成内容 |
| 低风险/最小风险 | 代码补全、内容总结、内部效率工具 | 基本无强制义务，但建议做最佳实践 |
关键点在于：风险分级针对的是"用例"而不是"模型"。同一个大模型，用来做代码补全可能只是最低风险，用来筛选简历就可能是高风险。所以你的 AI 系统台账里，每条记录必须填清楚使用场景、输入输出、涉及的个人数据、决策是否影响个人权益，由平台负责人和业务负责人共同签字确认风险等级。
3.2 合规证据是"跑出来的"，不是"写出来的"
很多团队把 EU AI Act 当作文档任务，找咨询公司写一套厚厚的制度文件就以为完事了。这是最危险的误判。这套法规的核心在于持续性的证据，审计查的一定是：你能不能实时拿出模型版本、训练数据说明、调用日志、人工监督流程记录、风险监测报告。
打个比方，传统食品安全检查要看你的厨房干不干净，但更看你的食材来源记录、温度监控曲线、抽检数据是不是连续的。EU AI Act 在某种意义上就是这个逻辑：它要求高风险 AI 系统在全生命周期里留下运行证据，包括自动记录的日志、定期的人工审查记录、部署后的持续监控结果。
所以工程上你需要准备的是"证据管线"而不是"文档库"。具体来说至少要有：
- 系统登记与变更记录：每个 AI 系统从立项到上线、到升级，所有环节都留痕。
- 模型卡片（Model Card）：每个模型的技术文档，包含用途、训练数据范围、已知限制、测试结果。
- 运行日志留存：高风险系统的关键调用日志按合规要求留存，还要防篡改，日志必须上只读存储。
- 人工监督记录：系统自动决策的关键节点，人审结果要可检索。
- AI 内容标识机制：面向用户的 AI 生成内容要有披露和标识的机制。
这套管线的成本和 FinOps 共享度极高——大多数日志监控基础设施可以复用，关键是数据保留策略要单独配置，不要用默认的"删了就行"。
3.3 把合规检查嵌进 CI/CD 和日常运维
合规要求一旦变成文档，就会迅速过时。把它变成代码和流水线的一部分，才能保证"不会忘"。
我在团队里推的做法是"合规护照"机制：每个 AI 系统在上生产之前，必须生成一份合规护照，里面记录风险等级、负责团队、数据集来源、人工监督方案、日志留存策略。 CI/CD 流水线里加一道门禁：没有合规护照的 AI 服务根本部署不到生产环境。听起来像是"加了一道审批"，但它比人工审批靠谱得多——因为机器不会因为"老板今天着急上线"就跳过检查。
一个简化版的合规护照配置长这样：
apiVersion: ai-governance.example.com/v1 kind: CompliancePassport metadata: name: resume-screening-api labels: app_id: hiring-portal cost_center: hr spec: riskLevel: high useCase: resume-screening dataGovernance: piiInvolved: true dataSources: [applicant-db] retentionDays: 180 oversight: humanReviewRequired: true humanReviewNode: hr-review-queue logging: enabled: true tamperProof: true transparency: userDisclosure: true status: valid: true lastReviewed: 2025-06-01这份护照既是合规证据，也是 FinOps 里 app_id、cost_center 的标签来源——治理和成本在资产登记层面就统一了。合规水印、AI 生成标注这类"透明度义务"也可以在网关层统一注入，而不是让每个业务团队各做各的。
3.4 合规成本也要计入 FinOps 账单
合规是有成本的，而且这些成本经常被忽略：日志留存要买存储、防篡改要上加密和审计、人工监督要占用业务专家的时间、偏见检测要跑测试、透明度标识要改前端。这些都属于"治理成本"，理应纳入预算。
我在实际运营中把合规成本分成三类：一次性建设成本（工具和流程搭建）、持续运行成本（存储、算力、人审工时）、事故处置成本（发现问题后的修复和上报）。前两者可以在 FinOps 月报里单列一个"治理成本"分类，让管理层直观看到"花在合规上的钱产生了什么保护"。当合规成本被看见，才会被优化——比如日志分级存储策略（不同风险级别不同留存量）就能直接省下一大笔存储费。
4. AI Platform Engineering：把治理能力长进平台里
AI Platform Engineering 不是一个新名词包装的旧概念。简单说，它指的是用平台工程（Platform Engineering）的方法论去构建企业内部的 AI 基础设施：把模型接入、权限控制、成本护栏、可观测性、合规门禁都变成平台能力，让业务团队可以自助消费，而不是每次都要找平台团队手把手开通。
平台工程圈有句老话：好的平台让"做正确的事"变成"最简单的事"。这句话放在 AI 治理上再合适不过——治理规则如果只是写在制度里，一定会被绕过；但如果把它做成平台的默认能力，开发者在不知不觉中就完成了合规和成本控制。
4.1 平台工程的黄金路径，AI 同样适用
传统平台工程讲"黄金路径"：为开发者提供一条默认推荐、经过验证、开箱即用的技术路线，让大多数项目顺着这条路走就能上线。AI 平台的黄金路径应该包含：统一模型网关、标准化的模型调用 SDK、日志和追踪自动接入、预算配额自动生效、合规护照自动生成。
我们内部落地的一个典型设置是：开发者注册一个新的 AI 应用时，平台自动分配 app_id 和 cost_center，自动创建模型网关的访问凭证，自动设置预算告警阈值，自动生成合规护照模板。整个流程 10 分钟走完，开发者感觉不到"治理"的存在，但每一步都被记录了。这样团队就不需要为了用上一个新模型去申请五六个权限，也不用因为接入方式不同而绕过平台。
4.2 模型网关：成本控制与策略执行的咽喉
模型网关是所有 AI 流量的必经之路，它是整个治理体系里最关键的"咽喉要道"。只要所有请求都从这一个口子过，就能同时完成四件事：模型路由与降级、预算实时控制、访问策略执行、全量调用日志。
预算实时控制这块特别值得说。很多团队做 FinOps 只在云账单层面设预算告警，那是"事后看到账单才知道超了"。真正的成本护栏需要前置到网关：每次调用发生时实时累计应用当日/当月消耗，达到阈值的 80% 告警、100% 直接熔断或降级到廉价模型。以我们自己的经验，网关层预算护栏把"月底账单超支"的意外减少了 90% 以上。
一个配置化实现预算护栏的思路大致如下：
budget_guard: scope: app_id limits: daily: 500 # 美元 monthly: 10000 # 美元 actions: at_80_percent: [notify_owner] at_100_percent: [block_new_requests, fallback_to_cheap_model] exclusions: - service: billing-etl reason: offline-batch-ignored需要提一句：网关上的策略最好用策略即代码（Policy as Code）管理，比如 OPA（Open Policy Agent）加 Rego 语言。把"哪些应用能用哪类模型""谁能调用外部模型""预算上限是多少"都写成代码、走 Git 评审，审计时可以翻出每一次策略变更的提交记录，比在控制台里手点十几次安全得多。
4.3 Agent 与 RAG：真正的治理盲区
单次模型调用好管，模型网关记一笔日志就行。但今天越来越多 AI 应用是 Agent 形态——一个业务目标由模型自行拆解成多个步骤，调用多个工具，循环执行。这正是治理和成本控制最容易失守的地方。
先说成本。Agent 的"自主循环"有一个经典风险：某个 Agent 在执行任务时陷入循环，不断地调用模型、调用工具、得到反馈、再调用，如果没有人给它设置上限，成本可能在一小时内翻几十倍。我在生产环境就见过一个加班场景：一个文档自动化 Agent 的调试任务因为 prompt 设计有缺陷，3 小时内产生了 4000 多次调用，烧掉上千美元，直到开发同学下班关机才发现。后来我们在平台层面对 Agent 增加了三类护栏：单次会话的最大迭代次数限制、单次会话的预算上限、关键工具调用的逐步人工确认。
再说治理。Agent 能调用的工具可能包括读取内部数据库、发邮件、改文件——这些动作的权限范围必须遵循最小权限原则。平台需要给 Agent 提供"沙箱化的工具凭证"：Agent 只能调用它被授予的那几个工具，而不是用开发者账号的全部权限。权限模型上，我们采用了按会话临时授权的模式：Agent 每次需要调用敏感工具时，请求一个短期 token，用完即失效，避免 Agent 在循环中不断获得新的权限。
RAG 的治理盲区则在数据侧。向量库里究竟放了哪些文档、这些文档有没有权限边界，是很多团队忽略的。我在审计中见过把合同、薪资制度、未公开财报一股脑塞进向量库做"全员问答"的案例。正确的做法是：RAG 索引必须继承源系统的权限标签，检索时先过滤后返回，同时在网关日志里记录检索命中了哪些文档。这个设计不仅关系数据安全，也直接影响成本——检索范围越精确，塞进上下文的 token 越少，成本越低。
4.4 自助式 AI 工作台：让"做正确的事"成为默认选项
治理的最终目标不是限制，而是让开发者和业务用户都能安全、高效地用 AI。自助式 AI 工作台是收敛影子 AI 的最有效手段：内部提供一个统一入口，用户可以自助选模型、配置 prompt、申请预算、查看自己的消耗账单。
我比较推荐的形态是"一个门户、三类用户角色"：研发人员通过 API 接入平台，分析师通过对话式助手处理数据，普通员工使用受限的 AI 工具完成文档撰写、翻译等轻量任务。不同角色的模型权限、数据权限、预算包都不同，但都走同一套治理底座。
这类工作台的隐性收益是"治理数据的自动积累"。用户在使用过程中产生的每一次调用、每一个反馈、每一个低质量结果标注，都会沉淀为平台数据，反过来帮助平台团队优化模型路由策略、预算分配和合规风险识别。治理不是一个静态的门禁，它应该像一台持续学习的机器。
5. 90 天落地路线图与避坑经验
讲了这么多，最后给一个可以直接用的落地框架。如果你们公司现在 AI 用量已经起来了，但治理体系还是零，我建议按 90 天三阶段推进。不用追求一步到位，先跑通最小闭环，再逐步加码。
5.1 三阶段框架：盘点、分摊、收敛
| 阶段 | 时间 | 核心任务 | 关键交付物 |
|---|---|---|---|
| 第一阶段：盘点 | 第 1-4 周 | 建立 AI 系统台账，连通网关日志，识别所有生产环境 AI 调用 | AI 系统清单、首个成本基线报告、未分摊成本清单 |
| 第二阶段：分摊 | 第 5-8 周 | 统一标签体系，上线 Showback 报告，建立预算告警 | 成本标签规范、周级分摊报表、80%/100% 预算告警 |
| 第三阶段：收敛 | 第 9-13 周 | 启用网关层预算熔断，搭建合规护照门禁，治理成本入账 | 实时预算护栏、合规护照流水线、治理成本月报 |
每个阶段的验收标准都要明确。比如第一阶段的验收不是"建了台账"，而是"你能在 10 分钟内回答：上个月生产环境一共有几个 AI 系统、谁在调用、总成本多少"。回答不上来就不算过。
5.2 我踩过的几个坑
这些坑都是真金白银换来的经验，按"踩的频次"排序：
第一个坑：标签体系上线太晚，历史数据彻底无法追溯。我们一开始只在云账单层面做了资源级标签，等想往前回溯三个月的 AI 成本时，发现网关日志没有留存请求级归属字段，什么都查不出来。所以我现在逢人就说：标签和日志留存一定要在"第一笔大额 AI 账单出现之前"就设计好，这种事没有后悔药。
第二个坑：把分摊维度设计得过于复杂。前面提到过 30 多个标签的失败案例。复杂标签体系的下场就是覆盖率极低，最后报表里 60% 都是"未分摊"，等于白做。少而精、强制必填、网关自动打标签，这三条比任何激励都管用。
第三个坑：预算护栏只做在云账单层，没做在网关层。云账单告警是 T+1 甚至 T+2 的，等你看到告警，钱已经烧完了。很多厂商云账单延迟一天是常态，而一次 Agent 失控循环可能一小时就烧掉大几百甚至上千美元。所以关键不是"事后告警"，而是"事前熔断"——预算护栏必须做在实时链路上。
第四个坑：把合规工作当一次性项目。EU AI Act 这类法规的执行是持续性的，系统一升级、模型一换版本、使用场景一变，合规状态就变了。我见过团队年初做完合规认证，年中被审计一查，发现半年里新增了十几个 AI 应用完全没走合规流程。这就是缺乏"流水线门禁"的代价。
第五个坑：靠"堵"来解决影子 AI。越是禁止，越容易把 AI 使用逼到不可控的地方。正确做法是让企业内部的 AI 平台比外部工具更好用、更便宜（因为成本中心承担了）、更安全，让用正门成为开发者唯一有吸引力的选择。
5.3 用哪些指标判断治理体系是否在运转
最后给一套我自己在管理层汇报时使用的指标，不需要多，但每个都必须能持续追踪：
| 指标 | 计算方式 | 健康目标 |
|---|---|---|
| 成本归属覆盖率 | 已分摊到责任方的 AI 成本 / 总 AI 成本 | >= 95% |
| 资源浪费率 | 空闲算力 + 未分摊池成本 / 总 AI 成本 | < 5% |
| 合规护照覆盖率 | 有有效护照的生产 AI 系统 / 全部生产 AI 系统 | 100% |
| 预算违规次数 | 每月撞破预算阈值的应用数 | 趋近于 0 |
| "谁花了什么"响应时间 | 从提问到给出可审计答案的耗时 | < 15 分钟 |
| 单位 AI 成本趋势 | 每万 token 的综合成本月度环比 | 持续下降 |
这六个指标里，前三个是治理有效性的硬指标，后三个反映的是运营效率和优化空间。管理层不太关心过程，但非常关心"覆盖率是否在提升、浪费是否在减少、每个业务单元的 AI 单位成本是否在下降"。把这三类问题答好了，你的治理项目就能长期拿到资源。
最后再分享一点我个人的体会。AI 治理和 FinOps 这件事，最忌讳的是把它当成一个"项目"，好像做完就结束了。它更像一套持续演进的基础设施——今天你做的标签体系、网关日志、合规护照，半年后可能都要随着 Agent 形态、新法规、新成本模型而迭代。我自己的经验是，不要试图一年之内把所有东西都做到完美，先把"可归因、可分摊、可门禁"这个三角跑起来，后续的一切都会顺很多。等哪天你接到领导电话问"这个月 AI 花了多少钱、谁花的、合不合规"，你能在 15 分钟内给出一个带证据链的答案，那时候你就知道，这套东西真的值了。
