本体知识块：可执行合规性与基于配置文件的验证用于可信AI系统

# 本体知识块：面向可信AI系统的可执行合规与基于配置文件的验证

**来源：** https://arxiv.org/html/2605.23297

###### 摘要

部署在关键数字基础设施中的AI使能服务需遵守涵盖透明度、问责制、公平性和可追溯性等方面的治理义务。目前的合规实践仍以文档为中心：义务以自然语言描述，审计依赖静态检查表，验证依靠人工审查。这些方法无法扩展到自动化AI系统。本文介绍了**本体知识块**（OKBs），这是一种可编程的治理基础设施，它将监管义务编译为可机器检查的约束，作用于结构化证据图之上。我们将OKB形式化为一个五元组⟨O, C, V, E, P⟩，该元组将规范性义务与RDF/OWL概念模式、可执行的SHACL验证规则、明确的证据需求以及PROV-O溯源链接绑定。一个确定性的监管编译器将结构化的中间表示（IR）记录转换为可组合的知识块（KB）模块，从而无需修改服务代码即可实现基于配置文件的治理重配置。我们实现了两个原型，并在一个AI辅助的HPC资源分配场景中进行了评估，涉及24次验证运行和四个治理配置文件。结果表明：配置文件敏感的验证、严格可加的违规累积（失败案例中：问责制1个、公平性2个、组合方案3个违规）、SHACL验证延迟在12.6毫秒到100.3毫秒之间，以及配置文件等效性测试确认了组合方案是最严格、最全面的配置文件，它包含了问责制和公平性，且不存在等效对。所有工件均已作为开源发布。

## 一、引言

负责任AI治理正跨越一个门槛。曾经是自愿性指南[3，4]的领域，正逐渐演变为可执行、可操作义务的版图。欧盟AI法案要求高风险系统维护技术文档、记录带时间戳的决策、提供透明度通知，并实施人工监督机制[1]。NIST AI风险管理框架（RMF）则在AI全生命周期内系统性地处理这些问题[2]。实际问题是，**问题的关键不在于是否存在治理义务（它们确实存在），而在于这些义务能否针对AI系统实际产生的证据进行自动检查？**

诚实的答案，在今天，是“**不能**”。合规实践仍然依赖于为定期审计而编制的叙述性文档。这种方法存在结构性缺陷：它记录的是**声明**，而不是验证**证据**。一份声称“日志记录已到位”的文件，无法确认单个决策是否带有正确类型的时戳、溯源链接是否连接到生成该决策的模型工件、或者资源分配是否满足声明的公平性阈值。

*问题：*据我们所知，目前尚无广泛采用的、符合标准的、可组合的机制能够同时做到：(a) 使治理义务明确且可供人工审查, (b) 将其确定性地编译为可执行检查, (c) 对AI服务发出的证据进行持续验证。虽然存在独立的组件（基于本体的合规模型[11, 13]、基于SHACL的合规检查[14]以及策略即代码引擎[10]），但据我们所知，没有现有系统能够将语义证据表示、确定性义务编译和可执行的基于配置文件的验证集成到一个统一的流水线中。

*方法：*我们提出**本体知识块**（OKBs），这是一种基于W3C标准构建的可编程合规基础。每个OKB将治理义务编码为一组RDF/OWL概念模式，并配以在**证据图**上执行的SHACL约束形状。一个监管编译器将经过人工审核的IR记录确定性地转换为知识块（KB）模块。治理配置文件可以选择和组合KB，而无需接触服务代码。

*贡献：* (i) **形式化：** 一个OKB模型 KB = ⟨O, C, V, E, P⟩，包含合规决策程序和配置文件组合代数。(ii) **编译器：** 一个确定性的IR到SHACL编译器。(iii) **原型：** 涵盖日志记录、透明度、公平性和溯源的开源参考实现。(iv) **评估：** 验证了配置文件的敏感性、精化关系以及低于100毫秒的延迟；确认了组合方案配置文件是最严格、最全面的。

*范围：* 本工作不涉及法律解释的自动化。规范性决策仍由人工治理主体负责。一旦义务被捕获到IR中并经过审查，编译和检查就是确定性和可重复的。

## 二、背景

*RDF 和 OWL：* 资源描述框架（RDF）[7]定义了一种图数据模型，用于将实体和关系表示为主体-谓词-客体三元组。Web本体语言（OWL）通过正式的类层次结构扩展了RDF。两者共同为结构化证据表示提供了基于标准的基础。

