面向中型市场后台的 AI 智能体：控制先于自动化

1. 将董事会决策界定为委托授权

AI 智能体应被视为一种受委托的运营能力。董事会决策涉及系统可以追求哪些目标、可以使用哪些信息、可以调用哪些工具、可以作出哪些承诺，以及哪些行动仍需审批。使用模型的许可或一次成功演示并不能回答这些问题。

从经济角度看，这一方案可能具有吸引力。后台部门包含重复的检索、对账、文档处理、异常分类处置、跟进和状态更新。智能体可以跨系统和跨时间连接这些步骤。它可以准备供应商准入材料包、追踪有争议的发票、编制现金预测或协调客户服务案例。当公司消除延误、返工和权责分散，同时保留可靠证据时，价值便会显现。

控制风险敞口也会扩大。智能体可能选择错误的记录、遵循嵌入不可信文档中的指令、将凭证用于预期目的之外、披露个人数据、造成重复付款、适用过时政策，或在业务环境已变化后继续运行。其后果可能在人工发现之前经过多个系统传导。

因此，董事会委托应界定四个边界。结果边界规定智能体可以实现什么。资源边界规定它可以使用的数据、应用、身份、预算和时间。行动边界规定它可以执行哪些操作以及哪些操作需要审批。失效边界规定系统如何停止、控制危害、保留证据并将工作交还人工。

第一项政策决策应识别禁止性操作。示例可能包括释放资金、变更银行账户信息、终止雇佣关系、承担合同责任、提交监管申报表、绕过职责分离，或向个人传达最终不利决定。具体清单取决于公司的法律义务、运营模式和风险偏好。

目标、身份、工具和输出始终处于明确的政策、审批和证据边界之内。

2. 以当前跨市场证据为基础开展该计划

官方框架在生命周期治理、问责制、测试和干预能力方面趋于一致。NIST 的 AI 风险管理框架通过治理、映射、度量和管理来组织工作。其生成式 AI 概况识别可能由生成式系统带来或放大的新型风险，并提供贯穿生命周期的行动。2026年2月，NIST 启动了 AI 智能体标准倡议，围绕智能体安全、身份、授权、互操作性和评估设立具体支柱。该倡议确认，企业智能体控制仍是一个活跃的标准制定领域。

DIFC 于2023年修订了《数据保护条例》，纳入关于通过自主和半自主系统处理个人数据的第10号条例。该条例及相关指南将个人数据使用、问责和受影响个人置于基于结果的控制环境之中。在 DIFC 内运营或通过 DIFC 运营的中型市场公司应将该条例映射到每个处理个人数据的智能体，并就范围和义务寻求最新建议。

英国 NCSC 的国际安全 AI 指南涵盖安全设计、开发、部署、运营和维护。它要求进行威胁建模、供应链尽职调查、受保护的基础设施、日志记录、监控、事件管理和负责任发布。当后台智能体依赖外部模型、连接器、库或应用程序编程接口时，这些控制措施至关重要。

欧盟委员会表示，AI 法案第50条规定的透明度义务已于2026年8月2日开始适用。欧盟委员会的2026年实施材料也反映了高风险规则修订后的日期。公司应确认其是作为提供者、部署者、进口商还是其他运营者，并依据现行官方文本和适用行业法律评估每个用例。

金融服务业证据提供了有用的控制信号。英格兰银行与金融行为监管局2024年联合调查显示，75%的受访企业正在使用 AI，33%的用例涉及第三方，55%涉及某种程度的自动化决策，仅2%完全自主。调查还报告，网络安全是感知到的最大风险，并且对已部署 AI 的完整理解有限。调查证据不能决定单个公司的正确设计；但它确实表明，责任归属、第三方可见性和经过校准的自主性非常重要。

表1. 官方证据与控制启示

适用性、定义和义务需结合公司当前具体情况予以确认。

3. 区分自动化、辅助与自主性

“自动化”一词掩盖了三种不同的运营模式。确定性自动化遵循编码规则：匹配采购订单、校验字段、流转文档或计算阈值。AI辅助会为人员生成草稿、分类、摘要或建议。有限自主性在既定目标内选择行动并安排其顺序，且可跨多个步骤持续推进。

