AI 运营模式：责任归属、数据、控制与收益跟踪

1. 治理企业级系统，而非一组零散的 AI 工具

董事会关于 AI 的首要问题应是公司意图改变何种运营结果。许可证、模型、助手或试点都只是投入。只有当公司改变某项决策、流程、产品或客户主张，并能在获批的风险边界内维持这一改变时，价值才会产生。运营模式将技术能力与可问责的业务行动连接起来。

这一区分很重要，因为一个组合可能看起来活跃，但经济上仍然薄弱。团队可能会统计演示、用户、提示词或生成的文档。这些指标几乎无法说明收入、成本、现金、服务、质量或风险。一个用例可能在受控测试中表现良好，却在生产环境中失败，原因是数据访问、工作流集成、员工采用、供应商可靠性或客户接受度不足。

OECD AI 原则要求在整个 AI 生命周期中落实问责、可追溯性和系统性风险管理 [1]。NIST 将 AI 风险管理围绕治理、映射、衡量和管理来组织 [3][4]。ISO/IEC 42001 将 AI 管理构建为由政策、目标和持续改进流程组成的体系 [7]。这些来源支持一个务实的企业结论：AI 治理应位于运营模式之内，而不是作为合规附录置于其旁。

完整的运营链条包含五个相互关联的对象。战略识别值得改变的决策或工作流。用例章程界定范围、负责人和预期成果。数据与模型控制确定该能力能否负责任地运行。生命周期关口决定其能否推进。收益台账显示该变革是否触及损益表、现金流、资产负债表、服务成果或风险状况。董事会获得覆盖全部五个对象的统一视图。

每一层都有指定的负责人、证据集、决策权和审查频率。

2. 在确定组合优先级之前建立企业级清单

管理层无法治理其尚未识别的内容。清单应涵盖内部开发的模型、外部托管的模型、企业软件中嵌入的 AI、员工助手、自动化决策组件、分析模型、智能体、由模型支持的产品以及重要实验。它还应记录通过调查、访问日志、采购数据、网络控制和业务审查发现的影子使用。

核算单位应是用例，而不是供应商名称。一个通用模型可以支持客户服务、编码、营销和合同审查，但其数据、用户、决策和后果各不相同。反过来，一个用例可能依赖多个模型、检索服务、数据源和工作流应用。清单应体现这两种关系。

每条记录都需要业务负责人、技术负责人、风险层级、预期用户、受影响利益相关方、决策角色、数据类别、模型与供应商依赖、司法管辖区、生命周期状态、批准日期、监控要求、收益负责人和退役路径。记录应明确系统是提供建议、起草、预测、排序、决策、执行，还是控制另一个系统。自主性和可逆性往往比模型复杂程度更重要。

该清单还支持组合经济效益分析。可以识别重复许可证、相互重叠的试点以及不兼容的数据管道。一项通用能力可能服务多个用例，而一个高成本的专用模型可能仅由一位职责范围狭窄的负责人管理。管理层随后可以分摊共享成本、与供应商谈判，并决定哪些平台值得规模化。

表 1. 最低限度的企业级 AI 清单

该清单将运营、技术、风险和财务证据整合到一份受控记录中。

3. 围绕六项责任设计运营模式

一项 AI 计划需要的不仅仅是一个指导委员会。六项责任应清晰可见。董事会批准风险偏好、重大投资与监督。执行发起人负责组合投资主题。业务负责人负责工作流采用和运营成果。技术负责人负责架构、实施和服务绩效。独立控制职能对风险、隐私、安全、法律和合规证据提出质疑。财务控制效益基线并验证已实现价值。

在规模较小的组织中，这些角色可以合并，但问责应保持区分。提出用例的人可以准备证据。重大部署仍应受益于未构建模型或不承担预测收益的人提出的质疑。独立性可与风险、成本和组织规模相称。

决策权应与生命周期事件挂钩。产品负责人可批准低影响的配置变更。风险委员会可批准高影响部署。董事会可保留对涉及重大资本、员工影响、客户资格、安全、受监管结果或声誉风险敞口的决策。紧急暂停权限应明确且可立即行使。

委员会应作出决策，而非仅听取汇报。每个议程事项应说明所请求的决策、选项、证据、负责人、未解决的限制和下次审查。项目组合办公室维护标准和记录。它不应把职能部门使用该系统的高管所负的问责集中到自己身上。

表 2. AI 运营模式下的决策权

R 表示负责，A 表示问责，C 表示受咨询，I 表示知会；具体分工应反映组织规模与适用要求。

4. 将战略转化为受控的用例章程

用例章程是战略、交付、管控与财务之间最小的有效契约。它界定业务问题、当前工作流程、目标用户、受影响方、决策角色、拟议干预措施、预期成果、约束条件、依赖关系、负责人、成本包络、证据计划与退出条件。它应足够简短以便治理，又足够精确以便检验。

当前工作流程应与拟议模型受到同等重视。在自动化之前，管理层需要掌握基线周期时间、错误率、转化率、成本、管控负担与客户结果。薄弱流程可能只是变成更快的薄弱流程。因此，用例应明确哪些步骤会改变、哪些决策仍由人工完成，以及哪个下游流程承接输出。

