5.1 欧盟 AI 法案详解

5.1 欧盟 AI 法案详解

本节摘要：欧盟 AI 法案（EU AI Act）是全球第一部全面的 AI 法规，2024 年 8 月正式生效，它的核心创新是"风险分级"——把 AI 系统按风险分成不可接受、高、有限、最小四档，每档适用不同的要求，从"全面禁止"到"自由使用"。本节拆解这四档的判定标准和合规要求，重点讲高风险系统（覆盖生物识别、关键基础设施、教育就业、执法等领域）的六大严格要求（风险管理、数据治理、技术文档、人工监督、鲁棒性、合格评估），以及分阶段实施的时间表和罚则。

学习目标

阅读完本节，你应当能够：

1. 判断一个 AI 系统属于欧盟法案的哪一档风险
2. 列出高风险系统的六大合规要求
3. 复述法案的分阶段实施时间表
4. 估算不同违规类型的罚款金额
5. 为一个高风险 AI 系统搭建立项合规框架

问题与直觉

如果你做的 AI 产品要进欧洲市场，欧盟 AI 法案是绕不过去的。它不是某个行业的专项法规，而是横跨所有 AI 应用的通用规则——从你手机里的推荐算法，到医院里的诊断系统，到边境的生物识别，全都管。而且它的罚款力度对标 GDPR：最高可达全球年营收的 6%，对大公司来说动辄几亿欧元。

这个法案的设计哲学很特别：它不搞"一刀切禁止 AI"，也不搞"AI 完全自由"，而是按"这个 AI 用途的风险有多大"来分级管理。一个帮你挑电影的推荐算法（低风险）几乎不用管，一个决定你能不能拿到贷款的 AI（高风险）要满足一大堆严格要求，一个用 AI 做社会评分的系统（不可接受风险）直接禁止。这个思路的巧妙之处在于：它把监管资源集中在真正危险的用途上，而不是无差别增加所有人的合规负担。

理解这套分级的关键是认清"风险"的定义——它不是指"技术有多复杂"，而是指"这个用途如果出问题，对人的基本权利伤害有多大"。一个简单的决策树，如果用来决定谁能上学、谁被监禁，它就是高风险；一个超复杂的深度学习模型，如果只是给商品分类，它就是有限风险。风险取决于用途，不取决于技术。

核心原理

2.1 四档风险分级

2.2 高风险系统的六大要求

高风险是法案的重头戏。如果你的 AI 落在生物识别、关键基础设施、教育就业录用、执法移民、民主程序、信用评分这些领域，就必须满足下面六条。

# 高风险 AI 系统的合规清单(概念性)
high_risk_checklist = {
    "1.风险管理系统": [
        "建立持续的风险管理系统",
        "评估并减轻可预见的风险",
        "记录并报告安全事件",
    ],
    "2.数据治理": [
        "训练数据的治理(质量、代表性、相关性)",
        "数据偏见检测与减轻",
        "数据集设计与更新流程",
    ],
    "3.技术文档": [
        "系统描述与预期用途",
        "训练数据与模型架构说明",
        "性能指标与测试结果",
    ],
    "4.人工监督": [
        "自然人监督机制",
        "能理解和覆盖 AI 决策",
        "紧急停止能力",
    ],
    "5.鲁棒性与安全": [
        "网络安全措施",
        "准确性与鲁棒性测试",
        "容错与故障安全设计",
    ],
    "6.合格评估与注册": [
        "第三方合格评估(部分情况)",
        "CE 标记",
        "注册到欧盟数据库",
    ],
}
​

这六条对应的是前四章讲的技术能力：数据治理对应第四章的公平性（检测数据偏见），人工监督对应第二章的对齐（确保 AI 行为可控），鲁棒性对应第一章的安全（防御攻击），技术文档对应第三章的可解释性（能解释决策）。法规要求本质上就是把前四章的技术能力变成强制义务——这就是为什么本教程把它们放在合规前面讲。

2.3 实施时间表

法案不是一夜之间全部生效，而是分阶段落地，给企业适应时间。

⚠️ 常见坑：别以为"还没生效就不用管"。高风险条款 2026 年 8 月才强制，但从现在起你就该搭合规框架——建立风险管理系统、做数据治理、写技术文档都不是临时能赶出来的。等到生效前夕再补，多半来不及。

2.4 罚则

法案的罚款按违规类型分档，都和全球年营收挂钩，对大公司尤其有威慑力。

def calculate_fine(violation_type, annual_revenue):
    """估算不同违规类型的罚款(取较高者)"""
    rules = {
        "prohibited":   (30_000_000, 0.06),   # 不可接受:3000万或6%
        "high_risk":    (20_000_000, 0.04),   # 高风险:2000万或4%
        "transparency": (10_000_000, 0.02),   # 透明度:1000万或2%
    }
    floor, rate = rules.get(violation_type, (7_500_000, 0.01))
    return max(floor, annual_revenue * rate)

# 示例:年营收 1 亿欧元的公司高风险违规
print(f"罚款: {calculate_fine('high_risk', 100_000_000):,.0f} 欧元")
# 输出: 罚款: 4,000,000 欧元(4% > 2000万固定额)
​