这些模型不应共用同一审批标准。确定性自动化通常可以依据已知输入和输出进行测试。AI 辅助需要围绕事实依据、审核和使用建立控制。代理能力需要上述所有控制，外加权限、身份、工具访问、记忆、终止、异常处理以及每项中间操作的证据。

自主性应被分解，而不是用单一标签来描述。智能体可以拥有规划自由，但不拥有执行权。它可以执行低后果的内部更新，但在对外沟通前需要获得批准。它可以仅针对指定案例、在既定金额限额内、在较短时间内并以设有上限的工具调用次数运行。

公司应选择能够产生预期经济成果的最低代理能力层级。许多流程可通过更好的数据、确定性控制以及 AI 辅助的准备工作得到显著改善。只有在流程已被充分理解、操作可逆、权限可被严格限定、证据完整且故障可被控制的情况下，才适合采用完全无人值守执行。

自主性阶梯使进展可被观察。用例只有在满足当前层级既定证据门槛后，才能向上推进。生产事故、重大流程变更、新工具、模型变更或监控薄弱，应触发重新评估或退回较低层级。

只有在上一层级已证明具备证据、可逆性和可控性之后，权限才会扩展。

4. 建立流程与决策清单

智能体的采用应从流程、决策和证据链开始。一份罗列吸引人演示的目录，可能会遗漏成本和延迟的运营成因。公司应按价值流盘点后台：订单到收款、采购到付款、记录到报告、从入职到离职、从案件受理到解决、监管报告和管理信息。

每个流程都应分解为触发条件、输入、决策、操作、系统、负责人、交接、控制、异常和输出。管理层应衡量业务量、周期时间、错误、返工、积压、成本、资金敞口、数据敏感性和服务影响。清单应识别真正需要判断的环节，以及数据缺失或政策不一致造成“看似需要判断”的环节。

决策清单尤为重要。一项决策可以批准付款、放行客户订单、对投诉进行分类、变更供应商记录、确认会计分录、筛选候选人或传达结论。记录应明确受影响的对象、所需证据、相关政策、允许的自由裁量范围、申诉或更正路径，以及法律或控制后果。

优先级排序应结合经济价值和控制可行性。高业务量、低后果、证据充分的工作可以是有吸引力的起点。高后果、模糊或证据不足的工作应首先进行流程修复并加强数据控制。公司应避免自动化一个根本原因尚未解决、且本身存在问题的异常流程。

该清单成为用例审批的治理依据。它将声称的价值与可衡量基线相连接，并防止技术团队在流程负责人、风险负责人、数据负责人和控制负责人未就设计达成一致的情况下授予权限。

表2. 流程与决策清单

指标应根据运营情境选择，并应以经核对一致的证据为依据。

5. 界定授权范围

授权范围将政策转化为可由机器执行的限制。它应说明目标、允许使用的数据、允许使用的工具、操作、金额、交易对手、司法辖区、营业时间、期限、调用次数、审批节点和停止条件。仅靠自然语言指令是不够的，因为随着情境变化，它可能被作出不同解释。

授权默认应保持狭窄。发票代理可读取已批准的发票和采购订单，索取缺失的内部证据，准备付款建议并更新案件记录。它不应拥有更改供应商银行信息或放款的长期权限。催收代理可基于已批准的事实和条款起草跟进函，但超过既定敏感性或客户层级的对外沟通须由人工批准。

授权范围应绑定到具名业务负责人和风险层级。临时授权应到期失效。金额和业务量限制应同时按累计和单笔交易适用，以免大量小额操作绕过每日或案件层面的上限。地理、实体和币种限制应与法律和运营边界保持一致。

政策执行应在推理模型之外进行。确定性服务应依据身份、目的、权限、金额、案件状态和审批，对每一次拟议的工具调用进行校验。模型可以解释其为何建议某项操作；由策略引擎决定该操作是否可以继续。

每次拒绝都应生成结构化证据。反复出现的拒绝可能揭示提示词不佳、流程设计薄弱、正在出现的滥用，或权限边界需要审查。权限边界的变更应遵循版本控制、测试与审批，并保留先前版本。

每个拟议操作在执行前都必须通过累计限额、政策和审批。

6. 为每个智能体提供独立身份

智能体不应通过共享员工账户或无限制的服务凭证运行。它需要唯一的机器身份，并关联到具名负责人、明确用途、风险等级、版本和到期时间。这有助于实现最小权限、归因、凭证轮换、撤销和可靠审计。

