董事会级别的 AI 治理：只有高管才能做的五个决策

一家大型保险公司的 AI 系统正在拒绝理赔申请。人工审核这些决定后，发现其中 90% 是错误的。这家保险公司的工程团队构建了性能出色的模型，MLOps 团队有完善的部署流水线，数据科学家有严格的评估指标。但这一切都无济于事，因为在董事会层面，从来没有人回答过这个问题：对于影响病人能否获得治疗的 AI 决策，我们可接受的失败率是多少？

这个缺口——功能正常的技术系统与缺失的高管决策之间的鸿沟——正是 AI 治理在实践中最常出现问题的地方。结果是：组织同时在生产环境中运行 AI，却暴露在从未正式承认的责任风险之下。

目前，50–75% 的企业在运营中使用 AI，而拥有董事会批准的结构化 AI 政策的企业不足 25%。欧盟《AI 法案》中关于禁止用途的条款已于 2025 年 2 月生效，高风险 AI 的合规阶段将在 2026–2027 年陆续到来。美国证监会（SEC）已将 AI 治理信披列为投资者关切。类诉讼案例正在确立这样一个原则：董事会对其监管下的算法决策负有受托责任。

工程师通常接触到的 AI 治理文章聚焦于工具层面：模型注册表、评估流水线、审计日志、提示词版本管理。这些工作很重要，但无法替代五项只有高管才能做出的战略决策——无论 MLOps 多么精密，都无法弥补这些决策的缺失。

决策一：风险偏好

风险偏好是最基础的决策，也是大多数组织从未正式做出的决策。

工程团队经常在做隐性的风险决策：为欺诈模型选择置信度阈值，为 Agent 工作流设置重试预算，选择最小化用户投诉的误报率。这些都是在一个未言明上限内做出的工程权衡——但这个上限本身是业务和法律决策，而非技术决策。

董事会需要明确界定不同类别 AI 决策可接受的失败率。推荐系统和信贷审批系统的可接受误差率截然不同。客服聊天机器人和诊断工具对人工审核的要求也不一样。这些阈值决定了哪些系统可以自主部署，哪些需要人工介入审核，哪些根本不应该构建。

这一决策的实际产出是一个风险分级矩阵——通常分为高、中、低风险类别——并为每个类别规定性能底线和人工监督要求。工程团队由此可以按规格构建，而不是靠猜测意图。

没有这个决策，风险就默认由工程团队承担。他们在竞争压力下做出本应是董事会政策级别的判断，且没有任何书面授权。

决策二：责任模型

当 AI 系统造成损害时，谁来负责？这看似是个法律问题，但其答案对工程实践有直接影响。

组织需要在几种责任立场中做出选择：严格责任意味着公司对所有 AI 输出负责，不论原因；替代责任意味着责任流向部署或使用系统的人；共同责任则根据决策链条，在供应商、部署方和运营方之间分配责任。

加拿大航空聊天机器人案说明了这一点的重要性。一名乘客从航空公司的客服聊天机器人处获得了错误信息并据此行动。法院判定加拿大航空承担责任——聊天机器人被视为公司代表，而非外部产品。治理失败不在于 ML 模型，而在于没有任何高管层面的人定义过公司对聊天机器人输出的责任立场，而这一立场本应决定所需的审核流程、免责声明和人工升级路径。

欧盟《AI 法案》现在对高风险 AI 部署者施加了责任框架，无论他们是否在内部定义过。保险条款正在收紧：董事及高管责任险（D&O）中广泛的 AI 除外条款，使董事会在 AI 事件发生时面临来自股东的个人诉讼风险。在 AI 事件中最能全身而退的组织，是那些在事件发生前就定义了责任模型的组织——而不是拥有最好模型的组织。

决策三：模型选择权限

谁有权批准部署新的 AI 模型或切换供应商？在大多数公司，这个问题的实际答案是：最后一个批准 PR 的人。

未定义模型选择权限的后果会悄悄积累：工程师使用最好用的工具，产品经理在紧迫的时间线内接入第三方 API，团队运行的实验逐渐演变为生产功能，影子 AI 蔓延。据 2025 年的安全数据显示，影子 AI 使用率高的组织，平均违规成本比有适当访问控制的组织高出 67 万美元。

模型选择权限要求董事会明确：在生产环境中使用新 AI 模型需要什么批准，不同风险等级的模型由谁有权审批，接入前必须进行哪些供应商尽职调查，以及开源模型与商业 API 的审批流程有何不同。

这个决策不必繁文缛节。分级审批制度行之有效：低风险模型可由部门负责人批准，中风险由 CTO 批准，高风险由正式的 AI 治理委员会批准。关键是决策树存在，且是书面的。

