治理、风险与问责

一个智能体系统即使通过了测试、落实了权限控制并保持稳定运行，也仍然可能被用于不合适的任务、缺少明确负责人、部署在不适用的司法管辖区，或者在无人有权接受其风险的情况下继续运行。技术控制回答边界如何执行；治理回答谁有权决定哪些边界和主张可以接受、依据什么证据、影响哪些人，以及决定在多长时间内有效。

治理常被误解为一个委员会、一份原则清单，或发布前补齐的一套文档。任何一项单独存在都不够：没有决策权的委员会无法阻止部署；没有决策规则的原则无法改变行为；文档如果没有负责人、可执行控制、复审触发条件和违反要求后的处理方式，最终只会成为记录意图的文档堆。

论点

治理是一套支撑组织作出重要决策的运行机制。它让完整系统及其使用情境清晰可见，赋予具名负责人采取行动所需的权限和资源，把系统主张与证据和义务联系起来，明确记录风险处置和残余风险决策，并在决策依据发生实质性变化时启动重新审查。

问责需要的不只是责任矩阵中的一个名字。承担问责的负责人必须知道作出了什么决定，能够查阅关键证据和异议，具备改变结果所需的能力与权限，并在假设失效时承担明确的响应义务。只分配责任而不给予相应权限，本质上只是预先指定事后追责对象，不是治理。

治理完整系统及其实际用途

模型提供方的模型卡（model card）或安全框架只描述了已部署系统的一部分。组织真正需要治理的对象还包括：

预期用户、受影响者、任务、收益，以及受支持的系统运行主张；
模型、提示词、上下文组装、检索、记忆、接口、策略与控制逻辑；
身份、委托权限、数据、租户、目的地与外部影响；
人工操作人员、审查者、审批者、支持团队、客户以及下游用户；
模型与服务提供方、集成组件、分包处理方、基础设施与供应链依赖；
部署环境、规模、地理位置、语言、无障碍需求与运行时长；以及
可预见的误用、失效、事件、人工绕过、申诉、退出和退役路径。

把“模型”标记为已批准，并不等于批准围绕它构建的每个应用。一个处理公开文本的摘要工具、一个福利资格辅助系统和一个长时间运行的运维智能体，可能使用同一个模型，却带来截然不同的后果和义务。因此，治理必须跟随实际使用情境和系统能够造成的外部影响。

OpenAI 2023 年关于智能体系统治理的论文区分了模型开发者、系统部署者和用户等角色，并提出各方在整个生命周期中应承担的基本职责（OpenAI, 2023）。这种参与方划分是有用的起点，但真实供应链可能把一个角色拆分给多个实体。应根据实际系统明确责任边界，而不能假定一个提供方标签就能解决问题。

维护支持决策的清单

清单不是模型名称的电子表格。每一条记录都应让组织能够找到系统、判断哪些决策适用，并识别谁可以行动。至少记录：

字段	治理目的
系统与负责人	稳定标识、业务或任务负责人、技术负责人、运营联系人
目的与主张	预期收益、受支持任务、禁止用途、受影响方、已知限制
生命周期状态	提议中、试验中、已批准、有限发布、生产中、暂停或已退役
系统组成	模型、提供方、提示词、策略、数据、记忆、接口、依赖和部署环境
权限与影响	主体、租户、数据范围、外部动作、审批要求、可逆性
范围与上下文	用户群体、规模、持续时间、司法管辖区、语言、行业、可访问性与脆弱性因素
风险与义务	风险分类、风险负责人、义务映射、例外、复审日期和保证活动状态
证据与历史	评估报告、控制证据、事件、投诉、决策、变更、已知缺口
退出路径	更换提供方、数据导出与删除、回滚、用户迁移和退役负责人

使用稳定标识符，使评估报告、追踪记录、事件、合同、风险记录、发布工件和面向用户的披露都指向同一个系统版本。如果已经存在权威元数据，应尽量自动填充清单字段；但自动发现一个服务端点，无法替代人工明确其用途、受影响方、可接受后果和风险负责人。

清单质量本身就是运营问题。应通过采购记录、代码仓库、云账户、API 流量、费用数据、身份系统和集成目录发现未登记系统。登记流程应足够简单，并明确区分试验与生产；但不能用“试点”标签规避审查，让系统无限期运行。