用例章程应说明模型的预期用途与禁止用途。一个用于汇总文件的系统，不应在未经新的评估的情况下，逐渐被用于客户资格决策。销售助手不应仅因其界面便利，就摄取保密的交易材料。清晰的边界有助于访问权限设计、监控与员工培训。

成功标准应涵盖四个维度：技术性能、运营采用、管控有效性以及财务或服务成果。只有当与其层级相关的各维度均具备证据时，用例才能推进。这可防止亮眼的模型评分让薄弱的运营用例通过关口。

用例章程还应界定决策假设。它说明谁将做出不同的决策、系统提供何种证据、决策必须在多快时间内发生，以及管理层将如何得知该变化改善了结果。这会迫使发起人识别模型输出与价值之间的人工或自动化行动。仅停留在输出质量层面的预测仍是不完整的。

退出标准同样重要。当问题已消失、干预措施无法达到其阈值、供应商经济性已变化、管控负担超过价值，或更简单的流程改进表现更佳时，管理层可以停止用例。用例章程应明确如何关闭访问权限、数据、记录、合同与下游依赖关系。预先规划的退出路径可在投资初期强化资本纪律。

5. 按后果、自主性、风险敞口与可逆性对用例分级

风险分级应决定治理强度。分类可考虑错误的后果、自动化程度、受影响利益相关方、风险敞口规模、数据敏感性、法律背景、模型新颖性、可解释性、外部依赖与可逆性。由受过培训的员工使用的起草助手，与改变客户访问权限或转移资金的自主系统存在实质性差异。

层级应结合具体情境归属于用例。同一模型用于内部头脑风暴时可能影响较低，而当其输出影响招聘、信贷、定价、安全或健康时则可能影响较高。这一用例视角与欧盟 AI 法案 [9][10]、NIST AI RMF [3]、ASIC 对持牌机构治理的审查 [27] 以及 OSFI 的模型风险框架 [29] 中所见的基于风险的方法相一致。

一种实用结构可包含四个内部层级。第一层涵盖后果较低且有人工明确复核的有限辅助。第二层涵盖可能影响客户或财务结果的运营建议或内容。第三层涵盖重大决策、敏感数据、高度自主或受监管的工作流程。第四层涵盖被禁止或超出风险偏好的活动。未经特定司法辖区分析，内部层级绝不应被呈现为法律分类。

分级是动态的。业务量增长、新数据、供应商更新、更广泛的自主性、新用户群体或重大事件都可能改变分类。因此，清单应记录分级依据、审批人和下次审查日期。

该矩阵是管理工具；法律分类需要另行分析。

表3。层级触发条件与最低控制措施示例

管理层应根据适用法律、行业和风险偏好调整触发条件和控制集。

6. 将数据权利和数据血缘视为运营先决条件

AI 的绩效与问责取决于组织能够识别、使用、保护和复现的数据。数据控制文件应记录来源、所有者、允许用途、合法或合同依据、分类、地域、保留期限、质量测试、转换、数据血缘和下游用途。还应识别个人数据、保密数据、享有特权保护的数据、受版权保护的数据、许可数据和敏感数据。

数据权利可能与数据质量同等重要。技术上可用的数据集可能无法用于模型训练、检索或供应商处理。客户协议、雇佣条款、数据库权利、知识产权、隐私规则和行业义务可能限制使用。法律批准应与具体用途和数据流挂钩，而不是与 AI 这一宽泛标签挂钩。

数据血缘应跟踪数据从来源到准备、检索、提示上下文、模型交互、输出存储和下游决策的全过程。这有助于复现、事件分析、删除、访问审查和收益归因。经合组织将 AI 问责与跨数据集、流程和决策的可追溯性联系起来 [1][2]。OSFI 的最终 E-23 指南同样强调模型的适用性、来源和企业数据治理 [29]。

生产数据应与开发和测试数据进行比较。总体变化、缺失字段、新类别、季节性和操作变通方法可能在不改变模型代码的情况下削弱模型。监控设计需要数据质量阈值，并明确一名能够纠正源流程的负责人。

7. 控制完整的模型与供应商依赖链

相关系统通常不限于单一模型。它可能包括基础模型、嵌入、检索数据库、编排层、安全过滤器、业务规则、应用程序、云服务、人工审核和下游系统。运营模型应记录该链条，并识别各方分别控制哪些组件。

供应商尽职调查应涵盖预期用途、服务架构、数据处理、次级处理者、模型版本、安全性、测试证据、知识产权条款、保密性、保留、事件通知、服务水平、审计权、变更通知、业务连续性、终止和数据返还。知名供应商的名称不能替代针对具体用例的尽职调查。

配置可能实质性改变行为。系统提示词、检索来源、温度参数、工具、权限、记忆、操作限制和回退规则均应纳入受控的变更管理。供应商可能在应用程序名称不变的情况下更新底层模型。公司需要设定明确的触发条件，以重新测试和重新审批。

集中度应在组合层面清晰可见。多个关键工作流可能依赖同一模型提供商、云平台或数据服务。董事会应了解中断、定价、合同和战略依赖，然后决定哪些替代方案、回退方案或人工流程是适当的。

表 4. 跨 AI 依赖链的证据

