eu-ai-act-readiness

《欧盟人工智能法案》准备情况

提供实际操作层面的分流建议，而非法律意见。《人工智能法案》会因修正案、授权法案／实施法案、指南、标准和各国执法实践而变化；每次评估开始时都应核实法律和日期。

输入信息

收集或说明：

• 评估日期、目标欧盟／欧洲经济区国家、组织所在地、客户／用户所在地，以及系统输出的使用地点。
• 每个 AI 系统／模型的目的、预期用途、用例筛查、合理可预见的误用、生命周期状态、准确的系统／模型版本、发布／变更日期、重大修改和受影响人员。
• 每个系统对应的组织角色：提供者、部署者、进口商、分销商、产品制造商、授权代表或 GPAI 模型提供者。
• 模型／供应商链、品牌标识、微调或实质性修改、集成、数据来源和合同责任分配。
• 司法管辖区、决策领域、自动化程度、人类监督的设计／权限、输出、透明度界面、监控、事件、投诉／申诉途径以及明确的重新评估触发条件。
• 现有的风险、质量、隐私、安全、无障碍、采购、记录保存和 AI 素养证据。

如果没有可靠的清单，请使用空白的 AI 系统清单模板。

输出要求

返回：

1. 评估日期、最后核实法律来源的日期、司法管辖区、官方来源、假设和限制。
2. 清单，包含司法管辖区、系统／模型版本、初步欧盟关联、运营者角色、用例筛查、可预见的误用、重大修改、自动化／监督、风险状态假设、分类依据／置信度以及重新评估触发条件。
3. 差距登记表，列出条款／主题、适用时间节点、现有证据、差距、优先级、负责人、目标日期和核查方法。
4. 分别列出禁止性实践升级处理、Article 50 透明度、高风险系统、GPAI 模型，以及 AI 素养等广泛适用的治理要求。
5. 30／60／90 天实施计划，以及需要合格的欧盟法律顾问或主管机关解答的问题。

使用 preliminary、potential 或 counsel review required；不要将组织标记为“合规”，不要提供确定的法律分类，也不要承诺监管机构会予以认可。

工作流程

1. 核实法律、司法管辖区和日期

打开 current-law-and-sources.md，然后查阅其中链接的 EUR-Lex 法律文本和欧盟委员会／AI Act 服务台页面，确认自 2026-08-09 以来的变更。结合 Regulation (EU) 2024/1689 阅读 Regulation (EU) 2026/1744 以及任何后续修正案或合并文本。

记录访问日期和适用的语言／版本。确认后续授权法案、实施法案、委员会指南、协调标准、共同规范、行为准则、法院判决或国家规则是否会影响相关问题。如果无法核实最新官方来源，应将法律时间线标记为过时，并在得出任何期限或分类结论之前停止。

依据 Articles 2 和 3 确定相关的欧盟关联和角色。考虑在欧盟市场投放、在欧盟境内部署以及在欧盟境内使用输出的情形，同时考虑排除项和行业特定法律。属地适用范围和豁免属于法律问题；如有不确定之处，应转交法律顾问。

2. 构建并进行结构性检查

为每个实质上不同的系统／模型／用途创建一条记录。运行此技能目录中附带的完整性检查器：

python3 scripts/check_ai_inventory.py assets/ai-system-inventory-template.csv --as-of 2026-08-09 --pretty
python3 scripts/check_ai_inventory.py /path/to/populated-inventory.csv --as-of YYYY-MM-DD --pretty
python3 scripts/check_ai_inventory.py /path/to/populated-inventory.csv --as-of YYYY-MM-DD --output /path/to/check.json --pretty

检查器使用标准库启发式方法，不会给出法律分类，其输出标签为 structural/completeness screening only—not semantic fact verification or legal verification。它会报告系统 ID、缺失字段、无效的受控词汇值、日期问题、适用年龄／事件状态以及基于关键词得出的信号；不会复制其他来源行的值。使用 --output 时，它会拒绝库存别名和非普通文件目标，然后通过同级临时文件以原子方式创建或替换报告。对 article_50_status 和 counsel_status 使用其受控值；手动核实每项源事实和信号。纳入影子 AI、试点项目、员工工具、供应商功能、嵌入式模型、旧系统，以及仍有持续影响的退役系统。

默认的 365 天过时标记是管理提示，并非法定期限。每当发生已记录的触发事件时，都应尽早重新评估，包括新用途、新系统／模型版本、新供应商、新地域、新角色、实质性修改、事件或法律更新。因此，即使评估时间不久，也可能需要立即重新评估。

3. 筛查紧急排除事项和禁止行为

首先确认该项是否属于《法案》定义内的 AI 系统或 GPAI 模型。依据第 5 条（包括修正案）筛查预期用途和可预见的运行情况。如果发现可能涉及禁止行为，应停止常规评分、保留证据、建议暂停部署／扩展，并上报合格的法律顾问和负有问责责任的负责人。除非 Agent 获得明确授权，否则不得暂停或更改正在运行的系统。不得试图重新设计或隐瞒用途以规避适用范围。

另行识别就业、教育、生物识别、关键基础设施、基本服务、执法、移民／边境、司法、选举、健康／安全、未成年人和弱势群体相关情境。这些是升级处理信号，并非自动分类依据。

4. 确定角色和初步风险路径

对于每个系统，记录支持以下判断的事实：