*SHACL：* 形状约束语言（SHACL）[8]提供了可机器检查的、作用于RDF图之上的约束形状。SHACL Core支持结构和数据类型验证；SHACL-SPARQL通过基于查询的约束扩展了此功能，从而能够实现诸如阈值比较之类的定量检查。

*PROV-O：* 溯源本体（PROV-O）[9]表达了实体、活动和代理之间的溯源关系。在本工作中，PROV-O将AI决策与生成它们的模型工件和活动联系起来，从而实现了欧盟AI法案和NIST AI RMF所要求的可追溯性审计。

## 三、相关工作

### 三-A 治理框架和文档工件

NIST AI RMF[2] 在AI生命周期内构建治理框架。模型卡[5]和数据集数据表[6]标准化了AI系统的描述方式。这些工件支持人工检查，但不包含任何可执行内容，也没有为基于配置文件的治理变化提供机制。

### 三-B 策略即代码与自动执行

诸如OPA[10]之类的策略即代码系统在基础设施边界强制执行声明式规则。它们对于访问控制有效，但操作的是语法上的系统状态，而非语义关联的证据图。关于AI决策的、具有溯源意识的声明不在其原生数据模型范围内。

### 三-C 基于本体的合规自动化

近期工作将本体方法应用于监管合规。Gallina等人[11]提出了针对机械立法流程合规的本体；后续工作将其扩展到合规感知的系统变更管理[12]以及受监管行业中基于本体的产品演化[13]。Anim等人[14]展示了基于SHACL的、对RDF数据的自动合规检查，证实了SHACL-SPARQL约束对于满足时间性和聚合性的法律要求是必要的。这些贡献推进了合规建模，但未涉及在运行时AI证据图上组合可执行的治理配置文件，也没有提供从经人工审核的义务到SHACL形状的确定性编译流水线。

### 三-D 定位

表一（https://arxiv.org/html/2605.23297#S3.T1）描述了OKBs与先前方法相比的特点。OKBs整合了可执行验证、可组合模块化、跨配置文件治理变化以及证据基础：据我们所知，这种组合此前尚未被展示过。

**表一：** 合规方法比较。✓ = 是；× = 否；∼ = 部分。

## 四、方法论

该方法论通过四个层级将治理义务转化为可机器检查的基础设施，将规范性解释（人类责任）与约束执行（确定性机器过程）分离开来。

*第一层 - 义务表示：* 义务被捕获为结构化的**监管IR**记录（YAML格式），指定目标概念、所需关系/属性、约束类型（结构、数据类型或定量阈值）、参数和严重性。IR记录在编译前由合规工程师编写和批准，从而保留了规范性权威。

*第二层 - 确定性编译：* 编译器 C 将每条IR记录映射为KB模块内的一个SHACL节点形状：

C: IR ↦ KB = ⟨O, C, V, E, P⟩。 (1)

其中 O 是义务集；C 是RDF/OWL概念模式；V 是SHACL形状集；E 是所需的证据工件；P 是PROV-O溯源链接。映射是确定性的：相同的IR总是产生相同的形状。

*第三层 - 证据图构建：* 每个AI服务决策都附带一个RDF证据图，该图将决策与溯源工件、使用日志、解释参考和定量测量关联起来。证据图由服务本身发出，使得合规检查与操作并发进行。

*第四层 - 配置文件组合与验证：* 一个治理**配置文件**选择KB模块。组合通过集合并集来定义：

KBa ⊕ KBb := ⟨Oa ∪ Ob, Ca ∪ Cb, Va ∪ Vb, Ea ∪ Eb, Pa ∪ Pb⟩。 (2)

SHACL引擎评估证据图 G<sub>S</sub> 上的所有形状：

validate(G<sub>S</sub>, KBa ⊕ KBb) → ⟨conforms, violations, G<sub>report</sub>⟩, (3)

其中 G<sub>report</sub> 是一个机器可读的SHACL报告。若配置文件 P1 检测到P2 检测到的所有违规，则称P1 **精化** P2 (P1 ⊑ P2)；当双向成立时，则为等价。当验证失败时，报告会指出触发了哪个形状、在哪个节点上、以及什么消息，从而为修复或审计关闭反馈循环。

## 五、框架架构

图1（https://arxiv.org/html/2605.23297#S5.F1）展示了治理流水线。图2（https://arxiv.org/html/2605.23297#S5.F2）展示了系统架构，图3（https://arxiv.org/html/2605.23297#S5.F3）展示了从证据捕获、配置文件选择到验证和报告的操作流程。

请参见图注 图1：可执行的治理流水线：义务被编译成KB模块，并针对每个AI决策发出的证据图进行验证。