权限应针对具体任务。读取访问权、提议权和执行权彼此不同。在政策服务验证事项和审批状态后，智能体应在需要时获得短期凭证。密钥应保留在受管保险库中，绝不应放入提示词、记忆、日志或文档中。

身份架构应保持职责分离。创建供应商的智能体不应批准该供应商或放款。编制日记账的智能体不应过账并批准同一日记账。当审批人缺乏独立性、证据或充足时间时，人工审批并不能消除冲突。

智能体之间的调用需要同样的规范。接收方智能体应认证调用方、验证被委托的范围，并拒绝无法追溯到原始主体的权限。委托链应设置最大深度，并保留原始负责人、事项和累计限额。

紧急撤销必须切实可行。公司应能够禁用身份、撤销活动令牌、停止队列中的操作并隔离该事项，而无需等待模型提供商。访问权限重新认证应在流程或角色发生重大变更后进行，并按与风险相称的周期定期进行。

7. 控制数据、提示词、工具和记忆

智能体的实际运行环境不仅包括模型。它还包括系统指令、用户指令、检索到的文档、记忆、工具描述、应用响应和第三方内容。其中任何一项都可能不准确、具有恶意、过时或超出授权用途。

数据访问应遵循分类、用途和最小必要性。公司应梳理个人数据、保密商业信息、支付数据、雇佣数据和受法律特权保护的材料。检索应强制执行实体、事项和用户边界。敏感字段可被遮蔽，直到任务和审批需要它们。

不可信内容应被视为数据，而不是指令。发票附件中要求智能体忽略政策或将信息发送到别处的消息不应具有任何权限。架构应将可信控制指令与检索内容分离，在适当情况下清理工具输出，并测试提示词注入场景。

工具需要允许列表和参数控制。通用数据库查询、命令外壳或无限制浏览器可能使智能体获得比业务目的所需更广的操作面。具有类型化输入、范围狭窄的操作、确定性验证和幂等性的专用工具可提供更强的边界。

记忆应具有明确用途、保留期限和删除路径。公司应区分临时案件状态、经批准的参考知识和已学习偏好。持久记忆可能将过时事实、未经授权的个人数据或某个案件的指令带入另一个案件。记忆写入应明确、可归因且可审查。

表 3. 智能体运行面的控制登记表

技术实施应由公司的安全、隐私和控制负责人验证。

8. 为概率性工作设置确定性控制

智能体可以帮助解读杂乱信息，而确定性控制应管理必须精确的事实。银行账户格式、税务标识、发票金额计算、币种、重复检测、审批限额、会计期间、制裁状态和职责分离规则应通过受控数据和代码进行验证。

工作流可以用模型定位可能的发票号码、解释差异或建议类别。随后应由确定性服务对照源系统验证标识符、计算金额、测试规则，并返回通过、失败或异常。智能体不应将低置信度的解读转化为已执行的交易。

对账是核心。公司应比较申请、审批、执行和记录的操作。每笔交易都需要幂等键，以便重试不会造成重复。批次合计、控制账户和异常队列应与源系统和目标系统对账。工具成功响应只是调用发生的证据，并不能证明实现了预期的会计或运营结果。

置信度不应替代授权。高置信度模型仍可能出错，而低置信度输出在明确转交人工处理时仍可能有用。决策规则应在任何模型评分之外，综合考虑后果、证据完整性、政策和可逆性。

设计应支持优雅降级。如果模型、连接器或数据源不可用，流程应根据有文档记录的服务计划暂停、回退到更简单的规则或将工作转交人工。公司应了解哪些运营承诺依赖该智能体，以及可以容忍多长时间的中断。

9. 围绕后果和可逆性设计人工审批

只有当审核者获得正确的证据、理解决策、拥有权限并有时间提出质疑时，人工参与才能形成控制。数百项例行审批排成队列可能流于形式。设计应将人工判断集中在重大、异常或不可逆的操作上。

审批层级应反映后果。低价值内部分类可采用抽样复核。客户沟通若改变合同立场或涉及弱势个人，则可能需要审批。付款、银行信息变更、会计分录过账、人事操作或监管报送可能需要双重控制或专家复核。

审批包应展示拟议操作、目的、来源证据、政策规则、重大假设、例外、金额、受影响方、备选方案和下游后果。审核者应能够批准、修改、拒绝或退回该事项。拒绝原因应有助于流程改进，但不应自动用于训练系统。

