欧盟《AI法案》已经生效。根据Protiviti的合规解读，欧洲委员会于2021年4月提出草案，法案在2024年7月12日刊登于官方公报，并于同年8月1日正式生效。
这组日期能确认规则已经生效，却不能推出两个常见结论：所有接入AI的SaaS都属于高风险系统，或者所有数据都必须留在欧盟境内。数据存储、跨境传输和个人信息处理需要另行核对适用规则，不能与AI系统的风险分类混成一项。
Bird & Bird的指南给出了更清楚的框架：极小或无风险系统不受《AI法案》的监管限制，某些系统需要履行特定的透明度义务，高风险系统还要满足额外要求，禁止类行为则不能在欧盟市场投放或投入使用。其他法律是否适用，仍需单独判断。
还有一个容易误读的时间点。金杜梳理的材料显示，欧盟委员会在2025年11月19日发布了《数字综合法案》和人工智能规则简化提案。关键词是“提案”。在法律状态和最终文本明确前，企业可以跟踪变化，但不宜据此撤掉现有控制措施。
先把AI功能拆开
判断风险时，公司级别的“我们只是普通SaaS”没有多少用处。Lexology刊载的出海解读指出，企业需要结合商业模式和出海安排，判断是否进入法案规制范围以及承担哪些义务。
产品团队应当按功能列清单，而不是只登记模型名称：
- AI用在客服、内容生成、推荐、排序，还是评分环节；
- 输入数据来自客户、公开数据集还是第三方供应商；
- 输出直接展示给用户，还是只供内部人员参考；
- 功能是否影响招聘、教育、信贷或其他基本服务；
- 最终决定由谁作出，人工能否覆盖、停止或纠正模型结果；
- 底层模型、微调版本和调用链发生变化时，由谁重新评估。
同一个模型接入文案助手和简历筛选系统，风险判断可能完全不同。聊天机器人和内容生成工具通常要先核对透明度要求；招聘筛选、信贷辅助决策等功能，则应优先确认是否涉及高风险分类。仅仅加上“最终由人工决定”，不足以直接排除风险，还要看模型在实际决策中发挥了多大作用。
先排除禁用行为，再判断风险等级
Bird & Bird的指南列举了部分禁止行为，包括使用潜意识技巧或故意操纵、欺骗性技术，严重扭曲人的行为并造成重大危害，以及利用自然人或群体因特定特征产生的弱点。
如果产品设计触及这类机制，应暂停上线并交由法律团队复核。这个检查要放在风险分级之前，不能等模型发布后再补材料。
对于关键基础设施、教育、就业和基本服务等场景，也不要凭产品名称下结论。需要记录AI功能参与了哪个环节、输出是否影响个人机会，以及人工复核能否真正改变结果。产品说明、客户合同和系统日志应保持一致，不能在合同里写“仅供参考”，实际界面却直接给出录用、拒绝或授信建议。
一份能交给产品和工程的自查单
下面的清单用于组织内部工作，不代表每一项都是所有SaaS统一适用的法定义务。具体结论仍要结合产品用途和法律意见确认。
- 功能与适用范围：逐项登记AI功能、目标用户、销售地区、输入输出和决策影响。留存功能清单、数据流图和产品说明。
- 禁止性行为检查：核对是否存在操纵、欺骗或利用特定群体弱点的设计。留存评审记录和处理结论。
- 风险分类：按真实用途评估，尤其关注招聘、教育、信贷、基本服务和关键基础设施场景。留存分类依据、负责人和复核记录。
- 数据来源：记录训练数据、微调数据和用户输入的来源、允许用途、授权材料、保留及删除方式。涉及个人数据时，另行检查相应的数据保护要求。
- 透明度提示：在适用场景中，让用户知道自己正在与AI交互，或正在接触AI生成内容。保存界面文案、发布截图和API文档。
- 人工复核：对可能影响个人权益或重要决策的功能，明确触发条件、复核权限、停止路径和纠正方式。留存工单和处理结果。
- 公平性测试：根据实际业务场景检查模型在相关群体和失败案例中的表现。Protiviti的材料特别提示了招聘等场景中的算法偏见风险。测试数据、方法、结果和修复记录都应保存。
- 版本与变更记录：登记模型供应商、模型版本、策略版本和上线时间。模型、数据或业务用途改变后，重新检查原有分类是否仍然成立。
- 事故处理：预先确定停用、回滚、投诉升级和内部通知流程，确保出现重大错误时能够还原当时使用的模型和配置。
模型版本、请求时间和策略版本适合写入内部审计日志。是否把这些信息放进API响应头，应由产品和客户需求决定。现有素材并不能证明这是一项适用于所有SaaS的统一法定格式。
偏见审计也不必随手写成固定的季度任务。更实用的做法是结合发布、模型更换、数据变化和业务用途调整设置检查点，再由法律和风险负责人确认频率。
开源工具能做什么，边界在哪
LangGraph：适合编排已有的多步检查
如果SaaS后端本来就有多个处理节点，可以用LangGraph增加独立的合规节点，检查风险标签是否缺失、是否需要人工复核、审计字段是否完整，并把结果写入日志。
风险分类结论应来自已经审核的规则和产品清单，不要让大模型在每次请求中自行判断“是否符合欧盟AI法案”。模型可以辅助提取信息，最终放行条件应尽量明确、可复核。
Label Studio：给数据补齐来源证据
Label Studio可以用于维护数据标注和审核流程。字段设计应尽量具体，例如数据来源、采集方式、允许用途、授权材料、审核人和版本。
不建议只增加一个“GDPR合规”的勾选框。单一标签无法证明数据取得、使用和删除流程都符合要求，也不方便在审计时追溯依据。
Rust：只处理经过验证的性能瓶颈
数据过滤、日志写入和元数据校验如果位于高并发链路，可以在压测确认瓶颈后考虑用Rust实现热路径。原型和频繁变化的规则仍可保留在现有技术栈中。
Rust的内存安全和性能优势属于工程收益，不会自动提高法律合规程度。如果当前网关并不存在延迟问题，为了“看起来更合规”而重写，只会增加维护成本。
把检查放进发布流程
合规要求写进文档还不够，发布流程要能发现明显缺口：
- 新模型或新版本没有分类和测试记录时，暂停发布；
- 数据缺少来源或允许用途时，不进入训练、微调或知识库；
- UI改版删除了必要的AI提示时，由回归检查及时发现；
- 日志缺少模型版本或策略版本时，触发告警；
- 产品用途从内容辅助变成评分或排序时，重新启动风险评估。
这些检查大多可以用固定规则完成，不必全部交给“合规Agent”。LangGraph负责流程编排，Label Studio管理数据证据，Rust解决特定性能问题，三者都只是实施工具。
面向欧盟客户上线前，团队至少应能拿出功能清单、风险分类记录、数据来源材料、透明度文案、模型变更记录、测试结果和事故处理方案。如果这些内容仍散落在个人电脑和会议纪要里，再复杂的工具链也无法补齐证据。
至于《数字综合法案》等后续提案，单独建立跟踪事项，记录负责人、法律状态和受影响功能。等文本和适用范围确认后再调整控制措施，远比根据“监管松绑”的标题提前删流程稳妥。
