监管版图——只讲义务的形状，不是法律意见。
工程师不必当律师，但在不理解 AI 监管形状的情况下上线一个自主智能体，如今是一种「先建好再被迫拆掉」的做法。本文是一张定性地图，不是法律意见：监管正在收敛到的风险分级结构、在各法域间反复出现的文档与人工监督义务，以及如何在还没人来要文书之前就把智能体设计成可治理的。任何具体义务请咨询有资质的法律顾问——这里的价值在于知道该问什么。
监管按风险分级：义务随潜在危害伸缩。
主导性的结构思想，在欧盟 AI 法案里最清晰，是义务随系统带来的风险伸缩，而非随它有多惊艳。少数用途被禁止；一组界定的高风险用途（例如就业决策、信贷、某些生物识别与关键基础设施用途）背负沉重义务；有限风险用途主要背负透明度义务；多数系统处于最小风险，几无义务。因此任何智能体的第一个治理问题不是「这先不先进」，而是「它在替谁决定什么、后果如何」——是这个定位，而非模型大小，驱动了其余一切。
同一个模型，做代码助手是低风险，决定贷款资格是高风险。给用途分级，不是给技术分级——这直接对应到 C6 的治理分级。
文档是一项义务，不是事后补的东西。
在各法域间，更高风险的用途都伴随一项记录文档的义务：系统是做什么的、它已知的局限、它基于并据以评估的数据、评估了哪些风险及如何缓解，以及它在生产中如何被监控。这就是为什么模型卡与数据卡作为治理制品重要，而不只是 ML 卫生——它们是文档义务反复呈现的形式。对构建者的现实后果：证据必须在你构建的同时生成。在限期之下、为一个已在生产的系统、事后重建一份风险评估与一条数据血缘，是那个昂贵的失败模式。
通用模型增加了一层提供方义务。
监管越来越区分通用模型的提供方与在其之上构建应用的部署方。基础／通用模型规则（欧盟 AI 法案的 GPAI 条款是参照范例）把文档、透明度，以及——对最强模型——系统性风险义务，附加到提供方身上。多数产品团队是部署方，而那个承重的要点是：使用一个第三方模型，并不把你部署层面的义务转移给它的提供方。你从上游继承一个文档基线；你仍然拥有对你实际如何使用它的风险评估、监督与监控。
对高风险用途，人工监督是一项必需的设计属性。
对高风险用途反复出现的一个具体要求是有效的人工监督：必须有一个人能理解系统的输出、能拒绝或推翻它、并能停止它——而这必须被设计进去，不是事后栓上。对一个自主智能体而言这是一道硬性架构约束，不是 UX 点缀：它强制一个介入点、一条真能让效果停下的推翻路径，以及足够的决策可读性，使那个人能行使判断而非橡皮图章。安全材料里的人在回路与最小权限模式就是你满足这一点的方式；此处的要点是，对高风险用途它是一项义务，不是一个选项。
「事后有人能看日志」不是监督。要求的是在那个有后果的效果之前由一个有能力真正判断它的人做出有意义的介入。
框架把法律变成你能据以构建的东西。
在抽象监管与你的代码之间，坐落着把它操作化的自愿框架。NIST AI 风险管理框架把工作组织为治理／映射／度量／管理。ISO/IEC 42001 定义了一个 AI 管理体系——可审计、可认证的过程层，类比 ISO 27001 对安全所做的。这些本身不是法律，认证也不等于法律合规，但它们是那座现实之桥：一种可辩护、被认可的方式来组织监管所要求的风险评估、文档与监督，且它们彼此交叉映射，使一个有纪律的项目能同时服务多个法域。
诚实的取舍——以及那条免责声明。
时间线与细节确实在变动中：欧盟 AI 法案的义务按错开的日期分阶段生效，修订进程已经移动了其中一些，其他法域则在不同轨道上推进。按可信的最严分级来设计是稳健的，但可能给一个低风险产品压上过重负担；按今天最宽松的读法来设计，则冒着在某个限期落地时来一次昂贵改造的风险。把可治理性——可审计性、一个监督点、真实的文档——当作架构默认，从用途而非技术来决定分级，并就任何具体义务咨询有资质的法律顾问；本文是一张地图，不是法律意见。