可逆性影响审批关口。更新内部任务状态比划付资金、披露数据或作出最终决定更容易逆转。时效性也很重要。系统应在截止时间前升级处理，而不是在最后一刻迫使审核者作出草率决定。

应监控人工审核表现。反复快速批准、高覆写率、频繁的批准后更正或审核者差异过大，可能表明证据不足、培训不足或自动化偏差。即使由智能体准备工作，责任仍归属于指定负责人。

后果越严重、可逆性越低，就需要越强的证据和独立审批。

10. 治理多智能体与第三方依赖

智能体很少单独运行。它可能依赖模型提供商、云平台、编排层、向量数据库、连接器、身份服务和业务应用。多智能体设计会增加不同所有者和能力各异的系统之间的委托任务与通信。

依赖登记册应标明提供商、服务、数据位置、模型或版本、关键性、合同权利、次级处理者、保留、事件通知、服务水平、审计证据、变更流程和退出路径。当多个关键工作流依赖同一提供商或凭据平面时，集中度应清晰可见。

公司应测试提供商变更。模型行为、工具模式、速率限制、安全设置和数据条款都可能变化。发布应先经过带有回归测试的受控环境，再进入生产环境。紧急提供商变更应触发既定的遏制与回退路径。

智能体间消息应采用经过身份验证、带类型且受边界约束的协议。接收系统在验证前应将自由格式内容视为不可信。每项任务应包含目的、发起主体、委托范围、到期时间和证据要求。子智能体获得的权限不应超过其父智能体。

合同应涵盖数据使用、保密、安全、知识产权、审计、事件、变更、服务连续性、可移植性和终止。需要就相关司法管辖区和运营模式寻求法律意见。技术保障仍然必要，因为合同救济发生在事件之后，且可能无法恢复数据或客户信任。

11. 保持财务与采购控制

财务与采购提供了有价值的智能体用例，因为它们包含重复性的证据汇总和例外处理。它们还包含直接的现金、报告、欺诈和供应商风险。智能体架构应扩展现有内部控制环境，而不是在其周围另建一条并行路径。

在采购到付款中，智能体可以检查入驻完整性、比对发票与采购订单证据、识别重复项、编写例外说明并流转审批。银行账户信息的创建或变更仍应接受独立验证，且验证应在用于提出请求的通信渠道之外进行。付款建议应与已批准发票进行核对，并通过既定资金管理权限放行。

在记录到报告中，智能体可以汇总对账、追踪差异、准备会计分录支持材料并起草说明。期间状态、账户归属、证据和审批应由机器验证。重大或异常会计分录应接受独立审查。系统应保留每笔拟议分录所采用的准确来源、转换过程和决策轨迹。

在订单到收款中，智能体可以识别文档缺口、对争议进行分类、准备催收行动并协调内部责任人。对外沟通应使用经批准的事实和权限。信用额度变更、让步、核销和涉及法律敏感性的升级应遵循现有审批。

设计应避免因数量而稀释控制。智能体生成的建议可能超过审查人员能够评估的数量。容量限制、基于风险的路由和队列账龄应纳入发布决策。财务收益应通过周期时间、返工、错误、现金时点和释放的产能来衡量，并同时辅以服务和控制指标。

表4. 财务与采购控制矩阵

该矩阵补充公司现有的授权、会计和资金管理政策。

12. 保护客户、员工和受影响个人

后台代理可能影响个人，即使该用例看似属于行政事务。客户可能收到催收升级通知。供应商可能被阻断。员工可能被排名、被调查或被拒绝给予福利。投诉的分类方式可能改变其处理方式。公司应评估每项决策对个人及关系造成的影响。

评估应识别受影响群体、所使用的数据、目的、法律依据、潜在损害、公平性顾虑、透明度义务、人工复核和申诉路径。个人数据应仅限于授权目的。特殊类别或敏感数据需要根据适用法律进行更严格的分析并采取保障措施。

对外沟通应在必要时准确说明自动化的作用，并提供切实可行的转人工途径。受影响个人不应被困在一个智能体审查另一个智能体决策、却缺乏有意义独立干预的循环中。投诉和申诉应保留原始证据、决策路径和所用版本。