证据材料应与用例层级以及公司控制各组成部分的能力相称。

8. 依据总体运营经济性做出构建、购买和配置决策

自建还是购买的决策应纳入战略差异化、数据优势、集成复杂性、控制要求、价值实现时间、人才、基础设施、供应商依赖和全生命周期成本。一旦将集成、保障、监控和变更纳入考量，最便宜的试点也可能成为昂贵的运营依赖。

购买模型并不会转移对该用例的责任。企业仍须对用途、用户、数据、工作流、决策、监控和客户结果负责。内部自建可对一些组件提供更强的控制，同时也会带来工程、安全、文档、维护和人才延续性方面的义务。

配置往往是企业的主流路径。企业将外部模型与专有数据、提示词、规则和工作流相结合。这可以在不训练基础模型的情况下创造差异化价值。它也会形成一个性能依赖众多可变组件的系统。运营模式应治理配置后的整体系统。

投资论证应区分可复用的平台能力与特定用例的支出。身份、日志记录、评估、安全数据访问和编排可支持多个用例。财务部门可以透明地分摊共享成本，同时管理层应避免将整个平台的成本都计入每个早期用例。

9. 采用要求证据而非热情的生命周期关卡

生命周期可包含六个关卡：发现、设计、验证、部署、扩展和退役。每个关卡都应有准入标准、所需证据、决策权限、有条件批准以及有时限的例外通道。关卡应在证据支持下一阶段风险敞口时关闭，而不是在项目团队完成幻灯片演示时关闭。

发现阶段确认问题、负责人和基线。设计阶段定义工作流、数据、系统和控制架构。验证阶段测试技术性能、人工流程、安全性和相关权利。部署阶段引入受控的生产环境暴露。扩展阶段需要证据表明，在更大规模下采用率、控制措施和收益仍然稳健。退役阶段以受控方式移除访问权限、依赖关系和留存数据。

NIST 操作手册在治理、映射、测量和管理方面提供了行动措施 [4]。NIST 生成式 AI 概况增加了对虚构、信息完整性、隐私、安全和知识产权等风险的关注 [5]。生命周期关卡应将这些考量转化为用例证据。

当局限性已知且受控时，有条件批准可能很有价值。记录应明确范围、缓解措施、负责人、到期时间以及续期所需证据。开放式例外会让试点缺陷固化为永久性的生产设计。

只有在相关证据和授权到位后，才应增加风险敞口。

10. 在系统实际运行的场景中验证系统

验证应针对预期用途测试系统、工作流和用户行为。技术评估可包括准确性、可靠性、稳健性、偏见、可解释性、隐私、安全、延迟和成本。运营评估应考察升级处置、人工审核、下游行动、边缘案例、例外数量和恢复情况。

测试集应反映生产总体和实质性失效模式。平均性能可能掩盖罕见事件、特定客户群体或高价值案例的不良结果。阈值应与后果挂钩。轻微的起草错误和错误的付款指令需要不同的容忍度。

独立质疑应与风险相称。审查者应理解用例、数据、模型、工作流和适用要求，然后评估证据是否支持部署。对于影响较大的用例，审查者应能够复现关键测试，并质疑指标、总体、阈值和缓释措施的选择。

生成式系统除了基准分数外，还需要定性评估和对抗性评估。测试可涵盖无依据陈述、提示注入、机密数据泄露、有害内容、工具滥用、不一致回复和拒答行为。NIST 生成式 AI 概况以及 CISA 与国际合作伙伴的安全开发指南提供了相关参考点 [5][17][18]。

真实基准应受到治理。标签和预期答案可能包含专家分歧、过时政策或历史偏差。验证记录应标明谁创建了测试案例、来源日期、审查方法、不确定性和总体覆盖范围。在无法获得确切答案时，管理层可评估系统是否引用权威证据、表达不确定性并适当升级处理。

评估还必须反映频率和成本。高用量助手可能需要自动监测加抽样专家审查。罕见但重大的决策可能值得全面案例审查。运营模式应为持续评估编制预算，而不是将生产前测试视为一次性项目成本。当模型、数据、工作流或受影响总体发生变化时，验证证据会失去相关性。

11. 将人工监督定义为决策设计

人工监督应明确谁审查什么、依据哪些信息、在什么时间约束下以及拥有什么权限。当审查者缺乏专业知识、产出过多、证据薄弱或有动机接受机器建议时，要求“保留人工在环”的泛泛指令可能失效。

该设计可区分批准、核验、异常处理和申诉。审查者可以批准每一项高影响结果、抽样低影响输出、调查阈值突破情况，并为受影响方提供升级路径。审查者需要获取源证据和已知局限性，而不仅仅是润色后的模型答案。

自动化偏差应被视为运营风险。培训、界面设计和质量抽样可以检验员工是否会质疑输出。覆盖操作应记录原因，以便管理层区分健康判断与不一致做法。反复出现的覆盖模式可揭示模型、数据或工作流问题。

权限应与后果相匹配。用户可以更正草稿。职能负责人可以暂停工作流。风险负责人可以要求实施控制。董事会或保留委员会可以撤回重大用例。在停机或事件期间，该操作仍应可行。

12. 通过受控生产发布和变更管理进行部署

