4. 治理制度体系的顶层设计

AI治理制度体系如果直接从“员工不得泄露数据”“模型上线需审批”这类条款写起，往往会陷入两个困境：一是条款之间互相冲突，二是没人说得清最终由谁拍板。顶层设计要解决的正是这两个问题——先用一份AI治理章程确立治理的合法性来源与总原则，再用治理委员会架构明确决策层级，最后用RACI职责矩阵把每一项治理活动落到具体角色上。三者构成“宪法—政府—岗位说明书”的递进关系。

一、AI治理章程：写什么、不写什么

章程是治理体系的最高文件，它不规定技术细节，只回答四个根本问题：为什么治理、治理什么、谁来治理、按什么原则治理。一份可落地的章程通常包含以下要素：

• 目的与适用范围：明确覆盖本企业全部AI系统（含自研、采购、嵌入式AI功能），并声明与现有信息安全、数据合规制度的关系。
• 治理原则：建议控制在5～7条，例如“人类最终控制”“风险分级管理”“可追溯与可解释”“数据最小必要”“公平无歧视”。原则过多会失去约束力。
• 治理组织与授权：写明治理委员会的设立依据、主任人选、表决机制，以及其对AI项目“一票否决”或“暂缓上线”的权力边界。
• 违规与例外处理：规定例外申请的审批路径和有效期，避免“特批”变成常态。

章程不宜写入具体阈值（如“准确率不低于95%”），这类参数应放在下位的《AI风险管理规范》中，以便随业务调整而修订。章程的修订周期建议为一年一次，或发生重大监管变化时临时修订。

二、治理委员会架构：三层决策与两条支撑线

治理委员会不是单一会议，而是一个分层架构。典型设计为三层：决策层（AI治理委员会）、管理层（AI治理办公室/工作组）、执行层（各业务线与职能部门的AI责任人）。决策层由CEO或CTO担任主任，成员包括法务、合规、信息安全、数据、人力资源、核心业务负责人；管理层通常设在合规部或战略部之下，负责日常协调、材料准备、风险台账维护；执行层则是各业务单元指定的AI联络人。

两条支撑线同样关键：一条是独立监督线，由内部审计或董事会风险委员会承担，直接向决策层汇报，不经过管理层，以保证监督独立性；另一条是外部专家线，通过外部顾问或伦理委员会提供技术、法律、社会影响方面的独立意见。缺少监督线的治理架构，容易退化为“自己审批自己”。

三、RACI职责矩阵：把治理活动落到角色

架构解决了“谁在哪个层级”，RACI解决的是“每件事谁负责”。RACI分别代表：R（Responsible，执行者）——实际做事的人；A（Accountable，批准者）——最终拍板并承担后果的人，每项活动有且仅有一个A；C（Consulted，被咨询者）——事前提供意见的双向沟通方；I（Informed，被告知者）——事后知悉的单向沟通方。

以下是一份可直接参考的AI治理RACI示例表，覆盖从制度制定到模型退役的关键活动。表中角色缩写：GC=治理委员会，GO=治理办公室，BL=业务线AI责任人，IA=内部审计，LG=法务合规。

填写RACI时有三个常见错误需要避免。第一，多个A：一项活动出现两个A，等于没人最终负责，必须收敛到一个角色。第二，把C当I用：C是事前必须征求意见，I只是事后通知，混淆会导致要么过度沟通、要么关键意见被漏掉。第三，执行层缺位：如果所有R都落在治理办公室，业务线只当I，制度就会脱离实际，落地时必然打折扣。

四、顶层设计草案的落地路径

完成上述三份文件后，建议按以下顺序推进：第一步，由治理办公室起草章程和RACI初稿，用2～3周时间与各业务线一对一沟通，收集对职责划分的异议；第二步，召开治理委员会首次会议，审议章程、确认委员会成员与表决规则、批准RACI矩阵；第三步，将章程和RACI以正式文件发布，并纳入新员工AI合规培训和年度考核指标；第四步，设置3个月试运行期，期间记录RACI执行中的模糊地带，试运行结束后修订一次。

顶层设计的最终检验标准很简单：当出现一个高风险AI项目时，能否在48小时内明确“谁批准、谁执行、谁监督、谁被告知”。如果答案清晰，说明章程、架构和RACI已经形成闭环；如果仍然需要临时找人拍板，说明顶层设计还需要回到RACI矩阵中补齐职责空白。