雇佣相关用例需要特别谨慎。候选人筛选、绩效分析、缺勤管理、纪律处分和解雇可能带来重大的法律和人身后果。公司应获取最新的雇佣和数据保护建议，让具备资质的人力资源负责人参与，并实施独立审查。

公平性应结合具体情境进行测试。总体准确率可能掩盖不同群体、地区、语言或客户细分之间不均衡的错误或负担。公司应定义相关结果指标，检查错误模式，并在部署后监控变化。公平性审查还应考虑该流程本身是否适合由智能体执行。

13. 针对网络安全与安全失效进行设计

威胁模型应覆盖完整的智能体系统。攻击者可能操纵提示词、文档、工具输出、记忆、连接器、凭据和依赖项。他们可能试图获取数据、资金、持久化能力、破坏能力，或对业务决策施加影响。普通配置错误也可能在没有恶意意图的情况下产生类似后果。

安全设计始于范围狭窄的工具、隔离环境、最小权限、输入和输出控制、受保护的密钥以及明确的信任边界。开发应使用受控代码库、经过审查的依赖项、可复现构建和测试。部署应保护基础设施、配置和模型访问权限。运行应监控行为、漏洞、提供商变更和事件。

安全失效设计应说明在以下情况下会发生什么：证据冲突、工具返回意外结构、达到限制、凭据失效、模型变更、依赖项不可用，或智能体的行为超出其经过测试的分布范围。首选响应通常是暂停、保留状态、控制待处理操作，并将案例转交给人工处理。

关停能力必须独立于智能体。操作人员应能够禁用一个身份、连接器、用例、模型或整个编排层。排队中的工作和部分完成的交易需要恢复流程。业务连续性计划应涵盖中断期间所需的人工或简化流程。

事件响应应保留提示词、检索到的证据、工具调用、审批、模型和配置版本、时间戳以及已执行的交易。团队应确定范围、控制仍在生效的权限、通知相关所有者和顾问、核对结果、更正受影响的记录，并决定是否需要进行监管或合同通知。

安全失效会保留证据、控制权限，并将未解决的工作交回给承担责任的负责人。

14. 使每项实质性操作均可重建

可审计性不仅仅需要一份文字记录。证据记录应能够重建以下内容：谁或什么发起了该案例、适用了哪项权限、检索了哪些数据和文档版本、使用了哪个模型和配置、发生了哪些中间决策、调用了哪些工具、执行了哪些策略检查、谁批准了该操作，以及目标系统记录了什么。

日志应结构化、时间同步、受访问控制，并防止未经授权的更改。日志应避免包含不必要的密钥和个人数据。保留期限应符合法律、监管、合同和运营要求。公司应能够通过共同的案例和操作标识符，将身份、智能体、应用和交易日志关联起来。

溯源应区分来源事实与模型生成的解释。审核人应能够打开作为依据的发票、合同、政策或系统记录。如果代理合并了多个来源，证据应显示哪项陈述来自哪个来源，以及该来源在决策时是否为最新版本。

监控应同时关注结果和技术活动。公司应核对已执行的交易、客户沟通、分类账记录、访问权限变更和例外事项处置。抽样应覆盖常规案例，而重大行动可接受全面审查。

对证据本身的访问具有敏感性。审计日志可能包含业务流程、安全细节和个人数据。需要基于角色的访问控制、用途限制和独立监控。公司应测试其能否重建案例，再在生产环境中依赖该证据设计。

15. 在生产授权前测试系统

测试应从流程和控制设计开始。团队应确认目标清晰、源数据可靠、政策可编码、授权范围有限且失败路径切实可行。模型基准测试无法弥补流程含糊或证据缺失。

测试集应包括正常案例、罕见但重要的案例、不完整记录、相互矛盾的证据、过期文件、重复请求、对抗性指令、未经授权的工具调用、金额限额突破、依赖不可用、审批延迟以及跨越实体或案例边界的尝试。团队应测试多步骤累积，因为一系列各自看似合理的操作可能造成重大风险敞口。

评估应衡量任务结果、事实依据、政策合规性、工具正确性、重复预防、上报质量、证据完整性、延迟和成本。安全测试应覆盖提示注入、数据泄露、权限提升、依赖项受损和拒绝服务。隐私和公平性测试应反映受影响人群和法律背景。