NIST AI RMF 1.0 把系统清单、明确角色、高层责任、监测、利益相关方意见、第三方风险和安全退役纳入贯穿风险管理全流程的 GOVERN 职能（NIST, 2023）。它是美国的自愿性风险管理框架，并且正在修订；引用时应注明具体版本，不能把“符合 NIST”当成永久属性。

先评估固有风险，再计入控制的降险效果

风险分类应决定所需证据、审查、审批、监测、外部输入和退役规划的深度。应从拟议用途开始，而不是先假定每项控制都有效。考虑：

可能伤害的严重度、范围、持续时间和可逆性；
受影响的人、权利、财产、服务、基础设施、组织和生态系统；
受影响者能否发现问题、提出质疑、获得更正或从结果中恢复；
数据敏感性、委托权限、外部影响、运行时长与传播路径；
暴露面：用户数量与脆弱性、频率、地理范围和对抗性访问；
可预见的误用、相关故障、集中度风险与依赖风险；
新颖性、不确定性、证据质量，以及能力或上下文变化的速度；以及
适用的法律、监管、合同、行业和内部政策要求。

这就是固有风险：尚未计入当前决策所依赖控制措施的降险效果。接下来需要识别风险处置措施，并取得控制有效性的证据。计入这些因素后仍然存在的就是残余风险，其中还应包括测量不确定性、未经测试的条件、控制依赖关系，以及会使评估失效的情形。

不能把无法通过其他收益抵消的伤害藏进一个总分。平均发生概率较低，并不能让不可逆的权利侵害或跨租户数据披露变得可以接受。数值矩阵可以辅助比较，但把依据薄弱的严重程度与概率相乘，容易制造虚假的精确感。证据不足以支持精确数值时，应使用具体场景、后果等级、估计范围、不确定性和明确的决策规则。

分类适用于一个定义明确的版本和范围。一个低风险的内部起草助手，当它获得客户数据、写入权限、自动记忆、新用户群体，或进入受监管的决策路径后，就可能成为高风险系统。

将风险转化为负责人明确的处置决策

风险登记表应当是决策工具，而不是一般性担忧的仓库。对每一项重要风险，记录：

风险场景与受影响方：
原因、事件与后果：
系统与生命周期范围：
固有后果与暴露面：
现有控制及其负责人：
控制设计与有效性证据：
依赖、假设与不确定性：
残余风险与失效条件：
处理方式：避免 / 降低 / 转移 / 分担 / 接受：
行动负责人、资源、截止日期与验证：
决策权限与升级处理路径：
监测信号与审查触发条件：
关联事件、投诉、例外与义务：

“用防护栏降低风险”还不是完整的处置措施。必须明确具体控制、强制执行位置、所应对的威胁或失效、已知局限、负责人和所需证据。安全、可靠性、评估、可观测性、产品、法务和运营工作都可以提供控制措施；治理负责把这些措施与风险决策连接起来，而不重复定义其实现方式。

规避风险和退役系统同样是有效的处置方式。如果某项任务无法达到可接受的安全水平，组织缺乏必要证据或运营能力，或者该用途与必须履行的义务冲突，那么正确决定可能是不开发、不发布、缩小范围，或者停用系统。

使风险接受显式化

风险接受是一项经过授权的决定，表示在明确范围和期限内，现有证据足以支持组织带着这些残余风险继续推进。它应包括：

系统版本、用途、用户、受影响方、司法管辖区与运营限制；
所追求的收益或必要性，以及已考虑的可行替代方案；
已审阅的证据、关键不确定性、异议与未解决缺口；
残余风险场景、可能性或不确定性、严重度与影响分布；
控制、监测、事件准备、补偿性措施与停止条件；
风险负责人，以及拥有与潜在后果相匹配权限的风险接受决策人；
生效日期、到期时间、审查触发条件与所需后续工作；以及
一份写明理由、可供日后检查的决策记录。

沉默不等于接受。不能因为工单长期无人处理、发布日期已经过去、提供方支持某项功能、用户点了“我同意”，或者没有委员会提出反对，就认定风险已经被接受。高层管理者也不能通过风险接受取消具有约束力的法律义务、他人的权利，或超出其授权范围的风险。

风险接受决策人不能只因系统按时上线而获得奖励，却无需面对决策后果。可能造成重大后果或存在争议的决定，可能需要技术、领域、法务、安全、可靠性专家或受影响方开展独立质询。独立性用于发现共同假设和利益冲突，不是仪式性的第二个签字。

