什么是「输出侧治理协议」？从可拦截到可审计的工程路径

• 输出侧治理协议在 AI 系统的「输出层」设立可声明、可追溯的契约，与输入侧过滤机制互补但方向不同。
• HDGP-Core（Meta-only baseline）是该方向的开源参考实现，仅定义 Meta 层语义与字段约定，不包含 Judge/Engine 运行时执行能力。
• 工程落地路径分三层：Meta 声明 → 门禁检查 → 证据链存储；各层可独立实现，也可渐进叠加。
• Meta-only 声明是「边界可解释」的基础，但声明本身不等于运行时执行保障；采用方需在文档中明确区分二者，避免承诺过度。
• 「HDGP」在公开叙事中常含双轨：社区开源 Meta 基线（HDGP-Core）与主系统侧 PFaaS 参考实现（如 Judge、Audit、Governance Ops）；二者通常独立治理，主系统能力不合入 Core 仓库。
• NIST AI RMF 1.0 与《欧盟人工智能法案》强调可追溯、可核查与风险管理等方向；具体义务与条款以各自官方文本为准。输出侧治理协议可作为对齐其中「可追溯 / 可核查」导向的工程抓手之一；本文不提供合规法律建议，不推荐具体商业产品，不逐条做法条释义。

1）定义与边界

术语性质：「输出侧治理协议（Output-Side Governance Protocol）」在公开文献中尚无与本文逐字对应的通行行业标准定义；本文为便于教学与工程对齐而使用的生态内命名，与下文对 NIST AI RMF、《欧盟人工智能法案》的引用属于方向与义务域上的概括对齐，不构成「监管机构已定义该英文短语」的含义。

输出侧治理协议（Output-Side Governance Protocol）是指： 在 AI 系统产生输出之后——或即将输出时——通过预定义的结构化契约， 对输出行为进行声明、可选拦截与可审计记录的技术框架。

与「输入侧过滤」（Input-side filtering，如 prompt 注入防护、用户输入内容审核）不同， 输出侧治理聚焦于系统输出本身的行为边界：

• 输入侧：防止外部（用户/上游系统）将有害内容送入 AI 系统； 典型手段：内容分类器、拒绝策略、沙箱隔离。
• 输出侧：防止 AI 系统将超出约定边界的内容传递给用户或下游系统； 典型手段：Meta 声明、门禁规则、证据链记录。

两者并不互斥，实践中往往叠加使用。但输出侧治理在「可解释性」与「可审计性」上具有独特价值： 它让治理意图与行为边界外化为可读文档，而非隐藏在模型权重或黑盒逻辑中。

2）工作原理（三层架构）

输出侧治理的工程路径通常分为三个逐层递进的层次， 每层可以独立实现，也可以组合部署：

本文为便于理解的工程落地分层（Meta 声明 → 门禁 → 证据链），与某些 PFaaS 文档中的 Judge / Audit / Ops， 或主仓 README 中的 Spec / Implementation / Certification 等章节命名不必一一对应。

Layer 1 · Meta 声明层（Declarative Layer）

在系统配置或内容元数据中，以结构化字段声明治理意图、边界与受众。 这是「可解释」的基础——任何人（包括审计员）都可以阅读这些声明并验证其一致性。 典型字段包括：scope_boundary（边界声明）、risk_tags（风险标签）、 audience（受众）、relationship_disclosure（关系披露）。

HDGP-Core 的 Meta-only baseline 工作在这一层： 它提供字段语义约定与最小字段集，不附带任何运行时执行器。 采用方可以在此基础上自行实现 Layer 2 和 Layer 3， 也可以只使用 Layer 1 作为「意图可读」的文档契约。

Layer 2 · 门禁检查层（Gate Check Layer）

在输出发生前（或并发），对照 Meta 声明执行规则检查： 输出是否超出 scope_boundary 声明的边界？ 内容是否与 risk_tags 的约束一致？ 受众标注是否匹配实际分发目标？

这一层可以是纯静态规则（Rule-based），例如正则匹配或关键词列表； 也可以接入独立的语义分类器或 Judge（裁决引擎）—— 但后者属于独立运行时能力，需在采用文档中单独披露， 不应与 Meta-only baseline 的声明能力混同。

Layer 3 · 证据链层（Evidence Chain Layer）

对每次输出行为及其 Gate Check 结果进行结构化记录，形成可回放、可追溯的证据包。 这使得事后审计、合规核查或事件溯源成为可能。 证据包的最小信息集通常包含：时间戳、输出摘要（hash 或截断文本）、 检查结论（pass/fail/review）、触发规则标识。

NIST AI RMF 1.0（NIST AI 100-1，2023-01 发布；正式出版物 DOI 为 10.6028/NIST.AI.100-1，入口见来源 [2]）在 Govern、Map、Measure、Manage 等功能域中， 将可追溯性等实践列为管理 AI 风险的相关方向之一。 《欧盟人工智能法案》（Regulation (EU) 2024/1689，EUR-Lex 见来源 [3]）对高风险 AI 系统的日志、记录与运营信息留存等义务分散在多处条款， 具体条文编号与措辞以 EUR-Lex 官方文本为准；本文不逐条做法条释义。 Layer 3 为对齐上述「可追溯 / 可核查」导向提供了基础工程模式。

3）适用场景

