AI 治理的落地实践：面向真实系统解读 ISO/IEC 42001

引言

随着 AI 系统从实验阶段走向生产环境，企业面临一个关键却常被低估的挑战：我们该如何治理这些动态的、具有概率性且日益自主的系统？

与传统软件不同，AI 系统并不遵循确定性的执行路径。它们的行为取决于训练数据、运行时上下文、用户输入，以及被授权访问的工具。要治理这样的系统，仅靠政策文件远远不够——还需要架构支撑。

ISO/IEC 42001 这样的标准提供了宝贵的基础，明确了问责制、风险管理与生命周期控制方面的要求。但它们有意止步于最重要的实操问题之前：我们究竟该如何在真实运行的生产系统中落地治理？

标准定义了治理应当达成的目标。架构则决定了它是否真正得以实现。

治理与落地之间的鸿沟

大多数 AI 治理框架都建立在三大支柱之上：政策、流程与责任。这些是必要的——但并不充分。治理框架描述的是"应当做什么"，却很少说明"应当如何做"。

根本问题在于时间维度的错位：治理框架是在规划阶段被设计与记录下来的，而 AI 系统的行为却发生在运行时。这就造成了一种危险的脱节——一家企业完全可能拥有出色的治理文档，却仍然眼睁睁看着 AI 智能体读取本不该触碰的数据库、生成本应被过滤的输出，或在没有任何审批机制的情况下调用外部 API。

缺乏运行时强制执行，治理就只会沦为文档，而非真正的控制——审计人员可以查阅它，系统却对其视而不见。

解决之道，是将治理原则转化为可执行的系统组件，让其在 AI 运行的每一步中与之同步运作，从而弥合这一鸿沟。

ISO/IEC 42001 做对了什么

ISO/IEC 42001 是目前最全面的 AI 专属治理标准。其核心原则十分扎实，值得作为构建基础：

• 基于风险的管理——在整个生命周期中识别并缓解 AI 特有的风险
• 问责与监督——明确 AI 系统及其输出的责任归属
• 生命周期治理——从设计到退役全程适用的控制机制
• 持续改进——用于监控、反馈与调整的机制

这些原则绝非官僚式的打勾清单，而是来自金融、医疗、航空等强监管行业的深刻教训——在这些行业中，失控的自主系统所付出的代价，是以患者伤害、经济损失与法律责任来衡量的。

真正的挑战在于转化。每一项原则都必须映射为具体的系统能力：风险管理必须转化为策略评估引擎；问责制必须转化为审计日志；生命周期治理必须转化为部署控制机制；持续改进必须转化为监控仪表盘与反馈闭环。

从政策到执行

从一项治理原则，到一个真正运行的系统控制机制，需要经历四个明确的步骤，每一步都必须被清晰地设计与实现。

**策略定义**回答的问题是：什么被允许，什么受到限制？这意味着以精确的语言写下约束 AI 行为的规则——哪些数据可以被访问、哪些工具可以被调用、哪些输出被允许，以及在什么条件下可以出现例外。

**决策逻辑**回答的问题是：策略如何被评估？这正是策略即代码发挥作用的地方。决策逻辑不再依赖运行时的人工判断，而是被编码进一套系统中，以机器的速度，对 AI 尝试执行的每一个操作进行一致的评估。

**执行节点**回答的问题是：决策究竟在系统架构的哪个环节被真正执行？如果没有任何机制根据评估结果采取行动，策略评估本身毫无意义。执行节点位于 AI 与其试图访问的资源——数据库、API、工具、外部服务——之间，根据策略决策来阻止或允许访问。

**可审计性**回答的问题是：每一个决策是否都能被追溯、解释与复核？对强监管行业而言，这一点没有商量的余地。每一次策略评估——无论允许还是拒绝——都必须被记录下来，且附带足够的上下文信息，以便完整还原当时发生了什么、为何如此决策。

策略即代码：缺失的一环

策略即代码，是弥合书面治理原则与运行时执行之间鸿沟的技术方法。策略不再是一份没有任何系统会去读取的 PDF 文档，而是以声明式语言表达，由策略引擎持续进行评估。

Open Policy Agent（OPA）是这一领域领先的开源策略引擎。在基于 OPA 的治理架构中：

• 策略以 Rego 编写——一种专为策略场景打造的语言
• AI 的每一个操作在执行前，都会触发一次策略评估
• 评估结果具有一致性——相同的上下文，始终产生相同的决策
• 执行过程自动化——常规决策无需人工复核
• 例外与覆盖规则均被明确编码，而非临场即兴决定

这使治理从一个管理概念，转变为一项系统能力。策略文档与执行机制合二为一——策略的任何变更，都会立即改变系统所允许的行为。

将治理应用于 AI 系统

AI 系统必须在四个不同的控制维度上接受治理，每个维度分别对应 AI 执行流程中的不同环节。

输入控制

任何数据进入 AI 系统之前，都必须先接受合规性评估：这是否是需要特殊处理的患者隐私数据（PHI）？该用户是否有权限查询这些数据？这条输入是否正在尝试提示词注入攻击？输入控制是第一道防线，也是执行策略成本最低的环节——拒绝一条不合规的输入，远比过滤一条不合规的输出要便宜得多。