• 不在适用范围内或属于排除事项，并注明需要法律顾问确认的确切依据。
• 依据第 5 条涉及禁止行为的疑虑。
• 依据第 6 条和附件 I 或附件 III 可能属于高风险，包括任何例外及其记录条件。
• 第 50 条透明度义务。
• 第 V 章规定的 GPAI 模型义务，包括可能需要的系统性风险分析。
• 最低／其他风险，附自愿控制措施及任何其他适用的欧盟或国家法律。

角色可能重叠，也可能因重新品牌、投放市场、重大修改或预期用途变更而改变。不要仅依赖供应商的标签或合同。

5. 梳理义务和里程碑

阅读 assessment-checklist.md。仅梳理初步范围／角色分析支持的义务，并注明相关条款／附件。至少评估：

• AI 素养和负责任治理。
• 提供者／部署者的透明度义务及受影响人员告知。
• 适用时的高风险风险管理、数据治理、技术文档、记录／日志、说明、人类监督、准确性、稳健性、网络安全、质量管理、合格评定／登记、监测、事件响应和基本权利影响评估。
• 适用时的部署者运行控制、输入数据相关性、日志保留、员工告知、监测、人类监督以及影响评估／通知义务。
• 适用时的 GPAI 技术文档、下游信息、版权政策、训练内容摘要以及额外的系统性风险义务。

使用经核实的现行法律中的适用日期，不要使用记忆中的截止日期或未注明日期的清单。

6. 验证证据，而非政策措辞

针对每项控制措施，索取现有的证明材料，并测试其是否涵盖确切的系统、版本、角色、用途、司法辖区和生命周期阶段。示例包括经批准的清单条目、风险记录、数据集溯源信息、评估报告、日志、模型／系统卡、用户说明、人类监督测试、安全证据、变更记录、合同、透明度通知、事件演练、培训记录以及决策／申诉程序。

只有在证据最新且经过测试时，才标记为 implemented。否则，请使用 partial、planned、missing、not assessed 或 not applicable—basis pending counsel。

7. 确定优先级并向法律顾问简要说明情况

优先处理可能被禁止的用途、已适用的义务、正在运行的高影响系统、具有误导性的透明度信息、缺少监控的情况以及重大事件。制定一份 30/60/90 天计划，列明负责人员、依赖项、验收证据和法律决策关口。

向法律顾问提供简明的事实情况和明确的问题，而不是泛泛地要求审查。说明确切的预期用途、角色、受影响人员、日期、变更历史和有争议的条款。

安全与权限边界

• 此技能提供运营准备支持，不构成法律建议或代理。有关地域范围、豁免、角色、禁止或高风险分类、合规评定途径、申报、执法风险或解释争议，必须咨询具备资质的欧盟法律顾问。
• 未经明确授权和法律审查，不得联系主管机关、提交注册／通知、签署行为准则、作出合规声明或发布通知。
• 尽量减少个人数据和特殊类别个人数据的使用。使用系统 ID 和汇总证据；不要将生产数据集复制到评估中。
• 不得推断受保护特征、进行生物特征分类，也不得为了完成清单而对人员开展高风险系统测试。
• 保留法律特权标记和访问控制，但不要承诺享有法律特权。
• 将疑似禁止用途、严重事件、权利影响、误导性披露或错过适用期限的情况视为紧急上报事项。
• 单独核查 GDPR、产品安全、就业、消费者权益、平等、无障碍、网络安全、版权、行业法规及成员国法律；AI Act 准备工作不能替代这些核查。

验证与签署

• 重新打开每个引用的官方来源，并记录访问日期。
• 对照基础法规核查修订内容，并以现行有效的法律文本为准，而非摘要。
• 将每项分类假设追溯到事实、角色、条款／附件、版本和法律顾问问题。
• 对照正在运行的系统抽查证据，并核实负责人／日期，不要仅凭政策声明就予以接受。
• 由系统负责人验证事实，由安全／隐私负责人验证控制措施，并由具备资质的法律顾问验证法律结论。
• 记录尚未解决的不确定性，以及触发重新评估的事件：新用途、模型／供应商／版本、地域、角色、重大变更、事件或法律更新。将年龄阈值视为兜底要求，而非替代由事件触发的审查。

补救

如果评估使用了过时法律、错误的司法辖区、错误的系统版本或缺乏依据的分类，应撤回受影响的结论，找出依赖该结论的下游计划／通知／申报，保留先前报告，并在法律顾问审查后发布注明日期的更正。不要悄悄改写记录。如果出现潜在的禁止用途或严重事件，在获得授权的情况下停止进一步推广，保留证据，并通过组织的法律和事件响应流程上报。

示例

招聘助手

请求：“在面向欧盟推出前，评估我们的简历排序助手。”

记录提供者／部署者角色及欧盟关联，筛查第 5 条和附件 III 中的就业用途，核实当前适用日期，梳理高风险和透明度证据，找出人工监督和员工告知方面的缺口，并将分类结果和推出门槛提交法律顾问，而不是直接宣称合规。

客户服务聊天机器人

请求：“第 50 条现已生效，我们的支持机器人必须做出哪些改变？”

核实第 50 条的现行文本和指南，确定提供者／部署者角色，以及用户是否已得到明确告知；测试披露时机和可访问性；分别记录合成内容功能；并整理证据要求和需咨询法律顾问的问题。

AI 系统组合清单

请求：“为我们的 60 个供应商和内部系统制定一份为期 90 天的《人工智能法案》准备计划。”

对清单进行结构性检查，人工核实其中的信息，优先处理紧急／禁止事项和已适用的义务，按角色／用途／风险假设对系统分组，抽样检查证据，明确负责人，并制定基于风险的路线图，其中包括法律审查关卡和重新评估触发条件。