EU AI Act合规指南：高风险AI系统要求清单【2026】

核心摘要

EU AI Act 合规不是只写法律文件。对高风险 AI 系统而言，它会变成工程架构要求：风险管理、数据治理、日志、透明度、人类监督、准确性监控、鲁棒性、网络安全和上市后监控都必须内建到产品中。最快的稳妥路径，是在 AI 系统旁边建设合规证据层：模型注册表、数据集血缘、决策日志、人工复核工作流、评估报告和事故监控。

目录

• 核心要点
• 什么算高风险 AI
• 技术义务清单
• 合规参考架构
• 风险管理系统
• 数据治理
• 日志与审计轨迹
• 人类监督
• 准确性、鲁棒性与网络安全
• 实施清单
• 常见问题
• 总结

核心要点

• 高风险取决于法律用途、角色、产品路径和例外条件，不是模型开源还是闭源。
• 合规证据应由系统自动生成，不能等审计时手工补。
• 人类监督需要工作流设计：复核队列、升级路径、覆盖记录和责任人。
• 日志要保留上下文，同时避免泄露个人数据和敏感 Prompt。
• 上市后监控要与风险相称：漂移、事故、投诉和性能变化都应有责任人、流程和证据。

当前适用时间表

AI Act 分阶段适用，截止日取决于具体条款与系统路径。AI Omnibus 已于 2026 年 7 月 27 日生效，并延后了两个高风险里程碑：

不能把这张表简化成“2027 年才需要合规”。产品可能已经受到禁止性实践、透明度、GPAI、数据保护、行业安全、合同或事故义务约束。第一份正确产物应是带日期的适用性记录，明确法律实体、角色、预期用途、目标市场、产品路径与已复核条款。

什么算高风险 AI

EU AI Act 按使用场景对 AI 系统分类。通用模型本身不一定是高风险，但基于它构建的应用可能是高风险。

常见高风险领域包括：

如果 AI 产品影响权利、机会、安全或基本服务获取，应记录预期用途并完成 Article 6/Annex III 适用性复核，不要把“先按高风险处理”当成法律分类结论。

分类还取决于组织扮演的角色：

角色、预期用途与系统版本必须一起判断。即使把组件称为“决策辅助”，只要真实工作流决定就业、教育、信贷、医疗或其他受保护机会的获取，名称本身并不能排除高风险分类。

可参考 EU AI Act 合规实操清单 和 开源 AI 许可证合规指南。

技术义务清单

高风险 AI 系统需要以下技术基线：

合规参考架构

证据收集器是关键组件。它记录每个决策用了哪个模型版本、数据集版本、Prompt 模板、检索上下文、策略版本和人工复核人。

风险管理系统

风险管理应该是一个持续运行的系统：

{
  "riskId": "HR-AI-EMP-001",
  "useCase": "candidate screening",
  "severity": "high",
  "hazard": "qualified candidates may be unfairly filtered",
  "mitigation": "human review required for configured high-impact recommendations",
  "metrics": ["false_negative_rate", "demographic_parity_gap"],
  "owner": "ai-governance"
}

工程团队应把风险登记表连接到测试和监控。应把算法公平视为伤害识别与需求治理过程，而不是寻找一个合规分数。人口统计均等不以标签为条件比较选择率，均衡赔率则在标签足够可信时比较真正率与假正率。它们都不是统一法定阈值；团队必须说明标准为何适用于该用途，以及还需要哪些切片、不确定性检查与补充证据。

数据治理

数据治理关注血缘与质量。需要记录：

• 数据来源和收集依据。
• 标注流程和复核一致性。
• 受保护属性处理方式。
• 数据最小化和保留周期。
• 训练/验证/测试集切分。
• 已知偏差和覆盖缺口。

每个数据集版本都应作为受发布流程控制的依赖。Manifest 至少要标识来源、法律或合同依据、预期用途、人群与时间覆盖、标注流程、质量检查、受保护属性处理、已知排除项、留存策略和批准责任人。每次训练与评测都关联不可变 Manifest ID；candidates-final.csv 这样的文件名不构成血缘。

日志与审计轨迹

审计日志应在必要且合法的范围内回答：发生了什么、涉及哪个版本和策略、使用了哪些证据、谁复核或干预过。

{
  "eventType": "ai.decision.created",
  "decisionId": "dec_123",
  "modelVersion": "risk-model-2026-06-01",
  "promptVersion": "candidate-screen-v4",
  "inputHash": "sha256:...",
  "output": {"recommendation": "review_required"},
  "policyVersion": "eu-ai-act-v2",
  "humanReviewRequired": true,
  "timestamp": "2026-06-07T12:00:00Z"
}

除非必要且有保护措施，不要记录原始敏感输入。哈希不提供保密性，也不能证明授权；应结合最小化、脱敏、加密、访问控制、留存和删除。

人类监督

人类监督不是“理论上可以覆盖模型”这么简单，而需要产品和工作流设计：

• 复核人要知道为什么这个案例被升级。
• 覆盖、通过、拒绝都要记录。
• 复核人需要策略指引。
• 复核人分歧要被衡量。
• 当需要人工批准时，AI 输出不能被展示为最终决策。

糟糕设计：“人类理论上可以覆盖。”
更好的设计：明确哪些动作需要复核，为复核人提供证据和权限，在记录决定前阻断副作用，并测试超时、分歧和急停路径；具体门禁取决于用途。

准确性、鲁棒性与网络安全

被分类为高风险的系统应覆盖正常、边界和对抗场景测试；法案没有规定统一的指标组合或通过阈值。