发布应依次经过离线评估、沙盒、影子模式、人工批准的生产环境和有边界的无人值守运行。每个阶段都应有进入和退出标准。影子模式将建议与实际流程结果进行比较，但不授予执行权限。有限生产应限制交易对手、金额、用户、数量和时间。

在模型、提示、数据源、工具、政策、连接器或重大业务流程发生变更后，必须进行回归测试。发布记录应显示已批准的版本和证据。公司应保留在结果恶化时回滚或撤销授权的能力。

表 5. 测试与发布关卡

阈值和样本量应反映用例风险、业务量以及适用的保证要求。

16. 建立可问责的运营模式

运营模式应在技术交付之前明确业务问责。业务流程负责人对结果和运营政策负责。风险负责人批准风险处置。数据负责人管理来源质量和允许用途。安全团队负责威胁模型和访问架构。技术团队负责可靠平台。内部审计或独立保证职能根据其职责范围评估设计与运行。

一个 AI 治理论坛可以批准用例、风险分级、权限边界、发布和重大变更。该论坛应包括业务、技术、安全、隐私、法律、合规、财务、人力资源或其他职能，具体视用例而定。董事会或相关委员会应批准风险偏好，并接收简明的组合视图。

智能体登记册应包含负责人、目的、流程、受影响方、数据、模型、工具、身份、权限、风险等级、审批、测试证据、发布、监控、事件、依赖关系和退役状态。登记册应区分实验与生产系统，同时对使用敏感数据或实时工具的实验仍适用适当的控制措施。

变更管理应面向员工队伍。员工需要接受培训，内容涵盖智能体能力、局限性、升级上报、证据审查和禁止用途。角色设计应明确哪些工作被移除、哪些判断仍保留，以及产生哪些新的控制职责。释放出的产能应有意识地重新部署，而不是假定其可直接使用。

独立质疑应聚焦于证据。负责人应展示控制措施和结果，而不是依赖政策声明。在技能有限的情况下，公司可以使用外部专家进行架构、网络安全、隐私、法律、审计或流程设计，同时保留内部问责。

17. 按 120 天序列推进落实

前 30 天确立事实与边界。管理层选择一个狭窄的价值流，梳理流程与决策，核对基线，对数据分类，识别受影响方，分配负责人，完成威胁模型并起草权限边界。在授予任何生产执行权限之前，可通过人工或 AI 辅助的原型验证拟议价值是否存在。

第 31 至 60 天构建受控路径。团队创建唯一智能体身份、收窄的工具集、策略门禁、案例证据模型、审批包、日志记录、安全停止程序和测试集。离线和对抗性评估应解决指令处理、来源依据、工具参数和异常路由中的缺陷。

第 61 至 90 天进入沙盒和影子模式。团队将智能体提议与真实流程结果进行比对，衡量基线和控制绩效，测试连续性和事件处理程序，完成第三方尽职调查并培训审核人员。在满足退出标准之前，生产范围仍为只读或需人工批准。

第 91 至 120 天采用有界生产。公司限制价值、数量、实体、交易对手、行动和时间。它对每项已执行行动进行对账，监控例外情况和审核人员行为，并验证所声称的运营收益。治理论坛决定保留、扩大、收窄还是撤销授权。

扩展应复用控制平面，同时重复开展用例分析。统一的身份、策略、证据和监控架构可以降低边际实施成本。每个新流程仍需进行自身的决策、数据、后果和法律评估。

授权通过证据关口，从流程真实情况推进至有界生产。

18. 衡量控制、运营价值和企业价值

记分卡应区分技术活动与业务成果。工具调用、令牌数量和模型延迟可以支持容量规划。它们不能证明流程已得到改善。董事会需要获得有关周期时间、积压、错误、返工、现金时点、服务质量、控制例外、事件和释放产能的证据。

控制指标应包括未经授权行动的拒绝次数、升级率、证据完整性、重复操作预防、对账差异、审批绕过、事后纠正、安全事件、隐私事件、供应商变更和恢复时间。只有在授权和监控有效时，较低的拒绝率才有意义。

价值应基于经对账的基线进行衡量。劳动力产能可根据观察到的业务量和处理时间估算，再通过实际岗位和工作量变化加以验证。现金影响应与交易以及银行或账簿证据对账。避免损失应以谨慎方式表述，并有已观察到的事件或书面记录的风险模型作为支持。

