EU AI Act高风险AI义务

可视化演示

动态演示EU AI Act高风险AI的核心机制，通过采集/分析/决策/反馈四种模式展示关键概念与交互流程。

风险评估体系

晨光航空公司购入“智航号”AI客机，首飞之前，安全总监在机库里挂起一面白板，把能想到的事故逐条写下：鸟击、引擎失效、自动降落误判跑道……每条都要回答两个问题：这事多常见？真发生多严重？这正是EU AI Act要求高风险AI提供方做的第一件事——建立风险管理体系。

《人工智能法案》第9条把风险管理系统列为高风险系统的头号义务。它要求企业在设计、开发、部署、退役的全生命周期里循环执行四步：识别风险、分析风险、评估风险、实施缓解措施。这不是一次性文档，而是一面伴随系统成长的“安全白板”。

风险的量化常用最朴素的公式：可能性×影响度。可能性指某类故障发生的概率高低，影响度指一旦发生造成的伤害程度。分数越高，系统越危险。超过阈值就必须设计缓解机制并持续监控残余风险，就像给发动机加装双备份、给降落系统再加一套独立传感器。

白板永远擦不干净，这恰恰是好事。系统升级、场景拓展，新风险总会长出来。EU AI Act要求定期复审，正像航空公司每次开新航线都要重新过一遍白板——把风险当回事，飞机才敢升空。

训练数据治理

飞行员的履历如果只记录晴天起降，遇到雷雨天就会手足无措。AI的学习资料就是它的“飞行履历”——《法案》第10条要求高风险AI的训练数据必须来源合法、有代表性、无偏差，而且标注要经得起查。

换句话说，你不能拿来路不明的数据炼模型；数据要覆盖足够多样的人群与场景，不能“偏科”；标注过程要有人工审核并记录规范。数据质量不只是模型效果问题，更是法律问题：训练数据不合规，整个系统都进不了评审流程。

实践中，团队常用“人口统计均衡差”来抓偏差：比较两个受保护群体（比如不同性别、不同年龄组）获得模型正面结果的概率。差值越接近零，说明系统越“一视同仁”。

履历造假、记录偏科，事故调查时一眼就会被戳穿。数据治理不是装修门面，而是给AI的“驾校档案”抹平每一道暗伤——只有这样，“智航号”才敢载着形形色色的乘客上天。

技术文档维护

客机出厂必须随附《飞行手册》和《维护手册》，写清系统由哪些部件组成、在极限状态下怎么操控、哪些操作绝对禁止。没有手册，机长不敢飞，维修员不敢修，民航局不敢发证。

《法案》第11条要求高风险AI提供方在投放市场前编制技术文档，并在监管机构要求时随时提交。文档必须足够详细，能证明系统符合全部义务，至少要覆盖：系统架构、训练方法、数据基准、预期用途、风险评估过程等。这份文档就是AI的“随机手册”。

附件四（Annex IV）给出了技术文档的提纲，实践中最有效的做法是把它做成“清单”，逐项打钩并做版本管理。因为系统一旦发生重大变更，文档必须同步更新，甚至触发重新评估。文档完备度可以这样量化：

文档之于监管，就像飞行手册之于飞行员——事故发生后，监管者第一件事就是翻开手册和记录，看你有没有按规矩做事。文档烂尾，合规直接归零，“智航号”的适航申请也会被盖上“退回”章。

日志记录留存

飞机上的黑匣子平时没人看，却在事故后成为最关键证人。它自动记录操作与状态，让调查员能倒推每一秒发生了什么。《法案》第12条要求高风险AI系统配备同样的“自动日志记录”能力。

日志要记什么？系统运行的时间、触发的事件、输入输出的关键特征、回退机制是否启动、人工干预的痕迹。有了这些记录，部署方和监管者才能实现“可追溯性”：出了事能定位到是哪一环、哪一条数据、哪一次决策。

关键细节有三条：第一，保存期限要“与预期用途相称且至少6个月”；第二，日志本身要防篡改；第三，存储量要提前规划，否则上线三个月就撑爆磁盘。存储量用简单的乘法估算：

黑匣子不能当摆设。许多AI事故扑朔迷离，正是因为日志缺失——就像飞机黑匣子没插电。日志留存不是存储部门的杂活，而是整个合规链条的“事故证人”，关键时刻能救企业一命。

透明度披露

登机前，广播会告诉你航班号、目的地、预计到达时间；机上安全演示会告诉你在紧急时如何撤离。乘客有权知道“我正在乘坐什么、遇到危险怎么办”。《法案》第13条就是AI的“机上广播”：高风险AI必须向部署方和用户提供透明信息。

具体来说，使用说明要清晰、易懂、完整，覆盖系统的能力边界、预期用途、潜在风险、性能指标以及人机交互注意事项。当系统涉及公共场所的特定场景时，部署方还要依法告知当事人——这就好比在舱门口立一块牌子：“本航班由AI辅助驾驶，请注意听从机长指令。”

透明度做得好不好，可以用可读性公式来度量。面向普通用户的使用说明，如果写得像法律条文，就等于没写。Flesch阅读易读度是常用标尺：

透明披露的本质是“让乘客知道自己在坐什么飞机”。AI可以不是白盒，但它的说明书必须是白的——用户看不懂，再厚的合规文档也只是废纸。

人工监督机制

即使自动驾驶技术再成熟，民航规定驾驶舱里必须有人。机长的作用不是每时每刻操纵，而是在自动驾驶失效、遇到特情时能立刻接管、拍板、关停。《法案》第14条要求高风险AI配备同等意义的人工监督。

