核心摘要
EU AI Act 合规不是只写法律文件。对高风险 AI 系统而言，它会变成工程架构要求：风险管理、数据治理、日志、透明度、人类监督、准确性监控、鲁棒性、网络安全和上市后监控都必须内建到产品中。最快的稳妥路径，是在 AI 系统旁边建设合规证据层：模型注册表、数据集血缘、决策日志、人工复核工作流、评估报告和事故监控。
目录
核心要点
- 高风险取决于法律用途、角色、产品路径和例外条件，不是模型开源还是闭源。
- 合规证据应由系统自动生成，不能等审计时手工补。
- 人类监督需要工作流设计：复核队列、升级路径、覆盖记录和责任人。
- 日志要保留上下文，同时避免泄露个人数据和敏感 Prompt。
- 上市后监控要与风险相称：漂移、事故、投诉和性能变化都应有责任人、流程和证据。
什么算高风险 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"
}
工程团队应把风险登记表连接到测试和监控。demographic parity 是一种策略选择，不是统一法定阈值；应说明为何适用于该用途，以及还需要哪些切片和不确定性检查。
数据治理
数据治理关注血缘与质量。需要记录：
- 数据来源和收集依据。
- 标注流程和复核一致性。
- 受保护属性处理方式。
- 数据最小化和保留周期。
- 训练/验证/测试集切分。
- 已知偏差和覆盖缺口。
推荐使用数据集清单：
interface DatasetManifest {
datasetId: string;
source: string;
purpose: string;
piiFields: string[];
retentionDays: number;
qualityChecks: Array<{ name: string; passed: boolean }>;
approvalBasis: string;
reviewedBy: string;
}
日志与审计轨迹
审计日志应在必要且合法的范围内回答：发生了什么、涉及哪个版本和策略、使用了哪些证据、谁复核或干预过。
{
"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 输出不能被展示为最终决策。
糟糕设计：“人类理论上可以覆盖。”
更好的设计：明确哪些动作需要复核，为复核人提供证据和权限，在记录决定前阻断副作用，并测试超时、分歧和急停路径；具体门禁取决于用途。
准确性、鲁棒性与网络安全
被分类为高风险的系统应覆盖正常、边界和对抗场景测试；法案没有规定统一的指标组合或通过阈值。
| 领域 | 必要控制 |
|---|---|
| 准确性 | 分人群/分场景评估和置信度校准 |
| 鲁棒性 | 漂移测试和分布外检测 |
| 网络安全 | Prompt 注入防护、访问控制、限流 |
| 滥用 | 异常检测和误用监控 |
| 韧性 | 降级模式和事故响应 |
安全控制可参考 LLM Guardrails 工程指南 和 Prompt Injection 防御。
实施清单
- 记录提供者/部署者角色、预期用途、产品路径和 Article 6/Annex III 判断依据。
- 建立模型注册表和数据集清单。
- 为决策和建议增加具备隐私控制的可追溯事件日志。
- 对高影响结果实现人工复核。
- 按用户群体和场景生成评估报告。
- 监控漂移、事故、投诉和覆盖率。
- 上线前创建技术文档包。
- 审查开源模型许可证和 GPAI 义务。
- 做 Prompt 注入和数据泄露安全测试。
- 指定上市后监控负责人。
常见问题
EU AI Act 下什么是高风险 AI 系统？
当预期用途落入 Article 6、Annex III 或产品安全路径时，系统可能属于高风险。招聘、教育、信贷、医疗、执法和移民只是需要复核的信号，并非自动分类。
高风险系统需要哪些技术控制？
需要风险管理、数据治理、技术文档、日志、透明度、人类监督、准确性监控、鲁棒性测试、网络安全和上市后监控。
开源 AI 模型能否免除 EU AI Act 义务？
开源处理方式取决于提供者角色、模型特征和适用条件；下游提供者或部署者仍可能因集成系统和预期用途承担相应义务。
工程团队应先建设什么？
先建设模型注册表、数据集血缘、决策日志、风险分类和人工复核工作流。这些能产生审计和产品安全评审所需证据。
AI 日志需要多详细？
足以复原决策上下文：模型版本、Prompt 版本、输入哈希、输出、策略版本、检索上下文和复核动作。避免无必要存储原始敏感数据。
总结
高风险 AI 系统的 EU AI Act 工作需要工程与法律协作。应把适用性记录、风险登记、模型与数据血缘、决策日志、人工复核、评估和监控内建到架构中；合规是受治理的生产流程，不是上线后补一份 PDF。