OpenAI 2026 年发布的 Frontier Governance Framework 把系统性风险评估与明确的风险接受决定、书面理由、安全裕度、具名组织责任、外部专家意见、报告和框架变更控制联系起来（OpenAI, 2026）。Anthropic 的 RSP v3 也规定了专门负责人、风险报告、违规报告渠道、外部审查标准、程序审查、董事会批准和公开变更日志（Anthropic, 2026）。这些是当前前沿模型风险治理的重要实施案例，但不能直接当成所有公司的组织结构或风险阈值。

分配决策权，而不仅是任务

至少应区分以下职能，即使一个小组织把它们合并到少数几个人身上：

职能	需回答的问题
系统或用途负责人	这一用途是否有价值、得到必要支持，并受到负责任的运营和退役管理？
风险负责人	这一具体风险是否得到理解、处置、监测，并在跨越职责边界时及时升级处理？
控制负责人	该控制是否已经实施、持续运行、证据充分，并得到维护和修复？
证据负责人	评估、保证材料及其限制对于当前决策是否有效且最新？
独立复核方	哪些假设、利益冲突、缺失的参与方或薄弱证据可能改变决定？
风险接受决策人	接受这一残余风险是否在我的授权范围内，现有记录是否足以支持决定？
事件与整改负责人	谁负责阻止影响扩大、开展沟通、纠正状态并完成后续行动？
义务负责人	哪些外部或内部要求适用，如何证明已经履行？

RACI 图可以表达参与关系，但无法提供决策权、专业能力、时间、信息访问权限或预算。必须明确谁有权停止发布、限制能力、要求补充证据、批准例外、通知受影响方、联系监管机构和退役系统。负责人出现分歧，或决定超出某人的授权范围时，还应有明确的升级处理路径。

当潜在后果较大时，应适当分离系统实现与保证活动（assurance）。构建团队掌握关键上下文，但也可能共享相同假设和交付激励。根据需要，独立复核可以由其他内部职能、领域专家、受影响方、外部评估机构、审计人员或监管机构承担。应记录利益冲突和信息访问范围；只能看到经过筛选摘要的复核方，无法发现被省略的关键证据。

保护善意报告和升级处理。应提供不止一条报告疑似违规或隐蔽风险的渠道，禁止报复，跟踪调查和整改，并让具有相应权限的人看到尚未解决的重要问题。一个惩罚风险信息上报者的组织，再好的流程也会失效。

将政策转化为系统行为

政策必须落实到工程和运营。对每一项要求，明确：

政策陈述与理由：
适用范围内的系统、参与方、数据、决策与生命周期阶段：
所需、禁止与可酌情处理的行为：
决策负责人与例外授权：
实现控制与强制执行点：
证据与质量门槛：
监测、事件与报告信号：
例外条件、补偿性控制与最长期限：
复审触发条件、负责人、版本与生效日期：

有些要求可以落实为确定性的策略检查、授权规则、Schema 约束、发布门槛、数据保留任务或部署配置，另一些则需要人结合具体情境判断，必须明确两者的边界。如果政策只是写着“敏感操作需要人工审查”，却没有定义何为敏感、由谁审查、需要查看哪些证据，以及审查者不可用时如何处理，这项要求仍然不完整。

政策例外是受控决策，不是绕过治理的旁路。应记录适用范围、原因、负责人、风险、补偿性控制、到期时间和退出条件，并监测例外的实际使用情况。例外反复出现，可能说明政策本身不合理、控制缺少资源，或者业务流程已经超出原先获批的系统运行主张。

政策应进行版本管理，并能够还原某项决策发生时适用的版本。如果系统未通过质量门槛后才修改阈值，这属于需要具名负责人和明确理由的政策变更，不能被包装成日常测试维护。

建立义务登记表，而不是“合规”标签

法律、监管、合同、专业、行业和内部政策义务，会因司法管辖区、角色、系统类别、预期用途、受影响人群和日期而不同。一份有用的义务记录会注明：

发布机构或合同相对方，以及权威来源；
该条目属于法律、法规、已采纳标准、合同、自愿框架、指南、草案还是内部政策；
司法管辖区、角色、受影响系统与用途、生效日期及适用理由；
具体的要求、禁止、通知、记录、评估、报告或响应义务；
负责人、实现控制、证据、审查频率，以及已知的解释问题；以及
与现有管理体系的依赖和重叠。

