把AI Agent送上欧盟市场前：GPAI义务与AI Act合规的12项落地清单
不谈判法条原文，只谈工程落地。本文用一张检查清单串起GPAI模型提供者义务、高风险系统判定、技术文档、日志留存、人在回路与后市场监测，帮你判断自己的Agent到底踩在哪一档监管上。
先明确一件事：AI Act不是”过了某个日期才管”
很多团队的误解是”AI Act 有个生效日，到期前不用管”。实际上它是一条滚动生效的时间轴：禁止性条款最早上线，通用目的AI（GPAI）模型提供者义务随后落地，附件中的高风险系统再往后排。同时，模型层和系统层是两套不同的责任——你做的是Agent应用，但你调用的基础模型有它自己的义务，你复用它、把它包装成产品后，还可能被认定为”提供了GPAI模型”。
合规第一步不是写文档，而是回答三个定性问题：
- 我是模型提供者（provider），还是部署者（deployer），还是两者都是？
- 我的系统是否属于高风险？是否有豁免情形？
- 我的输出是否涉及”与自然人交互”或”生成合成内容”，从而触发透明度义务？
这三个答案决定了后面所有工作量的量级。
12项落地清单
A. 角色与责任划分（1-3）
- 角色矩阵：逐个系统标注 provider / deployer / importer / distributor 身份。尤其是”把开源权重微调后对外提供”的场景，往往从部署者瞬间变成提供者。
- 供应商条款审计：与基础模型供应商的合同中，确认对方是否承担GPAI义务、技术文档是否可获取、是否允许你在其基础上再发布。缺少这些承诺，风险全部落在你头上。
- 风险分级结论书：一页纸，写清判定依据、豁免理由、复审周期。这张纸在监管问询和客户尽调时最有用。
B. 技术文档与数据治理（4-6）
- 模型/系统卡（Model Card）：训练数据来源概述、能力与局限、已知失效模式、适用与不适用场景。Agent类产品还要额外写清工具权限边界。
- 数据治理记录：训练/微调数据的来源合法性、去重、偏差检查、个人数据处理的法律依据（GDPR 与 AI Act 是并行的两套）。
- 版权政策：如涉及生成式输出，需有 opt-out 尊重机制和侵权投诉通道。
C. 运行期控制（7-9）
- 日志与可追溯：输入、检索命中的文档ID、工具调用、模型版本、输出。高风险场景要求留存周期通常远长于普通业务日志，“事后无法还原当时发生了什么”是审计中最常见的致命缺陷。
- 人在回路（Human Oversight）：不是”可人工介入”就算，要能在设计上证明：操作员看得懂输出依据、能中止、能覆盖，并且系统默认不会绕过人类决策。
- 透明度提示：对用户明确告知正在与AI交互；合成内容加机器可读标识（C2PA或等效方案）。
D. 质量管理与后市场（10-12）
- 风险评估与缓解记录（FRIA）：高风险系统需在投产前做基本权利影响评估，重点覆盖歧视、儿童、弱势群体。
- 准确性与鲁棒性测试：留存评测集、评测方法、失败案例回归。每次模型升级后重跑，形成版本化证据链。
- 事件报告与后市场监测：定义”严重事件”阈值、内部上报时限、召回/下线流程。这一条在审查中最容易被忽略，也最容易被抓。
几个真实的踩坑点
- “开源就没事”是错的：开源权重只豁免部分文档义务，透明度、版权、系统性风险评估对特定规模模型仍适用。
- 透明度义务比高风险义务更容易踩：聊天机器人、内容生成、深度伪造标识属于广覆盖义务，几乎每个Agent都涉及。
- 微调把风险等级抬高了：在你没改判定结论书的情况下，产品侧的改动就可能让分类失效。
- 日志合规成本被严重低估：完整链路追踪的存储与脱敏成本，通常会超过模型调用成本本身。
给团队的最小行动项
如果这个月只能做三件事：画清角色矩阵、为每个Agent写一张系统卡、把工具调用日志接上。这三项覆盖了多数监管问询的高频问题，也是后续所有文档的地基。
监管不是创意工作，它是一场”证据完备度”的比赛。你今天多留的一条日志、多写的一行局限性说明，就是明天少一次返工的代价。