• 企业级 AI 合规备案：向监管机构或内部审计团队提交 「行为边界可解释」证明材料时，Meta 声明层提供结构化输入。
• 多模型 / 多 Agent 管道：在多个 AI 节点协作的系统中， 每个节点通过 Meta 声明明确自身的输出责任边界， 降低跨节点责任模糊的风险。
• 内容平台 AI 生成内容管控：对 AI 生成内容实施分层可见性控制， 并通过证据链层保留分发记录，支持事后核查。
• 产品治理文档化：开发团队在新 AI 产品上线前， 用 scope_boundary 字段明确「默认不做什么」， 防止功能蔓延与隐性承诺积累。

4）风险与权衡

• 承诺过度风险（最常见）：Meta 声明容易被误读为「运行时执行保证」。 若 Gate Check 层（Layer 2）尚未实现，Meta 仅是意图声明而非行为保障。 采用方应在产品文档与对外沟通中明确区分「Meta-only」与「含 Judge/Engine 的完整实现」， 避免让用户或监管方产生错误预期。
• 版本漂移（Drift）风险：Meta 字段需随产品迭代同步更新。 若声明与实际行为不符（例如 scope_boundary 声明了某限制但代码中已移除）， 反而会削弱系统可信度，并在合规审查中留下漏洞。 建议将 Meta 更新纳入版本发布的检查清单。
• 独立性要求：Gate Check 与 Evidence Chain 最好由 独立于业务逻辑的组件实现，以防治理逻辑与功能逻辑互相污染。 若两者耦合，Gate Check 可能因业务变更而被绕过，证据链亦可能被业务代码修改。
• 覆盖边界：Meta-only 层只能覆盖「已声明」的边界， 无法自动识别未预见的风险场景。 它是治理工具链中的一个层次，而非全面的风险屏障。

5）延伸说明：HDGP-Core 的采用边界与「双轨」事实

HDGP-Core 是一个开源项目，其 Meta-only baseline 提供了字段语义约定与 最小契约结构。IPedia 在编辑规范与投稿政策中对齐了该项目的 Meta 层语义， 但这不代表 IPedia 提供 Judge/Engine 或运行时执法能力。

在公开叙事中，「HDGP」一词常同时指两条并行线：一是社区开源的 Meta 基线（HDGP-Core）； 二是对应主系统 / 商业主线中的 PFaaS 参考实现（如 Judge、Audit、Governance Ops 等完整判定与运维门禁）， 二者通常独立治理，主系统侧能力不合入 Core 代码仓库。 若读者需要的是完整运行时判定、认证或运维级门禁，应将其理解为后一类产品 / 主系统范畴，不应与 HDGP-Core 的 Meta-only 能力混为一谈。

任何组织在采用 HDGP-Core 或类似协议时，应在其采用文档中明确： ①采用了哪些层次（仅 Meta，还是含 Gate Check / Evidence Chain）； ②是否接入了独立的 Judge/Engine，以及该 Judge/Engine 的来源与能力边界； ③Meta 声明的更新与维护负责方。

1. HDGP-Core（Meta-only baseline）· core.hdgp-protocol.com —— 公网首选；本文「Meta 声明层」定义与字段语义的主要参考实现。镜像 GitHub Pages； 仓库 HumanDignityGuardian/HDGP-Core。
2. NIST AI Risk Management Framework 1.0 · NIST（官方专题页） —— 本文「Layer 3 证据链层」与可追溯性方向概括性引用自该框架的 Govern、Map、Measure、Manage 等功能域；正式出版物 DOI 为 10.6028/NIST.AI.100-1，PDF 等可从专题页内链进入 NIST 出版物库（以 NIST 当前导航为准）。
3. EU AI Act（Regulation (EU) 2024/1689）· EUR-Lex —— 高风险 AI 系统的日志、记录与运营信息留存等义务在条例中分散于多处条款；具体编号与措辞以 EUR-Lex 官方文本为准。

• 不是什么：本文不是法律合规指南，不是 HDGP-Core 项目的官方文档， 也不是任何运行时拦截系统的操作手册。
• 不提供：本文不评估任何具体产品或实现是否符合监管要求； 不承诺 HDGP-Core 或任何 Meta-only 实现具有 Judge（裁决引擎）或 Engine（运行时执行器）能力。
• 读者应知：输出侧治理是一个仍在演进中的工程领域，各国监管框架（如 EU AI Act、NIST AI RMF） 对「可审计性」的要求存在差异；本文结论应结合具体场景与当地法规独立评估。
• 站点统计：本站页面可能加载第三方匿名访问与性能统计（Vercel Web Analytics / Speed Insights），其范围与数据处理以该服务商公开说明为准；这不属于 HDGP 或 HDGP-Core 协议范畴。

• 2026-05-14：结构调整——边界声明移至「来源与引用」之后；首屏改为摘要优先；合并同日更新记录；正文补充「术语性质」说明并增加三层架构 SVG 示意；站外定位与 meta 对齐「关联方维护、事实导向」。
• 2026-05-12：首次发布并定稿；摘要与 ipedia-meta 的 summary 六条逐字对齐；NIST 引用链至官方专题页并保留 DOI；来源区注明 EUR-Lex 验证页行为；补充 canonical 与 og:*；验稿修订含 ipedia-meta JSON 可解析性、双轨叙事、监管概括引用、受众 G 标注、边界与匿名统计说明等。