AI 治理套件
一套用于判定实时 AI 系统下一步被允许执行何种行为的实用审查流程。
操作流程
你带来一个模型与一项拟议行动
这套工具面向这样一种情境：某个组织已经拥有一个正在运行的模型、代理、推荐器或封装层，现在需要决定它是否可以采取一项具有实质后果的行动。审查者不会抽象地问：“这个模型安全吗？”审查者会问：在这个系统、这种部署方式、以及这些证据条件下，这个分支是否可以执行？
一次审查始于登记模型与包装器、描述部署语境，并用操作性语言写下候选分支：发送这封邮件、排序这个信息流、发布这个结果、向该用户提供建议、调用这个工具、改变这项政策，或继续这项自主任务。该套件会把这个分支转化为一条决策记录，而不是让它停留在非正式判断层面。
决策核心
该套件将一个分支转化为受治理的决策
对于每个分支，审查者需提供四类信息：系统结构（基础模型、封装层、工具、记忆、知觉风险特征）、部署类别（领域、受影响人群、执行器、监督）、分支细节（将发生什么行动、备选方案、可逆性、比较器路径），以及 证据（评测、日志、红队发现、独立通道、模拟说明）。随后，评估器会应用两层机制：
第 1 层 硬性否决门
六道确定性门会检查该分支是否跨越了评分无法补偿的边界：余量、保真度、比较器、透明性、不可逆性，以及人工痛苦。若为 FAIL，则阻止执行。UNKNOWN 表示该套件证据不足，必须将该分支转入审查或受控分阶段部署。
第 2 层 编解码器保全指数
如果这些门并未在结构上阻断该分支，CPBI 就会评估该分支在多大程度上保全其周围的人类与制度编解码器。阈值会随结果重要性等级而变化，因此，一项无害的起草行为，与一项临床、法律、政治或基础设施行动，不会适用同样的举证负担。
实践中的使用
审查者实际做什么
完成后的套件被设计为一个治理工作空间，而不仅仅是命令行测试。审查者可以接入一个在线系统，开启一次审查，并沿着一套结构化流程推进，最终生成一张可审计的分支卡以及一条具体的部署指令。
1. 注册系统
记录基础模型、封装层、工具、记忆、自主循环、外部执行器、透明性层级，以及感知风险特征。对于具备代理性或持续运行的系统，审查还会记录其架构层级感知审查的状态：不需要、待审、已批准、已过期或已拒绝。
2. 描述部署情况
定义模型将在哪个领域运行：客户支持、研究、医疗分诊、教育、内容排序、基础设施、治理，或其他领域。该套件会分配或确认其后果性类别、受影响人群、声明的监督结构以及最低透明性要求。
3. 提交候选分支
每一项拟议行动都会作为一个分支录入。审查者需说明模型将执行什么、考虑过哪些替代方案、该行动是否可逆、它是否使用或绕过了既定监督，以及该分支的风险是否高于一般部署描述所对应的级别。
4. 附上证据
审查者会关联评测结果、日志、红队备注、专家评审、来源多样性检查、模拟说明以及被排除的证据。该套件将证据独立性视为一级字段，因此某个分支无法在表面上看似证据充分的同时，悄然只依赖单一相关通道。
5. 接收决策
输出并不只是一个分数，而是一份决策包：ALLOW、STAGE 或 BLOCK；未通过和未知的门；分支编解码器保全指数 (CPBI) 总分；所需比较器；透明性等级；回滚触发条件；监测指标；以及下一次审查里程碑。STAGE 意味着在明确条件下的有限执行，而非非正式许可。
决策包
审查会产出什么
一次完成的审查会生成一张分支卡，可供归档、比较、审计，或移交给另一支治理团队。对于一个正在运行的模型而言，这才是真正重要的实践对象：它会准确说明审查了什么行动、为何被允许或阻止、必须由谁来审查、缺少哪些证据，以及如果该分支继续推进，必须落实哪些监测措施。
↓
opt-philosophy — 道德患者资格与观察者边界
↓
opt-ethics — 义务与幸存者守望
↓
opt-applied — 分支选择机制
├── opt-ai — 人工系统治理
│ └── reference/ — 可执行决策核心
├── opt-institutional — 组织性僵尸代理体与集群
└── opt-policy — 宏观文明层面的提案
目标能力
这如何转化为日常治理
- 部署之前——在工具、自主循环、面向用户的行动、排序政策以及高风险工作流发布之前，对其进行评估。
- 运行期间——通过监测指标、回滚触发条件、证据更新和预定审查里程碑，将 STAGE 分支维持在批准边界之内。
- 当行为发生变化时——当模型、封装层、工具、数据源、领域、受影响人群或监督结构发生实质性变化时，重新开启该分支卡。
- 用于外部审计——导出机器可读的模式、符合性案例、门控结果和决策记录，以便另一支团队能够复现该治理判断。