工程团队实际上会受益于这种清晰度。"我们没有权限在完成风险分级之前部署这个"，比"我们有顾虑但管理层要求上线"是强得多的工程立场。

决策四：AI 事件升级路径

当 AI 系统以可能造成伤害的方式失败时，会发生什么？谁会知道，以什么顺序，拥有什么权限来采取行动？

大多数组织都有针对基础设施故障的事件响应手册，但极少有单独的 AI 事件升级路径。区别很重要，因为 AI 故障有其特殊性：它们可能是统计分布式的而非二元的，可能缓慢积累才变得可见，可能需要领域专家（律师、临床医生、金融分析师）来评估严重程度，并且可能需要公开披露而不只是内部缓解。

文章开头那个 90% 错误率的案例，几乎可以肯定经历了数月的信号，但这些信号从未上升到董事会，因为没有定义好的传递路径。等到失败通过诉讼变得可见时，责任已经锁定。

一个有效的 AI 事件升级路径需要明确：什么构成 AI 事件（一个阈值，而不是主观判断），严重程度分级是什么，每个级别谁在什么时间内收到通知，哪些决定可以在工程层面做出、哪些需要高管或董事会介入，以及如何通知外部各方（监管机构、保险方、受影响用户）。

这里新兴的框架借鉴了流行病学模型——从"无证据发生"到"流行但已缓解"分阶段——因为 AI 故障的分布式、概率性特征与传染病更相似，而不像传统软件故障。工程师不需要懂流行病学就能实现这一框架；他们需要清晰的严重程度阈值和升级触发条件——而这正是高管需要定义的。

决策五：数据留存策略

AI 系统需要数据——训练数据、推理日志、评估数据集、审计跟踪。什么数据要保留、保留多久、访问控制如何，这些问题不能只由工程决定。

监管要求设定了最低标准：医疗 PHI 数据需要保留 6–7 年，SEC 和 FINRA 规则下的金融记录需要保留 5–7 年，GDPR 的删除义务与训练数据留存需求存在冲突。欧盟《AI 法案》还为高风险 AI 系统添加了审计跟踪要求，且这些要求在系统退役后仍然有效。这些要求适用于组织层面，而非系统层面——意味着董事会需要对可能横跨数十个 AI 系统、涉及多个监管司法管辖区的数据留存决策承担责任。

除合规最低要求外，董事会还需要决定：推理日志的留存时限（较长的留存窗口支持更好的审计和调试；较短的窗口降低违规风险），是否在记录层面追踪训练数据溯源（如果可能需要证明符合知识产权或同意要求，则必须如此），以及模型退役或数据主体请求删除时适用什么删除程序。

工程团队能构建出色的留存流水线，但没有组织政策，他们只是在为一个未言明的目标建设基础设施。加拿大航空案和版权诉讼案都涉及数据治理失败，而这些失败在技术上都有解决方案——如果政策存在并要求这些解决方案的话。

设计治理接口

善于治理 AI 的董事会并不要求董事具备 ML 专业知识，而是需要技术团队与高管监督之间有效运作的接口。

这个接口有三个组成部分。

第一是按风险分级的 AI 清单。生产中的每个 AI 系统都有一页摘要：它做什么，属于哪个风险等级，以业务语言（而非 ML 指标）表达的关键性能指标，事件历史，以及最近一次审计日期。这不是技术白皮书，而是让董事会成员能够提出有依据问题的文档。

第二是升级接口——从工程到高管的明确路径，由特定触发条件而非个人判断来激活。当 AI 系统的误报率越过某个定义的阈值，这个信息会自动传递到正确的高管层面，而不是通过非正式渠道。

第三是模型选择文档。当工程团队评估 AI 供应商或模型时，他们会生成一份结构化记录，说明考虑了什么，应用了什么标准，谁批准了这个决定。这有两个目的：创建审计跟踪，并赋予工程团队拒绝或放缓尚未完成必要审核的部署的权力。

做出了这五个决策的董事会，其 AI 速度并不低于未做出这些决策的组织。他们拥有更清晰的权限结构，这意味着工程团队花更少的时间承担他们本不该承担的责任，花更多的时间构建产品。

问责缺口正在收窄

2023 年，主流态度是 AI 治理只是受监管行业的合规问题。这种态度已不再站得住脚。

欧盟《AI 法案》执法已经生效。SEC 的投资者预期已经正式化。集体诉讼判例正在为算法失败确立受托责任。保险除外条款正在收窄。到 2027 年，记录清白的组织不会是行动最慢的那些——而是那些早早做出五项决策、为技术团队构建所需治理接口、从一开始就将 AI 风险视为董事会级别问题的组织。

工程可以构建很多东西，但无法构建风险偏好、责任立场、权限结构或问责链条。这些必须来自顶层。