工程实践要点

3.1 搭建合规框架

合规不是"做一次性的检查"，而是建一套持续运营的框架。核心是把法规要求翻译成可执行的内部政策、流程和工具。

class EUAIActCompliance:
    """高风险 AI 系统合规框架骨架"""
    def __init__(self):
        self.policies = {
            "data_governance": self._data_governance_policy,
            "human_oversight": self._human_oversight_policy,
            "technical_docs": self._technical_docs_policy,
            "risk_management": self._risk_management_policy,
        }

    def _data_governance_policy(self):
        return (
            "数据治理:1)数据来源验证 2)质量评估 "
            "3)偏见检测(用第四章的 Fairlearn/AIF360) "
            "4)数据保护 5)定期审计"
        )

    def _human_oversight_policy(self):
        return (
            "人工监督:1)操作员有覆盖权限 "
            "2)能理解 AI 决策(用第三章的 SHAP 解释) "
            "3)紧急停止按钮 4)高风险决策需人工确认"
        )

    def audit(self):
        """定期合规审计"""
        results = {}
        for name, policy_fn in self.policies.items():
            results[name] = {
                "policy": policy_fn(),
                "implemented": self._check_implementation(name),
            }
        return results
​

3.2 把法规映射到技术动作

💡 关键直觉：合规不是法务团队一个人的事，它要求技术、产品、法务协同。最有效的做法是把每条法规要求映射到一个具体的技术动作——"数据治理"映射到"用 Fairlearn 跑偏见检测"，"人工监督"映射到"高风险操作加人工确认按钮"，"技术文档"映射到"用 SHAP 生成解释报告"。本教程前四章的每一项技术，都能在合规清单里找到对应的落点。

3.3 部署前检查清单

把高风险 AI 上线前，过一遍这个清单（对照法案要求）：

一页速查

• 欧盟 AI 法案按风险分四档：不可接受（禁止）、高风险（严格要求）、有限（透明度）、最小（自由），风险取决于用途不取决于技术。
• 高风险系统要满足六大要求：风险管理、数据治理、技术文档、人工监督、鲁棒性、合格评估。
• 法规要求本质是前四章技术能力的强制化——防御、对齐、解释、公平都能在合规清单里找到落点。
• 分阶段生效，2026 年 8 月高风险条款全面强制，现在就该开始搭框架，别等生效才补。
• 罚则与全球营收挂钩，最高 6%，对大公司有强威慑力，合规是成本也是竞争力。

下一章看中国的监管体系——算法备案、深度合成水印、安全评估。

工程补充：通用目模型条款的技术含义

欧盟法案里对通用目模型（GPAI）的单独条款，对大模型团队有直接的技术含义，值得展开。法案要求训练数据摘要要说明数据来源与治理方式——注意这是"摘要级"义务，不要求公开完整数据集，但要有方法论描述，这意味着数据治理文档从内部规范升级为法定交付物。系统性风险评估义务则对应一套技术流程：威胁建模、红队测试记录、缓解措施及其局限说明，本质上就是把安全团队已经在做的事文档化、可审计化。还有一项容易被低估：版权政策义务，模型方要公开尊重版权的政策文本和 takedown 流程，这和训练数据的确权工作相互咬合。工程上的应对是把这三样东西在训练流水线里做成模板工件——每次大版本训练自动生成数据摘要、风险评估、版权合规说明的草稿，人工只做审核补充。第一次搭会花两三周，之后每个版本的边际成本接近于零，这比监管截止日前手忙脚乱攒材料划算得多。

再补一个执行层面的观察：法案落地后的真正瓶颈是"合格评定"的实操。高风险系统需要做合规评定，但公告机构（有资质的第三方评估组织）的数量和产能有限，排队周期可能比技术整改还长。计划进入欧盟市场的团队，除了文档准备，还要把公告机构的接触和排期提前启动——先做预评估摸清差距，再正式申请，比材料齐了才去找机构要快几个月。另一个省钱渠道是中小企业可以先用内部合规自查加第三方咨询的组合过渡，成本约为全程外聘评定的一半，但要确保咨询方能出具监管认可的差距分析报告。合规的时间管理，一半是管自己的工期，另一半是管别人的档期。

还有一个常被问到的边界问题：开源模型是否豁免。法案对以开源许可发布、非商业目的的通用模型给了部分义务豁免，但这个豁免有明确边界——一旦模型被用于商业服务、或存在系统性风险，义务照旧。团队选用开源基座时，要同时评估自己的使用方式落在豁免区内外哪一侧，而不是默认"开源等于不管"。

关于义务的颗粒度还有一点补充：法案对高风险系统的要求里，日志留存有明确时长下限，这直接冲击现有日志系统的保留策略——很多团队的日志默认七天滚动，离法定要求差着数量级。存储成本要提前测算，冷热分层、抽样脱敏都是可行的压缩手段，但法定必须完整留存的部分不能省。这块的预算缺口，越早暴露越好。