【摘要】9月首周，微信支付AI支付内测推进、印度筹备UPI代理支付框架、EMVCo发布代理卡支付框架草案（反馈截止9月30日）。AI从"建议"走向"执行"。本文拆一个反直觉的数学题、三道防线，和一份可直接抄的授权矩阵。
周二那篇讲结账AI 化，我给了一条建议：别追求 100% 准确，先定义你能接受的误差上限，Genpact 给的对账首过率是 95%，剩下 5% 交给人。
那条建议在结账场景里是对的。今天我要告诉你它在什么场景下会要命。
昨天讲的是货物背后的数据链，今天讲另一条链——授权链。
一、先别看新闻，先看你自己的账
你可能觉得"AI 替企业付钱"这件事离你很远。
那我换个问法：这个月，你公司里有多少笔钱，是员工用某个AI 工具下的单？
市场部的同事让AI 助理续订了设计软件的年费。运营在用带自动下单功能的插件买投放额度。采购部门试用的某个智能体，可以直接在平台上完成比价和提交订单。行政的会议室预订、差旅工具，也都在陆续接入自动执行能力。
这些钱走的是公司的卡，走的不是公司的审批流。
UOB 建立 AI 治理体系时，第一件事是建一份全行 AI 用例的中央清单，理由说得很直白——"我们要确保没有任何东西在影子里运行"（nothing operates in the shadow）。
你公司的影子里，现在有多少个正在花钱的智能体？
如果这个问题你答不上来，那么后面的内容和你有关，而且很急。
二、九月第一周，三件事同时发生
三件事源头不同、路径不同，但方向完全一致：AI 正在从"建议"走向"执行"，而执行的第一个大规模场景，就是花钱。
微信支付：内测推进，克制而聪明。早在2026 年 4 月，微信支付就已发布面向 AI 的支付接入体系——Skill 技能包、AI 友好文档、AI 友好 API 三件套，路径是"唤起 AI、加载 Skill、说出需求"。目前 AI 支付处于内测推进阶段，商户文档中心已开放接入指引。
它的设计有两点特别值得学：支付资金与用户主余额隔离，以及支付需要在手机端做最终确认。前者限制了损失上限，后者保留了人的否决权。它选的不是"让 AI 自由花钱"，而是"让 AI 在一条划定好的小河里花钱"。
印度UPI：更激进的路线，但仍在筹备。 据路透 9 月 1 日援引消息人士报道，印度正在准备一套框架，允许 AI 智能体在不需要用户逐笔确认的情况下完成小额支付。用户可以设定智能体能花多少、什么时候能付。控制手段包括支出限额、身份验证、审计轨迹和商户接入。
请注意这是"正在准备"，不是已经落地。但它代表了一种姿势：我不管你每一笔，我管住你的上限、你的身份、你的痕迹、你能碰的商户。规则由人定，执行由机器做。
EMVCo：把"意图"变成一层基础设施。 9 月 1 日，制定银行卡国际标准的 EMVCo 发布了《EMV 代理支付——规范框架》草案 v1.0，公开征求意见至 9 月 30 日。
它要解决的问题极其底层：怎么确认消费者把购买权"委托"给了 AI，以及这个意图如何在时间中保持有效。它聚焦的正是意图需要长期管理的场景——经常性购买、累计预算、交易后活动（比如退货、改单）。
草案提出的核心概念叫"意图服务"（Intent Services）：一个共享的、可互操作的层，让支付各方能在交易前、中、后注册、引用、检索和管理经消费者授权的意图。EMVCo 还提到未来可能纳入"了解你的智能体"（Know Your Agent，KYA）和代理交易标识——用来识别一笔交易背后到底是哪个智能体、它有什么属性、它是否代表某个人在行动。
KYC 之后，是 KYA。 这个词今年可能还很陌生，三年后大概率会出现在你的内控制度里。
顺带一提，草案的公众反馈期到9 月 30 日截止。如果你所在的企业是支付链条上的一环，这是行业标准定型前少有的发声窗口。
三、那个反直觉的数学题
现在回到开头。
周二我说，健康的财务AI 不是无人化，是例外管理——AI 兜住 95%，人打那 5%。
UOB 的 Alvin Eng 给了一个补丁，我认为是这半年关于智能体最重要的一句话：
"如果你有一个 95% 准确的智能体，听起来还不错。但如果你把十个串起来，整体表现会迅速下降到 60% 以下，这对大多数场景来说都不够好。"
算一下：0.95 的十次方，等于 0.599。
这就是单体准确率和系统准确率的区别。
一笔代理支付背后通常不止一个环节：理解需求、检索商品、比价、确认规格、下单、发起支付、处理回执。每一环都可能是一个智能体，每一环都有自己的错误率。你验收的是单个环节的95%，你承担的是整条链的 60%。
Eng 的原话是：智能体的错误会在系统中累积并传播（errors compound and propagate）。
所以周二那条建议要加一个前提："接受 95%"只适用于错误可以在事后被发现并修正的场景。
结账就是这样的场景——过程中的错误可以在关账前改，不可逆的只有最后那一步关账。
而支付不是。钱一旦出去，就出去了。
这就是为什么同一个"95%"，在结账场景里是合理的验收标准，在支付场景里是不可接受的风险敞口。
它同时解释了代理支付的风险形态：小概率× 高频次。单笔出错率哪怕只有万分之一，一家企业一年上百万笔交易，就是上百次错误支付。这种形态，传统的"抽检"和"事后对账"都拦不住——必须在授权环节就设防。
四、为什么这件事必须CFO 管
我猜有人会说：这是支付工具的事，让IT 去评估。
恰恰相反，第一责任人必须是CFO，理由有三个。
第一，它直接动钱。IT 管的是系统能不能跑通，CFO 管的是钱会不会出错。代理支付一旦出错，那是财务损失，不是技术故障。
第二，责任归属目前是空白。AI 付错了一笔钱，谁负责？批准它的员工？开发它的供应商？部署它的公司？全球范围内这个问题都没有定论——EMVCo 起草框架、印度做监管沙盒，本质上都是在填这个空。而在标准落地之前，这个空白默认落在企业自己头上。
第三，UOB 给出了组织答案。它把 AI 治理放进了银行成熟的三道防线：第一道是业务部门，业务拥有 AI 的产出，也拥有 AI 的风险——用 Eng 的话说，"我们不把责任外包给技术部门"；第二道是独立的 AI 与数据风险职能，负责挑战、政策制定、监督和升级；第三道是内审。最上面，"高管和董事会始终是最终责任人，跑不掉"。
注意第一道防线的位置：不是IT，是业务。在财务相关的代理支付上，那就是财务自己。
五、防线一：授权——把"能花多少"写死
道理讲完，给可以直接抄的东西。
第一层，分层限额，别只设一个总额度。
至少要有三层：单笔上限（一个智能体单次最多能付多少）、日或周累计上限（一段时间的总天花板）、异常触发线（单笔超过某个金额自动转人工）。
微信支付的"资金隔离"思路在企业里同样适用：给智能体开一个独立的资金账户，账户里的钱就是它的损失上限。这个设计简单、粗暴、极其有效。
第二层，品类白名单比金额更重要。
给一个可以直接改数字的示例矩阵：
可全权授权——办公软件订阅续费，单笔 5000 元以内、日累计 2 万元封顶，仅限白名单供应商；
可授权但需事后复核——差旅预订、云服务扩容，单笔 1 万元以内，超出转人工，每笔次日进复核清单；
永不授权——供应商货款、员工报销打款、合同尾款、跨境支付、任何新供应商的首笔付款。
判断标准只有一条：这笔支出错了，能不能无损撤回？能撤回的可以给AI，不能撤回的必须留人。
第三层，保留关键操作的二次确认和"急停开关"。
微信支付保留手机端最终确认，不是保守，是必要。UOB 对高风险应用的做法是两条：人在环路中（human in the loop），以及kill switch（急停开关）。
Eng 强调了一个很多人会忽略的点：护栏不只是技术护栏，还有流程护栏——人在哪个节点必须介入、以什么方式介入。而且急停开关必须被测试过。一个太慢的、真实条件下会失灵的、或者按下之后员工不知道该怎么办的开关，等于没有。
不要为了"全自动"的观感把这些开关关掉。全自动不是先进，是风险裸奔。
六、防线二：审计——让每一步都留痕
第二道防线解决的是：出了事，你能不能还原现场。
每个动作都要有日志，至少记五项：时间、动作、对象、触发依据（依据哪条规则、哪条指令）、结果。其中"触发依据"最容易被漏掉，也最关键——事后追责时，你要能说清楚"它为什么这么做"。
Kyndryl 与瑞士 Incore Bank、Google Cloud 那个概念验证里，技术方案的核心正是这个：用策略即代码（policy-as-code）加护栏智能体，最终产出的是"可审计的决策记录"（auditable decision records），供合规人员使用。产出物不只是结果，是结果加上它的理由。
日志必须独立于智能体存储。如果日志存在智能体自己的数据库里，理论上它可以被修改。最好是一次写入、不可更改的存储。这一点在财务领域的对应物很清楚：记账的人不能自己保管凭证。
建立"AI 行为对账"机制。就像每天对银行流水一样，定期把智能体的动作日志和资金系统的实际流水做勾稽，看有没有"日志里没有、钱却出去了"或者"日志里有、钱没出去"。高频支付场景建议每天一次，其余每周一次。
再加一条中央清单。参照UOB：公司里所有会花钱的智能体，必须登记在册，注明责任人、额度、适用范围。没登记的，一律不许接支付权限。
这一条能解决本文开头那个问题——你至少知道影子里有什么。
七、防线三：责任——在合同和制度里写清楚
第三道最容易被忽略，但它决定了前两道失效时你站在哪。
对外，与AI 服务商的合同至少要明确四件事：出错时的赔偿责任上限；服务商的数据安全义务；审计权，即你有权调取全部日志和操作记录；终止条款，即发现问题时你能多快把它关掉。
对内，责任划分必须在部署之前定。员工批准了智能体、智能体付错了钱，损失算谁的？
建议原则：在授权范围内出错，公司承担；超出授权范围且员工未履行复核义务的，员工按过失程度承担。
关键是这条规则要在上线之前写下来、让相关人签字确认。事后再定规则，就是甩锅，而且下一次没人敢再碰任何AI 项目。
保险可以跟上。针对大额代理支付场景，可考虑网络安全责任险或董监高责任险的相关扩展。这一块国内还不普及，但趋势已经出现——中国人保在本周正在举办的服贸会上首发"算力保"系列产品，填补算力产业风险保障空白。新的技术形态出现，保险产品会跟着出现，这是市场在给风险定价。
八、一个正面案例，和它真正的结论
讲完风险，给个正向参照。
8 月 31 日公开的项目：Kyndryl 与瑞士 Incore Bank、Google Cloud 基于 Gemini 模型完成了一项概念验证，把智能体 AI 用在银行客户开户与风险评估（KYC）上。多个智能体分工协作，跨结构化与非结构化数据、内部系统和可信外部源，完成信息提取校验、证据收集、风险因素识别、可解释的风险评分，以及可审计的决策记录。
公开数据：开户文档自动数据提取准确率最高达99%；开户周期有望从数月压缩到数天。
但真正值得CFO 关注的不是这两个数字，而是 Kyndryl 高管的那句总结：在银行这样的高度监管行业，成功取决于强治理、可解释性、可审计性、安全的数据访问和人工监督。
Incore Bank 的 CEO 说得更直接：创新必须与信任、透明和强监管治理同行。
而UOB 那句话，我建议你直接转给团队：
"未来几年不会由谁拥有最好的模型来定义……而会由谁拥有最好的运营纪律来定义。"
Eng 还打了个比方：有人觉得负责任的 AI 和创新速度之间有取舍，因为治理确实会引入摩擦。但车上有刹车是为了让你能开——你想开得快，就更得有刹车。
模型不是瓶颈，治理才是。
九、写在最后
AI 替企业花钱，不是未来时，是现在进行时。而且它推进的速度会比你内部的审批流程快得多——支付基础设施、卡组织标准、监管框架三方在同时推。
CFO 面对的选择其实很清晰：要么在系统上线之前把三道防线建好，要么在系统出事之后补作业。前者的成本是几周的制度建设，后者的成本可能是一笔说不清的错付款加一次董事会问责。
最后把三道防线压缩成一句话，方便你转发给团队：
授权要分层，日志要独立，责任要前置。
再补一句今天真正想说的：在可撤回的场景里，95% 是效率；在不可撤回的场景里，95% 是风险。
分清楚这两者，比选对任何一个AI 工具都重要。
因为AI 不会替你承担一次错误的付款。承担的人，永远是签字的那个。
优贲提示：先做一件五分钟的事——列出你公司现在所有能自动下单或自动付款的工具，写清楚它们的责任人和额度。如果这张表你列不出来，那就是本周最该做的事。优贲 FDE 先锋会员体系"企业 AI 治理"模块已上线《AI 智能体授权矩阵模板》《AI 行为审计日志规范》《AI 服务商合同 SLA 与责任条款清单》《AI 用例中央清单模板》四份可直接使用的文档，并配套 1 对 1 治理框架搭建辅导。
会员可免费获赠"AI 财务管理师"证书。评论区或私信回复"AI治理"，领取四份文档。
