运营中的 AI 护栏：审批、审计留痕，以及让人始终在环

一夜之间有 37 笔退款获批，共 8,400 美元，而且每一笔都在限额之内。一家有 12 家门店的零售商上个月上线的客服智能体，单笔最多可退 300 美元，配置里却没有任何一条限制全天总额。

过了午夜，一波声称包裹破损的消息涌来，每一条都客气而可信，智能体就这样一笔一笔批了下去。周二早上，财务负责人才看到总数。这是一个示意场景，但其中每一步都是那种一次只检查一个动作的限额会出的常见故障。

智能体做的正是提示词允许它做的事，而提示词是唯一的围栏。提示词只是一个请求，请求可能被忽略、被误解，也可能被陌生人的一条巧妙消息推翻。真正的安全来自模型之外的控制措施：权限、限额、审批、频率限制和记录。不管模型表现好不好，这些措施的运作方式都不变。

本文是这些控制措施的设计指南：谁来批准什么，怎样让操作重复执行也不出事，审计记录里必须有什么，如何防范恶意文本，以及截至 2026 年 9 月初，欧盟、ISO 和 NIST 的规则对一家普通企业有什么要求。

本文是“2026 运营中的 AI”系列的第 3 篇，也是最后一篇。第 1 篇讲了AI 智能体在 ERP 里能安全做什么，第 2 篇讲了 MCP 如何让 AI 安全地连接业务数据。这一篇讲的是，怎样让人始终握着决定权。

为什么控制措施必须放在模型之外

语言模型靠预测下一段文字来做决定。它大多数时候是对的，偶尔会信心十足地出错，而且没人能保证某一天你遇到的是哪一种。如果模型和你的支付系统之间只隔着一句“退款不得超过 50 美元”，那是寄希望，不是控制。

真正的控制，是模型靠说话绕不过去的东西。退款工具本身会拒绝超限金额；审批环节智能体跳不过去；智能体的账号压根没有碰工资数据的权限。这些规则枯燥、确定，是写死的代码，正因为如此才管用。

这和你管理新员工的思路一样：权限有限、有支出上限，大决定要经理签字。你不会只凭新人的好意办事，对智能体也不该如此。

原则一：最小权限，每个智能体一个独立身份

给每个智能体一个以职责命名的专用账号，比如“purchasing-agent”。别让它借用某个员工的登录，也别共用管理员密钥。然后只授予任务所需的权限。

• 读取范围：只开放它需要的模块和字段。采购智能体用不着客户的电话号码。
• 写入范围：可以创建草稿，不能过账到总账；可以改标签，不能改价格。
• 时间与来源：只在有人触发或按计划运行时工作，并且只能来自已知系统。
• 预算：为支出、模型用量和每小时操作次数设上限。

独立身份的好处还在后面。一旦发现异常，日志会写明“purchasing-agent 代表 Maria 执行了此操作”，你只需停用这一个身份，不会影响其他任何人。

原则二：审批取决于可撤销程度和金额

第 1 篇把智能体的操作分成四个层级，从回答问题到无法挽回的资金操作。实际用起来还需要第二个维度：这个操作有多大？8 美元的退款和 8000 美元的退款是同一类操作，风险却完全不同。

把两个维度合成一张矩阵，并且写下来。下面的金额只是示例，请按出错会让你损失多少来定，而不是看着整齐顺眼就定。

矩阵要真正管用，靠三个习惯。操作落在哪一格，由代码根据操作类型和金额判定，而不是去问模型“你觉得风险大不大”。把操作作为尚未发生的提案交给审批人。审批的那一刻再核对一次金额，因为从发起到点击之间，购物车或草稿可能已经变了。

把矩阵放进一个操作的完整路径里，它就成了一张有四道关卡的流程图。每一个出口，包括拒绝，都会留下一条记录。

原则三：制单与复核、预览和试运行

会计行业沿用“制单与复核”分离的做法已经很多年：准备付款的人，不能是放行付款的人。对智能体也照此办理。智能体永远是制单方，复核方是一个人，风险最高的格子则要两个人。涉及资金时，智能体不能去复核另一个智能体的工作。

复核的人只能核查看得见的东西，所以每个提案都需要清晰的预览：

• 究竟会改变什么，用“修改前、修改后”的形式展示。
• 智能体为什么提出这个建议，用两三句平实的话说明，并附上所依据记录的链接。
• 要花多少钱，哪些部分无法撤销。
• 条件允许时给出“试运行”结果：在副本或模拟环境里执行同一操作，只展示结果、不保存。