企业价值可以通过持久的成本能力、更快的现金转换、更好的客户或供应商服务、更强的控制、更具可扩展性的运营以及更低的运营风险而提升。交易证据应表明该收益具有持续性、依赖于受控基础设施，并能在关键人员或供应商变动后继续存在。买方和贷款方可能会对依赖不透明系统或薄弱证据的收益打折扣。

商业交付应将诊断与执行连接起来。外部顾问可以支持流程梳理、商业案例设计、控制架构、实施治理、供应商选择、财务建模和董事会报告。专业的法律、数据保护、网络安全、审计、雇佣、会计和监管工作应由合格顾问执行。成功应通过已验收的交付成果、已签署的委托、已收取的费用和持续的客户成果来证明。

表 6. 受控智能体采用的董事会记分卡

目标为示例性管理选择，应针对每个流程和风险层级进行审批。

实施结论

AI 智能体可以改善中间市场后台运营，前提是权限设计得到与工作流同等的重视。实际实施顺序从经过核对的流程与决策清单开始，选择最低的有效自主级别，界定明确的授权范围，并为每个智能体赋予单独身份。确定性策略、验证与勾稽用于管控概率性判断。

人工审批集中于后果和可逆性。数据、工具、提示词、记忆和提供商始终处于既定信任边界之内。测试从离线证据开始，依次经过沙盒、影子模式和受限生产环境。日志记录使重大行动可重建，而独立的终止和恢复机制可遏制故障。

一项为期 120 天的计划可以建立控制平面，并在一个狭窄流程中展示运营价值。扩展时，每个新增用例都遵循相同的关口。这为董事会提供有关生产率和风险的证据，并为可扩展、可交易的企业价值奠定更可信的基础。

参考文献

1. 美国国家标准与技术研究院。AI 风险管理框架，包括 AI RMF 1.0、Playbook 和生成式人工智能概况。 https://www.nist.gov/itl/ai-risk-management-framework
2. 美国国家标准与技术研究院。人工智能风险管理框架：生成式人工智能概况，NIST AI 600-1，2024年7月。 https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf
3. 美国国家标准与技术研究院。AI 智能体标准倡议，创建于2026年2月17日，更新于2026年4月20日。 https://www.nist.gov/artificial-intelligence/ai-agent-standards-initiative
4. 迪拜国际金融中心。关于通过自主和半自主系统处理个人数据的第10号法规。 https://www.difc.com/business/registrars-and-commissioners/commissioner-of-data-protection/regulation-10
5. 迪拜国际金融中心。数据保护合规指南，包括通过自主和半自主系统处理个人数据。 https://www.difc.com/business/registrars-and-commissioners/commissioner-of-data-protection/guidance
6. 英国国家网络安全中心。安全 AI 系统开发指南，2023年11月27日。 https://www.ncsc.gov.uk/collection/guidelines-secure-ai-system-development
7. 欧盟委员会。AI 法案监管框架及实施时间表，2026年7月更新。 https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai
8. 欧盟委员会。特定 AI 系统提供商和部署者的透明度义务，2026年7月20日。 https://digital-strategy.ec.europa.eu/en/news/commission-publishes-guidelines-transparency-obligations-providers-and-deployers-certain-ai-systems
9. 金融行为监管局和英格兰银行。英国金融服务中的人工智能：2024年调查结果。 https://www.fca.org.uk/publications/research-notes/ai-uk-financial-services
10. 经合组织。经合组织 AI 原则，2019年通过并于2024年更新。 https://www.oecd.org/en/topics/ai-principles.html
11. 新加坡个人数据保护委员会。新加坡的 AI 治理方法及示范 AI 治理框架。 https://www.pdpc.gov.sg/help-and-resources/2020/01/model-ai-governance-framework
12. 国际标准化组织。ISO/IEC 42001:2023，人工智能管理系统。 https://www.iso.org/standard/42001
13. 网络安全和基础设施安全局。CISA 与英国 NCSC 发布安全 AI 系统开发联合指南，2023年11月26日。 https://www.cisa.gov/news-events/alerts/2023/11/26/cisa-and-uk-ncsc-unveil-joint-guidelines-secure-ai-system-development

关于作者

Chennakeshav Adya 是一名独立研究员，也是 Matchpoint Partners 的管理合伙人。他的工作重点关注公司金融、资本战略、交易执行，以及将财务证据、董事会决策和可衡量的企业绩效连接起来的运营系统。