欧盟《人工智能法案》——智能体视角：义务跟着用途走，不跟着模型走。
法案的结构——不可接受 / 高风险 / 有限风险 / 最小风险——是一个自主智能体产品在欧洲会撞上的主导监管框架，而多数会动钱、招人、对公民打分的智能体用例，不论底下模型是不是"通用"，都会落到高风险一档。本文从智能体开发者的视角读法案：什么会把你放进高风险、高风险义务清单具体要什么、通用人工智能（GPAI）提供方义务里有什么会向部署方下沉，以及义务分阶段生效的形状。这是一张地图，不是法律意见——任何具体义务，请咨询有资质的法律顾问。
从智能体一侧来读那四档风险分级。
法案按系统用途带来的风险，把 AI 系统分成四档——而非按模型的大小或精巧度。从最沉重的一档往下：
- 不可接受风险——禁止。由公共机构进行的社会评分、无差别抓取人脸图像、执法机关在公共空间进行的实时远程生物识别（有限例外）、利用脆弱性、某些职场与教育中的情绪识别用途。一个落进这类的智能体，在欧盟根本无法合法部署；这件事要在需求阶段就设计掉，而不是评审阶段才发现。
- 高风险——义务清单最重。法案列了若干类别——生物识别、关键基础设施、教育与职业培训、就业与劳动力管理、获取核心公共与私人服务（含信用评分）、执法、移民与边境管控、司法行政——再加上本身是产品、或落入其他欧盟产品法规所覆盖的安全件的系统。多数对人采取行动的智能体用例，会落到其中某一类。
- 有限风险——透明度义务。与人交互、生成或操控内容、做情绪识别或生物特征分类的系统，承担披露义务：用户必须知道自己在与 AI 打交道；AI 生成的内容必须以机器可读形式做出标识。一个不做高风险决策的客服智能体通常在这一档。
- 最小风险——自愿最佳实践。那条长尾；法案下没有特定义务，但一般法律仍适用。
对工程师的认知重构：问题不是"我的模型多强"，而是"这个智能体在替谁决定什么，后果如何"。给用途分级；模型的问题随之而来。
就算模型本身没被点名，你的用例也很可能让你坐在"高风险"这一档。同一个通用模型，做写作助手是有限风险，做就业申请分流是高风险——你的义务跟着你的用途走。
"高风险"对一个智能体开发者具体要求什么。
高风险的义务清单是具体且架构层的。反复出现的主题：
- 风险管理体系——一个显式、有文档、迭代的过程，覆盖系统全生命周期来识别、评估并缓解它带来的风险。不是一次性的上线评审。
- 数据治理——训练、验证、测试数据满足质量准则：代表性、错误率、缺口、偏差缓解，以及来源的文档化。data-governance 那套纪律直接对应在这里。
- 技术文档——系统做什么、怎么造的、训练与评估用了什么数据、能做什么不能做什么、剩余风险是什么。随系统演进而维护。
- 记录保存（日志）——足以在全生命周期追踪运行的自动日志，并保留。audit-trails 那些工程内容就是这项义务的形态。
- 对部署方的透明度——使用说明要详细到下游部署方能正确使用本系统并履行各自义务。
- 人工监督——必须被设计进去，不是事后栓上；一个人能理解、能拒绝、能推翻、能停下系统。对自主智能体而言这是一道架构约束，不是 UX 点缀。
- 准确性、健壮性与网络安全——与既定用途相称的水平，包含对错误、故障、不一致以及操纵系统的对抗尝试的韧性。
- 质量管理体系——提供方运作其下的组织脚手架（职责、流程、上市后监测）。
通用人工智能（GPAI）：提供方义务，以及向下游流转什么。
法案把通用人工智能（GPAI）模型单独处理。GPAI 模型的提供方承担与下游用法无关的义务——至少包括：技术文档、对下游部署方的信息、尊重欧盟版权法的政策，以及一份训练内容的公开摘要。被判定具有系统性风险的 GPAI 模型（最强的那批模型，按算力与能力门槛界定）的提供方，承担额外义务：模型评估、系统性风险评估与缓解、严重事故报告、网络安全保护。
对一个几乎肯定是部署方而非 GPAI 提供方的智能体团队，承重的要点与 regulatory-landscape 里一致：使用一个第三方 GPAI 模型并不把你部署层面的义务转移给它的提供方。你从上游继承一个文档基线；你仍然拥有对你实际如何使用它的风险评估、监督设计与审计日志。读你的提供方的文档；固定到那些你能持续保留其文档的版本；把上游模型当作你自己高风险义务的输入，而不是免责凭证。
关键时间点（不去编具体日期）。
法案在生效之后的若干年里分阶段适用。比起任何单一日期，分阶段的形状更可靠地用来做规划——而且日期在实践中也已经移动过——所以可操作的指令是阶段顺序，而不是日历：
- 禁止条款先生效。不可接受风险的用途在分阶段中最早出局。
- GPAI 提供方义务紧随其后。如果你建在一个第三方通用模型之上，预期你提供方的文档与"对部署方的信息"义务会先于你自己的高风险义务完全生效之前就开始向你流转。
- 高风险义务在更晚的阶段生效。风险管理、数据治理、技术文档、日志、透明度、监督、健壮性与质量管理这些义务有更长的阶段，对嵌入已受管制产品里的高风险系统还有额外时间。
- 罚则在相应阶段生效后起作用。罚款分档（标称区间随严重程度上升）；实际暴露与营收挂钩，所以一个小产品可以忽略标称数字，但一个严肃产品不行。
对一个智能体团队，规划姿态是：如果你的用例落在任一被列出的类别里，就按高风险义务清单去建——即便完全适用的日历日期还没到。在限期之下、为一个已经上线的系统补一项日志义务、一个监督点或一份有文档的风险管理流程，正是监管版图那篇文章警告过的那个昂贵的失败模式。
它在哪里与 NIST AI RMF 相遇——以及本文不是什么。
法案是欧盟具有约束力的法律；NIST AI RMF（下一篇讲）是一份美国的自愿框架。它们在执法层面不重叠，但在工程工作上重叠得很多：把风险管理做成持续过程、把治理写成具名职责、把监督设计进去、把证据当成默认。一个认真跑 NIST AI RMF 项目的团队，离高风险的技术与组织义务已经走了大半路——而一个满足法案高风险义务的团队，通常也覆盖了 NIST 的领地。选其中一个作脚手架，把它认真做下去，第二个大体会从第一个里自然落出来。
本文不是什么：法律意见。法案有合并文本、修订、二级法案与国家落地。任何具体类别的归属、某个用途处于"有限风险"还是"高风险"之间的边界、豁免，以及你所在法域的义务时点，都需要有资质的法律顾问。用本文知道该问什么；用一位律师知道该做什么。