当心审批疲劳。要是让一个人每天批两百条，他只会不看就点。审批只留给真正重要的格子，把低风险的操作合并成每日抽检，并统计审批人修改和驳回的频率。一个从不驳回的“橡皮图章”是警讯，不是成绩。

让每个操作重复执行也安全

智能体会重试。网络超时、任务重启，模型有时也会把同一个工具调用两次。如果“创建采购订单”执行了两次，你就下了两次单。

解决办法是幂等键（idempotency key）：给每个提案操作附上一个唯一标识。系统记住已经完成的键，遇到重复的就悄悄忽略。重复的供应商发票、重复退款、重复的库存调拨，靠这一个习惯就能避免。

再配上另外三道刹车：

• 频率限制：比如每个智能体每小时最多修改 20 个订单。失控的循环会在酿成事故之前自己停下来。
• 熔断机制：错误率或驳回率一旦攀升，智能体自动暂停并通知相关人员。
• 紧急停止开关：一个名称醒目的控件，能立即暂停某个智能体或全部智能体。找个平静的日子试一试。真到要用的时候才发现它不灵，是最糟糕的时刻。

审计记录：每个操作要记什么

出了问题，你需要迅速回答五个问题：谁提出的请求，智能体看到了什么，它做了什么，是哪个模型做的决定，谁批准的。如果日志答不全这五个问题，你就无法调查，也无法向客户、审计师或监管机构证明当时发生了什么。

有三个细节把有用的日志和摆设式的日志区分开。在提出操作时就写记录，而不是等结束后才写，这样失败和被拒绝的操作也看得见。把模型名称和版本，连同提示词或策略版本一起存下来，因为其中任何一个变了，行为都会变。还要让记录具备防篡改能力：采用只增不改的存储，至少要规定智能体及其管理员不能修改历史。

也要留意隐私。完整保存客户消息的日志，本身就是敏感数据。尽量记录引用和简短摘录，设定保留期限，并限制谁能查看。

防范恶意文本

第 2 篇讲过提示词注入：邮件、评价或商品描述里藏着一段文字，指示模型去做它的主人从未要求的事。OWASP 的大语言模型应用十大风险把它排在第一位。没有哪种过滤器能彻底消除它，所以设计时要假定总有一部分注入会得手。

1. 智能体从外部读到的一切，包括邮件、网页、评价和上传的文件，都当作不可信的数据，绝不当作指令。
2. 只要对话里出现不可信内容，就撤掉危险工具，或者要求额外确认。读取客户邮件的那一步，智能体不应当能直接发起退款。
3. 把敏感数据和对外发送的通道隔开。一个既能读取全部客户、又能给任何人发邮件的智能体，可能被诱骗把你的客户名单发出去。
4. 让审批人在提案旁边看到原始来源文本，这样人一眼就能发现不该出现的指令。
5. 记录并复盘被拦截的尝试。数量上升，说明有人在试探。

改动之前先测试

模型、提示词、工具和你自己的数据都会变，其中任何一项都可能悄悄改变智能体的行为。所以上线之前，先建一个小型评测集：五十到几百个真实或贴近真实的案例，每个都带着预期答案，并且要包含棘手的情形，比如重复订单、缺失数据、情绪激动的客户和注入攻击。

每次更换模型、提示词或权限，都重跑一遍评测集。和上一次的结果对比，指标持平或更好才上线改动。这和软件里的回归测试是同一个思路，只不过测的是行为。

上线后，每周盯几个数字：提案的采纳率、驳回原因、被策略拦下的操作、单次操作成本，以及流到客户或供应商那里的错误。回滚也要提前规划。对每一类操作，都要清楚怎么撤销、谁来撤销、还有多长时间。如果答案是“这件事撤销不了”，这类操作就该放进只能由人来做的那一格。

2026 年 9 月，规则对你有什么要求

成长型企业运营中的大多数 AI 用法，比如库存问答、采购草稿和发票核对，在欧盟《人工智能法案》下并不属于“高风险”。但这不等于什么都不用做。以下是 2026 年 9 月初的情况。

