先把时间线说准：2026年7月不能被笼统写成所有高风险AI系统的统一截止日。
欧盟委员会于2021年4月提出《欧盟AI法案》草案。法案在2024年7月12日刊登于官方公报，8月1日生效，后续义务分阶段实施。到2026年，规则又进入首次修法和时间线调整阶段。
复旦大学发展研究院整理的修法进展显示，2026年3月26日，欧洲议会以569票赞成、45票反对、23票弃权通过《人工智能数字综合方案》一读立场。WTO/FTA咨询网6月24日发布的材料则专门讨论了EU AI Act时间线调整。一读立场尚不能替代最终文本，企业仍要跟踪后续程序。
因此，7月19日不宜被写成统一法定节点。团队可以把7月31日设为内部整改日，但每套系统的适用时间，仍要按风险类别、企业角色和最终规则分别确认。
排查前先建一张适用性表：系统在哪些市场提供，企业属于提供者还是部署者，产品解决什么问题，会影响谁，使用哪些数据，数据会流向哪里，当前运行哪个版本，由谁负责。
别按“Agent”这个标签判断风险
EU AI Act采用基于风险的监管框架，将AI系统区分为禁止类、高风险、有限风险和最低风险。部分系统还要单独履行透明度义务。
AI Agent只是一种产品或技术形态，不会因为名称里带有“Agent”就自动落入高风险类别。自动起草内部邮件的Agent，与自动筛选求职者、评估信用或影响保险理赔结果的Agent，不能采用同一套风险判断。人力资源筛选、信用评分、保险定价和关键基础设施安全评估等用途，都应对照高风险清单及适用例外逐项核实。
欧盟侧至少要留下以下证据：
- 角色和预期用途写清楚：明确企业是系统提供者还是部署者，系统用于辅助判断还是直接作出决定。接入外部模型API，不代表自身责任自然转移给供应商。
- 风险分类有依据：先排查是否涉及操纵、欺骗或利用特定人群弱点等禁止性行为，再核对高风险清单和透明度义务。分类结论要对应具体版本和业务场景。
- 技术文档能对应运行系统：记录系统架构、预期用途、模型与工具版本、评估方法、已知限制、风险控制和变更历史。红队测试（Red Teaming）可以作为证据，但法规并未用一个通用“拒绝率”替代完整的风险证明。
- 数据治理能追到来源：说明训练、验证和测试数据从哪里取得，采用了哪些筛选规则，已知偏差如何测试和处理。使用开源基座模型时，应向上游索取可用文档，同时补齐自身应用层的材料。
- 人工监督经过实际验证：界面和业务流程要支持暂停、覆盖、升级处理和责任交接。保险理赔等高影响场景中，不能只放一个没有实际作用的“人工复核”按钮。
- 日志、网络安全和上线后监控可执行：记录系统版本、关键决策、工具调用、人工接管和异常事件，并建立事故处理和纠正流程。日志留存期应按适用义务及行业要求确定，缺少依据时不要自行承诺“至少等同产品生命周期”。
中国侧先画数据流，再判断备案和出境路径
算法程序、生成式AI服务管理和数据出境是三组问题，不能压缩成一句“完成双重备案”。
- 确认服务范围和适用程序：核对产品是否面向境内公众，是否具有舆论属性或社会动员能力，再判断是否触发安全评估、算法备案及变更或注销程序。《互联网信息服务深度合成管理规定》和《生成式人工智能服务管理暂行办法》应按服务形态分别核对。
- 给语料和RAG知识库建台账：记录内容来源、授权范围、更新与删除机制。未经授权的出版物、包含个人信息的文档以及来源不明的数据，不应因为进入RAG知识库就被视为已经完成确权。
- 沿着实际链路检查数据出境：把用户输入、境内服务器、海外模型API、MCP工具、境外SaaS和日志平台画在同一张图上，标明传输了哪些字段、由谁接收、存储在哪里。判断依据是实际数据流，不是供应商名称。
- 匹配适用的出境路径：如果存在数据出境，再核对是否适用安全评估、个人信息出境标准合同（SCC）及备案，或其他现行安排。采用标准合同路径时，还要检查签署和向所在地省级网信部门备案等要求。具体门槛和豁免应以现行正式文本为准。
- 把数据用途写进供应商合同：明确用户输入是否可用于模型训练、保存多久、如何删除、是否存在其他处理方，以及安全事件如何通知。销售人员的口头说明不能替代合同和技术配置。
- 核对模型与业务数据的隔离方式：金融、医疗等行业还要单独检查行业规则。物理隔离、本地部署和访问控制可以缩小风险面，但不能被概括成所有项目统一适用的法律要求。
已有Stable Diffusion工作流或秋叶包V8本地化经验的团队，可以用同样的方法检查推理环境和数据路径。本地运行可能减少向境外服务发送数据的环节，但语料授权、账号权限、日志管理和输出责任仍要单独处理。
MCP能提供拦截点，不能充当合规证明
AI Agent接管自动回邮件、跨系统处理订单等任务后，每次工具调用都可能触发数据传输或外部动作。MCP（Model Context Protocol）适合设置审计点，但审计必须落到具体调用记录。
| 审计节点 | 至少需要记录或控制的内容 |
|---|---|
| 工具注册 | 工具名称、负责人、部署区域、可处理的数据类型和权限范围 |
| 调用前 | 发起用户或Agent、任务目的、参数字段、接收方和审批状态 |
| 调用中 | 工具白名单、敏感字段过滤、停止条件和人工审批规则 |
| 调用后 | 实际执行结果、对外动作、返回数据、异常及人工接管记录 |
| 版本变更 | 模型、工具、提示词、状态机和路由规则的版本及批准人 |
涉及付款、外发邮件、调用境外SaaS接口或提交个人信息（PII）的动作，可以按风险设置强制审批或直接阻断。只读的内部检索可以采用较轻的控制，但也要保留调用来源和权限记录。
在提示词中写“不要泄露隐私”只能算模型约束。权限校验、参数过滤、审批、阻断和可追溯日志，仍要由系统执行。
把7月31日变成一次真正的发版检查
如果团队已经把7月31日设为内部节点，完成标准应落到证据上：
- 每套AI系统都有适用性表，并标明法规来源、更新时间和责任人；
- 欧盟侧的企业角色、风险类别、例外和透明度义务已有书面结论；
- 技术文档、数据治理、人工监督和日志机制与当前线上版本一致；
- 中国侧的服务程序、语料来源和算法相关材料已经核对；
- 数据流细化到具体字段，出境路径、合同和备案状态可以查证；
- Agent工具调用能够被审批、阻断、回放和追责；
- 模型、数据源、工具或部署区域发生变化时，会重新触发审查。
一套AI系统如果无法在一页纸上回答“谁在使用、它会决定什么、数据去了哪里、谁能叫停”，就还不适合给出合规完成的结论。
参考材料
- 甫瀚咨询：欧盟AI Act合规解读
- WTO/FTA咨询网：欧盟人工智能法案EU AI Act时间线调整
- 复旦大学发展研究院：欧盟《人工智能法》首次修法进展
- Bird & Bird：欧盟人工智能法案指南
- 趋势科技：什么是欧盟人工智能法案
中国部分未设置统一数值门槛或办理期限，实际项目应按现行正式规则、数据类别、处理规模和行业要求核对。