生产部署应使用经批准的环境、访问控制、版本控制、日志记录、职责分离、回滚、容量规划、服务监控和发布记录。部署决策应确认运营负责人、支持团队和用户与技术一同就绪。

发布包应标明模型和组件版本、配置、数据源、测试、局限性、审批、监控阈值、事件联系人和回退方案。这创建了可复现的基线。重大变更应触发相应子集的重新测试和审批。

变更分类可区分常规、重大和紧急变更。提示措辞更正可走标准流程。新的工具权限、模型系列、数据源、自主行动或受影响客户群体可能需要重新进行风险评估。紧急变更应在事后审查。

部署还应保护非AI工作流。当提供商不可用或模型被暂停时，人工回退、服务连续性和记录访问至关重要。在系统变得关键之前，应测试韧性。

13. 监控性能、漂移、事件和控制有效性

监控应遵循用例假设。技术指标可包括准确率、错误类型、校准、漂移、延迟、可用性、token 或计算成本以及安全事件。运营指标可包括采用率、完成时间、返工、人工覆盖、投诉、例外和下游缺陷。效益指标应跟踪受控的财务或服务结果。

阈值需要触发行动。黄色边界可能需要调查并限制规模。红色边界可能需要暂停、回滚或人工兜底。应记录责任人、响应时间和升级路径。没有行动逻辑的仪表盘只是观察，而非控制。

事件管理应对危害进行分类、控制暴露面、保留证据、在需要时通知内部和外部相关方、纠正系统并确认恢复。它应涵盖供应商事件和未遂事件。经验教训应更新测试、阈值、培训和组合标准。

监控必须保持版本意识。模型或数据变更前的性能不应与变更后的性能混合。记录应支持队列分析，并说明是哪个群体、版本和工作流产生了结果。

这些数值为假设性管理设定，用于展示均衡的监控视角。

14. 将安全与韧性纳入产品设计

AI 系统在带来常见的软件和数据风险的同时，也带来模型特有的攻击路径。威胁可能涉及提示注入、数据投毒、不安全的工具访问、模型窃取、敏感数据泄露、对抗性输入、不安全输出和依赖项被攻破。因此，安全应从架构和预期用途开始。

威胁模型应识别资产、行为者、信任边界、接口和潜在滥用。控制措施可包括经批准的环境、最小权限、输入和输出处理、密钥管理、网络限制、检索权限、工具允许列表、内容控制、日志记录、异常检测、红队测试和事件响应。正确的控制组合取决于后果和暴露程度。

智能体系统值得特别关注，因为它们可以调用工具并改变外部状态。权限、交易限额、确认步骤、职责分离和可逆操作都应明确。模型能够生成正确的计划，并不代表其有权执行该计划。

CISA、英国 NCSC 及国际合作伙伴发布的安全设计指南强调，应在设计、开发、部署和运营各阶段落实安全 [17][18]。运营模式应将其转化为关卡证据和可问责的安全负责人。

15. 将隐私、知识产权和记录纳入工作流

隐私分析应遵循实际数据流和受影响人员。管理层应了解哪些个人数据进入提示、检索系统、日志和输出；数据流向何处；谁可以访问；保留多长时间；以及权利如何行使。用途变更和自动化决策的使用可能需要额外分析。

知识产权控制应覆盖输入、训练或微调数据、生成输出、供应商条款、开源组件、员工工作成果和客户材料。公司应界定生成内容何时可以发布、纳入产品、作为建议依据或对外共享。

记录政策应在遵守保留期限的同时保留决策和证据。重大审批、测试、模型版本、提示词或配置、例外、事件和效益验证可能需要受控保留。日常对话数据可能适用不同的保留安排。

欧盟 AI 法案、相关透明度指引、英国数据保护指引、UAE 以及沙特伦理框架和新加坡治理材料，均表明可追溯性、透明度和可问责使用日益重要 [9][11][15][20][21][22][25][26]。适用性和法律效力取决于具体系统、角色和司法管辖区。

16. 基于受控基线和反事实构建效益论证

效益跟踪在部署前开始。章程应记录当前流程、数量、人工、成本、周期时间、质量、转化率、服务和风险结果。还应界定反事实：管理层预期在没有干预的情况下会发生什么。简单的前后对比可能将市场增长、定价、人员配置或流程变化错误归因于 AI。

每项效益都应有公式、数据来源、频率、负责人和验证方法。节省的时间只有在公司改变产能、成本、吞吐量或服务时才会转化为财务价值。预计处理时间减少在运营上可能有用。在有证据表明其与人员配置、产出或避免支出之间的衔接之前，不应将其表述为 EBITDA。

收入效益也需要类似的纪律。由 AI 辅助的销售流程可能影响线索质量、转化率、价格、留存率或销售代表产能。公司应识别作用机制，在可行时比较同类群组，控制其他变化，并避免在多个举措中重复计算同一收入。

全成本视图应包括许可证、算力、实施、集成、数据准备、保证、安全、培训、支持、变更管理和持续监控。共享平台成本应一致分摊。退出成本和供应商价格敏感性也应纳入论证。