请参见图注 图2：OKB系统架构：义务以IR表示，编译成KB模块，在运行时对RDF证据图执行。

请参见图注 图3：操作流程：AI服务为每个决策发出一个证据图；治理引擎选择活动配置文件，合并SHACL形状，并进行验证。报告为审计跟踪提供证据。

## 六、原型：场景、模块与案例

### 六-A HPC资源分配场景

我们在一个AI辅助的GPU小时调度器上实例化了该框架，该调度器负责在研究小组间分配资源。HPC调度器做出的高吞吐量决策会影响可测量的数量，其运行跨越监管边界，且其公平性属性可以被精确量化。

### 六-B 知识块

**问责制模块**（A）包含五个SHACL形状（A1–A5），用于强制日志记录、溯源链接和模型可追溯性。**公平性/透明度模块**（B）包含五个形状（B1–B5），用于强制解释的存在、公平性阈值声明、每个小组的分配，以及代码清单1中所示的定量差异检查：

```sparql
ex:B5Shape a sh:NodeShape;
    sh:message "Fairness disparity exceeds threshold.";
    sh:targetClass ex:Decision;
    sh:sparql [
        a sh:SPARQLConstraint;
        sh:select """
            SELECT $this WHERE {
                $this ex:allocatedGPUHoursGroupA ?a;
                      ex:allocatedGPUHoursGroupB ?b;
                      ex:fairnessThreshold ?t.
                BIND(IF(?a > ?b, ?a, ?b) AS ?mx)
                BIND(IF(?mx = 0, 0, (ABS(?a - ?b) / ?mx)) AS ?ratio)
                FILTER(?ratio > ?t)
            }
        """
    ].
```
**代码清单 1：** B5形状：用于定量公平性的SPARQL约束。

**组合模块**是A和B的集合并集（全部十个形状）。

### 六-C 配置文件与证据案例

**OKB原型**使用了四个面向管辖区域的配置文件：欧盟、美国、中国、以及欧盟+公平性。**编译器原型**使用了三个面向能力的配置文件：问责制、公平性和组合方案。证据案例用于隔离特定的治理失败（详见附录A（https://arxiv.org/html/2605.23297#A1））。

### 六-D 实现

两个原型均使用Python，并采用 rdflib 7.6.0 和 pyshacl 0.31.0，启用了RDFS推理和高级SPARQL约束评估。所有策略工件（IR义务记录、SHACL形状、验证配置文件和证据图）均通过DVC[17]与Git一起进行版本控制。DVC校验和可检测到策略文件的任何修改，作为合规安全框架的一部分，提供防篡改的审计跟踪。

## 七、评估

### 七-A 实验设置

实验1：3个案例 × 4个配置文件 = 12次运行（OKB原型）。实验2：4个案例 × 3个配置文件 = 12次运行（编译器原型）。总计：24次验证运行。

### 七-B 配置文件敏感性

**表二：** OKB原型：符合性（✓/×）和违规计数。表二（https://arxiv.org/html/2605.23297#S7.T2）：Case Conform 通过了所有配置文件。Case Profile 通过了美国和中国配置文件，但未通过欧盟和欧盟+公平性配置文件，恰好有一个违规（缺少解释），表明相同的证据通过配置文件选择产生了不同的裁决。Case Violate 的违规累积是单调递增的（1, 1, 2, 3）。

**表三：** 编译器原型：符合性（✓/×）和违规计数。表三（https://arxiv.org/html/2605.23297#S7.T3）：原子性的失败案例被编码了相应义务的配置文件精准检测到。案例 C（缺少模型工件）未通过问责制和组合方案配置文件，符合预期：A5形状正确地针对的是共同类型化为 `ex:Activity` 的溯源活动节点。违规累积是严格可加的：问责制检测到1个失败案例，公平性检测到2个，组合方案检测到全部3个。

### 七-C 配置文件精化与设计见解

**表四：** 配置文件精化关系。✓ = 成立；× = 不成立。

| 关系 | 成立？ | 含义 |
| :--- | :--- | :--- |
| Fairness ⊑ Accountability | × | 公平性遗漏了溯源（A5） |
| Combined ⊑ Accountability | ✓ | 组合方案检测到所有问责制违规 |
| Combined ⊑ Fairness | ✓ | 组合方案检测到所有公平性违规 |
| Fairness ⊑ Combined | × | 组合方案额外检测到案例C |
| Accountability ⊑ Fairness | × | 遗漏了解释/差异 |
| Accountability ⊑ Combined | × | 遗漏了公平性义务 |

组合方案是