不能把这些字段压缩成“符合欧盟要求”“已获 NIST 认证”或“遵循 ISO”之类的笼统标签。NIST AI RMF 是自愿框架，并不存在由 NIST 授予的此类通用产品认证。ISO/IEC 42001:2023 是已发布的国际管理体系标准；即使进行了认证，认证也有明确的组织和体系范围，不能证明每项产品结果都安全或合法（ISO, 2023）。EU AI Act 是具有约束力的法律，具体义务取决于角色、用途和生效日期；其中包括适用范围内高风险系统的全生命周期风险管理和质量管理要求（Regulation (EU) 2024/1689）。是否适用必须由合格的法律专业人员判断，本工程手册不提供法律意见。

如果现有的信息安全、隐私、质量、安全保障、采购、记录和事件流程确实能满足相关 AI 要求，就应复用它们，而不是只为给同一项控制换个名称，就建立一套重复的治理流程。反过来，如果现有认证没有涵盖模型行为、委托权限、提示词注入、评估有效性或受影响方救济，就不能假定这些内容已经得到保证。

治理第三方与共享责任

外部提供方和集成方可以提供有价值的证据，例如系统卡、评估报告、安全保证材料、数据条款、事件通知、变更日志、可用性承诺、分包处理方列表和数据删除机制。必须核对每份材料是否覆盖组织实际依赖的版本、地区、功能、部署模式和系统主张。

部署方仍需对用途、数据、提示词、检索、记忆、接口、权限、审批、用户体验、监测和恢复等选择负责。模型或服务提供方不可能评估每一种下游使用情境。合同条款可以分配义务和约定救济方式，却不会让技术控制自动生效。

对于重要依赖，应治理：

受支持和被禁止的用途、数据处理、训练和保留条款；
模型与 API 变更通知、版本稳定性、弃用与回滚；
证据访问、审计或评估权、事件通知与配合；
分包处理方、数据位置、安全性、可用性、容量和集中度；
知识产权、保密、出口、行业与司法管辖区限制；
平稳降级、更换提供方、数据可移植性、删除与退出测试；以及
每次移交中负责每一项控制的主体。

当提供方更改模型、安全行为、接口、定价、地区、保留条款或服务依赖时，应重新评估。“同一个 API 名称”并不意味着同一个受治理系统。

保留决策记录，而不是模型的“思考过程”

可审计性意味着能够还原组织当时知道什么、要求什么、作出了什么决定，以及最终造成了什么影响。应保留：

系统、配置、策略、义务和证据的版本；
决策问题、可选方案、标准与权限；
关键输入、已验证事实、不确定性、异议与被排除的证据；
选定的处理、批准或拒绝、条件与时间戳；
外部影响、事件、投诉、人工绕过、例外与后续行动；以及
决策依据的变化，以及为何进行了或未进行重新评估。

不能用模型生成的理由或隐藏的思维链（chain-of-thought）替代正式记录。它们可能不完整、无法真实反映决策过程、包含敏感信息、无法获取，或者与实际执行的政策和状态转换无关。应记录可观察输入、被接受的状态转换、策略决策、证据和实际影响，并通过访问控制、保留期限、完整性保护、隐私和删除规则管理这些记录。“永远记录一切”只会制造另一类治理失败。

保证活动回答的是：现有证据是否足以支持面向特定受众、服务于特定决策的系统主张。自评、同行评审、独立测试、红队测试、审计、符合性评估和认证各自覆盖的范围不同。必须说明由谁执行、依据哪个标准和版本、可以访问哪些信息、采用什么抽样方法、独立程度如何、存在哪些限制，以及材料何时失效。新加坡 IMDA 的 AI Verify 项目说明了技术测试与流程检查的区别，同时明确指出，框架输出不能保证系统绝对安全或不存在偏差（IMDA）。

让受影响者参与，并允许质疑和申诉

受系统影响的人可能发现开发者和负责人看不到的伤害、实际使用条件、无障碍问题和救济机制缺陷。应明确在设计、评估、部署、监测、事件响应和复审各阶段，需要听取哪些人的意见。参与必须发生在仍能改变决定的时候，并向参与者提供可以理解的信息；等到决定已经不可更改时才收集意见，不能算作有意义的质询。