归因可采用多种设计。随机化推广可在符合伦理且运营可行的情况下提供有力证据。分阶段实施、匹配队列、中断时间序列或流程级分解在其他场景可能更合适。所选方法应在审查结果之前说明，并记录局限性和同期变化。管理层应抵制在事后选择能产生最有利数字的方法。

效益可以是财务、服务、风险或能力成果。当证据不支持时，不应强行将其转化为货币估算。响应变异性的受控降低或可追溯性的改善，即使财务无法验证对损益表的即时影响，也可能对董事会具有重要意义。登记表可以展示运营成果及其决策相关性，同时保留财务价值的边界。

公共部门效益指引提供了一条有用的通用原则：效益应在整个生命周期中被识别、定义、跟踪、实现和保持，并配有可问责的负责人和保证 [31][32]。同样的纪律可改善私营公司的资本配置。

表 5. 受控 AI 效益登记表

预测值、观测值和经财务验证的数值应保持分离。

17. 将运营证据转化为损益表、现金和价值桥

财务应维护一座从运营总效益到经验证经济成果的桥接。从观测到的产出或绩效变化开始。剔除销量、组合、价格、市场及其他同期效应。扣除运行成本、相关实施摊销、增量控制成本及替代效应。识别结果是否落到收入、毛利率、运营费用、营运资本、资本支出或风险。

会计处理应与管理层效益计量保持分离。IAS 38 包含无形资产的确认标准，IASB 也持续研究涉及 AI 相关数据与解决方案的问题 [33]。管理层应获取会计建议，而不是假定内部描述的投资或效益决定财务报表处理。

效益桥应采用期间、累计和运行率视图。一个用例可能带来一次性实施负担、经常性成本和随后产生的经常性效益。现金时点可能与会计费用不同。董事会需要这三个维度来分配资本。

预测置信度应明确。与基于薄弱采用假设构建的单一精确数字相比，带有明确驱动因素的区间对决策更有用。敏感性分析可展示用户采用率、任务量、供应商价格、错误率和规模化时间。

上述数值为假设性的管理层假设，不代表客户成果或预测。

18. 将采用和工作流程重塑视为投资的一部分

AI 的效益取决于工作方式改变。采用应定义为在预期工作流程中的正确使用，而不是登录或许可证活动。公司应知道谁使用系统、用于哪些任务、经过何种审查，以及输出是否改变下游决策。

工作流程重塑可以消除交接、改变角色边界并创建新的控制步骤。它也可能暴露此前由员工吸收的隐性工作。流程映射应识别时间转移到何处、哪些队列消失、哪些例外情形增加，以及哪些技能变得更有价值。

培训应针对角色和用例。用户需要了解目的、边界、数据规则、审查期望、升级路径、示例和已知限制。管理者需要解读监控和效益证据。技术和控制团队需要了解生命周期职责。董事会成员需要了解组合经济性和重大风险敞口。

劳动力计划应着眼于能力配置，而不是假定可立即削减成本。释放出的时间可用于支持业务量增长、服务、质量或避免增加人员编制。已实现的经济效果取决于管理层的行动。还可能适用员工协商和当地就业要求。

19. 通过项目组合门控配置资本

项目组合应围绕稀缺的资本、数据、工程能力、控制能力和管理关注度展开竞争。通用评分框架可比较战略相关性、可触达价值、证据质量、产生影响所需时间、复用性、风险、依赖关系和实施负担。评分用于辅助判断，不应使投资决策自动化。

资金可以分阶段投入。发现阶段获得少量证据预算。基线和架构可信后，验证阶段获得资源。生产资金在测试成功和控制就绪后到位。规模化资金在采用和早期效益证据出现后跟进。这可减少沉没成本不断升级。

项目组合审查应识别停止决策。一个用例可能在技术上成功但经济上缺乏吸引力。另一个用例可能仍有价值，但需要不同的供应商或工作流。证据变化时，资本应随之转移。

共享平台需要独立的治理。身份、数据访问、评估、监控和模型网关可降低整个项目组合的边际成本。其价值可通过所支撑的用例、避免的重复建设和控制质量来衡量，同时还要考虑服务成本和集中度风险。

资本审查应考虑学习的价值。一个范围有限的实验可能值得资助，因为它能消除有关数据、采用、客户反应或技术可行性的重大不确定性。决策记录应说明该不确定性、所需证据、最大敞口，以及管理层将据此扩大、重新设计或停止的日期。这将以具有明确到期日的购买选择权来对待实验，而不是将其视为无限期试点。

项目组合还应识别瓶颈。十个已获资助的用例可能争抢同一名数据负责人、安全审查人员或工作流团队，导致所有用例延误。能力规划应围绕决定吞吐量的稀缺能力来安排工作顺序。董事会随后可以决定是增加能力、收窄项目组合，还是改变架构。

20. 在不割裂核心的情况下应用司法辖区和行业叠加层

企业可以维护一个核心运营模式，并针对法律实体、地理区域、行业和用例附加叠加层。核心包含清单、归属、分级、生命周期、证据、监控和效益。叠加层增加适用的权利、审批、记录、披露、测试或监管期望。

欧盟 AI 法案采用基于风险的框架，其义务因系统和行为主体而异；执法和适用时间仍在持续发展 [9][10][11][12]。英国当局在现有监管机构之外采用跨行业原则，而 PRA 对指定公司适用模型风险预期 [14][16]。美国来源包括自愿性 NIST 框架、行业规则以及对无依据主张的执法 [3][5][19]。

