软件工程师如何应对欧盟《AI法案》与可信AI治理

2024年3月，我曾写过关于负责任AI的文章。今天，我想在此基础上稍作展开，聚焦AI治理与可信AI，以及这对在企业环境中使用AI的软件工程师意味着什么。对我而言，欧洲的立法尤其值得关注。《欧盟AI法案》已不再是遥不可及的未来之事。部分条款已经生效，另一些要求则有较晚的截止期限。而且时间线本身也发生了变化。

这如何影响我们的日常开发工作？在发布AI功能之前，我们应该考虑什么？

本文反映的是截至2026年11月4日欧盟官方公开的信息。这是一篇实务入门，不构成法律建议。义务取决于你的角色、系统及其预期用途。

《AI法案》采取基于风险的方法。重要的问题不在于你使用哪个模型，而在于系统被用于什么目的、影响谁，以及其输出可能带来什么后果。

同一个模型可能被用于截然不同的系统。起草职位描述的功能与筛选申请人的功能是两回事，即便两者调用同一个API。因此，在查看法案的任何条款之前，我会先描述AI实际做了什么。合规义务由此推导而来。

作为软件工程师，我们以两种不同方式接触AI：我们构建软件所使用的工具，以及我们交付的功能。它们引出的问题不同。

使用编程助手并不会自动使我们产出的软件成为AI系统，也不会使我们的工作流程变成高风险。这里的问题主要关乎数据与控制：

在我们的软件中加入AI功能则需要单独评估，因为此时AI已成为客户所获产品的一部分。在这里我会问：

一份关于用途、数据流和权限的简短记录，能让隐私、安全和法务同事有具体材料可供评估。这并不是说每个编程助手都需要一份正式的《AI法案》合规档案。这是一种避免在实现完成后才发现重要义务的方式。

也有好消息。大多数AI系统不属于禁止类、高风险类和透明度类，在法案下没有特定要求。立法听起来可能吓人，但对我们构建的许多东西而言，答案将是几乎不适用额外要求。

法案区分了提供者和部署者。提供者开发AI系统，或委托他人开发，并以自己的名义将其投放市场或投入使用。部署者在其职权范围内、在专业场景中使用AI系统。

使用现有AI助手（如编程工具或供应商提供的聊天机器人）的企业，通常属于部署者。自行构建AI系统并将其投入使用的企业则是提供者。同一企业针对不同系统可以同时是两者。

让人意外的一点是：你不训练模型也可以成为提供者。如果我们把模型API封装进自己的应用，并提供给客户或同事，组织就可能是在提供AI系统，即便它并未训练该模型。从大供应商处购买模型并不会让这一判断消失。

角色也可能随时间变化。第25条涉及高风险系统，其中实质性修改或新的预期用途可能使你成为提供者。我们开始用来筛选求职者的一款通用聊天机器人就是一个很好的例子。

模型供应商也有自己的角色。通用AI模型的提供者有单独的义务。这些义务不会自动转移给每一个基于其模型构建的公司，也不覆盖我们应用所做的所有事情。

这些法律角色属于组织，而不属于每一个写代码的工程师。我们的工作是让系统的用途和行为足够清晰，以便组织确定其角色。

以下是我会放在手边的时间线，依据欧盟委员会当前的概览。

最后两个日期尤为重要。较早的文章可能仍给出最初的截止期限。欧盟委员会确认《AI Omnibus》已于2026年7月生效，并延长了这些时间线。这是已通过的变更，而不仅仅是提案。

这些延期并不推迟GDPR，也不移除已经适用的《AI法案》义务。

第5条中的禁止性做法是法案最早适用的部分之一，罚款也最高：最高3500万欧元或全球年营业额的7%，以较高者为准。该清单包括造成重大损害的操纵性或欺骗性技术、利用与年龄、残疾或社会经济状况相关的脆弱性、社会评分、仅基于画像预测个人犯罪风险、未经定向抓取人脸图像、工作场所和教育中的情绪识别，以及推断政治观点或宗教等信息的生物特征分类。执法领域的实时远程生物识别也受到限制。

《AI Omnibus》新增了两项自2026年12月2日起适用的禁令：未经同意生成可识别身份个人的逼真色情图像或视频的AI系统，以及生成儿童性虐待材料的系统。如果你构建图像或视频生成功能，现在就该了解这一点。

欧盟委员会关于禁止性AI做法的指南

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）