框架	现状	对你意味着什么
欧盟《人工智能法案》，透明度义务（第 50 条）	自 2026 年 8 月 2 日起适用。仅对已在市场上的系统，AI 生成内容的标识义务另有一段短暂的宽限期，至 2026 年 12 月 2 日。	人们在和 AI 对话时要告知他们，并在需要时为合成内容加上标识。
欧盟《人工智能法案》，高风险系统（附件 III）	2026 年 5 月达成一致、6 月获欧洲议会和欧盟理事会通过的《人工智能数字综合方案》（Digital Omnibus on AI），把日期从 2026 年 8 月 2 日推迟到 2027 年 12 月 2 日。已受欧盟产品安全法规管辖的产品推迟到 2028 年 8 月 2 日。	如果 AI 参与招聘、员工评估、信贷或基本服务准入的决定，就适用。要求日志、人工监督和记录。
ISO/IEC 42001:2023	2023 年 12 月发布。可认证的 AI 管理体系标准。	自愿采用。是梳理政策、职责、风险评审和持续改进的好框架，对大客户也是一个可信度信号。
NIST 人工智能风险管理框架 1.0	2023 年 1 月发布，2024 年 7 月补充了生成式 AI 专项指南。自愿性质。	四项可以借用的职能：govern、map、measure、manage。

有两点提醒。这类法规的日期已经变动过一次，最终文本的各种解读在措辞上也还不一致，所以采信任何日期之前，请核对官方文本或咨询专业人士。另外，推迟不等于取消：义务依然存在，而本文介绍的做法，即日志、监督和书面限额，恰恰是高风险规则要求的内容。

即使风险很低的用法，也要做到两件事：人们在和 AI 对话时要告知他们，并保留好记录。想看标准原文，可以访问 ISO/IEC 42001 的 ISO 页面和 NIST 人工智能风险管理框架。欧盟之外，各国规则不一，而且仍在变化，请核实你的销售所在地有什么要求。

一份可以直接拿去用的 AI 操作策略

把你的规则写在一页纸上，让员工、供应商和审计人员都能读懂。下面是一份带示例数值的模板，每个数字都请按你自己的风险调整。

操作	智能体可以做	限额	审批	撤销
回答库存和订单问题	只读	仅限其角色范围内的数据	无需	无需
采购订单草稿	创建草稿	每天 20 份草稿	发送前由采购员批准	删除草稿
给订单打标签或预留库存	修改	200 美元以下的订单，每小时 50 个	每日抽检	一键还原
客户回复草稿	创建草稿	不得承诺退款或补偿	智能体不会自行发送任何内容	尚未发送
退款	只能提议	1000 美元以内一位审批人，超过则两位	必须由人审批	通过支付服务商冲回
向供应商付款、发放工资、总账过账、删除	不可以	不允许	只能由人操作	不适用

每个季度、每次出事故之后，都要复盘这份策略。有证据支持时，把某一行提升一个层级。绝不能因为某个供应商的幻灯片这么说，就提升。

上线检查清单

1. 为每个智能体建立独立身份，只给刚好够用的最小权限。
2. 写好审批矩阵和操作策略，请负责人和财务负责人签字确认。
3. 限额和审批由系统强制执行，而不是写在提示词里。
4. 加上幂等键、频率限制，以及一个测试过的紧急停止开关。
5. 日志里记录请求、智能体、模型版本、输入、操作、判定、审批、结果和撤销指引。
6. 建立包含注入攻击的评测集，每次改动都重跑。
7. 先让一个团队试点，每周复查日志，有证据再扩大权限。

回到那个周二。有了这些控制措施，每笔退款都只是等待真人处理的提议，每日退款总额上限会在头几笔之后让这一轮停住，而当提议开始变得千篇一律，熔断机制会让智能体自己暂停。财务负责人看到的会是一条暂停告警和一份很短的待审清单，而不是一个 8,400 美元的麻烦。智能体的能力一点没少，只是它最糟的一夜现在有了边界。

核心要点

• 控制措施要放在模型之外：权限、限额和审批由系统强制执行，而不是在提示词里恳求。
• 给每个智能体一个独立且范围狭窄的身份，审批要同时看可撤销程度和金额。
• 采用带清晰预览的制单与复核分离，把审批留给高风险的格子，并留意审批疲劳。
• 让操作具备幂等性，再加上频率限制、熔断机制和一个测试过的紧急停止开关。
• 记录谁提出请求、智能体看到了什么、做了什么、哪个模型版本执行，以及谁批准。
• 大多数运营场景的用法在欧盟《人工智能法案》下不属于高风险，高风险日期已推迟到 2027 年 12 月，但透明度和完善的记录依然适用。

Anichur Rahaman 是一名软件架构师，也是 StoreConsole 的创建者。他为成长型企业设计电商与 ERP 系统，专注于事件驱动架构、数据完整性和自托管部署。