具体要求有三层：第一，监督者要理解系统的能力与局限，能识破“自动化偏见”（盲目相信AI输出）；第二，系统要能向人显示运行状态、置信度和告警信息；第三，人要能干预，甚至一键中止系统。用人机工程的话说：好的人机界面，要让“该看见的看得见，该按下的够得着”。

怎么衡量监督机制有没有用？一个实用指标是“高危样本人工复核覆盖率”：所有应当复核的高风险决策里，人真正看到并处理了多少。覆盖率掉到1以下，说明系统在“蒙眼飞行”。

人工监督不是“人在副驾喝咖啡”式的假监督，而是“机长在位”式的真监督。监督者必须有能力、有手段、有权限让AI停下——哪怕只是按下一个红色按钮。

合格评定认证

一架新机型要上天，必须先拿到民航局的型号合格证，飞机才被允许载客运营。EU AI Act对高风险AI同样设定了“出生证明”——合格评定。通过评定后，系统就可以加贴CE标志并投放欧盟市场。

对大多数高风险AI，提供方可以依据附件六做基于内部质量控制的自我评定；但对生物特征识别等特定场景，必须由公告机构（notified body）介入。评定的内容正是前面六关的总验收：风险管理、数据治理、技术文档、日志、透明度、人工监督是否全部达标。任何一关亮红灯，都要退回整改。

评定周期可以这样估算：准备时间加评估时间加整改时间，三段串联。企业踩过最多的坑，是把上市日期定得太死，没给整改留余量——就像航空公司把首航日定在拿到适航证的前一天。

拿到CE不是终点而是起点。就像飞机拿到适航证后还要做日常维修、定期检查、持续适航管理——AI上市后还要应对重大变更重新评估和上市后监督。证书会过期，义务不会。

供应链责任分工

一架航班的安全，靠的不只是飞行员：航空公司选型和维护，空管指挥，机场保障，油料公司加注合格燃油。任何一环掉链子，飞机都上不了天。EU AI Act把高风险AI的合规责任同样分散到一条供应链上。

提供方（开发者）承担绝大多数义务：风险管理、数据治理、文档、日志、透明度、人工监督、合格评定，并在重大变更时重新评估。部署方（使用AI的企业）要按说明使用、保证输入数据真实、履行人工监督、保留自动日志。进口方和分销方要核验CE标志与配套文档，发现不合规必须停止投放。按现行时间表，绝大多数高风险系统义务在法案全面适用后开始执行，部分受行业法规约束的产品类系统会延后一年——留出的过渡期，正是供应链上各方补课的时间窗。

合规成本也按角色分摊。一个常用的估算框架是把五大块成本相加：风险控制流程的成本、数据治理与加工的成本、文档编制与维护的成本、合格评定（可能含公告机构）的费用、以及上线后的运维成本（日志、监督、监控）。综合行业经验，高风险AI的合规投入通常占研发预算的5%到15%。

供应链上责任往下游流动，却不可以转嫁。航空公司可以把维护外包，但甩不掉“安全第一责任人”的头衔；AI提供方可以把评测外包给第三方，但监管找上门时，第一张罚单上写的永远是你的名字。

AI 应用场景

Python 演示

# -*- coding: utf-8 -*-"""高风险AI合规检查器: 对照EU AI Act逐项模拟核验."""import randomfrom datetime import date  class HighRiskAIChecker:    """模拟一个高风险AI系统的提供方合规自检."""     def __init__(self, name, data_size, bad_rate):        self.name = name        self.data_size = data_size        self.bad_rate = bad_rate        self.risk_log = []    # 日志记录, 对应黑匣子        self.doc_map = {}     # 技术文档清单        self.check_count = 0  # 记录评估次数     def risk_score(self, likelihood, impact):        # R = L x I: 可能性 x 影响度        return likelihood * impact     def data_accuracy(self):        # 抽样检查训练数据标注正确率        correct = 0        sample = min(500, self.data_size)        for _ in range(sample):            if random.random() > self.bad_rate:                correct += 1        return correct / sample     def add_doc(self, key):        # 提交一份技术文档        self.doc_map[key] = True        self.risk_log.append('[%s] add doc: %s' % (date.today(), key))     def check(self):        self.check_count += 1        risk = self.risk_score(4, 5)        acc = self.data_accuracy()        doc_ok = len(self.doc_map) >= 4        passed = acc >= 0.95 and risk <= 20 and doc_ok        self.risk_log.append(            '[%s] check #%d: R=%d ACC=%.2f%% doc_ok=%s passed=%s'            % (date.today(), self.check_count, risk, acc * 100, doc_ok, passed)        )        return passed  def main():    checker = HighRiskAIChecker('medical_image_ai', 12000, 0.02)    checker.add_doc('system_architecture.md')    checker.add_doc('training_method.md')    checker.add_doc('intended_use.md')    checker.add_doc('risk_control.md')    if checker.check():        print('CE assessment: PASS')    else:        print('CE assessment: FAIL')    print('log entries:', len(checker.risk_log))    print(checker.risk_log[-1])  if __name__ == '__main__':    main()

1. def risk_score(self, likelihood, impact):把风险评估公式R=L×I落成方法，供每轮检查复用。
2. correct += 1抽样中每判定一条正确标注就累加，最后除以样本数得到准确率。
3. self.doc_map[key] = True每提交一份文档就登记入清单；不足4份时不允许通过。
4. self.risk_log.append(...)每次动作和评估结果都写入“黑匣子”日志，形成可追溯的证据链。
5. passed = acc >= 0.95 and risk <= 20 and doc_ok三个合规门槛同时满足才判定CE评估通过。
6. if __name__ == '__main__':保证脚本可直接运行，也能作为模块被其他工具导入复用。

常见误区

面试题