安全控制可参考 LLM Guardrails 工程指南 和 Prompt Injection 防御。

把合规证据变成发布门禁

只有构建系统能证明某次发布由哪些已批准证据产生，合规包才真正有用。下面这段仅使用标准库的 Go 程序会验证一条精简证据记录，并输出机器可读的发布决定。生产实现应从模型注册表、评测存储和策略系统加载带签名记录，而不是把数据写死。

package main

import (
	"encoding/json"
	"errors"
	"fmt"
	"os"
)

type evidence struct {
	SystemID        string   `json:"system_id"`
	SystemVersion   string   `json:"system_version"`
	IntendedPurpose string   `json:"intended_purpose"`
	RiskRoute       string   `json:"risk_route"`
	ModelVersion    string   `json:"model_version"`
	DatasetVersion  string   `json:"dataset_version"`
	PolicyVersion   string   `json:"policy_version"`
	EvaluationIDs   []string `json:"evaluation_ids"`
	ApprovedBy      string   `json:"approved_by"`
}

func validate(e evidence) error {
	if e.SystemID == "" || e.SystemVersion == "" || e.IntendedPurpose == "" {
		return errors.New("system identity and intended purpose are required")
	}
	if e.RiskRoute == "" || e.ModelVersion == "" || e.DatasetVersion == "" {
		return errors.New("risk route and version lineage are required")
	}
	if e.PolicyVersion == "" || len(e.EvaluationIDs) == 0 || e.ApprovedBy == "" {
		return errors.New("policy, evaluation, and approval evidence are required")
	}
	return nil
}

func main() {
	record := evidence{
		SystemID:        "candidate-screening",
		SystemVersion:   "release-42",
		IntendedPurpose: "prioritize applications for human review",
		RiskRoute:       "annex-iii-employment",
		ModelVersion:    "ranker-12",
		DatasetVersion:  "dataset-2026-09",
		PolicyVersion:   "oversight-7",
		EvaluationIDs:   []string{"quality-184", "bias-92", "security-31"},
		ApprovedBy:      "release-board",
	}

	if err := validate(record); err != nil {
		fmt.Fprintln(os.Stderr, err)
		os.Exit(1)
	}
	output, err := json.MarshalIndent(record, "", "  ")
	if err != nil {
		fmt.Fprintln(os.Stderr, err)
		os.Exit(1)
	}
	fmt.Println(string(output))
}

门禁必须验证引用，而不只是检查字段存在。确认每份评测产物确实存在，绑定精确模型与数据版本，覆盖必要用户切片和风险切片，仍在批准有效期内，并带有预期评审人或自动签名。模型、策略、预期用途发生变化，或数据出现实质漂移时，应使旧决定失效并触发重新评测。

实施清单

1. 记录提供者/部署者角色、预期用途、产品路径和 Article 6/Annex III 判断依据。
2. 建立模型注册表和数据集清单。
3. 为决策和建议增加具备隐私控制的可追溯事件日志。
4. 对高影响结果实现人工复核。
5. 按用户群体和场景生成评估报告。
6. 监控漂移、事故、投诉和覆盖率。
7. 上线前创建技术文档包。
8. 审查开源模型许可证和 GPAI 义务。
9. 做 Prompt 注入和数据泄露安全测试。
10. 指定上市后监控负责人。
11. 把已批准证据与精确模型、数据、Prompt 和策略版本绑定为发布门禁。
12. 系统发生实质性修改或预期用途变化后，重新执行适用性复核。

常见问题

EU AI Act 下什么是高风险 AI 系统？

当预期用途落入 Article 6、Annex III 或产品安全路径时，系统可能属于高风险。招聘、教育、信贷、医疗、执法和移民只是需要复核的信号，并非自动分类。

高风险系统需要哪些技术控制？

需要风险管理、数据治理、技术文档、日志、透明度、人类监督、准确性监控、鲁棒性测试、网络安全和上市后监控。

开源 AI 模型能否免除 EU AI Act 义务？

开源处理方式取决于提供者角色、模型特征和适用条件；下游提供者或部署者仍可能因集成系统和预期用途承担相应义务。

工程团队应先建设什么？

先建设模型注册表、数据集血缘、决策日志、风险分类和人工复核工作流。这些能产生审计和产品安全评审所需证据。

AI 日志需要多详细？

足以复原决策上下文：模型版本、Prompt 版本、输入哈希、输出、策略版本、检索上下文和复核动作。避免无必要存储原始敏感数据。

高风险规则何时开始适用？

2026 年 AI Omnibus 生效后，Annex III 高风险规则从 2027 年 12 月 2 日起适用，Annex I 产品嵌入式高风险规则从 2028 年 8 月 2 日起适用。其他义务有不同日期且部分已经适用，因此发布记录应逐条标明适用条款，而不是保存一个全局截止日。

总结

高风险 AI 系统的 EU AI Act 工作需要工程与法律协作。应把适用性记录、风险登记、模型与数据血缘、决策日志、人工复核、评估和监控内建到架构中；合规是受治理的生产流程，不是上线后补一份 PDF。

相关资源

• EU AI Act 合规实操清单
• 开源 AI 许可证合规指南
• LLM Guardrails 工程指南
• 生成式 AI 术语解释
• 大语言模型术语解释

一手来源

• Regulation (EU) 2024/1689（EUR-Lex）
• AI Omnibus 正式生效
• EU AI Act 实施时间表
• 欧盟委员会：AI Act
• 欧盟委员会：AI Act Service Desk