治理负责决定是否必须提供通知、解释、更正、人工复核、质疑、申诉、救济和支持机制，并明确由谁响应、保留哪些证据。“产品与体验”部分负责这些机制如何呈现给用户以及如何使用。具体法律义务和适当机制取决于实际情境。

OECD AI Principles 在 2024 年更新后，提出应根据参与方的角色、具体情境和采取行动的能力落实问责，并把问责与全生命周期可追溯性、系统化风险管理、透明度和质疑结果的能力联系起来（OECD Accountability、Transparency）。这是一套当前有效但不具约束力的政府间建议，不是具体实施规范。

决策依据变化时重新审查

批准不是永久的。应定义实质性变化和周期性审查触发条件，包括：

新模型、提供方、微调、提示词、策略、阈值或上下文组装方式；
新的数据类别、记忆行为、接口、权限、目标地址或集成；
新的用户群体、语言、司法管辖区、行业、规模或运行时长；
能力、评估、控制表现、攻击方法或外部研究的变化；
事件、险情、投诉、申诉、审计发现或无法解释的漂移；
提供方条款、依赖、法律、标准、合同或自愿承诺的变化；以及
已经过期的例外、缺少负责人、控制失效或恢复路径不可用。

并非每项变更都需要同等强度的审查。应明确哪些证据可以复用、哪些质量门槛需要重新执行、需要通知哪些负责人，以及哪些变更要求重新作出风险接受决定。如果认为某个触发条件不会造成实质性影响，也应保留判断理由。

退役也是需要治理的生命周期阶段。应撤销权限和凭据，停止流量、集成与定时任务，处理已存记忆、影子副本和用户入口；保留依法或依政策需要的记录；履行删除和通知义务；迁移用户与工件；并验证系统不再产生外部影响。服务端点即使标记为 deprecated，只要后台任务和凭据仍然有效，就还没有真正退役。

权衡

选择	收益	成本或风险
集中制定最低治理要求	提高一致性、共享专业能力、形成可比较记录	可能形成瓶颈，对具体领域理解不足
由领域团队负责决策	更了解实际情境，行动更快	标准可能不一致，也可能受到局部利益影响
细粒度风险分类	覆盖更全面，也更便于比较	分类成本较高，容易产生虚假精确感
简单的后果分级	便于分流并采用相称流程	可能掩盖重要差异
独立保证活动	质询假设并发现利益冲突	成本与延迟增加，信息访问可能受限，也可能沦为形式审查
更充分的透明披露	便于审视、建立信任并让受影响方提出质疑	可能暴露隐私、安全信息、可被滥用的信息和商业秘密
大量决策记录	可重建性与问责	陈旧性、敏感数据集中、文档负担
严格禁止例外	最低要求清晰	可能催生隐蔽绕过，也难以处理合理的特殊情况
受控例外	保留适应性，并让残余风险可见	如果负责人和到期机制失效，绕过会逐渐常态化
统一提供方	降低集成和保证活动成本	增加集中度风险、相关故障和退出难度

治理流程与风险相称，并不意味着小团队可以完全省略治理，而是证据深度、复核独立性、流程复杂度和决策权限都应与潜在后果匹配。对于低后果的内部工具，一份简明记录和一位真正有权采取行动的负责人，可能比一个脱离实际运营的大型委员会更有效。

失效模式

没有决策权的委员会

审查组可以提供建议，却不能阻止发布、要求证据、资助整改、缩小范围或退役系统。

只有模型清单，没有系统实情

登记表列出了提供方和模型名称，却遗漏了用途、数据、权限、集成、受影响者、版本、事件和负责人。

没有场景的风险评分

一个红、黄、绿状态取代了具体风险场景，没有说明谁可能受到伤害、伤害如何发生、在什么条件下发生、有哪些不确定性，以及系统通过什么路径造成影响。

承诺了控制，却假定了有效性

风险记录计入了某项防护栏、审批或提供方过滤器的降险效果，却没有负责人、失效行为、当前有效的证据或依赖分析。

以不作为达成接受

因为一个工单没人回复，发布就继续推进。并没有具备所需授权的人接受该残余风险。

名义上负责，实际无权

产品经理在纸面上负责风险，却无法获取证据、修改发布、限制权限、获得资源或独立升级处理。

永久性的临时例外