UAE 和沙特阿拉伯发布伦理与治理指引，强调问责、透明、隐私、安全和负责任采用 [20][21][22][23]。印度 RBI 的 FREE-AI 工作涉及金融领域的负责任 AI [24]。新加坡的治理框架和 AI Verify 计划支持实际测试和负责任部署 [25][26]。ASIC 已发现受审查持牌机构在 AI 采用与治理之间存在差距 [27]。加拿大 OSFI 已敲定一项广泛的生命周期模型风险指引，纳入 AI 考量，并于 2027 年生效 [29][30]。

这些来源在法律地位、范围和时间安排上各不相同。运营模式应记录每个用例的适用性和建议。全球政策声明不应替代当地法律分析。

跨境架构要求从运营角度审视数据位置、远程访问、供应商处理、支持团队、事件通知和监管访问。合同可能指定一个服务区域，而遥测、人工支持或子处理商却在其他地区运营。数据流记录应反映实际处理情况，并应在服务变化时更新。

行业叠加层可以增加控制，而无需创建单独的企业系统。金融用例可能需要模型风险、行为操守和客户结果证据。医疗健康、就业、安全或关键基础设施用例可能需要不同的专业、权利和韧性分析。通用清单和门控结构可保持项目组合可见性，而叠加层可保持特定领域的问责制。

21. 通过一个假设的服务运营案例测试该框架

设想一家假设的被投企业每年处理 240,000 个客户服务请求。管理层提议使用一个助手，该助手检索经批准的知识、起草回复并推荐路由代码。员工仍负责审核和提交。公司预计处理时间缩短且返工减少。

探索阶段确立当前工作流程：处理时间中位数、质量审核、重复联系、投诉率、排队情况、人员构成和季节性业务量。项目章程将客户运营确定为业务负责人、技术确定为系统负责人、知识团队确定为数据负责人、财务确定为收益验证方。设计前先对个人数据和机密数据进行映射。

该用例被归入中间层级，因为输出会触达客户，并可能影响服务或权利，而经过培训的员工保留审批权。验证使用代表性案例、困难类别、对抗性提示词，并单独测试检索权限。公司为事实支撑、路由准确性、机密数据处理、审核质量和投诉结果设定阈值。

初步试点显示，符合条件的请求处理时间在假设情形下缩短 24%。只有 58% 的请求符合条件，采用率达到符合条件的业务量的 70%。因此，管理层避免将 24% 应用于整个成本基数。财务部门根据实际符合条件的业务量、采用率、返工和增量运行成本，对已实现产能进行建模。

规模化审批取决于受控的知识更新、用户培训、阈值稳定性以及针对释放产能的人员计划。董事会分别获得预测、观测和验证收益。不能仅因模型已部署就赋予其价值。

22. 向董事会提供决策材料包，而不是 AI 活动报告

董事会材料包应展示组合敞口、决策和证据。一页式仪表板可以包括按层级和生命周期划分的用例、已承诺资本、预测价值和已验证价值、采用率、重大依赖、控制例外、事件、逾期审查和所需决策。明细应放在仪表板的下钻层。

每个重大用例都应显示负责人、预期成果、阶段、风险层级、最新证据、未解决的限制、下一道关口和收益状态。收益应分为预测值、观测值和经财务验证的价值。成本应包括已承诺、已发生和运行率视图。

指标变化时，叙述说明很重要。管理层应解释采用率、模型表现、控制阈值或价值为何变动；随后采取了什么决策；以及谁负责该行动。材料包应保持版本和期间一致性。

董事会还应看到集中度：按供应商、云、数据源和关键人员划分的关键工作流。这将 AI 监督与运营韧性、网络风险、采购和继任衔接起来。

保证工作应以覆盖图的形式呈现。内部审计、风险、合规、安全、隐私、财务和外部专家可能各自测试系统的一部分。董事会应看到哪些重大认定已被审查、审查期间和范围、未解决的发现以及管理层回应。当多项审查检查同一狭窄控制点，且未触及责任归属、采用或收益归属时，多项审查并不能形成完整保证。

董事会信息应随组合的成熟而完善。早期材料包可强调清单完整性、风险偏好和关口设计。扩张中的组合应强调生产环境表现、事件、集中度和已验证价值。成熟组合还应显示退役、控制效率以及共享能力是否在降低边际成本。当董事会的决策发生变化时，信息架构应随之改变。

表 6. 董事会 AI 运营模式记分卡

每一行都应导向一项决策、升级或已确认的运营行动。

23. 在一百天内实施运营模式

前三十天建立可见性和权限。任命执行发起人，批准临时风险偏好，识别重大用例和工具，确定清单，指定负责人，并停止任何超出明确边界的活动。财务部门选定少量优先效益基线。

第三十一天至第六十天构建控制骨架。定义风险层级、生命周期关卡、最低证据要求、变更分类、事件上报路径、供应商要求和效益登记册。选择两到三个具有商业相关性且边界足够清晰、可用于测试该体系的优先用例。

