AI Act 合规正在从法务清单变成产品能力

欧盟 AI Act 于 2024 年 8 月生效，并在 2025 至 2027 年分阶段适用，让“合规以后再做”变得不现实。系统属于什么风险类别、谁是 provider 或 deployer、模型来自哪里，会直接改变产品能否上线、必须保留哪些证据，以及用户界面需要披露什么。

第一项产品能力是分类。团队要把预期用途、用户群体、部署地区和可能造成的影响写进需求，而不是只描述功能。一个通用组件进入招聘、信贷或公共服务后，责任会因场景改变，不能沿用原来的低风险假设。

第二项能力是可追溯。训练与评估数据、模型版本、系统提示、风险测试、人工监督和重大变更需要形成连续记录。若这些信息散落在聊天、表格和个人电脑里，发布前补文档既昂贵，也无法证明当时实际运行的系统。

合规最有价值的产物不是一份发布前的说明书，而是一套能在开发中持续回答问题的证据：模型用在哪里、输入来自哪里、哪些人会受到影响、系统何时需要人工介入。把这些信息嵌入需求、评测和日志，团队才能在产品变化时同步更新，而非临时追忆。

第三项能力是透明交互。用户需要知道自己在与 AI 交互，合成内容在适用场景下要可识别，限制和申诉路径要进入界面。透明度不是长篇条款，而是在正确时刻提供能改变用户决策的信息。

第四项能力是持续监控。上线前评测只能覆盖已知场景，真实使用会暴露分布漂移、滥用和群体差异。事件记录、反馈入口、回滚、供应商变更审查和严重事件处理，都应当与普通可靠性工程共享基础设施。

这会改变采购关系。使用第三方模型并不会转移全部责任，产品方仍要了解能力边界、数据处理和版本变化。合同、模型卡和技术接口需要共同支持下游合规，否则一次供应商升级就可能让原有证据失效。

好的合规设计反而能提升产品质量：清楚的用途减少功能漂移，完整日志帮助调试，人工监督改善异常处理，透明说明降低误用。最差的做法是用弹窗和免责声明覆盖没有被控制的系统风险。

把责任完全交给法务会造成另一种失真。工程团队可能不知道哪些设计会改变风险等级，产品团队也可能把透明度当成一段固定文案。真正的难题是把抽象要求翻译成可操作的界面、数据流和运行规则，例如告知、申诉、记录、监控和故障处理。

AI Act 的长期影响不是增加一份法务审批，而是把证据生产嵌入产品开发。能低成本回答“系统为何这样设计、如何验证、出了问题怎么办”的团队，会把合规从阻力变成进入高信任市场的能力。

把讨论带回真实场景，最先要拆开的就是风险分级、数据治理、人工监督、日志与上市后监控的连续证据。它们在演示里常被一条顺滑的故事线覆盖，落到产品、组织或公共系统中却由不同角色承担成本。先把对象、状态变化和责任交接画清楚，团队才知道究竟该自动化哪一段，又该把哪些判断留给人。

最容易出现的误判是把合规当成发布前由法务补写的一套文档。这类错误通常不会在第一次体验时暴露，而会在边缘案例、利益冲突或长期使用后累积成不信任。设计时应主动保留反例和拒绝路径：当证据不足、目标冲突或风险升高，系统能否减速、解释并让用户重新选择。

一个务实的做法是为每个高影响功能维护最小证据包：预期用途与禁用用途、训练或检索材料的来源说明、主要失败模式、人工接管路径、变更记录和上线后监测指标。它既服务监管，也让内部复盘有共同语言。

判断进展不能只看声量或一次性完成率，更应持续记录高风险变更的可追溯率、异常发现时间和整改闭环速度。这些指标把“看上去很聪明”转化为可复盘的经营与治理问题，也能让团队发现效率提升是否只是把成本转移给用户、审核者或未来的维护者。指标一旦能关联具体任务，改进才不会停留在口号。

最终，制度要求不能替代对实际用户伤害与失败模式的持续观察。成熟方案不是承诺消灭全部摩擦，而是把必要摩擦放在真正需要判断的节点，并让当事人看得见、改得动、退得出。只有能力、激励和责任被放在同一张图上，本文讨论的变化才可能从热闹的功能叙事，变成值得长期依赖的实践。

《AI Act 合规正在从法务清单变成产品能力》涉及的变化不应只用“技术会不会发生”来判断，还要问它在谁的生活和组织中发生、谁拥有选择权、谁承担失败成本。能力一旦进入教育、工作、基础设施或公共决策，就会遇到原有的制度、权利与资源差异；脱离这些条件的效率叙事，往往把最重要的影响留在了画面之外。

风险也不能只理解成一次明显事故。更常见的是缓慢的偏移：默认设置改变了谁能被看见，自动建议改变了谁需要解释，数据收集改变了谁敢表达，成本优化改变了谁承担等待和复核。研究与产品评估应同时观察少数群体、异常情境和长期反馈，避免用平均值掩盖分布不均的后果。

当合规能力被产品化，速度并不必然下降。清楚的边界会减少反复返工，结构化记录会让客户更敢接入，治理要求也能推动更可靠的体验。把它视作产品质量的一部分，比把它当作外部阻力更符合长期竞争。

可操作的衡量需要把原则落实为事件：系统何时拒绝、何时升级人工、谁能撤销授权、出现损害后多快发现与补救、当事人是否能够理解并申诉。这样做不是为创新增加无止境程序，而是让社会可以判断一项能力究竟在扩大人的选择，还是在用不可见的方式替人做决定。

治理责任也不应被推给最后一位用户。开发者、部署组织、模型供应方和接入平台分别控制不同杠杆：数据、接口、默认值、商业激励、审计和救济。把责任沿这条链明确下来，才能避免事故发生后每一方都说自己只提供了中立工具，而实际受影响的人找不到可以纠正的入口。

长期值得追求的不是一条预测所有后果的规则，而是一套能够学习的公共能力：保留证据，允许独立检验，在错误出现时快速修复，并为不同的人提供真实的退出与替代方案。技术因此不只是被接受或被拒绝，而是在可问责的协商中不断被重新塑形。