欧盟《AI法案》规则将合规期限转化为一场运营考验
欧盟《AI法案》已进入关键合规阶段，尽管 Google News 的标题往往将这一变化简化为又一个监管截止日期。
这项法律如今影响企业如何对 AI 系统进行分类、记录保障措施、告知用户，以及为监管机构准备证据。其影响范围并不局限于欧洲开发者。当海外提供商的系统或输出进入欧盟时，也可能被纳入适用范围。
其中最重要的是三点：风险分类决定适用哪些义务；合规需要运营层面的证据，而非一份政策声明；执法对象可覆盖 AI 供应链中的提供商、部署方、进口商、分销商及其他参与者。
这造成了核心矛盾：企业希望在多种工作流程中部署可灵活调整的 AI，而法律则根据每个系统的预期用途和实际使用情况分配责任。
因此，问题并非简单地在推出或撤回模型之间二选一。组织必须将法律分析与产品设计、数据治理、安全、采购以及上市后监测联系起来。
欧盟《AI法案》已从政策辩论进入运营期限阶段
最重要的变化是，《AI法案》如今规制的是实际部署决策，而非假设中的未来产品。
该法规于 2024 年 8 月 1 日生效。此后，其要求将按照分阶段时间表开始适用，而非在某一个统一日期同时启动。
针对部分不可接受用途的禁令于 2025 年 2 月 2 日开始适用。同一天，提供商和部署方也开始承担 AI 素养义务。
欧盟委员会将 AI 素养描述为作出知情 AI 使用决策所需的技能与理解能力。这项义务的覆盖范围超出了专业合规团队。
通用 AI 模型相关规则于 2025 年 8 月 2 日开始适用。随着法律的分阶段实施，治理条款和成员国处罚框架也开始变得相关。
其余大多数条款原计划在 2026 年 8 月 2 日前后适用。与受监管产品相关的某些高风险系统义务则遵循更晚的时间表。
确切时间表之所以重要，是因为《AI法案》按风险和功能区分系统。企业不能仅凭识别模型供应商来判断自身的截止日期。
官方的 AI Act timeline 提供了起点。然而，企业仍需将这一时间表映射到自身的角色和部署情况上。
一个基础模型可以支持普通写作助手、招聘筛选工具或医疗产品。这些用途承担的义务并不相同。
企业之间也是如此。模型提供商、软件集成商、分销商和企业部署方，在同一条产品链中可能面临不同责任。
这种基于角色的结构，使得企业难以仅通过一项统一政策应对该法规。每个已部署系统都需要明确的责任人、用途、风险判断和证据链。
这也解释了为何“新规则开始适用”之类的标题几乎无法提供实际指导。真正有用的问题是：哪项要求适用于哪个系统，以及由哪一责任方承担。
企业首先应盘点其 AI 系统，包括通过大型软件合同采购的嵌入式工具。员工未经批准采用的工具也应纳入盘点，因为这可能带来未受管理的风险敞口。
随后，企业应记录系统的预期用途、受影响用户、模型依赖关系、数据流和决策权限。这些事实构成分类的基础。
采购团队还需要了解供应商是否提供所需文档，并在事故调查中给予支持。系统失效后，合同条款无法弥补缺失的技术信息。
因此，这一转变体现在运营层面。组织必须将宽泛的法律框架转化为围绕系统、人员、数据和控制措施的数百项具体决策。
对于用于就业、教育、基本服务、执法、移民、司法及特定安全功能的系统，这项工作尤为重要。
当满足具体条件时，这些领域可能落入法案的高风险类别。系统的营销标签并不决定结果。
首先要记住的一点很简单：截止日期只是开始。分类决定实际工作量。
Google News 标题忽略了风险分类的关键问题
《AI法案》根据 AI 系统的用途和风险对其进行规制，因此同一个模型既可支持低风险部署，也可支持高风险部署。
Google News 可以呈现数十篇关于最新规则的摘要，但这些摘要很少解释决定组织义务的分类判断。
该法律从多个宽泛的风险等级出发。一些做法被禁止，部分系统属于高风险，另一些工具则承担透明度义务。
许多其他 AI 用途并不承受同样细致的合规负担。它们仍受适用法律、合同控制措施和常规组织风险管理的约束。
被禁止的做法包括特定形式的操纵、剥削、社会评分、生物特征分类，以及实时远程生物特征识别。每项禁令都包含需要谨慎解读的定义、条件或例外。
例如，该法规并未在所有场景下禁止所有与情绪相关的技术。它针对的是特定用途，包括职场和学校中的情绪识别，但存在有限例外。
高风险分类带来的是另一类问题。它并不必然禁止部署，但要求在系统整个生命周期内实施结构化控制。
官方法规 确定了两条主要的高风险路径。其中一条涵盖受所列欧洲法律规制的安全部件和产品。
另一条涵盖附件 III 中列出的特定使用场景，包括与就业、教育、信用评估、服务获取、移民和司法有关的某些决策。
因此，普通办公助手不会仅因使用大语言模型就成为高风险系统。当其用途和使用方式满足法律规定的相关条件时，其分类才会改变。
以雇主使用 AI 汇总公开职位描述为例。这与利用 AI 对求职者进行排序、决定其是否获得就业机会，在监管层面呈现出不同特征。
两种技术可能共享同一个底层模型，但决策语境、受影响权利和对人的后果不同。
这种区别会给那些在多个部门推广单一 AI 平台的企业带来压力。集中采购可能造成一种印象：一次供应商审查就能覆盖所有用途。
事实并非如此。一款获批用于营销支持的产品，之后可能被用于招聘、客户资格评估或员工绩效评价流程。
企业需要建立审查用途重大变化的流程，也需要设置控制措施，以发现团队何时在未再次评估的情况下改变已获批准工具的用途。
该法案同时规定了提供商和部署方的责任。在某些情况下，部署方若以自己的名义投放系统或对其进行实质性修改，可能需要承担提供商义务。
部署方也可能因改变预期用途而产生新的风险敞口。这种风险使产品配置和工作流程文档具有法律意义。
人工监督是另一项经常被误解的要求。在流程中加入一名员工，并不自动意味着监督具有实质意义。
该人员需要具备足够的权限、信息、能力和时间来质疑系统输出。流于形式的审批环节几乎无法防范自动化偏见。
因此，分类流程不应只产出一个风险标签，还应说明该标签为何适用、有哪些证据支持，以及哪些变化会触发重新评估。
这份记录有助于工程团队理解边界，也能帮助管理者避免将合规视为抽象的法律意见。
组织应与具备资质的法律顾问和技术专家共同审查边界案例。法规文本、委员会指引和适用标准都会影响这一分析。
这正是新规则背后的第一个重要教训：AI 合规始于系统地图，而非模型清单。
高风险 AI 在整个生命周期内都需要证据
高风险系统需要有文件记录的控制措施，并且这些措施必须在发布前、使用期间和问题出现后持续发挥作用。
《AI法案》的高风险框架将产品治理与持续运营监督结合起来。它要求组织管理风险，而不只是披露风险。
提供商面临的义务包括风险管理、数据治理、技术文档、记录保存、透明度、人工监督、准确性、韧性和网络安全。
这些要求彼此关联。风险评估识别可预见的危害，而测试和监测则表明控制措施是否能够应对这些危害。
在相关情况下，训练、验证和测试数据也会受到密切关注。组织必须审查数据的适用性、代表性、质量和潜在偏差等特征。
这项工作不能完全由法务部门承担。数据团队了解数据来源，工程师了解失效模式，用户了解决策发生的环境。
招聘模型便是一个有用的例子。即使开发者移除了明确的受保护属性，历史招聘数据仍可能保留早期的组织偏好。
代理变量仍可能重现不平等结果。因此，技术团队必须测试现实中的细分群体，并记录其评估的局限性。
准确性声明同样需要严谨对待。平均分数可能掩盖系统在少见案例或特定人群中的低劣表现。
团队应记录指标、测试条件、已知限制和可接受的运行范围，也应说明当系统缺乏足够置信度时用户必须采取何种措施。
网络安全又增加了一个维度。AI 系统可能面临数据投毒、对抗性输入、提示注入、模型提取，或对已连接资源的未授权访问。
适当的控制措施取决于架构和环境。独立分类器与连接企业系统的智能体，面临的攻击面并不相同。
提供商必须在高风险系统进入市场或投入使用前准备好技术文档，并在系统发生变化时持续更新这些文档。
部署方也承担实际责任。他们应遵循使用说明，安排适当的人工监督，监测系统运行，并在自身控制范围内保留日志。
某些公共机构和提供公共服务的私营实体可能需要履行基本权利影响评估义务。该评估将考虑受影响人群、危害、监督和缓解措施。
这一要求将抽象的权利讨论转化为部署检查点。它追问谁会承受系统后果，以及组织如何进行干预。
银行评估消费者信贷是一个显而易见的场景。另一个不那么显眼的例子，是帮助确定获得基本服务优先级的软件。
组织不应等到收到投诉后才开始汇集这些信息。当版本、提示词和数据来源已经发生变化时，想在事故发生后重建系统行为将变得困难。
版本控制至关重要，因为 AI 产品持续演进。模型更新可能在不改变周边界面的情况下影响性能。
检索数据发生变化时也会出现同样的问题。当知识来源接收新文档或权限变更后，系统可能产生不同的结果。
可搜索的 AI 知识库可以帮助团队组织证据，但该知识库需要明确的责任归属和留存规则。仅靠非结构化文档存储并不等于治理。
有用的证据包括分类决策、测试报告、数据记录、审批历史、事故日志、用户指令、供应商文档和整改措施。
每份材料都应关联到一个具名系统及其版本。否则，审查人员无法判断哪些证据适用于已部署的配置。
上市后监测构成闭环。提供方需要建立系统化方法，在发布后收集并分析性能信息。
严重事故报告义务也可能适用。组织需要建立升级路径，将客户支持、安全、工程、法务和高级决策者连接起来。
这种全生命周期方法是第二项重要经验。合规并非在上线时取得的一张证书。
它是一套持续维护的证据体系，说明组织如何识别风险、测试防护措施、监测行为并应对失效。
通用 AI 规则在供应链中划分责任
通用 AI 规则不会取代系统层面的义务；它们为支持众多下游用途的模型增加了另一层合规要求。
通用 AI 模型能够执行广泛的任务，并支持多种应用。其灵活性使其具有商业价值，也使得难以通过单一预期用途进行治理。
因此，《AI 法案》对这些模型的提供方规定了具体义务。这些义务的适用时间早于许多高风险系统要求。
模型提供方必须准备技术文档，并向下游组织提供信息。这些信息应帮助集成方理解模型的能力、局限性和合规考量。
他们还必须制定尊重欧洲版权法的政策。另一项要求涉及发布足够详细的训练内容摘要。
欧盟委员会已为该制度制定配套材料，包括一项 GPAI Code。该准则旨在帮助提供方证明其符合相关义务。
并非所有通用模型都承担完全相同的要求。《法案》为被认定具有系统性风险的模型规定了额外责任。
模型可通过委员会决定，或通过法规规定的计算阈值进入这一类别。法律框架也允许考虑其他相关能力和特征。
系统性风险模型的提供方面临涉及模型评估、对抗性测试、系统性风险评估、事故报告和网络安全防护的义务。
这些义务应对的是可能通过众多下游产品传播的风险。一个模型的失效或漏洞可能影响大量应用、公司和用户。
然而，下游组织不能将其全部合规责任外包给模型开发者。它们仍需决定模型如何在特定系统中发挥作用。
供应商可能记录了模型的一般局限性。雇主仍必须评估其招聘流程、受影响的候选人、监督设计和本地运营条件。
这种划分在上游透明度与下游责任之间形成张力。集成方需要获得足够的信息来评估系统，而模型提供方则要保护安全与商业利益。
合同变得重要，但无法解决所有信息缺口。客户可能获得保证，却得不到开展自身评估所需的测试细节。
采购团队应向供应商询问模型版本、评估方法、已知局限性、日志记录、安全控制、事故通知和文档更新。
他们还应了解分包情况。应用提供方可能依赖另一家模型供应商、托管公司或数据服务商。
该链条中任何环节的变更都可能影响性能或风险。组织需要涵盖重大模型和基础设施变更的通知条款。
开源分发带来了额外的复杂性。该法规对以符合条件的自由和开源许可证发布的模型作出了针对性规定。
这些规定并非普遍豁免。视模型和具体情况而定，系统性风险义务及其他条件仍可能相关。
这正是简单对比失效的地方。核心分界并非开放与封闭，或欧洲与美国。
真正的问题在于，每个参与方是否拥有足够的信息和控制权来履行其被分配的职责。当没有任何一方承担系统层面风险时，缺口会变得尤其严重。
透明度义务还涵盖某些由 AI 生成或操纵的内容。在法规要求的情形下，相关系统的提供方必须支持机器可读的检测和识别。
部署方可能需要针对深度伪造内容和部分公共利益文本履行披露义务。例外情形和编辑责任会影响这些义务的运作方式。
聊天机器人及类似系统可能需要告知用户，其正在与 AI 互动。目标是防止用户将自动化互动误认为人类沟通。
这些规则对媒体、客户服务、营销和工作场所工具都很重要。它们也会塑造内容如何通过搜索和聚合服务传播。
Google News 的报道可以告诉读者透明度规则已经到来，但无法判断某个组织的界面、输出或编辑流程是否符合这些规则。
该判断取决于已部署的系统、责任主体、受众和具体情境。因此，第三项经验关乎共同责任。
任何组织都不应认为，一个合规的基础模型会自动造就合规的产品。企业也不应假定应用供应商承担所有下游义务。
执法使文档成为商业议题
《AI 法案》的处罚备受关注，但运营中断和证据薄弱同样可能带来严重的商业风险。
该法规允许处以高额行政罚款。最高罚款水平因违规行为和涉及组织而异。
某些被禁止做法的违规行为，罚款最高可达 3,500 万欧元或全球年度营业额的 7%。违反其他义务的罚款最高可达 1,500 万欧元或 3%。
提供错误、不完整或误导性信息可能适用不同的上限。计算规则包括针对企业的规定，以及对较小企业更具比例性的处理方式。
这些上限并不意味着每个案件都会被处以最高罚款。主管机构会考虑严重程度、持续时间、合作情况、减轻措施和既往违规等因素。
但这一处罚结构仍改变了高管的关注重点。AI 清单、测试预算和供应商控制措施，如今要与其他获得资金支持的合规项目竞争资源。
国家主管机构承担重要的监督和执法职能。欧洲 AI 办公室也发挥核心作用，尤其是在通用 AI 方面。
欧洲 AI 办公室隶属于欧盟委员会，支持该框架相关部分的实施、协调和执法。
这种分布式结构带来实际的不确定性。组织将关注各国主管机构如何解释要求，并协调跨境案件。
标准也将影响实施。协调标准可以为证明符合特定法律要求提供结构化路径。
但标准工作并不能免除管理责任。清单可以显示某项流程存在，却无法证明其控制了系统的实际风险。
独立测试仍然重要。来自系统操作人员或体验者的反馈同样重要。
员工代表、无障碍专家、安全团队和受影响用户能够发现实验室评估遗漏的失效模式。他们的意见应纳入证据链。
最有力的质疑角度关乎实施能力。许多组织仍缺乏可靠的模型、嵌入式功能和员工自建自动化工具清单。
没有这份清单，它们就无法持续对系统进行分类或识别正确角色。它们也无法知道供应商何时更改了某个组件。
小型公司面临不同压力。它们通常拥有较少的合规专家，却高度依赖第三方平台。
大型供应商可能提供标准化文档，却无法回答客户狭窄使用场景的问题。协商获得额外透明度可能十分困难。
监管机构同样面临能力限制。一致的执法需要技术专长、国家间协调，以及与既有行业主管机构之间清晰的关系。
这种不确定性不应成为拖延的借口。它应推动一种基于证据的方法：记录假设，并随着指导意见的发展重新审视这些假设。
公司应避免仅凭政策审查就宣称完全合规。已部署的系统、用户行为、监测流程和供应链都很重要。
它们也应避免将法律模糊性视为许可。一份有记录、合理的分类决定，比出于便利而作出的无记录决定更具可辩护性。
Google News 读者会看到引人注目的罚款数字，因为这些数字能立即成为头条。更能说明问题的信号是，主管机构究竟关注文档质量还是可衡量的损害。
早期案件将显示监管机构如何评估人工监督、技术记录、事故响应和供应商依赖关系。它们也将澄清对部署方的预期。
在这些执法记录形成之前，企业应为两类问题做好准备：既要解释现有哪些控制措施，也要证明这些控制措施是否有效。
三项信号将显示新规则是否有效
下一阶段将检验，《AI 法案》会成为一套可用的治理体系，还是一组碎片化的形式义务。
第一项信号是欧洲 AI 办公室和各国主管机构的执法活动。初步调查将揭示哪些文档缺口受到最密切的关注。
若重点放在被禁止的做法上，将强化该法律以权利为基础的根基。涉及高风险控制措施的案件将显示主管机构如何解释运营证据。
第二项信号是协调标准及相关指导意见的采用情况。企业需要有关风险管理、日志记录、数据质量、监督和上市后监测的详细方法。
清晰的标准将减少不确定性，并使供应商比较更容易。延迟或相互冲突的解释将提高跨境部署的成本。
第三项信号是产品行为。主要 AI 供应商应提供更完善的文档、版本历史、评估结果和事故通知机制。
这些变化将表明，监管正在影响技术和商业设计。最低限度的信息披露会让下游组织承担尚未解决的风险。
企业采购方可以在这些信号完全显现之前采取行动。他们应建立统一的系统登记册，并为每项重要部署指定一名负责的所有者。
他们应根据每个系统的预期用途和实际使用情况进行分类。应以简短说明记录每项分类适用的原因。
高影响系统需要针对可预见的失效模式进行测试。测试应反映真实的人群、环境和人工决策流程。
供应商审查应检视证据，而非品牌宣传。采购方需要了解正在运行的模型版本、哪些内容可能发生变化，以及事件如何被通报给他们。
组织还应根据员工的职责开展培训。一次通用意识培训无法替代面向审核人员、开发人员、采购团队和事件响应人员的专项培训。
人工监督本身也需要测试。应询问审核人员能否理解输出结果、拒绝该结果、上报疑虑并暂停系统。
日志记录应支持调查，同时避免造成不必要的隐私暴露。访问控制和保留期限应与系统风险及法律要求相匹配。
随后，管理层应将这些控制措施与发布管理相连接。模型、用途、数据或工作流发生重大变化时，应触发再次审查。
通过 Google News 关注这一进展的读者，应在媒体报道之外同步关注主要监管来源。截止日期容易成为新闻，但指南与执法决定其实际含义。
欧盟委员会的 AI Act guidance 提供了一个有用的参考点。组织应将其与针对自身角色和行业的法律建议结合使用。
欧盟 AI Act 并非在提交日期后便告结束的一次性合规事件。它持续检验企业能否对具有适应能力的系统承担说明责任。
三个关键问题依然十分具体：该系统如何分类？哪些证据证明其保障措施有效？当其行为发生变化时，由谁采取行动？
首先选择一项重要的 AI 部署，并以书面形式回答这些问题。如果答案依赖于假设，应指定负责人和截止日期来解决这些问题。
这一练习比又一份政策备忘录更能揭示组织的准备程度。它也将帮助组织为即将到来的监管信号做好准备。