第六十一天至第九十天运行首个受控周期。为选定用例完成设计、数据映射、验证、安全审查、用户培训和生产就绪。记录附条件批准和例外情况。建立监控机制和由财务部门负责的效益衔接机制。

第九十一天至第一百天完成首个董事会周期。呈现清单、风险敞口、证据、早期运营成果、效益信心、决策以及下一季度资本配置。只有当治理、交付和财务部门使用相同的记录时，运营模式才会成为常规。

时间安排仅为示意，在系统影响、监管要求或组织准备度需要时应相应延长。

参考文献

1. 经合组织，经合组织 AI 原则，2024年更新， https://www.oecd.org/en/topics/ai-principles.html
2. 经合组织，AI，数据治理与隐私：协同效应与国际合作领域，2024年， https://www.oecd.org/content/dam/oecd/en/publications/reports/2024/06/ai-data-governance-and-privacy_2ac13a42/2476b1a4-en.pdf
3. 美国国家标准与技术研究院，《人工智能风险管理框架 1.0》，2023年， https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf
4. 美国国家标准与技术研究院，AI RMF 实践手册，2026年更新， https://www.nist.gov/itl/ai-risk-management-framework/nist-ai-rmf-playbook
5. 美国国家标准与技术研究院，人工智能风险管理框架：生成式人工智能概况，2024年， https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf
6. 美国国家标准与技术研究院，可信与负责任的 AI 资源中心，2026年， https://airc.nist.gov/
7. 国际标准化组织，ISO/IEC 42001:2023 人工智能管理体系，2023年， https://www.iso.org/standard/42001.html
8. 国际标准化组织，ISO/IEC 23894:2023 人工智能风险管理，2023年， https://www.iso.org/standard/77304.html
9. 欧盟委员会，AI 法案：人工智能监管框架，2026年更新， https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai
10. 欧盟委员会，AI 法案的执行框架，2026年， https://digital-strategy.ec.europa.eu/en/policies/enforcement-ai-act
11. 欧盟委员会，关于特定 AI 系统提供者和部署者透明度义务的指南，2026年， https://digital-strategy.ec.europa.eu/en/policies/guidelines-ai-transparency-obligations
12. 欧盟委员会，关于通用 AI 提供者义务的指南，2025年， https://digital-strategy.ec.europa.eu/en/faqs/guidelines-obligations-general-purpose-ai-providers
13. EUR-Lex，欧盟第2016/679号条例，通用数据保护条例，2016年， https://eur-lex.europa.eu/eli/reg/2016/679/oj
14. 英国政府，落实英国 AI 监管原则：监管机构指南，2024年， https://assets.publishing.service.gov.uk/media/65c0b6bd63a23d0013c821a0/implementing_the_uk_ai_regulatory_principles_guidance_for_regulators.pdf
15. 信息专员办公室，关于 AI 与数据保护的指南，2023年更新， https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/artificial-intelligence/guidance-on-ai-and-data-protection/
16. 英格兰银行，审慎监管局，SS1/23 银行模型风险管理原则，2026年更新， https://www.bankofengland.co.uk/prudential-regulation/publication/2023/may/model-risk-management-principles-for-banks-ss
17. 美国网络安全和基础设施安全局与英国国家网络安全中心，《安全 AI 系统开发指南》，2023年， https://www.cisa.gov/news-events/alerts/2023/11/26/cisa-and-uk-ncsc-unveil-joint-guidelines-secure-ai-system-development
18. 美国网络安全和基础设施安全局，《选择安全且可验证的技术》，2024年， https://www.cisa.gov/resources-tools/resources/choosing-secure-and-verifiable-technologies
19. 美国联邦贸易委员会，《人工智能：执法与商业指引》，2026年更新， https://www.ftc.gov/industry/technology/artificial-intelligence
20. UAE 人工智能、数字经济和远程工作应用国务部长办公室，《UAE 关于 AI 政策的立场》，2024年， https://ai.gov.ae/wp-content/uploads/2024/10/UAE-Guiding-on-ai-policy-EN-V3.pdf
21. UAE 人工智能办公室，《AI 伦理原则与指南》，2022年， https://ai.gov.ae/wp-content/uploads/2023/05/MOCAI-AI-Ethics-EN.pdf
22. 沙特数据和人工智能管理局，《AI 伦理原则》， https://sdaia.gov.sa/en/SDAIA/about/Documents/ai-principles.pdf
23. 沙特数据和人工智能管理局，《法规与政策》，2026年更新， https://sdaia.gov.sa/en/SDAIA/about/Pages/RegulationsAndPolicies.aspx
24. 印度储备银行，《FREE-AI 委员会报告：负责任且合乎伦理地赋能人工智能的框架》，2025年， https://www.rbi.org.in/Scripts/PublicationReportDetails.aspx?UrlPage=&ID=1299
25. 新加坡个人资料保护委员会，《人工智能治理示范框架》，2020年， https://www.pdpc.gov.sg/help-and-resources/2020/01/model-ai-governance-framework
26. 新加坡资讯通信媒体发展局，《生成式 AI 的 AI 治理示范框架》，2024年， https://www.imda.gov.sg/resources/press-releases-factsheets-and-speeches/press-releases/2024/model-ai-governance-framework-for-generative-ai
27. 澳大利亚证券和投资委员会，REP 798《警惕差距：面对 AI 创新时的治理安排》，2024年， https://asic.gov.au/regulatory-resources/find-a-document/reports/rep-798-beware-the-gap-governance-arrangements-in-the-face-of-ai-innovation/
28. 澳大利亚审慎监管局，CPS 230《操作风险管理》，2026年更新， https://www.apra.gov.au/standards/cps-230
29. 加拿大金融机构监管办公室，E-23 号指南《模型风险管理》，2025年， https://www.osfi-bsif.gc.ca/en/guidance/guidance-library/guideline-e-23-model-risk-management-2027
30. 加拿大金融机构监管办公室与加拿大金融消费者局，《AI 在联邦监管金融机构中的使用与风险》，2024年， https://www.osfi-bsif.gc.ca/en/about-osfi/reports-publications/osfi-fcac-risk-report-ai-uses-risks-federally-regulated-financial-institutions
31. 英国基础设施和项目管理局与内阁办公室，《重大项目中有效效益管理指南》，2017年， https://www.gov.uk/government/publications/guide-for-effective-benefits-management-in-major-projects
32. 英国政府，《政府效率框架》，2025年， https://www.gov.uk/government/publications/the-government-efficiency-framework/the-government-efficiency-framework--2
33. IFRS基金会，《无形资产：其他潜在测试案例，包括数据资源及人工智能相关数据与解决方案》，2026年， https://www.ifrs.org/content/dam/ifrs/meetings/2026/january/iasb/ap17d-other-potential-test-cases-data-ai.pdf