处理控制

在 AI 系统内部，控制机制决定了哪些转换操作是被允许的：哪些模型获批用于生产环境？模型是否在其规定的运行参数范围内工作？某个经过微调的模型，是否只被用于其经过验证的应用场景？处理控制在医疗领域尤为重要，因为模型漂移或分布外输入，可能产生具有临床危险性的输出。

输出控制

任何 AI 响应在到达用户或下游系统之前，都必须先经过评估：其中是否包含应被脱敏处理的患者隐私数据？是否给出了超出 AI 授权范围的建议？是否引用了请求用户无权查看的信息？输出控制，是危害波及外部世界之前的最后一道防线。

行动控制

对于具有智能体能力的 AI 系统——即那些不仅能生成文本，还能在现实世界中采取行动的系统而言——行动控制是最为关键的治理层级：该智能体可以调用哪些工具？在什么条件下？一次拟议中的数据库写入操作，是否需要人工批准？一封邮件应当自动发送，还是应排队等待人工复核？而这，正是 Aether 被构建出来专门执行的能力。

AI 治理的参考架构

一套完整的 AI 治理架构，会通过四个系统层级，将上述四个控制维度整合在一起。

**上下文层**负责汇集做出策略决策所需的信息：用户身份、数据分类、风险评分、会话上下文，以及其他相关元数据。如果缺乏丰富的上下文，策略就只能是一件粗糙的工具；而有了它，策略便能变得精准——对同一个操作，可以放行给某位用户，同时拒绝给另一位用户。

**策略引擎**是决策核心。它以上下文作为输入，输出允许、拒绝或升级的决策结果。它必须足够快速——现代策略引擎完全可以做到 20 毫秒以内——同时具备一致性与可审计性。至关重要的是，它必须是所有执行节点在做策略决策时唯一的真相来源。

**执行层**，是策略决策转化为系统实际行为的地方：API 网关执行输入与输出策略，智能体运行时执行行动策略，数据访问代理执行数据层策略。执行层分布在系统的各个角落，但所有执行节点都会查询同一个中央策略引擎。

**审计层**记录完整的决策历史。每一次策略评估——连同其上下文、决策结果与判断依据——都会被写入一份只可追加的日志中。这份日志，正是合规审计、事件调查与持续改进工作的证据基础。

Aether：作为基础设施的治理

在应答智能，我们专门构建了 Aether，用以弥合治理框架与实际运行系统之间的落地鸿沟。Aether 策略控制台为运行在强监管环境中的 AI 智能体，提供策略即代码的治理能力。

在实际运行中，Aether 会拦截 AI 智能体发起的每一次工具调用，实时根据您定义的 OPA 策略进行评估，然后允许该操作、以结构化错误拒绝它，或将其升级至人工审核。每一个决策，连同完整的上下文信息，都会被记录到不可篡改的审计日志中。

由此实现的治理，不再只是一种愿景——而是可执行、可验证，并能随着 AI 行为的演变而持续强制执行的现实机制。

与 ISO/IEC 42001 的映射关系

本文所述的架构，与 ISO/IEC 42001 的核心要求直接对应：

该标准的风险管理要求，由策略引擎予以满足——每一个 AI 操作在执行前，都会根据既定的风险标准接受评估。问责制要求，由审计层予以满足——每一个决策都可追溯到具体的上下文、策略与结果。治理要求，由策略即代码系统予以满足——策略经过版本管理、审核，并被一致地执行。控制要求，由执行层予以满足——策略不再是建议，而是系统级别的强制约束。

这对医疗行业意味着什么

医疗领域的 AI 应用，其风险之高使得治理没有讨价还价的余地。患者隐私数据（PHI）不仅要在存储环节受到保护，更要在每一次 AI 交互中都得到保护。临床决策支持系统必须具备足够的透明度，能够向医生解释其给出某项建议的理由。预授权智能体必须拥有完整的审计追踪记录，以满足 CMS 与支付方的合规要求。

在医疗领域，AI 治理不是合规负担，而是患者安全基础设施。每一个未受治理的智能体操作，都可能是一次数据泄露、一次临床差错，或一次监管违规。好消息是，设计得当的治理架构并不会拖慢 AI 系统的运行速度——恰恰相反，它能让系统具备足够的可信度，从而真正被部署到生产环境中。

结语

ISO/IEC 42001 所指明的方向完全正确。风险管理、问责制、生命周期治理与持续改进，正是治理 AI 系统所应遵循的正确原则。

但原则终须转化为架构，策略终须转化为代码，问责制终须转化为审计日志，治理终须转化为强制执行。

在强监管领域的 AI 竞赛中，真正能够领先的企业，不是那些拥有最完美治理文档的企业，而是那些已经将治理编码进自己系统、在运行时切实执行，并建立起相应审计基础设施来证明这一切的企业。

这正是我们在应答智能努力构建的方向。如果您正在强监管环境中部署 AI 智能体，并希望了解如何让治理真正落地，而非停留于愿景，我们非常乐意与您交流。