一个豁免没有到期、补偿性控制、使用监测或退出标准，并悄然成为常规路径。

把提供方的保证材料当成自己的保证

把提供方证书或系统卡直接当作证据，声称部署方自己的数据、检索、权限、工作流、用户和结果都已经安全合规。

合规等于安全

团队满足了文档或符合性义务，并得出结论：每一种可预见伤害都已受控，包括超出规则范围的风险。

用思维链代替审计记录

模型生成的推理被存为决策记录，而权威状态、策略检查、证据版本、批准和实际影响却缺失。

变化已实质发生，批准仍沿用旧版

系统获得了写入权限、一个新用户群体或一个新提供方，却仍在基于早先那个只读试点的风险评估下运行。

没有受众模型的披露

组织要么什么有用内容都不公布，要么因为“透明度”未与利益相关方和目的挂钩而发布敏感数据和安全细节。

工程手册指引

为每一项重要开发、部署、扩展、例外、持续运行和退役决策，维护一份治理决策记录：

决策、系统 ID、版本与生命周期转移：
负责人、用户、受影响方、目的与系统运行主张：
系统组成、权限、数据、影响、规模与司法管辖区：
支持、排除与可预见误用条件：
适用义务与自愿承诺：
固有风险场景与后果分类：
控制、负责人、依赖与有效性证据：
残余风险、不确定性、异议与失效条件：
所考虑的替代方案与风险处理措施：
决策权限、结果、理由与时间戳：
条件、监测、停止规则、例外与到期：
实质性变化与周期性复审触发条件：
披露、挑战、事件、整改与退役路径：
证据链接与后续行动：

只用一个审查问题：

如果此决策造成了伤害，我们能否说明谁有权且有证据来做决定，考虑了哪些不确定性和受影响方，依赖了哪些控制，以及当这些假设失效时需要做什么？

如果答案只是一个委员会名称、一张模型卡，或一句“政策就是这么规定的”，那么这项决策还没有真正纳入治理。

清单

参考文献及其使用方式

OpenAI, “Practices for Governing Agentic AI Systems” — 支撑生命周期角色、基线责任、适用性、约束、可理解性、监测与问责的核心早期智能体专门研究。2023 年论文明确属于初步性内容，并未定义当前的通用标准。
OpenAI, “Frontier Governance Framework” — OpenAI 前沿模型治理框架，用于支持相互衔接的风险识别、分析、接受、缓解、报告、外部意见、明确责任和受控框架更新。它适用于 OpenAI 指定的前沿模型与监管范围，不能直接推广为普通应用的通用治理方案。
Anthropic, “Responsible Scaling Policy, version 3.0” — Anthropic 自愿治理政策，用于支持明确负责人、风险报告、独立审查标准、受保护的违规报告渠道、程序审查、董事会批准和版本化公开变更。其灾难性风险范围和针对 Anthropic 组织结构的具体承诺不在本章中泛化。
NIST AI 100-1, “Artificial Intelligence Risk Management Framework 1.0” 和 NIST 当前的 AI RMF 页面 — 美国最终发布的自愿框架，用于支持贯穿全生命周期的治理、系统清单、风险容忍度、角色划分、高层责任、利益相关方意见、第三方管理、监测和退役。本章审阅时，第 1.0 版正在修订。
ISO/IEC 42001:2023, “Artificial intelligence management system” — 用于政策、目标、流程、风险处理和持续改进的已发布国际管理体系标准。公开摘要未披露完整规范性文本，而认证具有明确范围，并不证明每个系统都安全或合法。
Regulation (EU) 2024/1689，尤其是第 9、16 和 17 条 — 具有约束力的欧盟法律，用作全生命周期风险管理、质量管理、文档、监测、纠正措施以及适用范围内系统与参与方义务的具体示例。是否适用取决于角色、用途、司法管辖区和分阶段生效日期，需要专业法律判断。
OECD AI Principles: Accountability、Transparency and explainability 和 Robustness, security and safety — 2024 年更新的、仍具效力的非约束性政府间原则，支持基于角色与上下文的问责、可追溯性、系统性生命周期风险管理、披露、挑战和安全退役。它们并未规定组织实施方式。
新加坡 IMDA, “AI Verify” — 国家公共项目与开源测试生态，用于区分技术测试、流程检查、治理主张和保证活动的边界。工具包或自评输出不能被视为独立认证或系统安全的证明。