来源与延伸阅读

1. 经合组织，经合组织 AI 原则，2024年更新， 官方来源
2. 经合组织，AI，数据治理与隐私：协同效应与国际合作领域，2024年， 官方来源
3. 美国国家标准与技术研究院，《人工智能风险管理框架 1.0》，2023年， 官方来源
4. 美国国家标准与技术研究院，AI RMF 实践手册，2026年更新， 官方来源
5. 美国国家标准与技术研究院，人工智能风险管理框架：生成式人工智能概况，2024年， 官方来源
6. 美国国家标准与技术研究院，可信与负责任的 AI 资源中心，2026年， 官方来源
7. 国际标准化组织，ISO/IEC 42001:2023 人工智能管理体系，2023年， 官方来源
8. 国际标准化组织，ISO/IEC 23894:2023 人工智能风险管理，2023年， 官方来源
9. 欧盟委员会，AI 法案：人工智能监管框架，2026年更新， 官方来源
10. 欧盟委员会，AI 法案的执行框架，2026年， 官方来源
11. 欧盟委员会，关于特定 AI 系统提供者和部署者透明度义务的指南，2026年， 官方来源
12. 欧盟委员会，关于通用 AI 提供者义务的指南，2025年， 官方来源
13. EUR-Lex，欧盟第2016/679号条例，通用数据保护条例，2016年， 官方来源
14. 英国政府，落实英国 AI 监管原则：监管机构指南，2024年， 官方来源
15. 信息专员办公室，关于 AI 与数据保护的指南，2023年更新， 官方来源
16. 英格兰银行，审慎监管局，SS1/23 银行模型风险管理原则，2026年更新， 官方来源
17. 美国网络安全和基础设施安全局与英国国家网络安全中心，《安全 AI 系统开发指南》，2023年， 官方来源
18. 美国网络安全和基础设施安全局，《选择安全且可验证的技术》，2024年， 官方来源
19. 美国联邦贸易委员会，《人工智能：执法与商业指引》，2026年更新， 官方来源
20. UAE 人工智能、数字经济和远程工作应用国务部长办公室，《UAE 关于 AI 政策的立场》，2024年， 官方来源
21. UAE 人工智能办公室，《AI 伦理原则与指南》，2022年， 官方来源
22. 沙特数据和人工智能管理局，《AI 伦理原则》， 官方来源
23. 沙特数据和人工智能管理局，《法规与政策》，2026年更新， 官方来源
24. 印度储备银行，《FREE-AI 委员会报告：负责任且合乎伦理地赋能人工智能的框架》，2025年， 官方来源
25. 新加坡个人资料保护委员会，《人工智能治理示范框架》，2020年， 官方来源
26. 新加坡资讯通信媒体发展局，《生成式 AI 的 AI 治理示范框架》，2024年， 官方来源
27. 澳大利亚证券和投资委员会，REP 798《警惕差距：面对 AI 创新时的治理安排》，2024年， 官方来源
28. 澳大利亚审慎监管局，CPS 230《操作风险管理》，2026年更新， 官方来源
29. 加拿大金融机构监管办公室，E-23 号指南《模型风险管理》，2025年， 官方来源
30. 加拿大金融机构监管办公室与加拿大金融消费者局，《AI 在联邦监管金融机构中的使用与风险》，2024年， 官方来源
31. 英国基础设施和项目管理局与内阁办公室，《重大项目中有效效益管理指南》，2017年， 官方来源
32. 英国政府，《政府效率框架》，2025年， 官方来源
33. IFRS基金会，《无形资产：其他潜在测试案例，包括数据资源及人工智能相关数据与解决方案》，2026年， 官方来源